The next step

Most people consider the Hurd only a project to replace monolithical kernels. IMHO, it is more.

On the irc.freenode.net##hurd channel, we just had another discussion on the X window system. (You can read it up in the channel log.) Which seems a good occasion to summarize some of my thougths here.

While there are a number of other things that are flawed about X (which I may touch in other posts sooner or later), there is one really fundemental problem: The X server is basically a gigantic monolithic beast, suffering from much the same problems as monolithic kernels. (Flexibility, extensibility, robustness, usability, security, etc.) And it needs to be fixed in much the same manner.

The nice thing is that the underlying Hurd concepts (RPC, translators, etc.) not only give the foundation for reimplementing the functionality of monolithic kernels with a multi-server system in userspace, but also for refactoring monolithic higher-level infrastructure components like X -- just like the Hurd is splitting monolithical kernels into a set of interacting servers handling individual parts of the functionality, a hurdish windowing system will split the functionality of X into individual servers. (And just like the Hurd uses libc to implement POSIX interfaces on top of the multi-server system, allowing for a smooth and flexible transition to more powerful concepts, we will need a replacement X library implementing X interfaces on top of the multi-server windowing system.)

2 comments:

Ognyan Kulev said...

X.org is going to be modular. But it's questionable if there is sense in splitting X into interacting servers instead of one server process with loadable modules -- after all, these modules are not replaceable by ordinary users. Tell me if I'm wrong :-)

antrik said...

Well, the point is that those modules should be replacable. We want the possibity of individual services replaced or extended by the user; of running multiple instances of a service in parallel; the robustness of independant processes running in seperate address spaces; the transparency of components communicating via the filesystem in comprehensible ways; the flexibilty and extensibility of components not constrained by a predefined module system; of combining them in completely new ways, even in the running system; of developing components and subsystems independantly; the simplicity of changing the behaviour by setting up componets in a different constellation. We want advanced applications accessing individual components directly by their native interfaces, using and extending them in interesting new ways. And so on and on... In short, we want all those great advantages the Hurd offers over monolithic kernels, applied to the windowing system.