Slashdot Mirror
Replacing the Aging Init Procedure on Linux
SmellsLikeTeenGarlic writes "Seth Nickell (of Storage and Gnome HIG fame) has started a new project which aims to replace the aging Init system on Linux. OSNews has more details on the project, directly from Seth. The new Python-based approach will make booting faster and it will talk to the D-BUS daemon, freedesktop.org's leading project. And speaking of freedesktop.org, it is important to mention the release of HAL 0.1, an implementation of a hardware abstraction layer for KDE, XFce and Gnome, based on a proposal by freedesktop.org's founder Havoc Pennington and being implemented by David Zeuthen. It is innovative projects like Storage, SystemServices and HAL that can bring the kind of integration to the underlying system that current X11 desktop environments lack."
Reading this guy's thoughts on replacing init, makes it very clear that this is intended for very tight integration with the Gnome desktop system. It's not a general purpose mechanism built using the thinnest layer with the least dependencies possible (like init is). All you need to run init is a kernel, a filesystem, and for most init scripts, a shell program. This person's SystemServices concept is heavily tied into Gnome and would require a complete Gnome implementation to function properly. On the other hand, most init scripts do seem to be very specific in operation and make many assumptions about the tools available and the locations of files, making them tightly bound to the distribution they are running on as well. But at least init as a service starting program has minimal requirements, even if init script authors choose (typically because they have no other choice due to the lack of standardization of Linux systems) to make their scripts specific to the distribution.
This makes it unsuitable for the purpose of starting up system services on a Linux system which does not include Gnome. I think that init was designed with very limited requirements and thus runs on every Linux system no matter how it has been customized.
But that's typically the trade-off in software design: if your software can make more assumptions and be more specific in operation, then often it can be more powerful and integrate better with the specific system it is made to work on. Unfortunately, for something as general and low-level as the service running program, the SystemServices concept seems to specific to be useful for general use.
Which is not to say that it's a useless project, just don't expect to see it replacing init any time soon.
Dare I ask? I mean, I've never had any problems with the init process on Linux, Solaris, or HP-UX... Was there some problem or inefficiency I didn't know about?
I like python a lot, but why make it a requirement for init ? Just means more stuff has to be installed fort he default system to work. I prefer to sue the base shell.
SystemServices is not at all tied to Gnome. It will probably not require much more than the kernel and Python. His goal is partly to make a nice set of APIs callable from a desktop like Gnome to ease with management and error reporting. This project is not tightly integrated with Gnome just because someone from Gnome has started it.
Developers: We can use your help.
why would you need it on nix*? devices are standardized. eg, except for a few ioctl quirks, ide and scsi devices are the same, from userspace. usb devices often look like serial char devs (pda cradles) or blk devs (cameras).
His approach isn't very *nix-ish, it is very Windows-ish. It assumes you have a GUI. It relies on a large complex framework of interfaces. It assumes you have Python scripting. This may work very well for many desktop distros, but it can't become some great unifying thing like he wants, since he chose dependencies that are not the least common denominator. I believe that his goals can all be achieved with minor changes to the existing init system, rather than a megalithic rewrite.
This approach sounds like he is trying to push some specific technologies he is interested in, and so he decided a new init system that uses them would be a nice PR way to push them.
One of the great strengths of unix-like operating systems and the thing that makes them easy to port from one platform to another is that the core system components are very simple, not based on some relatively huge and complex thing like Python.
Ouch! The truth hurts!
So I skimmed through the D-BUS spec and, as I expected, they are simply reinventing CORBA.
When will Open Source developers figure out that just because the OS community didn't come up with a technology, doesn't mean it has to be re-written with fewer features?
I gaurantee that whatever aspects of CORBA the D-BUS developers found unnacceptable - complexity, overhead - will be reintroduced into D-BUS by the time it reaches maturity. That's just how these things go - someone decides that Standard X is "cool, but too complicated", and then five years later they realize that their solution has become just as complicated as Standard X because, lo and behold, all that complexity was there for a reason. Real-world solutions never stay simple, because real-world problems aren't simple.
--
CPAN rules. - Guido van Rossum
This is a dumb idea.
It is antithetical to the UNIX design philosophy, and it betrays an ignorance of history.
IBM tried to "improve" the init sequence in AIX, which was a godawful mess. The concept has not improved over time.
"but if someone comes up with better system that can boot my Linux system as fast as my XP system boots, I'm game."
I do find it interesting that anyone beside embedded developers care about Linux boot times. I guess dual-booters might need this, but then again booting and dealing with two different OS's on the same machine is always going to involve some headache.
I mean really how often do you have to reboot your linux box? This isn't the days of Win95 where you had to reboot daily. The most your should ever have to do on a linux box is Cntrl-Alt-Bkspace to restart X because something went way wrong. If your actually having to reboot your linux box more than once a month your either playing with too many kernels or have a serious hardware problem.
While I agree that speeding up boot time is a "good thing" for me just isn't an issue.
If you wanna get rich, you know that payback is a bitch
If someone comes up with a whizbang new boot system. great. Just make sure that if something goes wrong, or something needs to be changed, it's:
I don't want some horrific equivalent of the Windows Registry lurking in the background. There should be no mysteries about what gets started and when. I'm not a Windows guru, so maybe this stuff is easy to determine in XP or Server 2003, but I've always found plain ol' text files to be much easier to deal with than fancy-dancy databases. Or at least compile the databases from plain ol' text files.
This person needs to be hit with a clue stick. Init is used much more than at boot time. If he has a problem with the scripts it runs, well there is nothing saying they have to be scripts. He can rewrite the scripts that run as "services" or whatever he wants to call them. I've seen plenty of inittabs with executables in them. It seems like he is reinventing something that doesn't need reinventing just because he doesn't understand it.
I know it's people perogative to write whatever they feel like writing, but I cant help wishing that desktop linux had some sort of omnipotent boss who could order the dev community around, thusly: "Quit wasting your time on that until cut and paste works, and all the desktop apps look like something other than shit!"
I mean, thats how OSX and Windows got where they are.
I don't need no instructions to know how to rock!!!!
Some people don't leave their computers on 24/7. They turn them off when they leave the house etc. Hence they are booting their computers once a day probably.
I think Seth's idea is a good one. Of course, there are some things to refine: the dependency shouldn't be external (e.g. SystemService knowing the dependancy tree) but dynamic (e.g. GDM sees that its config requires network login, so it asks SystemService to start network), etc.
But overall rethinking the init is a good thing. Even just opening the debate is a very good thing. The mess of shell scripts is more a giant hack than a well-thought bootstrap system.
As an old school programner let me say I do not hate Python. I just do not know it. So far I have found noting about Python that makes me want to take the time to learn it.
I do tell people just learning to program that it sounds like a good first language.
For internal programming that requires a GUI I tend to use Java. Netbeans is just too good of an IDDE to give up.
For non-gui internal programs I tend to use Perl. Why perl over Python? I know Perl.
For programs that end up in the hands of our customers I use C++.
I really doubt that Python sucks. I have seen too many really good programs written in it.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
Unices are being deployed across more and more diverse kinds of systems, and dependencies on python and d-bus, both of which projects I support in themselves, are not going to be welcome in the init of the majority of unix systems today, especially in servers or embedded systems.
This still won't stop the GNU folks from fucking it up, though, because more dependencies ensure GPL-lock-in (you didn't think it could happen to us, too, did you?). This isn't a troll, but a very serious issue, where lots of software is becoming very GNU-specific rather than UNIX-specific (I hope everyone can see this distinction).
Healthcare article at Kuro5hin
Apparently freedesktop.org has devolved from a desktop standards initiative to a home of pointless wheel-reinvention. Here's a list of the projects listed above, followed by their existing, more mature counterparts:
Init Replacements: simpleinit, minit, jinit, runit, daemontools, serel. Progeny also has their own system based on Gooch's need/provide architecture.
D-BUS: CORBA
HAL: Discover
--
CPAN rules. - Guido van Rossum
This feature shouldn't really need hardware support. It should be able to make a memory image in a file on the hard disk, and when it reboots, if the image exists, to reload it.
I hereby place the above post in the public domain.
SystemServices: Hardly wheel re-invention. If you read the linked-to article you'll find that none of the listed "init replacements" address any of my four major goals. They addressed their own goals, which are nice ones I'm sure, but not things that the desktop needs. In fact, the only thing they really add over init that's interesting to me is a dependency system + parallelization. And RH's internal work on init scripts has suggested this results in only small improvements (neighborhood of 30% I believe) in boot time... which is better but not dramatic. Dependency systems are pretty trivial to implement and a dime a dozen, in any case.
DBus: yeah, its a lot like CORBA. Its even more like KDE's DCOP. In fact, its a lot like DCOP. You could even think of it as a major iteration of DCOP. So look, GNOME has been using CORBA for IPC for several years and its still something people avoid using whenever possible. KDE used CORBA for a while, and even with the comparatively nice CORBA/C++ bindings found KDE devs avoided it when possible. CORBA is a freaking PITA to use for lightweight desktop-style stuff. DCOP was the solution (its a good solution, GNOME should have done this ages ago): make it easy enough to use that developers will actually readily communicate over DCOP. Communication protocols have no inherent value on their own. They acquire value when there's things to talk to. Developers won't use the API unless its simple. You can write very simple comm layers for KDE and GNOME around DBUS. Even if we GNOME folk wanted to use CORBA (we don't), KDE wouldn't, and a requirement for DBus being truly useful is that KDE+GNOME have to be willing to use it. End of story.
HAL: I'm not really familiar with discover, so I'm not going to shoot my mouth off (much *grin*). From ransacking the web page you linked to, it doesn't look like discover really supports the sort of "central daemon with notification signals" model that we need to provide good hardware support on the desktop side. Without that... its sort of useless to us. It looks a lot like Kudzu, which is a good thing (and trust me, Havoc who proposed HAL in the first place knows about Kudzu, and probably discover) but it simply isn't what those of us who are in the ditches writing this desktop code need.
Moral of the story: a superficially similar "solution" does not necessarily address the issues that we as desktop developers face. We propose these things because we have concrete problems to solve. Sometimes the problems are not obvious until you try to do something and end up butting into them. We're lazy people, just like anyone, and we don't like :-)
This is what is great about Open Source - people can innovate, create new systems, and if they prove to be good, they can be widely deployed. That's how progress happens, and the heart of a developer rejoices on seeing things like this. In the end, superior technology will triumph, and seeing that he is using Python, he is already well on his way :-).
And as for all of you sticking to the old stuff, because it's good enough: are you sure you are not just getting old? The time I start to whine about progress ("the old way was good enough") will be a sad day indeed. Or perhaps this is the difference between sysadmin-types and programmer-type: sysadmins like to stick to old shell script based system because it's uniquity, while developers see the opportunities of new technologies and have a certain inborn respect for technological superiority.
Linux will evolve, live with it. If the old system is indeed better, it will be used indefinitely, but unless we try something different, we will never know. Having some distros doing the thing in an alternative way is a good way to hash this out.
I for one welcome our new freedesktop.org overlords. I'm really liking the direction that Havoc Pennington and other Gnome-related people are taking as far as desktop things go. We need more dynamic & motivated people like them on powerful positions.
Save your wrists today - switch to Dvorak
Even if you're using Linux boxen purely in a server environment, having parellelized startup of system services could be a big win: if your SSH daemon could start up before or in parallel with log rotation, hardware monitoring (devfsd, kudzu, etc.), etc., you could log back on to the server that just rebooted much more quickly. I know, in an ideal world, you'd never have to reboot a production system, but we live in the world of failing hard drives and power supplies.
Never attribute to malice, what can be attributed to sheer ignorance.
I suspect that most of those problems are people not knowing enough about the Solaris/BSD platforms to write portable code... not merely being careless.
Reminds me of an old story of somebody hired to improve the elevator waiting time that people had been complaining about. Instead of tinkering with elevator algorithms or making it run faster, he simply installed mirrors by the elevator. Nobody complained anymore.
It makes a difference, because it's something I'm waiting for. It's one more minute before I can read email, or search for something on Google, or whatever I turned on the computer to do.
An extra three minutes shutting down, on the other hand, isn't that important for a desktop, because I would probably have walked away to do something else. It might be for a laptop, however, because the user might be waiting to unplug it, etc.
The point is, it's not the amount of time, but whether I'm waiting for it or not. This means that one solution to the problem may simply be downloading Slashdot headlines and showing them while the system boots.
Ok, so I'm not the best person to say this because anyone who looks for my publishing credits will immediately realize that I'm a "Perl guy" and thus, I must hate Python (I'm not really a Perl guy, and I don't hate Python, but that's beside the point). I'll go on anyway because this is important, and folks who don't do sysadmin for a living may not have had to think about this.
init itself is so lightweight and small that it rarely, if ever, fails. This is a good thing, since it's init's job to start a ton of very heavy-weight services.
That said, I see the logic in bloating init with some of the features that are almost always implemented in a distribution built around it. For example, it would be nice to see init perform some service tracking such that it could be told directly to kill a service, and it could do so.
Keep in mind that every time you increase the size of init, you remove a class of systems that can now no longer use it because of it's footprint. This matters a lot for some kinds of embeded systems that have just enough brains (that is, RAM and installed libraries/software) that it makes sense to have init today.
You certainly could not achieve this minimal-growth by re-coding init in Python, Java, Perl, Lisp or any other high-level language. That's not a slam against high-level languages, it's a simple fact of life that their flexibility comes with costs.
As for the shell-script init-scripts, I certainly feel that all of that should be moved out of init's domain. Each application should have a control program (like apachectl) which knows how to start it, stop it, get status, reload configs, etc. That program can be written in C for speed; a high-level, general purpose language for ease of maintenance; or even in shell. But, the point is that that should not be a constraint of init.
init, might well provide a library and/or command-line tools to make writing those controlers easier and more modular, but I don't think there should be any REQUIREMENT that your program know anything more than the calling conventions of an "init controler". The more constraints you heap on, the less software is going to ship ready to integrate with your init system, and that way lies far too much integration work to create a workable OS (and thus MORE variants between distributions, not less).
Once you've done all of that, THEN you can think about the high-level glue so that things like a desktop integrate better.
Whoa an AC with some insight. Windows 2000 had a single-threaded boot, kind of like Linux. Load things one by one and in order. Win XP came out with a multithreaded boot process, which brings the system up faster. However it only appears to be ready sooner, it takes the same amount of time to get into a usable state.
Can I get an eye poke?
Dog House Forum
I still remember systems where bash scripts did not work as bash was broken or bash accidently was disabled for the user running the scripts. That time (3-5 years ago) there were many flamewars bash-vs-sh. What's happen? Bash is everywhere. Not precisely everywhere, but more systems have bash today.
I think the evolution of unix-like operating systems (especially Linux ones) is moved far forward enough to begin flamewars python-vs-bash. Yes, Python is not everywhere, but so isn't bash, Python has just a little bit smaller % of system with no Python, but still many of them have it. Especially if it will be required.
Why Python? Several years ago Bash won a simple sh just b/c it has a little bit more convinient programming extensions. Even with that Bash is still not exactly general programming language and if you try anything complex on it - you know what I mean. Python is much better for scripting complex tasks. Dependency checking is one of reasons to use it. String parsing, regeneration of config files - another ones. With bash you don't have a good luck to do it.
Evolution of system tools wasn't frozen these years. Get over it. It's time for real tools to come to the scene. If you don't like it - choose an OS more conservative than Linux, for example BSD - sure they will stisk to a simple sh for a couple of more decades. No wonder it's dea... sorry... :)
Well, thanks to the project like this, and Gentoo as well, in few years someone will point on this flamewar and say: "remember some conservators did not want to use Python? Now it's time for ..." Who knows, will it be Erlang or Haskell? :)
Less is more !
GNU software is better, cheaper and freer than its UNIX counterparts. It's no wonder that GNU is finishing off the lame and deaf UNIX moloch. Besides, that has always been the project's goal. It's not like that's a secret or anything.
As for "lock-in", well, if GNU's the prison, I don't mind being a criminal.
But I do like the idea of parallelization of the boot scripts, and starting X a whole lot earlier (like before the daemons are all started); I hacked up the init scripts to do this on my desktop linux machine a few years ago, and on Solaris and SunOS machines before that, and it was great for boot time.
Richard Gooch's need(8) and provide(8) tools look like a fantastic way to do this simply, comprehensibly, and without rewriting everything in a new language. that's available here, and that page notes that it should be in versions of init in util-linux since 2.10q.
And you're completely ignoring the BASIC FOUNDATION of why this is USEFUL: other SERVICES only have to WAIT on those they DEPEND on. Does loading X require a working DHCP lease? God, I hope not! So what happens is, that fundamental property of modern operating systems, "multitasking" switches between services starting in parallel.
For the record, right now my init system waits for a dhcp lease before making progress. In essence, everything is started up as if it depends on everything before it. In reality, they often don't. Maybe you think that startup screen is nifty, but most people who've seen init booting my desktop think that 1) its slow 2) its crappy. They just might be right.
I Browse at +4 Flamebait
Open Source Sysadmin
A smarter startup process would be good, perhaps a binary one could really save some time over shell scrips(I doubt this, Most boxen these days are so fast even the most complicated bash scripts for init you can imagine take no time to parse and execute). He plans to use python which is still an interperated languge and not much faster then bash for simple stuff. Still why reqire X and GDM and python and app of the month. Why not wirte a nice little C program with a GUI interface to configure it if you must but make sure it can be configured from the command line or config file as well. I don't see what real advantage in going graphical and therfore more fragile in the init process offers. I don't care if your grandmom or Sysadmin if the console messages had like two modes friendly and verbose everone could be happy. Imagine if it was just like,
/r /s
Friendly mode:
Starting Priniting support
Starting Sound support
Printing is ready
Starting Webserver
Webserver Ready
Sound support Ready
Verbose mode:
Starting lpd with
Loading cs46xx module
Done: Loading cs46xx module no error
Done:lpd lp ready.
you get the idea. If init needs replaceing there are lots of ways to do it and make something everyone can use, for all types of systems heavy server through desktop. I usually don't advocate one size fits all solutions but if your going to start writing custom extensions to deamons that call "services"/init to do stuff I want those apps to work on my desktop so I can experiment with them as well as the server in the back room, that means init needs to be compatible. A separte system for desktops is a BAD idea IMHO.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
inetd got buggered until it became xinetd. cron was forced to run side-by-side with the abortion known as anacron. In its defense, vim at least can be made to behave like vi, entirely UNLIKE bash, the sh-incompatabile sh replacement.
To the Linux developers: QUIT BREAKING THINGS from a "unix-like" perspective. If Linux is going to be an entirely unrelated OS, then fine. If it's going to strive to behave similarly, then quit adding features that break expected behaviour, especially for the reason of being 'really cool.'
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban