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?
The new Python-based approach will make booting faster
Oh wait, we forgot to convert back from decades... uh, nothing to see here.
====
Crudely Drawn Games
Even Windows XP has a way better init process while loading.
Seth his opinion regarding an error code and ultimately drive the screen that custom init system, not required for running KDE/GNOME/whatever. These can contribute services 100x more complex with xinetd so that allows desktop interface. A lot of course they make interfaces a nice all around. For an example of non-desktop-required System Services and more than just bridge to me anyway *wink*. I fear that is one of people who need runlevels, but for most (not all, but for system is to depend on demand" (xinetd) or "run always" (daemon). 2) Integrate well with an "exception" with -zero- gain. They also asked Seth his opinion regarding an org.apache. WebServer DBus service it will only provides the case, as initscripts (SystemServices can be able to it. I fear that in the basic Service interface. I *might* provide a little progress information in the case, as many features as companies where their business depend on much better integration work. My personal agenda is one of Unix tradition, I fear that a million people who have been started (or happen in the system is progressing. We need integration work. My personal agenda, and the project into them (not much :-).
SystemServices brings up boot for system has four major goals: 1) Provide a very small percentage of a service can't start (or happen in Gnome libs might result in Gnome being a services framework rather than just "start/stop"... the ability to write shell script wrappers 1) Provide a "stripped down because nobody wants to add the ability to adapt and part of these issues are not just "start/stop"... the Apache service between "run always" (daemon). 2) The way to contribute API that custom init works doesn't fit really only offer as companies where distros work but its nice idea, however it makes sense to, e.g. have never really big thing to get shot down console mode" aka "single" for services are not believe so that is one of the replacement of non-desktop-required System Services (Apache, ftp, etc).
The window goes away as soon as many features as the natural language parser needs more robust, esp. for running KDE/GNOME/whatever. These can use them), but most) sysadmins. There are not just a system recovery and ultimately drive the future, which will get shot down because nobody wants to encourage daemons contribute services 100x more than just the event these projects take off will be deferred until after KDE and part of a part of a full services framework for servers. 3) Start X, and part clean architecture. Its silly that what a waste of a regular non-graphical boot for most (not much :-). SystemServices has small concessions to write shell script wrappers 1) Provide a service can flip a system has four major goals: 1) Provide a very small concessions to directly contribute more complex with -zero- gain. They also make the event these projects take off will be deferred until after KDE and cumbersome, even after DBus service between "run on System Services (Apache, ftp, etc). The init works doesn't fit really only provides feedback on much better integration with the "Red Hat is clean architecture.
When daemons contribute more complex with xinetd so that provides the "Red Hat Network" is confusing and ultimately drive the basic Service interface. I expect a waste of these issues are not just a client interface. There's already have a services rather than just "start/stop"... the event these projects take off will get shot down console mode" aka "single" for system that this will be able to query status, etc.
The way init scripts is part halting constant re-invention of Init: Seth his opinion regarding an example of non-desktop-required System Services (Apache, ftp, etc). The window on Gnome being a nice all around. For an "exception" with initscripts (SystemServices can contribute services 100x more featureful and ultimately drive the interface needs some point!)... the idea of time (optional) dependency to start/stop/restart services. We asked Seth if a few "small" features (small to contribute more clunky). Of cour
if $OS [] *linux* or $OS [] *nix* then
repeat
SCO.account = SCO.account + yourbankaccount
until bankvault = empty
end if
I'm one of the crowd who will probably stick with init. It took me many many tries to tune my scripts the way I like it (and since I'll be reinstalling at some point, I'll have to spend some more time tuning) and I'm just too lazy to learn a new way. This is of course why old stuff is still all over the place, but hey, if it isn't broken, I'm not in a big hurry to replace it.
The current init system is actually fine in my opinion, 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 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.
"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."
HAL I can see, but Storage is just a substitute for the File System. Now how is the X11 DE environments lacking there? Or is this another example of the MS "One solution" thinking in action?
Keep Python interpreters out of my system guts!
System code should only be written in C!
Start Running Better Polls
Because of the crappy Sys V init, I use slackware for it's excellent init system.
Why go to all this effort when it's already done for you?
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
This strikes me as a completely misdirected load of nonsense. Integrating Init into the Desktop ???? Someone is missing the plot somewhere...
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.
Back in my day, young whippersnappers didn't show disrespect to their
elders by talking about replacing them with fancy-pants code. We were
shell scripts and we liked it.
Not Bash scripts either, real life ksh scripts. You hippies and your
bash shell.. why I outta.. ouch, hurt my arm waving it so.
Anywho.. back in the day when we were happy little startup systems
we didn't have to worry about snakes. Python? Who ever heard of that
back then? We has ksh and csh and WE LIKED IT.
Damn granola-crunching kids and their need to improve what don't need
improving.. Stay in school, don't become pot-junkies and enjoy the
blessed rc that nature intended.
It started with all this Rock and/or Roll that you ingrates listen to.
Back in the 70's we rc scripts were appreciated. Then along comes this
electric gee-tar thing getting so popular and that did it.
Dag nabbit... where's my crontab..
where was I? Oh yeah..
Back in my day, young whippersnappers didn't show disrespect to their
elders by talking about replacing them with fancy-pants code. We were
shell scripts and we liked it.
.
.
.
Is that part of the ongoing process of making Linux boot faster? :-)
"The current init system is actually fine in my opinion, but if someone comes up with better system that can boot my Linux system as fast as my XP system boots, I'm game"
This is Linux. Why are you rebooting so much that boot times are a point of comparison.
The Linux startup process works. Is there any need to muck about with it? On Red Hat et al and Debian, there's the powerful but complicated init.d directory; while Slackware users have a less sophisticated system to contend with.
;-)
And hey, it's not like we have to boot all that often, is it
Je fume. Tu fumes. Nous fûmes!
It's "faster", because it's "python based"?!
The standard Linux init system is based on sysvinit and is slow precisely _because_ it is interpreted (it's basically a ton of shell scripts). The other reason why it's so slow is because glibc is slow and the init system starts several hundred processes during the init process. Just log in on a freshly restarted Linux system and type "echo $$" in a shell prompt to see how many programs were run before you logged in. On my minit based notebook, the number is below 20. On my minit based server, it's still below 30.
minit takes less than one second to initialize the whole server system, on an aging 466 MHz Celeron box, right from the point where the kernel starts init up to the login prompt. And the server does file sharing, cvs serving, rsync serving, runs a mail server and sshd.
In fact, because minit does not even depend on glibc, minit can probably initialize a small system in less time than it takes to even load python and glibc on this init system.
Fast and python based, give me a break. And the freedesktop people should keep their bloat to themselves, if you ask me. With the notable exception of KDE, all the gui systems on Linux have gotten progressively slower and more bloated over the years. KDE has also become slower, but less drastically, so it can be excused IMHO. But Gtk? Give me a break! Even starting the gnome theme engine takes 5 seconds on my 2 GHz Athlon XP!
If you're going to re-invent a major wheel, why not just use adapt Hurd to run with the Linux kernel?
A replacement for the current init system, while necessary, should have fewer, if possible, dependencies than the current init, not more. 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.
Where do people get the time for this crap?
What? The people taking the time to paste goatse.cx text-pics or the people replying to the pic asking about it?
I will no longer have to explain init.d and runlevels to noobs. I like init, once you understand how to use it, it kind of makes sense. It does look like a 2 decade old silly way of starting/stopping services, and I dont see how anyone could grok it without reading some man pages.
TallGreen CMS hosting
- Where do people get the time for this crap?
You mean replying to troll posts? I don't know. Work, maybe?"Raise the standard of Humanity -- Support the arts." - R. Maplethorpe
Why do so many projects use Python? Lots of people hate it, and for good reasons. Yuck.
for god's sake make it so we dont have to log in each time we turn it on.
"It's so convenient to have a system where everyone is a criminal" - A. Hitler
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).
- That's classic! The first ASCII-Goatse that I felt safe enough to show my boss!
How did she react? I mean, to the fact you were reading Slashdot (at -1, no less) while "at work"?The relevant one here is the management of services -- far easier than anything similar I've ever dealt with in the Unix world. I realize that 1) this proposed replacement goes beyond what the Gentoo system manages and 2) real sysadmins running real servers aren't going to leave the existing system any time soon, but for desktop users today, it's a great advance that doesn't get the credit it deserves.
What I'm listening to now on Pandora...
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.
Uhm....
This feature has been available for a long time. If you use gdm, run gdmconfig as root, and in the "general" tab, check the box labeled "Login a user automatically on first bootup", and select a username from the dropdown box.
I'm sure kdm has similar features.
Microsoft is to software what Budweiser is to beer.
If this is well thought out and reduces startup times it will be a welcome change. Windows XP starts up quite a bit faster than my linux machine does and is usable quicker, and I'm counting AFTER bios post.
Chris
I was on my union-mandated 3-hour lunch break. What better time to schmooze with the boss?
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!
"if someone comes up with better system that can boot my Linux system as fast as my XP system boots, I'm game."
The real strength of open source is that you can choose to use the new init, I can choose to use the old one, and Joe Blow can write his own.
If someone designed a "more efficient" init for Windows XP, everyone would be stuck with the decision made at M$. With efficiency being relative in almost everything, the freedom of choice is unbeatable.
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
Is it too much to ask to require an IQ test before receiving moderator points?
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.
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.
Isn't this guy just just copying MacOSX? The terms remind me of what I read about MacOSX. And the delayed startups remind me of Windows, and all the complains about unsable machine for 30 seconds after typing password. And isn't just focusing just in the desktop? I recomend KISS, a GUI can be put on top of scripts fine, and I do now want to imagine "but I upgraded this app [which upgraded python cos otherwise it does not work] and now it does not boot". He complains a lot about coders knowing zero about GUI, but he doesn't seem a pro in the non-GUI.
In my day, when you wanted to start your computer, you had to use a SHELL SCRIPT! And TYPE! With your HANDS! And WEEEEE LIKED IT!
Facts do not cease to exist because they are ignored. - Aldous Huxley
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!!!!
When the damned kernel code I am currently working on panics and I have to debug it
Of course this only applies to about .1% of people doing development - but I hate watching systems boot - it happens WAY too often for me
I have mod points and I am not afraid to use them
Write a kernel level x-driver and gtk module, and get a fully working gui as soon as the kernel is loaded. Come on, beos did it, so can linux?
...........
Heres the concept boot sequence.
GCX 590-Motherboard
YHBT BIOS
Intel(r) 786(tm) processor 5000mhz.
Checking RAM : 2097152Kb OK
*beep*
LILO loading
$ linux gui=yes vga=799 init=/bin/gdm
Loading linux
[Gnome desktop manager ]
Welcome to Linux!
I don't think I've ever understood less of an article's description on /. ever. I think I caught maybe 10 words of that thing.
"I've got to stop masturbating! It makes me too lazy! Stop it, Albert. Stop it." -- Albert Einstein
looks very similar to all the other wheels that are already out there but this one's newer and shinier.
OK, this may be the greatest thing since sliced bread but why does it have to be done? I know it's more fun to go off and implement something from scratch than to incrementally fix something that's already out there so that existing users get the benefits as well but is that reason enough to do it?
If the author want's to do this that's great, after all this is their time they're spending on their own software. Making it out to be a great boon to the rest of us, well that's pushing it.
There are lots of rough edges in linux desktop world at the moment. Smoothing them off isn't as glamorous as building a new init system but it's probably more useful.
development.lombardi.com
The only init replacement i've seen that seem to have some sense is: http://www.atnf.csiro.au/people/rgooch/linux/boot- scripts/index.html
elFarto
i first read this article last night on Newsforge and did some cursory searches for the project. i couldn't find anything. has anyone else had any luck?
/. right away!!
the only things i've yet found are blog entries. he seems to be a reliable hacker but of what news is this until there's downloadable source-code? i'm planning on working on a new MUD; i'll be sure to submit that to
so if you have a link for us, please pass this along. also, like so many others have asked, how closely will this be tied to GNOME? even my desktop system uses WindowMaker ; why should a foundational mother-program rope me into a DE i don't like? or be reliant on the GUI in the first place?!
process 1 on my OS X box is init, same with the IRIX server i'm logged onto, and I'd imagine Solaris, AIX, HP-UX, *BSD, yadda yadda all use init. So, when do I get to use this on my Mac or Origin? (Just kidding...you can have my init when you pry it from my cold, dead fingers :D)
Facts do not cease to exist because they are ignored. - Aldous Huxley
In related news, Ford has started a project to replace the aging wheel design (3,000 years out of date now) with a new python-transport. With only four of these powerful snakes, every vehicle will be able to slither around more reliabily and across all sorts of terrain forever untraversable by the obsolete and despicible wheel design.
The wheel is an "aging" idea too..Don't get me wrong: I support the new process if it makes the bootup process better/faster...you should be pointing out the limitations in the init process.
Best exemplified by his statement that runlevels aren't important. Maybe runlevels as explicit runlevels aren't, but the idea is. Remember, we started with one big monolithic init script, and runlevels and such were introduced because lots and lots of admins had the same need: to start a system with a predefined set of things turned on or not, eg. a single-user mode with no system services running so major things can be replaced without interference or major system breakage that prevents normal startup from happening can be fixed. If he leaves out "profiles", they will be reintroduced for the same reasons runlevels were introduced.
When the Good Lord created the Universe, He created Nature and all the Beatiful Things it contains.
The Good Lord created the Laws of Nature (physics) and of Mathematics
And He saw that they were Good.
Wanting worship and appreciation of His great Works, the Lord created Man.
He created intention, free will and and enquiring mind in this Man.
Aeons passed and Man lived as a child of Nature and God.
Man worshipped God and saw His greatness and the Truth and Beauty that God had created in Nature.
When Time was right, God endowed Man with great Reason, such that Man could comprehend Nature's great Mathematical Beuty.
Lo, man now logical and rational could move out of childhood into adolescence.
In a mere blink of God's mighty eye, Man beheld the Great Truth of Mathematics and studied Creation with great insight and insiration and was propelled forthwith into adulthood.
Man took his first tentative steps onto another cellestial body, and through Mathematics discovered the divine UNIX.
May years passed and Man took UNIX and made it Free as God has intended.
In this UNIX, God had in his great Divine Scheme begat Emacs and init.
The one day Satan came along and tried to ruin it all by replacing init with some rubbish written in Python.
There endeth the lesson for today.
Stick Men
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.
If you're going to boot into a desktop environment such as Gnome, why would you want to run 40 or 60 shell scripts (in serial no less) before starting the DE? Why not just do the minimal work to get the devices, kernel, and desktop going as early as possible? Then start launching services.
Coupling the desktop to the boot process should decrease boot time (or perceived boot time). It makes sense for Linux users who are only ever going to use a single desktop (and always use a desktop).
That ain't me, but it's probably a large and growing fraction of linux users....
Yea that is a great idea just write everyting in C, what a dork..
Got Code?
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
Ok, obviously the poster doesn't speak English as their first language, so no complaints about the odd word choices.
But most languages I've seen make at least some use of linebreaks and paragraph breaks...
Geez.
.sigs are for post^Hers.
So we decided to replace something that isn't broken with something that arguably is broken. Author would appear to be VERY inexperienced. Does he understand the flexibility of the current init system vs. the very rigid and inflexible one he has proposed? Oh well, I'm sure he'll have fun writing it, even if only deployed by the younger set. An example of the youth's inexperience, Seth Nickell states "The whole runlevels concept is confusing and cumbersome, even for most (not all, but most) sysadmins." This is absolutely FALSE. I teach Unix at a local college and my only comment is that perhaps some people like to believe that init is "cumbersome" and some may actually say so because they never bothered to learn it, but even students in my INTRODUCTION TO UNIX class FULLY comprehend Unix runlevels. In my Systems Administration class we use runlevels (which define the operational state for Unix, what daemons get run, etc.) to create our own kiosk runlevel. Runlevels are easy, flexible (much more so than Seth's "replacement").
Oh, you mean until you find another OS that can "fake" boot as fast as XP...
XP has some serious issues in some cases with the way it "optimizes" the boot order. It appears quick, but in a corporate environment that can lead to weird timing problems. That's probably why MS left/added a feature to disallow logins until XP was really booted.
.sigs are for post^Hers.
Where in the article does it say this depends on GNOME? You're asserting that the skilled GNOME devs can't help out and work on other projects? People like Havoc Pennington are interested in making the LINUX desktop a useable, viable environment to replace windows, and if it's lacking somewhere other than the desktop environment, why shouldn't they apply their skills and help out with that, too? This kind of scare-mongering went on some months back when people were convinced Keith Packard was collaborating with GNOME to integrate GConf and Glibc into X. As usual, it was all FUD, mostly on the part of anti-GNOME zealots who have no idea what the GNOME devs are trying to achieve. The point with OSS is that you don't have to use it, and there are usually at least three alternatives for everything you happen to want. But it really doesn't help when people go around spreading FUD about other projects that some of us just happen to like and to which a lot of people have contributed time, effort and money.
real men use sh.
.sigs are for post^Hers.
Yes this is a horrible perversion and deviation of UNIX.
/etc/inittab to see what further program it should call. For each runlevel there is such a program.
/etc/rc2.d/S*). But all this is just "usual" and could be completely modified without throwing away the standard init system.
Also, the so called disadvantages of init are void. It looks like he does not understand what init is.
Init is very simple: the kernel calls a program called "init" as soon as the kernel-part of booting is ready.
The "normal" init (there is a SYSV and a BSD variant, the SYSV variant being somewhat more complex) only reads a config file
Usually these are the init.d/rc shell scripts that sequentially carry out a number of initializations. Often there is a kind of master script such as rc2 (for runlevel 2) that calls further scripts in some order (those are usually in
If you want, you can configure inittab to call some multithreaded language to carry out some initializations or start background daemons (yes, a UNIX "service" is a daemon, heretic!) in parallel, speeding up the init process.
You can also simply use shell scripts instead of threads, but use shell background jobs (&) to do some things in parallel and then wait for each of them afterwards (the shell wait command), so you don't even need some multithreading for speeding up your boot process (the difference between multiple processes versus threads in this context is measured in milliseconds, not really a worthwhile advantage when it comes to boot time).
In short: it is an insane and heretic idea, that can only be bred by evil plans or by ignorance.
There already is a better init system: simpleinit. I've worked with it on embedded systems, and it rocks.
It's dependency-based, so you only start up the services you need. Read all about it.
Dependancies are a big improvement over runlevels, although you could implement runlevels on top of it.
The "file-rc" system is a replacement for the symlink method. It lets you define what runs when, in a single file.
Debian fully supports this alternative boot method in their policy. All packages are required to call update-rc.d, which in turn either adds/deletes/modifies symlinks or edits the file-rc if you're using that.
The "symlink mess" is already taken care of.
See file-rc package info for details...
Init may be old, but what's to improve on?
Init is solid, reliable, and standard. Best of all it works. What about systems where python is not installed?
cat article | sed -e s/"aging"/"tested and reliable"/g;
I have no problem with your religion until you decide it's reason to deprive others of the truth.
I used to laugh at folks who wanted to re-implement the whole OS in Perl .. now we've got folks wanting to do the same in Python?? Argh.
Look the "init" system in Unix is a pretty basic concept. A small program runs another program at boot. Everything else is just variations on the theme.
Let's concentrate on dependency systems, preferablly handled by a program in C that reads a simple text file and launches services in the right order so that the GUI can be up as fast as possible. That's all we need. Sure it's not sexy and it won't get on Slashdot but some distro author out there is going to do it and it's going to kick this Python business out the door.
Damn, I'm just trying to imagine installing Linux on my embedded 486 board.. not only do I have to copy the kernel, init, a shell, and some utils, but AN ENTIRE PYTHON RUNTIME?? Yow!
These kids today!! *shakes fist*
And the first minute is painfully slow, like in Windows, where it keeps loading things after you loggin. Or worse, some parts of the DE don't work without things like network, so I predict a nice mess (hunt in archive list, you will find how problems with DHCP or a bad configuration of the resolver makes GNOME puke).
Python is not GPL
"Python is absolutely free, even for commercial use (including resale)"
http://www.python.org/doc/Copyright.html
A Usenet Troll Triumphs on Slashdot
I always clean up my system so only the things I need start, and it boots extremely quickly. Less than 5 seconds after the init process starts.
Also, I don't know where you get this stuff about GNOME being slow and KDE being so fast, because the GNOME 2 series has gotten progressively faster. It loads in about 3 seconds on my machine, while KDE takes significantly longer(but not aggravatingly long).
Sticking feathers up your butt does not make you a chicken - Tyler Durden
(DANGER: Rant ahead!)
/sbin, /usr/sbin, /usr/distro-hacked-name/application-bins or whatever. Install a program? No user in their right mind wants to run some haphazard installer like "Installshield" or whatnot to get a program installed. Just annoyances, and at least Mandrake has that part taken to term - almost (I royally hate having the package management program in over three pieces). OS X is pretty good at this too. Windows is a nightmare. Sure, there's a directory of vendor-supplied installers/uninstallers to help you traverse the bloat. But installing/uninstalling apps should be a system function like RPM, not bloatware tag-alongs with the application. Installed Flash for Linux lately? YUCK! A shell script and some unknown archive in a tarball.
I can tell that Seth has the right idea: More API in the kernel, less hectic scripting that requires those irritating scripts. They're one more thing to break! I personally spent a lot of time with my newly-installed Mandrake system trying to get ALSA to work and it still isn't great. The OSS layer (another thing to break) also doesn't load right because of the init script.
I think there is vision here because it allows the system to start services without some outside script - everything rolled into the services themselves, where they belong. I hate having to track down a dozen different files to figure out how to make a tone come out of my sound card, or get my USB Cameras and scanners to work. Mandrake's distro works really well for this. But there are some flaws when you have 2 or more APIs up the totem pole to interface the same hardware. Why doesn't my video hardware scaler work in Mplayer through the "Vidix" interface when I'm not Mr. Root? Sure, there's some kernel-level workaround, but I'm not happy with the idea of re-compiling the kernel: It's a remarkable amount of work to do any tiny thing, and it always comes with the potential to break my distro.
That's a way-out-there example, but the point is that having a good set of APIs makes system management easier. ALSA's got a good API. X11 is a good API. Gnome and KDE seem to work fine, but the existance of both gives me a royal headache. It's like having a Mac and Windows inside the same OS and makes me dizzy. And when I'm dizzy, Joe User is passed out. Joe User wants click-go computing. It starts up in the preverbial morning, files are kept on the hard drive, no need to reconfigure it because of your network. No guessing what program will come up when you double-click a file.
No one has what Joe User wants. But Joe User wants something that includes an idea like what Seth wants. Want a web server? Click. It's running, and you don't have to guess whether it's in
The point of this rant, is: If we offer Joe User an OS that doesn't require a management headache, and offers Joe Software-Vendor an easy, straightforward way to program under it, and organizes everyone's clutter - Linux will take the day. OS X is way out ahead of the pack on this one, Mandrake is great but still kinda clunky, and Windows is barely holding. Who cares about "performance" when no one's in the audience?
echo "/tmp/.ICE-Unix should be owned by root"
sleep 5
Speaking as a certifiable Python lover... I hope they're just using Python as a development langauge with the intent to switch to compiled C later, once the design solidifies.
Other people have already observed this locks out embedded applications; if this is the intent then eventually the C version would be available to all, in a shorter period of time.
Also, just as a general feeling, that seems like a very heavyweight startup procedure for something that ought to be done as files dumped somewhere with a simpler interpreter for booting. A complicated interface can later be implemented on top of that for remote management or whatever while the system is already on and running, but the stuff needed to actually boot up should be as stripped down as possible, and I just don't see why all that other stuff should be there at bootup. (This would allow other motivated developers to create other methods of manipulating this data, instead of locking it away in a monolithic, non-UNIXy, inaccessible format.)
I don't know any more about the system then what I see on the gnome.org page, but that's my call: Head for C and keep the data firmly seperated from the manipulation so others can play too.
I reboot every over month. Sometimes theres a power outage. Sometimes I upgrade my kernel. Once the FS is journaling, boot times are more than managable.
/bin/bash to /usr/local/bin/bash. Works real well provided /usr is mounted.
Also all the dependencies you add to the boot process have to be on the root partition. I had a friend who upgraded bash once and his system wouldn't boot. Apparently he had a symlink from
One of the links in this headline has been pulled, and replaced with a simple link to the goatse man.
Folks at work, watch what you click in this story!
Either someone at freedesktop.org is dicking around, or someone hacked freedesktop.org.
I would agree that the init system in general could use an overhaul, however, the idea of writing a replacement init for "*Linux*" in Python is not going to fly. Maybe a replacement init for Red Hat, Suse, Mandrake, or other large distro.
Neither of my distros will benefit in the slightest from this sort of system. Coyote Linux and the Wolverine Firewall and VPN Server use a busybox init application. Coyote fits on a 1.44Mb floppy and Wolverine installs in 7.5Mb. This would not be possible if either system's init relied on Python.
The embedded Linux market will have no use for something that requires a Python interpreter. Not to mention, Bash shell scripting and Python source code are very different animals. Having to learn the basics of shell scripting to reconfigure the way your system boots is a far cry less complex than having to learn Python.
As an embedded Linux developer, this project gets an emphatic thumbs down (as do most interpreted programming languages, though). They have their place in larger systems, but "Linux" is no such system, it is just a kernel. If he wants to write an init replacement, he should target a given set of distros, not the kernel itself.
Welp, looks like the DBus project page has been compromised -- visiting it contains a link saying 'This file has moved here', the 'here' linking to goatse.cx. Anybody have a mirror of their site?
And they don't even like it, so let's not start assuming anything about our particular member of the Bourne family.
Besides, Bash is rather bloated and doesn't implement a few important features. Why can't we all just use ksh93? It is really better.
"There was an interesting idea posted on slashdotregarding using make to handle the boot process (Parallelize, and dependency handling) The original slashdot post is here."
Who are the morons moderating this off-topic? Now my current post is off-topic. The parent though, is quite on-topic. Gentoo reproduces most of these features.
AAAAIIIIEEEEEEEE!!
Since several GNOME people are involved in these projects, I assume they had good reasons not to go with CORBA. After all, GNOME uses CORBA extensively, so they probably had bad experiences with it.
Unless of course KDE would block the use of CORBA since that's what GNOME does...
I use the old Bourne scripts for just about everything because 1) they work. 2) They run on ANY *nix system in a consistent way. 3.)they don't require a lot of work to maintain. 4.) they're portable (excluding things like ps -ef / ps -aux).
... ad nauseum to realize that problems do happen and if you can't manage things at a TTY level, you can really have your hands full.
Any new run-level mechanism needs to have ALL of the functionality that the current init/simpleinit/telinit have. You need to be able to monitor them from a TTY device - not a bitmapped GUI. If it works well, and can be edited with a WY50/VT100 type interface, can be monitored on-the-fly, they it can be usable.
Adding fancy stuff to a boot-up routine doesn't make any sense as its just more stuff to deal with during boot. Keep it as simple as possible.
After almost 30 years playing with *nix systems, I've seen enough problems from V7, Sys5.0, BSDx.x, SunOS, Solaris, Ultrix
Banjo - The more I know about Windoze, the more I love *nix
ETLinux replaced init several years ago with an entirely scripted version. Different scripting engine (Tcl instead of Python) and for different reasons (keeping an embedded Linux kernel tiny.)
... added Tcl equivalents for some common syscalls and services: sys_dup, sys_exec, sys_fork, sys_kill, sys_nice, sys_pipe, sys_reboot, sys_sync, sys_wait, sys_chmod, sys_umask, sys_mknod, inp, inw, outp, outw, setleds, mount, umount, uudecode, uuencode, time, ifconfig, route, udp. The introduction of these commands allowed the rewrite of the initialization scripts in pure Tcl, avoiding the inclusion of large binary programs.
Making this happen was that the ETLinux folks
More on ETLinux architecture here.
My x86 box is an Athlon XP 1800 with 1GB DDR and a 40GB drive split evenly between Win XP Pro and Red Hat 9. Win XP on this machine boots easily twice as fast as Red Hat 9. And by boot, I mean the desktop is fully loaded and ready to use (both machines auto-login). Even after disabling all of the non-essential things being started by Red Hat's default install, the Win XP machine still boots faster, although by much less. Then again, I don't have any extra crap (tray applications, typically) starting up with Win XP besides AIM.
;-)
And even though its Linux, some of us turn our machines off after using them, so boot time does matter.
Perl - $Just @when->$you ${thought} s/yn/tax/ &couldn\'t %get $worse;
In my day (2000, yes Y2K) we had to toggle in our bootloader on the switches on the front panel of our Honeywell 316 at our nukular powerstation and then boot the OS off of paper tape.
yes, change is scary. why mess with what works? if the project fails miserably as many would hope then great! no one will use it. but hell, you never know, maybe it'll be useful. just because something's been around forever doesn't mean you shouldn't try to improve / replace it. i wish the guy luck.
Did anyone else happen to see the "This page has moved here" with a link to goatce on the FreeDesktop.org D-BUS page!? I hit the refresh button and now it's gone!
...next to xinetd under "Complex Replacements For Simple Things That Don't Need Replacing" (one of my aliases for /dev/null).
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
It needed saying.
If two programs don't need one another to run, but they sleep a long time waiting for i.e. network resources, they can both be started at the same time. Running all non-interdependent tasks in parallel speeds init times, because while one daemon is sleeping another can be doing its thing, rather than starting everything serially.
Parallel initialization is nothing new. This is something we were working on for U4X back in the day. Too bad U4X never took off; all of us developers had school and work to keep up with.
A solution to the problem with music today
Also worth a look:
r y/l-boot.html
http://www-106.ibm.com/developerworks/linux/libra
in PYTHON?
...
...
man, i am doing my best to ban and bar any and all python from my systems
i dont want a lot of different scripting languages on my system
it get so bloated after a while
python, ruby, blah blah blah
shell and perl is all i want on them
man, i cant wait for parrot
and I think this is a bad idea.
The less stuff my computer has to depend on to actually boot, the better. I like the fact that relatively modern Linux systems can still run effectively on old hardware.
My python library is about 62 megabytes in size. Are we going to create a separate boot-mode python that is minimal? In my opinion, we've just taken out one of the best features of python: All that cool stuff that comes free with python. In addition, now I have two python install to maintain. If not, I run the risk of upgrading python making my system unusable. Not likely, but not zero probability, either.
As much as I generally hate shell scripting, I'm happy to do it for init.
I'm not too sure about the choice of Python, though, seems awfully high-level and library encumbered for something that likely has to run before many filesystems containing libraries are fscked and mounted.
I tought I was courageous when I decided to go with C++. (But it did allow me to write very flexible code while keeping it clean).
-- MG
PS: My daemond is blindlingly fast, but not known to work on any box except my own. I'd enjoy people trying it out and seeing how it breaks, but don't rely on it just yet!
Another fork in the linux kernel tree -sigh-.
"ServiceManager" sounds like it came out of Redmond.
"does a check on SomeService's dependencies.."
Tell me how that is going to end up being simpler than init and scripts in place now. If ServiceManager ends up being written in C, it's going to need initialization/configuration in the form of text files - or something!!
What do you mean "as soon as X is runnable we start GDM" ? A lot of us run servers, don't even use X and want defaults to default to NO X.
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 :-)
Some of you may not have written your own dists, so here is a breif overview of why this is the stupidest thing I have heard in a very long time.
1) Bootloader straps a kernel
2) Kernel mounts a filesystem ro, and loads init from it
3) init forks a single shell
4) that shell launches everything found in the inittab
5) that shell then procedes to run your init scripts
From that shell what you do is up to you.
In single user {runlevel S/s} you stop at #4, and start from that shell.
Any other runlevel will be started from that shell. It doesn't matter if your scripts are written in perl, csh, sh, php, tcl or python.
It doesn't even matter if you write them in a language that you can compile for extra speed.
99% of your time is in loading the interpreter, and waiting on the daemons themselves.
sendmail is extremely slow on loadup, so are other apps. Try setting dhcp, and having it time out.
or RedHat's retarded Kudzu tool.
Calling those from a faster interpreter, doesn't make them load or run any faster. It never will.
If you think runlevels aren't important... Try patching a running system sometime.
-- Sir Ace
The wonderful thing about open-source software is that someone can rewrite init in python, and the rest of us can laugh at them. Everyone wins.
WARNING: there is a trojan on your
Ask every Windows user in the world why they are not using Linux and ...
Some will say they need better office apps
Some will say they need better device support
Some will say they need more games
Some will say the desktop should look sharper
Not one will say that Linux needs a better init mechanism.
This is a totally pointless project, let's ignore it and hope it just goes away.
Dude... Slackware's init system is not excellent. It's a mess! You add/remove things to/from startup by editing the startup scripts themselves! It doesn't even have dependency tracking. Yeah, Slackware's supposed to be "leet" and all, but it's not the init system that makes it so.
Gentoo's intelligent SysV-based init system is much more useful IMO.
A solution to the problem with music today
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
Sure, lets increase the start-up time by 20+ seconds while waiting for a vm to load in an attempt to shave off 5 seconds from system start-up.
Just use C.
See C run.
C be good.
Init Replacements
I say we just 'borrow back' SystemStarter from Apple/darwin.
It's got everything most people want and it's massively field tested. 'Not invented here' is its main problem.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
for a "tivo box" you can get quick startup times by starting your tivo app before anything else.
If you want a fully bloated User Friendly GUI, then of course it'll take longer to boot! Most Linux distros are anything but a minimal "weenie" gui coupled with some card games and a DOS-era text editor or two.
Try building everything unnecessary as a module, loaded after your UI starts, and make the UI as high a priority as possible.
Also look into hybernation, whereby a minimal kernel loads a ram image from a booted system and lets it go.
You can't judge a book by the way it wears its hair.
What happens if Python gets an update and has a major bug. Will the system never boot again?
WTF?
What's the point in this? We can already get linux to boot in under a second using various tweaks. Why do we need more speed than that?
Additionally, what's the point of making a functional and simplistic design such as the current init more complex? It doesn't need to be more complex to do what it does. It starts your computer and the processes.
The design is flat for a reason - it doesn't need to be anything but flat. Reimplimenting it is about as aburd as using PowerPoint for a bulleted list of things you need to accomplish in a day, when notepad or a pad of paper will do just fine.
Most linux systems reboot, what, once every month, if that? (desktops varying frequency, of course) Seems like a hell of a lot of effort for nothing.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
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.
so if python is too complex/difficult for you, what would you call elegant?
perl? c? c++? bash? simple/clean?
HAHAHAHAHAHAHAHAHAHAHAHAHA... nice one!
come on, this is so sad, he addresses the need for the change in the FUCKING ARTICLE. init is confusing, archaic and slow as hell to start. there is NO NEED for a modern system to take 2 full minutes to startup, with this new idea it could take 15 seconds.
he has a well thought out system of dependancies... so if your services needs to wait for other ones to be started, make them depend on them. problem solved.
Actually, this could also potentially lend itself to encouraging GUI designers to allow for more customization outside of just themes (colors and skins) and give administrators the ability to specify "enterprise" wide common controls without going through painful middleware processing and ugly hacks.
Or... this could all just end up making GUI designers create more unintuitive and hardcoded crap that can interface with multiple GUI's, who knows?
python is a great, powerful language. its small and light enough for the job... so why shouldn't he use the right language for the job? surely he shouldnt because luddites like you refuse to admin its *2003*
People complain that Mac OS X can't be Unix because it doesn't use the same init routines as other Unixes, so it's a lame operating system. But when someone tries to change the Linux init, suddenly it's cool and bold step forward.
It reminds me of the PC users who complained when the iMacs shipped without a floppy drive in 1998. How can you have a computer without a floppy drive? (Never mind that iMacs had integrated modems and ethernet controllers when ethernet cards were $50 add-ons for new PCs.) But when PC companies started doing the same thing 4 years later, suddenly it was a great step to throw away useless legacy systems (even though it was really just an attempt to squeeze out and extra $5 profit per unit).
jesus christ, you people are all morons, can't you fucking read??? this is pathetic.
In short: it is an insane and heretic idea, that can only be bred by evil plans or by ignorance.
Which, of course, means that lots and lots of people will leap on it and exclaim "Great Sega! Why hasn't this been done before?!"
Of course, insane and heretic ideas frequently become a great and wonderful thing. Christianity? The automobile? GPL?
Food for thought.
To celebrate the occasion of my 1000th post, I will post no more forever on Slashdot. Goodbye.
that *of course* X is not required, and you can choose what order things boot. but reading the article would be too much to ask, wouldnt it.
gosh, having python installed is such a burdon.
I have a serious hardware problem. I run Linux on my laptop you insensitive clod!
I signed up for a
Don't like it? Then don't use it! That seems simple enough to me.
It's not like init is just going to disappear as soon as something newer comes out.
0 1 - just my two bits
could we for just a second think about compatibility ?
if you have something better than sysV init procedure, that nice and sweet, but I dont give a shit as long as you dont provide a proof of superiority by sheer compatibility.
embrace and extend, not such a bad idea. The difference is only between the kiss of death and the kiss of love.
While boot time may not be an issue for servers and some desktop users, it _IS_ an issue when it comes to laptops. Laptops and other such devices are the future of computing for the masses and boot-time (boot to GUI) remains a bottleneck with these devices. I have a fairly powerful laptop. Even with all the boot-time optimizations with mandrake/redhat, it still takes much longer to boot compared to XP.
I just put everything in rc.local
Gnu's Not Unix. Linux Is Not UniX. RMS said in the GNU manifesto that copying Unix is not essential, and GNU will have improvements where appropriate.
Escher was the first MC and Giger invented the HR department.
"The lesson to be learned is not to take the comments on slashdot too literally." --Vinnie Falco, BearShare
Right. Starting python's "Virtual Machine" takes an ungodly amount of time, I mean, look at this:
Here I am on my machine, there aren't any python processes running.
jrodman@Skonnos:~> ps aux |grep python
(Yes, there could be tools written in python which don't have it in the process name, but there aren't.)
Okay, here's my python program:
jrodman@Skonnos:~> cat test.py
#!/usr/bin/python
print "hello world"
Okay, here I am running my program:
jrodman@Skonnos:~> time python test.py
hello world
real 0m0.050s
user 0m0.040s
sys 0m0.010s
Wow, you're right, it really does take 20 full seconds to start up a "virtual machine". Well, maybe 1/20th of a second. Close enough.
-josh
If you run a tight system, every package is a burdon, and a quantifiable risk. I don't want have to keep track of any more patches than I need to.
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 !
So you're saying that the big complicated scheme this story is about could be skipped if the kernel let you play Tetris while it booted?
It is trying to innovate past the ancient Unix ways, and it shows a willingness to look toward the future instead of stagnating in the past.
IBM tried once and failed, but that doesn't mean everyone should just give up. One of the several open-source init replacements available today (or in the planning stages) will eventually turn out to be better than kludgy old Unix init, and it will be replaced, as it should be.
Personally, I hope that within 10 years Linux will hardly even be recognizable as a Unix anymore. If Linux stays exactly like Unix forever, it will never be able to become the next-generation operating system we all want to use. Unix isn't the best possible operating system, and Linux has the potential to become more than Unix ever was.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
New stuff is nice, and to those who call this bloated, do you realize that the current system is pretty bloated as well? *gasp* *shock*
using shell scripts that execute a shitload of commands means a bunch of (unneeded) processes are started up at boot up.
now this new system looks bloated as well, here's the thing, why not fix the current init system?
instead of using shell, use C binaries instead, but have a package that has the C sources for these binaries, be much faster and efficient. wouldnt hurt at all.
this systemservices thing looks nice, but for some reason, the term "microsoft" comes to mind when I see that name.
of course we're trying to pull away fro the whole SCO deal too to make them really look like jackasses.
personally, I think ths should replace init on "desktop" linux systems, for sysadmin and hardcore geek systems, regular init should stay, or at least tinkered with, it hasnt changed much, it should be changed.
think it's funny how he uses redhat as an example, redhat isnt a good example for anything, he should look at slackware or debian.
whatever, I have a headache.
psch. we are talking about one package of 4 megs here, if thats a big deal to you, you are clearly incompetant.
I like the MacOSX init sequence myself. Plus, you don't have to replace init. They did it the right way, change what init does, not remove init. Leaves room for embedded systems to have lightweight init sequences, possibly with init calling everything itself, or complex boot sequences for desktop machines. Remember, the black boxes are there for a reason, it makes replacing each part that fails a LOT easier.
/ Co nceptual/SystemOverview/BootingLogin/chapter_4_sec tion_2.html#//apple_ref/doc/uid/20000981/TPXREF106
http://developer.apple.com/documentation/MacOSX
One Token Ring to Rule them All, One Search Engine to Find Them, One WAN to bring them in, and TCP/IP Bind them...
Of course, we do get new wheel designs all the time. Sure they have the same basic principles (ie they roll) just as this new init system has the same basic principles (it starts things up).
But wheels today are radically different to those 3000 years ago. They are different from wheels of 10 years ago. They will be lighter, more efficient, provide better grip or in some other way be better suited to the task they perform than the wheels that have gone before them.
It's called progress and it is desirable.
Boffoonery - downloadable Comedy Benefit for Bletchley Park
Wow, we can even store all configuration information in a non-human readable format!
Then all we need to do is add a default mode to fix problems with this 'registry' and fallback to a backup registry.
Oh wait, someone has already done this and it sucked.
Damn, I guess we can overcomplicate using python. It's just one more scripting language for us all to learn.
Wooooooo.......Whoooooooo!!!! Another resume bullet point.
Kernel Guys, please make this optional if you every put this in a release kernel. I'll just stick with what works.
python isn't minimal.
[/usr/local/lib]$ du -hs python2.2
39M python2.2
Comment removed based on user account deletion
Java and Python aren't even in the same league as far as these things go. Python is 870k and depends on 7 standard libraries. The JavaVM comes with a 75MB libs directory. Python takes 0.007s to give me the usage message. javac takes 0.264 seconds, even with a warm filecache.
A deep unwavering belief is a sure sign you're missing something...
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.
The SystemStarter process that Mac OS X uses is based on the Next init/rc system which is similar in principle to how FreeBSD does it's init/rc system. Since it's part of Darwin it should be available under a BSD license. I'm sure it could be rewritten to use X rather than WindowServer for it's graphics.
I think that's a more worthwhile replacement for linux's init/rc system IMHO.
Link
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
Did you see the story about that, where the Tories sent out a press release saying exactly what's in my sig? They meant it as a joke, but it's pretty over the top....
7 November 2006: The day Americans realized corruption and incompetence weren't addressing 11 September 2001
Goddamnit Stallman, manpages work fine and can be parsed with a text editor. Info was a solution in search of a problem. I shouldn't have to learn yet another tool to read the fucking documentation.
No more info pages that have more information than the man pages!
dumshite
As someone else noted (in an article with a link done as text, not as an , and with an extra blank in it), Mac OS X has a possibly-interesting scheme for starting and stopping system services. Here's the section on System Initialization in the Mac OS X online documentation; in particular, look at the Startup Items stuff.
It's a dependency-based scheme, like at least some of the other proposed system services mechanisms; see the section on adding your own startup items.
Note also that Boring Old Init isn't itself changed; /etc/rc runs SystemStarter as its last act, and that starts up the system services. SystemStarter can also be used as a command to start, stop, or restart services, so this isn't just a system startup mechanism.
NetBSD 1.5 and later have a new rc-based system for controlling services; it's also dependency-based. FreeBSD 5.x has rcNG, which is derived from the NetBSD scheme.
(Note that all of those systems have a BSD-style init, and thus don't have run levels.)
Those schemes don't address one of Seth's complaints, however - according to his description in his blog, he doesn't like having shell script wrappers doing the configuration, he wants it done in the service's process itself:
(I express no opinion on this one way or the other; if you like or don't like the idea, send bouquets or brickbats to him, not me.)
Note also that it appears that he is not designing something just for desktops - in particular, he says:
Now, whether the kernel should start ServiceManager directly, or whether it should continue to run init and have ServiceManager started from an rc file, is another issue; I'm not sure that there's a compelling argument to eliminate init other than to discourage people from continuing to use the current rc script scheme (which might be Seth's motivation for running ServiceManager as process 1 - he might want to discourage rc script tweaking).
Perhaps one of the reasons why people thought of ServiceManager as being purely for desktop systems is that they thought that, as D-BUS is somewhat associated with freedesktop.
the problem is that now I have to have python installed with all of it's megs of space just to run the fscking init. I was bad enough that I had to install perl for this a while back. Pretty soon I'll need a 60G drive to install the base system. Hmmm, sound like another OS I've heard of.
Point was made repeatedly about elevators and XP:
Does it really matter if the boot process is fast, or should it simply appear fast?
Here's the simple one:
First thing init should do is fire up X with a login prompt. Start everything else in the background. By the time most users have entered their credentials, the other services have started up.
You'd probably gain 30% speedup. With no need to rewrite the init system.
Assorted stuff I do sometimes: Lemuria.org
I solved the "3) start X and allow login ASAP" problem by taking advantage of the extreme flexibility that the ancient, limping, oh-no-it's-not-a-gui-it-must-die init procedure gives me by moving S90kdm to S21kdm.
1) sounds like gibberish to me, even after reading their site.
2) would be interesting to see.
4) sounds like (1) repeated.
What's the quote? "Those who do not understand Unix are condemmed to reinvent it, poorly."
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
From the OSnews article:
Could someone, preferrably someone who is a sysadmin, and preferrably someone who is confused, and most preferrably someone who is both a sysadmin and confused, please explain why this is confusing, to one of those "not all" sysadmins who is not confused by runlevels at all?
now we need to go OSS in diesel cars
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
A new init, Storage, HAL, D-Bus ... seems like we're looking at stage where the GNU is about to undergo some major overhauling at every level. So will Y Windows find a place in all this?
Linux users absolutely resist any change or progress whatsoever. They claim they are open-minded and free because they use an alternative OS, but when it comes to actually improving and moving forward by doing things differently, people are vehemently opposed and quite happy to use aging protocols like X11, etc.
"Sufferin' succotash."
Like the idea, but hate the consequences. Doing it in Python will force Python on the root fs. If you like reliability and the ability to recover from disk crashes, thats a big no no.
I wondered why it was called the "aging" init procedure, so I did some checking. Sure enough, it was the oldest process on my box! I guess they were right! (Who'da thunk it!)
Just as fucked as the stupid idea to reverse the ok/cancel buttons in gnome.
Seth should go and study krill or something, and leave us alone.
Python-based init? Hey, i don't think SysVInit it's
the best init out there, and there are other init
clones that are smaller and faster, but the last
thing i want is init DEPEND o Python. Whoaa, i don't
know what these guys are thinking when designing
new software...
>You add/remove things to/from startup by editing the startup scripts themselves!
That's a mess? Only if you choose to make it one!
Man, I don't understand these people either. I learned linux on Slackware, saw Sys-V inits for the first time, and almost lost my lunch. It's a really great way to use 10 lines to accomplish things that can be done in 1.
Also, why are people so afraid about actually editing their own startup scripts? I thought that was part of what linux was about.
I guess this is what I was trying to convey with my original point. Init is a system that calls shell scripts in a defined manner... When it comes to doing that, it does great. Performance of the scripts it is calling should not factor into the decision.
Why are people so hung up on boot speed?
Because leaving a notebook computer on all the time is a waste of battery power, and coming out of hibernation takes even longer than booting the darn thing much of the time.
Will I retire or break 10K?
How about some action instead of talk?
When I use a simple shell script as init, it is faster when I start daemons serially as opposed to in parallel (which is very simple in a shell script, just use &).
This is probably because the disk scheduler can work much better in the serial case, because it is much easier to anticipate what will be read next.
That's my fact. What is yours?
cd /etc/rc.d/rc5.d
mv S90kdm S21kdm
If you don't know the first thing about what the Linux init system is or how it works, why the fsck are you contributing your total lack of knowledge to the discussion?
And please don't tell me the above two commands couldn't be wrapped in a GNOME GUI shell just as easily as the proposed Python init replacement.
For starters, you don't need all of python installed to run a python program, there's a python compiler which can bundle all the necessary components into a single executble file. So we can toss that argument out.
But more importantly, this is a straw man. The problem was that the grandparent was spewing nonsense about VM startup times that had no relation to reality, which was disproved. I don't like this idea of an init system any better than you do.
The problem isn't python, but sysadmin-unfixable binary network interfaces and a lot of sysadmin-inaccessable frameworks without a clear explanation of any particular benefit.
-josh
According to a section from the GNU Coding Standards, the GNU system is supposed to be a BSD clone: "With occasional exceptions, utility programs and libraries for GNU should be upward compatible with those in Berkeley Unix" in preference to System V. So now that *BSD is free, has the GNU OS project (apart from GCC, which *BSD uses) lost much of its reason for being?
Will I retire or break 10K?
And when used with a good pager, they'll work with the vi command set
The w3m pager/WWW browser has both Emacs-style and vi-style key bindings.
I think info was an attempt to force book-sized documentation into a man-like interface.
True, the structure of a manpage limits the amount of detail in documentation, and Mr. Stallman was tired of having the system's detailed documentation tied up in expensive printed material. Info solves this problem by providing book-length electronic documentation with chapters and hypertext links.
Once the information threshhold of a man page is surpassed, the timesavings of info over other documentation methods is debatable.
Though HTML and DocBook now solve the same problem as Info, they weren't widespread when the GNU team designed Info. The Texinfo system can now generate HTML if you prefer to read your manuals in w3m.
Will I retire or break 10K?
So you know what "moving S90kdm to S21kdm" means? I'm very happy for you, but I don't, and I don't want to have to care about that sort of thing.
Then run a GUI tool that reads /etc/rc.d/rc5.d and lets the user drag daemons across a timeline to start earlier or later. I don't know if such a tool exists, but creating it would be a good starting point.
Will I retire or break 10K?
Honest query: make allows me to handle all build dependancies, and is able to parallelize its operations to make efficient use of an SMP system. (ie perform multiple build operations @ the same time)
So, it can handle dependancies, ensuring a necessary daemon loads before its dependant does, and can also dispatch commands to start operations that do NOT have a load dependancy.
My only 'issue' with init is that you can't specify that daemon A requires daemon B to be loaded first. Sure, it does have a load order, but there's nothing to stop you from being stupid and changing the order (guilty), and no way to really know if the way the init is ordered is necessary, or simply arbitrary.
A simple makefile can at least provide a language to show dependancies, clearing things up.
At least reading the basic makefile syntax, this shouldn't be overly difficult...
-- Sometimes you have to turn the lights off in order to see.
You'll also hear some people claim that the World Wide Web belongs to the Beast, making reference to WWW == VI VI VI == 6 6 6. But actually, the number of the beast is not the vector [6 6 6] but rather the scalar 600+60+6.
Read More...
Will I retire or break 10K?
IBM has an article on using make to parallelize your init scripts.
If someone is passing you on the right, you are an asshole for driving in the wrong lane.