Seth: "Stop worrying about ideas and get back to work" isn't an accurate paraphrase. I prefer: if you have an idea, do the work to make it happen. The realistic path is probably twisty - having a goal in mind does not imply a straight line to get there. Sometimes the work involves writing code; sometimes it involves cat-herding or scrounging up funding or writing a foundation charter or getting that next 1% of marketshare.
Here is my vision: replace proprietary software for as many users as possible. Without diving into details, I would argue that GNOME is doing the right things to achieve this, most of the time. You're cooking up elaborate explanations where simple ones will do. Possibly people are afraid and feel inadequate, or possibly they simply have a realistic, incremental plan to grow the userbase. Possibly people are risk-averse, and possibly the risks worth taking aren't in the areas you're thinking of.
I would add one other thing, and that is: open source technology has an inherent edge; its licensing and development model make it better. This is Compelling Feature #1 for anything we produce. If it weren't, then really there's no point; we'd just let Apple and Microsoft have at each other.
The reality is that we have a good chunk of users ready to jump to desktop Linux tomorrow despite its shortcomings, all we have to do is fix the few barriers that make it impossible. And once we've done that we'll have more users, thus more developers, and we'll be free to focus 100% on the next step. Which could be anything someone has the vision to guide us toward.
Speaking of copying Microsoft instead of innovating, should gnome-vfs really be a UNIX-like interface to bytestreams, or should it be more, say a general purpose data model with an evolutionary upgrade path from the hierarchical filesystem and features such as cross-machine synchronization.
Seth: for every cool thing that someone does, there were 100 people sitting around saying "we should do something cool" ;-) Keep making it happen.
People forget too quickly how huge some of the battles were that made GNOME what it is today. In my day, we didn't have time-based releases or basic UI sanity or HI guidelines, and we liked it. These things that are orthodoxy today used to be heresy.
Look at Linux on the server: kernel 2.0 was a laughable toy, 2.6 is a hugely scalable enterprise OS. But you don't go straight to enterprise OS. First somebody has to make the keyboard driver work. First you have to get some customers and userbase. Then you have the tools and the growth to take the next step.
The Apollo program had one luxury we don't have, namely it was one of the most amazing time and money sinks of all time. We have to evolve such that each evolutionary step is usable and attracts more users (and thus developers). Open source developers are attracted first and foremost to working code that they're using themselves. If cool were everything, we'd all be hacking on Enlightenment.
Cool things happen via a thousand small, practical steps. It's just that you don't usually notice these, unless you were the person taking them.
And so the moral of the story is, while someone should make the X server support smooth 3D graphics and implement the next generation of UI on top of it (and in fact people are taking steps toward that today), someone else should fix the session manager so my splash screen doesn't get stuck every time I log in. You knew I was getting to that!
I'm well into Robert Love's new book, Linux Kernel Development. The book rocks; a concise, readable explanation of all the major pieces of the kernel, how they work, how to use them. Now if only I had time to apply this knowledge. ;-) Really I just want to sound cool by using a lot of kernel jargon.
Question: if you wrote a similar guide to the implementation of the desktop, how much longer would the book be? Define the desktop as say "GNOME/OpenOffice.org/Mozilla/Evolution plus dependencies." There's so much code involved.
If all this code together had a Linus-like global architect, what would be different about the implementation? What's the impact of having dozens of separate projects coming together into a whole?
Intolerable Cruelty was a lot of fun, reminded me of His Girl Friday.
Since GTK+ went UTF-8, GTK+ programs have had to figure out text encoding (even for Latin-1 users, who often happily ignored it before). The rule we beat people over the head with is that all text must be either:
For Linux, the ongoing problem seems to be filenames. Lots of disks out there contain untagged random-locale-encoding filenames. The ext3 filesystem is defined to have UTF-8 filenames, but apparently POSIX requires the kernel to pass through filenames 8-bit clean without validation, so of course people have been sticking all kinds of non-UTF-8 junk on their filesystem. In the bad cases, you have an NFS mount with 1000 users running different locales. Oops.
Another relic of this problem: the Character Coding menu in gnome-terminal. ssh should do encoding negotiation and pass that to the terminal somehow, then it would just work without a silly menu. Or everyone should just use UTF-8 and be done with it - maybe someday.
For Red Hat Linux 8.0, we cut over to UTF-8 for all locales except CJK, creating a firestorm of whining from European users who suddenly experienced all the bugs CJK users have been enduring for years. But the bugs have mostly been fixed now; which just goes to show, to get the corner cases right, be sure everyone shares the pain equally.
Nice to see Joel's aside about the "be liberal in what you accept" myth; web browsers are the huge, glaring example of what a horrible idea that proverb really is. Imagine a compiler that guessed at your intent instead of printing errors. Wait, maybe perl already does that. ;-)
I bought a new notebook, so am geeking out with that. Fedora Core is working nicely. Sadly, no drivers for the built-in Cisco wireless card, other than the not-in-the-upstream-kernel ones and they just oops on load.
Lockdown discussion resumes, which is great. So nice to have a lot of interest in this at last. GNOME 2.6 is going to rock, and it comes out soon. Though for another week at least the focus is still on fixing bugs for 2.4.1.
Someone fix the session manager! You will be a hero.
Tried jumping to GNOME 2.5, with some broken local gconf changes. Lost all my settings. Then GTK+ 2.3 rather than 2.2 breaks the GTK+ version of Emacs somehow; the buffer and the toolbar end up with focus at the same time. So every time you hit Enter while editing it activates one of the toolbar buttons. This gets old fast.
It turns out there are a pile of outstanding gconf changes: coalescing the XML backend hierarchy into fewer files, moving change notifications into the backend, allowing custom backend stacks, half of an LDAP backend. Since 2.5 is just getting started and I have some time (relatively speaking), it's probably time to land all this kind of thing.
Changing gconf is risky; the smallest bug basically breaks the heck out of your desktop and probably loses your launchers and email account data and whatever else. But we have to do it sometime, so buckle up beta testers.
My rough thinking is that in GNOME 2.6 we can do a solid chunk of refactoring and cleaning up gconfd and the backends, then in GNOME 2.8 we can address the client side with a new API and a D-BUS access layer. The net result should be more robustness and fixing problems such as these (see also followup).
I'm keeping a page with gconf plans that has some random subset of the ideas.
Another thing I want to do is fix up the test suite to be as nice as the one for D-BUS; the gconf test suite is sort of a mess, making refactoring a lot harder. Perhaps we can address the test suite issue for each chunk of code as that chunk of code gets patched/reworked.
An open question; if we change the on-disk format for the XML backend, do we keep the old backend as a read-only fallback at the end of the user's search path; or do we just move to a new directory alongside ~/.gconf and ignore the old settings; or what.