I don't know if it ever was a "kernel up" development process. Gnome (and KDE) both had their own, pretty complex stack, even before Freedesktop.org came up (e.g. KDE had DCOP and a bunch of other services). And they weren't exactly bug-free, either -- but at least they covered a lot less surface.

I don't think it's a simple problem, and I don't think all the blame should be laid on Freedesktop.org, where a lot of good projects originated. I do think a lot could be solved by developers being a little more modest.

Not in a planned sense. But until Freedesktop, i had the impression that you had the kernel, then CLI user space, and the X and the DEs that wrapped the CLI tools in certain ways and the CLI tools in turn talked to the kernel.

Thus you could go from bare kernel, to CLI to GUI in a layered manner (and fall back when a higher layer had issues).

With Dbus etc the CLI has been sidelined. Now you have a bunch of daemons that talk kernel at one end and dbus at the other.

Never mind that they tried to push a variant of dbus directly into the kernel. And as that failed, is now cooking up another take that yet again is about putting some kind of DE RPC/IPC right in the kernel.

I wouldn't have a problem with a bunch of daemons talking D-Bus to each other, if their interfaces were properly documented, if D-Bus were properly documented and, in general, if D-Bus weren't quite a mess. I mean, if it weren't for this obscurity, issuing commands over D-Bus wouldn't be that vastly different than issuing them on a console, only more verbose.

Unfortunately, there is a lot of weird interaction between all these processes. It's often badly (or not at all) documented, and what plugs where is extremely unclear. It's very messy, and it doesn't stand still long enough for someone to fix it. They just pile half-done stuff over more half-done stuff.

It's really unfortunate because the Linux kernel is, pragmatically, probably the best there is. It may not excel in specific niches (e.g. security), but overall, it does a lot of things better than, or at least about as well as BSDs, on systems where not even NetBSD boots.

This seems an almost inveitable consequence of interfaces based on asynchronous message passing. Collaboration scenarios emerge which become impossible to trace. "If this secret handshake is done that way among these three processes, then such and such a use case is satisfied."

One problem with message passing as such is that messages are like function calls, but you can't put a breakpoint into the system and see a call stack!

If we call a function f on object a, which calls b.g(), a breakpoint in b.g() tells us that something called a.f() which then called b.g(). If we send a message f to a, which then sends a message g to b, a breakpoint in b on the receipt of message g tells us diddly squat! The g message came in for some reason, evidently from a. Well, why did a do that? Who knows; a has gone off and is doing something else.