Original post by E@zyVG

A couple of weeks ago, the O’Reilly editors asked Is Microsoft Relevant in a Post-Rails World? Contrary to some reports, there are still desktop applications in the world besides a web browser–and there are plenty of desktop applications under serious development.

Many of them are F/OSS. Of those, plenty have ties to existing projects to produce fully-free desktop software. They run on top of free Unixes, take advantage of free APIs and libraries, and interoperate well with other free software.

There are very few technical reasons much of this software cannot run on non-free platforms, however. One of the first pieces of free software I used reliably was Emacs (though I quickly switched to Vim). This was on Windows NT 4. Perhaps the most successful free software desktop application is Mozilla Firefox.

Nikolaj Nielsen recently ranted about why he finds Windows ports of F/OSS applications valuable and how much he dislikes the arguments against making such ports. By one theory, switching to free applications will make it easier for users to switch to free platforms in the future, as those applications are already available and, hopefully, work better on free platforms.

Then Aaron Seigo picked up the argument, asking “are there reasons to believe that users who switch applications really will switch platforms?” I suspect (but don’t want to speak for him) that Aaron and I are both glad to see more people have the option to use software that respects their freedoms and supports open standards and does not lock them into proprietary traps. Yet does this step really help in the long term?

It’s important to keep in mind the philosophical goal of some free software developers. That goal is to spread freedom by encouraging the use of free platforms, ideally from hardware through BIOS and drivers to all software, but certainly as much of the software stack as is possible. The question is whether it’s worth the additional development and maintenance work to make free software applications available to non-free platforms, or if that work subverts the goal of encouraging the use of completely free platforms.

Of course, with the source code available for porting, there are no universal technical barriers to running any given piece of F/OSS on Windows or Mac OS X. The project’s maintainers may refuse to merge the portability patches, in which case a fork is necessary, but this is a question of philosophy, not technical concern.

The best anyone can give at this point is likely anecdotal evidence. For example, my father has tired of Windows XP on his laptop and would like to move to Ubuntu. His only concern is that one job-related website he needs to visit requires the use of IE (and he reported that to the webmaster, who acknowledged the request but there’s no change yet). He already uses Thunderbird and Firefox, and with a decent photo gallery, he’d have everything else he needs. We set him up with good free software in the hope that he could switch one day.

Contrarily, one of the pieces of software that kept me on Mac OS X for as long as I remained was a ports system by which I could install free software without the silly .app bundle dance. (It’s so easy, after you’ve already found and downloaded the bundle manually, in the same way that receiving a trophy for a triathlon is easy after you’ve already finished the race.) Without a decent mechanism to install software, Mac OS X wouldn’t have lasted even one month for me.

I don’t expect any easy answers to this conundrum. I also suspect that many of the users of free software on proprietary platforms are home users of free platforms trying to make their work computers more palatable, rather than early adopters slowly sidling their way to freedom. However, I can’t prove that either.

Meanwhile, fully-free desktops improve daily, and not just in the quality and breadth of free software applications. Millions of people have liberated part or all of their software from proprietary restrictions. The question now is how to offer that freedom to everyone else.

Original post by chromatic

A request for opinion/experience today: does anyone have experience of running (local) Jabber servers under Linux? (Debian, ideally).

I’ve been experimenting with setting up a Jabber server to run within our LAN. I tried Openfire and found it quite hard work. Ejabberd worked better, but after running for a few hours on the same machine as our webserver, there were a lot of zombie blosxom.cgi processes and the webserver was no longer responding. I haven’t definitely confirmed this behaviour as due to ejabberd, but am not terribly keen to experiment further on a live webserver. I will be trying it on another machine to see how that behaves; but in the meantime, a) has anyone else seen problems on a server running ejabberd? and b) can anyone recommend a Jabber server that is straightforward to set up, well-behaved once running, and supports chatrooms?

I would also very much like for it to hook into our LDAP/Kerberos setup. I gather that single-sign-on is a nonstarter (since gaim and other clients don’t do GSSAPI), but being able to use the same usernames and passwords would be very useful. In theory both Openfire and ejabberd can be made to do this; in practice IME it doesn’t work. Any thoughts on that would also be welcome!

Original post by Juliet Kemp

I’m making the leap from point-and-shoot digital cameras to digital SLRs. This represents a considerable increase in cost and hassle. The latest generation of compact point-and-shoots are pretty darned good. Will it be worth it? Or will I be smitten with terminal buyer’s remorse? Does Linux offer sufficient high-end photo management and editing software? Visit Adventures in Digital Photography With Linux, part 2 to find out. The first two installments cover cameras and lenses, and digital arcana thereof. Over the next few weeks I’ll write about editing and managing photos on Linux.

And, of course, you fine readers are invited to share your own Linux photography adventures.

Original post by Carla Schroder