OSNews was the first news magazine to break the story on Gnome’s Seth Nickell effort to replace the Init system. Soon, it became confusing to many readers as to if Seth is planning to completely replace the Init system or simply “bridge” it. We had a chat with Seth and discussed about his plans on the project (which is a personal project so far) and for Storage, an exciting project which aims to replace the traditional filesystem with a new database-based document store.We asked Seth if he thinks that in the event these projects take off will be Linux-only and if they actively supported by Gnome libs might result in Gnome being OS-specific and ultimately drive the project into forks. Seth does not believe so that this will be the case, as companies where their business depend on Gnome (e.g. Sun Solaris, Ximian) will be able to adapt and port necessary technologies.
Regarding Storage, Seth told us that the natural language parser needs more work but the project is progressing. We also asked Seth his opinion regarding an ideal packaging management for Linux, and he told us that what Red Hat is doing currently with the “Red Hat Network” is a nice idea, however it still needs some refinement.
Here is Seth’s response on System Services and the replacement of Init:
Seth Nickell: I’m planning to fully replace the init system, not just bridge to it. I *am* providing full backward compatibility with initscripts (SystemServices can use them), but of course they will only offer as many features as initscripts already have written into them (not much :-).
SystemServices has four major goals:
1) Provide a full services framework (including handling “boot up”)
2) Integrate well with a desktop interface
3) Start X, and then allow login ASAP
4) Allow daemon binaries to directly contribute services rather than requiring each distro/vendor to write shell script wrappers
1) The init system has small concessions to being a services framework rather than just a “boot-up-tool”, but it really only provides the ability to start/stop/restart services. We need a system that is both more featureful and and more robust, esp. for desktop integration, but its nice all around. For an example of robustness, if a service can’t start (or if it crashes at some point!)… the interface needs to get an “exception” with an error code and a message. For an example of a feature: we need integration with xinetd so you can flip a checkbox to switch a service between “run on demand” (xinetd) or “run always” (daemon).
2) The way init works doesn’t fit really well into a desktop interface. A lot of these issues are covered by (1). The whole runlevels concept is confusing and cumbersome, even for most (not all, but most) sysadmins. There are a very small percentage of people who need runlevels, but for most people they make the conceptual model for services 100x more complex with -zero- gain. They also make interfaces a lot more clunky. Of course, being a part of Unix tradition, I expect a million people who have never really benefited from them to scream at me anyway *wink*. I *might* provide the idea of named “service profiles”. I *will* provide a way to boot into a “stripped down console mode” aka “single” for system recovery and backup, and a regular non-graphical boot for servers.
3) Most services are not required for running KDE/GNOME/whatever. These can be deferred until after KDE and GNOME have been started (or happen in parallel). Also, SystemServices brings up boot progress information in X almost immediately. Even after you’ve logged in, we provide a little progress window on the side of the screen that provides feedback on the startup of non-desktop-required System Services (Apache, ftp, etc). The window goes away as soon as the system is fully started.
4) This one is part halting constant re-invention of the wheel, part personal agenda, and part clean architecture. Its silly that custom init scripts is one of the areas where distros work separately, what a waste of time they could be spending on much better integration work. My personal agenda is to encourage daemons to depend on DBus in the future, which will make them more likely to *use* DBus for providing a client interface. I fear that even after DBus exists and when it makes sense to, e.g. have an org.apache. WebServer DBus service it will get shot down because nobody wants to add the (compile time optional) dependency to get a few “small” features (small to daemon/kernel/network hackers, big to the desktop!). But the really big thing to me is clean architecture. When daemons contribute services directly we have a framework for them to contribute more than just the basic Service interface. There’s already a concept that a service can contribute more than just “start/stop”… the Apache service can contribute API that allows desktop apps to query status, etc.