Filesystems are not the answer, what we need is a document store. None of the open source desktop projects will ever depend on ReiserFS or similar features. Because these projects have to be able to work with NFS, GFS, AFS, and across multiple UNIX flavors.
The document store approach is to create the equivalent of an IMAP server, or WebDAV server, but with a richer set of functionality and the ability to run locally. Document stores are not filesystems; they store structured data not byte streams, and while they may have a hierarchical-namespace "view" the hierarchical namespace isn't their core organizing principle.
A key thing to realize: you don't have to use the same solution for user data ("home directories") and system implementation details (the OS itself, random junk in /tmp). The traditional filesystem is just fine for the latter. User data can and should be special-cased. You don't want user-invisible implementation details showing up in search results and the like, anyhow.
Another key point is that apps can move to a document store piecemeal, just as IMAP is useful even though it's email-only. There's not a boil the ocean "get everyone to switch" problem.
Examples of the document store approach include WinFS, GNOME Storage, Chandler Repository, and the IBM Workplace data store.
Currently at OSCON. My presentations are both somewhat updated versions of talks I've given before, but the slides are Creating a Desktop OS and D-BUS.
Had dinner and a beer with Jon Trowbridge tonight, fun to go in to Cambridge. As ex-UofC we should really spend more time making fun of Harvard, don't get around to that often enough. GNOME has a long U of Chicago tradition including Owen, Dan Mueth, and Sam TH of GNOME Office fame.
My bike has the interesting property that it looks like I ride it a hell of a lot. That's because there was a time when I did. So it's beaten and worn, has "serious biker" components (e.g. seat that hurts like hell), and you have to bend in half to reach the handlebars. Not good if you haven't done it in a while.
On the topic of GNOME forks, a fundamental free software maintainer responsibility: if you reject a patch, don't complain about forks that add the patch. If someone wants to make "GNOME for geeks" then great. Not that I think this particular project will succeed, but anyone is welcome to try.
I think the free software world is sometimes too hostile to forks; having people with substantially different goals trying to work on the same project doesn't work out that well most of the time. You sort of have to agree on the project parameters to get anywhere. That said, it's important to be sure the goals are genuinely different.
Nice to see Bryan spelling out the rules on application naming, I think what confused all the hackers is that we have a different guideline for things that come with GNOME, and things that don't. Sort of ties in to my talk where I defined a platform as a unit that's designed (interaction/UI-wise) as a whole. Modularity is good engineering and bad interaction design most of the time, the ideal is to make the implementation modular and the user experience integrated. Which can be tricky.
So we have a problem that the menu spec was written without understanding the desired UI. We need to fix the spec somehow. Unless OnlyShowIn=GNOME fixes it, which I suppose is possible in many cases.
I don't think anyone would seriously argue that "Calculator" or "Dictionary" should be named things like "Frobfoodle" or "BlatherMaster" or other obscurity, so I think the disagreement here is on where generic names end and specific names begin, not on whether each should exist.
Took my bike to the shop for a tune up, new tubes, new bar tape. Then got back on and rode around for the first time since smashing my wrist into little bits two years ago, just before GUADEC Copenhagen.
Exercising again after long periods of sitting on one's ass is painful. I always get air whistling through my ears somehow, burning lungs, and a strong urge to vomit. My memory is that this goes away after a few days of regular exercise, but I haven't tested that in several years, given that the wrist smashing episode also came at the end of a long sedentary period.
I'm off on a nine-day trip (OSCON, LinuxWorld) in a couple days, so I can't really get started on the regular exercise until I get back. We'll see how that goes.
Blizzard took notes on Tom Fitzsimmons's talk, also I thought this link from the slides was a good overview.
Nice to read this article because it rings so true. Usability advocates such as Alan Cooper point out that feature-matrix-driven development results in bad design and bad outcome for users.
However, that I remember Cooper doesn't point out the cause of feature-matrix development. I hate to do it but I'd place a big part of the blame where this Microsoft Money guy does: reviewers.
There's nothing more frustrating than to spend many months figuring out what your users want, then read a review where the reviewer has no idea who the target audience is or what they could really benefit from.
What makes this especially bad is that it's the overwhelming rule, not the exception. Reviewers have no idea what would really make a product good or bad, they just do a feature matrix or review the product as if the target audience were magazine reviewers.
Do we need a Consumer Reports for software, based on real research and knowledge?
Why don't developers just ignore reviews? Because reviews have real impact on what people think and do. Not just for commercial software; volunteers writing free-of-cost software are sensitive to this as well.
Getting a clue for more reviewers and pundits would probably do more for usability than evangelizing every programmer in the world. The developers will come over naturally if the incentives are in place.
I consolidated my current thinking on where we should go with a config system in the future, it was sort of spread around between piecemeal emails and web documents.