First, default installations of Debian create ext3 and not reiserfs filesystems (Please correct me if I'm wrong. I've just recently installed a fresh etch, but I didn't specifically look at the fs.) And even if it were reiserfs (v3), I don't see why a reaction would be called for now. The stability of reiserfs has come up every once, before the whole murderer story begun, and that the interaction between the reiserfs developers (including, of course, Hans Reiser) and the kernel team were always difficult has also been known for a long time. This is the kind of reason where I think it's appropriate for Debian to take steps (i.e. switching to a different filesystem), not a single event, where it is not even clear yet how the reiserfs (v3 and v4) efforts will move on.

On to the technical stuff: Perlow tries, but doesn't really arrive at understanding the issues he's writing about. Reiser 4 is discounted without a single remark on its technical merits (I can't comment either as I have not looked at it so far.) Why he discounts ext4 is not clear to me (because it is not ripe for production use yet — but that's even more true of ZFS and this Linux-NTFS thingy he rambles about further down...) He discounts JFS2 because it hasn't got a new release for several years (is that bad in a filesystem?) but then touts ZFS as a great idea with minor licensing problems, without speaking of patents which is where the real problems lie (not to mention the fact that the Linux ZFS port probably is much less tested than ext4 or JFS.) And in a final jump into fantasy-land he mentions that NTFS might just be ideal for Linux, and Microsoft is said to have started cooperating nicely with the Free Software world, so all licensing and patent issues are certainly going away Real Soon Now™. At least for Novell, these issues shouldn't be a problem, I guess.

Not mentioned by Jason are btrfs (which has a quite tightly coupled network filesystem brother, crfs and is in a very early state of development), and hammer, which comes from the BSD world and currently lacks a Linux port. Both efforts are probably more likely to replace ext3 or reiser on Linux than both ZFS and NTFS: no patent issues, no license issues, and the development is actually done by a community and not a single company.

Update: Julien Blanche ha a much more succinct response to Jason Perlow. More intersting to read than mine, too.

Why? Because, first, many people do indeed see it as a war where there has to be a winner and a loser, and second, when I talk with people who never have seen Linux, or with people who'd never seriously consider switching to Linux (in business or for their home needs), most of them talk about not having tried it yet or it not being ripe yet. So the general expectation is that they'll only stick with (expensive, buggy, hated, ...) Microsoft software until they feel confident about switching. So the task is not to convince them that they should try Linux, but that they might want to try it now. Or at least that they might want to try Oo.org, the Mozilla family of programs, the Gimp etc. on Windows, so that they have an easy time when it's time to change the chassis underneath (is there a Windows port of Digikam?)

1. Regression testing is hard. Assuring that hardware that worked will still work in the next version of the distribution is where many Linux distributions fall down. At least I think Debian here does better than some others.
2. Mobile devices. I've written about this already some months ago. I want to just plug in my smartphone and sync it with my calendar application. I don't think this is too much to ask.
3. Software compatibility. I don't do video editing and I'm comfortable with the Gimp, but I witness people having difficulties with OpenOffice.org all day. Mostly, it's because either they were MS Office power users and stuff like form letters are different between the packages, or it is because the state issues silly form/macro based MS Office documents.
4. Wireless. Hmm. I haven't had real problems with Wireless in quite some time. But then, I know that I need to watch what kind of hardware I buy, so YMMV.
5. Hardware compatibility lists. Debian doesn't have one, so that's apparently a good starting point ;-)
6. Compiling drivers. I don't understand this complaint. The user should never even come to the point where he needs to compile a driver. But I think here Debian with module-assistant is quite good.
7. The Patent Trap a.k.a. I Want To Watch DVDs. This is a serious issue, and will probably not be going away unless some heavy duty political stuff is happening. Organisations like PubPat and the new End Software Patents initiative will help. In my opinion, though, these are not taking it far enough. Patents are monopolies granted by the state — in all other areas (post, railways, telecommunications), it has been agreed that monopolies are bad, so why not just abolish the broken idea of patents, too?
8. Off the Shelf Software. Hmm. My clientele is not the lone Linux user at home but the business user who has an IT support dept, so I don't see this issue for me.

Issues #9 and #10 is just “the community sucks” in nicer words. He's not wrong as such, but I think Matt's view is pessimistic on these.

The (not really surprising) conclusion: Kernel + libc + X + KDE + Mozilla compared to Vista (assuming that this is about comparable, functionality-wise), Vista is more than three times as big (LoC) and, consequently, expensive (COCOMO numbers.)

A standardized way to hook into session setup/teardown might also be good for security: if there's only few ways to get stuff started at login, that means fewer places to look where malware could be hiding. Of course, it also means that said malware can spread more easily, being more independent of the user's desktop environment.

Of course I didn't expect the rt2400 to magically acquire WPA capabilities, but I'd at least expect the specified stuff to work... This is not bleeding edge hardware, after all, so even the Linux drivers should have had time to mature. (OTOH WEP is b0rken regardless of the bit strength, so I should replace that rt2400 stuff anyway.)

I hoped the Live CD would be somewhat more complete than what's currently in experimental, but unfortunately, KDE wouldn't even start for me :-/ (Admittedly, I didn't fool around with it very long, so maybe it might have worked with some magic word.

Looking around, it seems there aren't that many open source (or even commercial) projects if it should be usable on Linux (Clients, too) and be reasonable priced (which pretty much kills Lotus and similar big enterprise solutions AFAIK.). Oh, and a web frontend is an absolute necessity, too, but that's usually not a problem.

• Open-Xchange, our current solution. The community seems to be quite dead (judging by the mailing list), and what'll happen on with the commercial variants is unclear to me, but at least there's some activity. We're moving away from OX because there are too many bugs both in the groupware itself and in the SyncML part.
• eGroupWare: The top candidate to replace OX. Looks quite good, there is a very active community, recently an additional developer has joined who will focus on the SyncML part. Most of the development is, however, done by only very few people, and apparently the project is about to fork because these people do not agree. (It's not yet clear if it will come to a fork or if egw 2.0 will properly replace the 1.x branch.)

There are some other groupware projects out there, and I might do them injustice, but on a first glance development seemed to either have stalled as a whole or at least regarding their SyncML support. I know of OpenGroupware.org (last news of SyncML support from 2005), Kolab (No production quality Web frontend, and I can't find much about SyncML either), Horde (Hmm. I didn't like the classical horde webmail very much, but "Horde Groupware" might be worth another look. The status of the SyncML part is not clear, judging from the website.) and phpGroupWare (egw's ancestor, when I last looked development seemed to stall, and the information I found about its SyncML support is somewhat scant.) The open direcory project lists some more, but I haven't looked at these.

Update 2007-12-11: As promised, a short summary of the replies I got (Thanks a lot!): James Andrewartha and Gürkan Sengün pointed me to SOGo (“originally a fork of OpenGroupware.org” apparently there is an alternative Web page, too) which should support SyncML via Funambol and sports an Ajax-heavy web frontend. Cornelius Weiss (one of the egw 2.0 developers) sent me an email that crashes Kmail 3.5.8, so I'll have to look at this later (grr!), and Serge Koenigsmann points me that Funambol seems to be the SyncML software of choice. I haven't processed this information yet; expect further blog entries on this topic in the medium-term future.

Update 2007-12-13: I managed to read the mail of Cornelius Weiss now; he points to Horde and to Horde as a possible Web frontend for the Kolab server (a combination that is officially encouraged, I gather from a recent announcement by the Kolab folks. I guess I'll have to look at this possibility.