“For a long time, Linux has been blamed to boot slowly, compared to other modern operating systems. In this article, we are going to focus on a new init system we developed for our Pardus Linux distribution, Mudur, together with other initiatives that are worth mentioning. Mudur is written from scratch in Python with simplicity, speed and maintainability in mind. It isn’t a replacement for the /sbin/init command like some other alternatives, nor just a parallel script executor. Mudur greatly simplified our boot process, making it faster and more flexible. Authors look forward for future boot process research for further improvement and optimizations.”
Reminds me of Lcat for Accelerated Knoppix. All the hoopla is now gone like a fart in the wind.
Maybe I missed it but as I read it all they’ve proven so far is they had some heinous scripts for the first version, hope they do better this time. Here is a set of boot scripts for simpleinit, pure shell, no awk, no sed, boot like a rocket in parallel, 1382 lines total, don’t see re-writing it in python as making the kind of difference they’re hoping for but I really look forward to future metrics. Python would seem a fairly big dependency just to boot up, wouldn’t expect to see that in embedded systems where boot time is really life and death super critical, workstations really aren’t that bad off once you dump sysV. I’d make some more improvements like getting init scripts out of /etc and up in /sbin out of user reach too.
http://gnnix.org/base/root/dist/usr/src/gnxbootscripts-0.8/sbin/ini…
“Limiting Resource Is IO, Not CPU”
Quite wrong. People has already (Suse, etc) tried to preload absolutely *everything* ie: optimizing the IO as much as it could be optimized.
Result: The system still was booting up slowly. Reason: even if optimizing the I/O gains a lot of seconds, what makes linux be behind windows/mac os x in this field is the fact that the linux bootup process is just doing way too many things. Not just in the scripts, but in X.org, gdm, gnome, etc. Pardus can’t make fast slow software, and many software that is used in bootup is slow in the linux land. See the “why userspace sucks” talk from dave jones. This is why people is optimizing gnome’s startup, etc.
Well, they did get boot time down to 17 seconds, which is comparable to what systems like InitNG often get.
“””Well, they did get boot time down to 17 seconds, which is comparable to what systems like InitNG often get.”””
Well, none of ther other 15 sys5init replacements has ever taken off and gotten used to any great degree.
The solution is obvious: Bake up another one.
We do need *something* better than sys5init.
But unless they have something really compelling, like this is not, it’s just another voice in the cacophony.
Canonical’s “solution”, Upstart, is just too pie in the sky for my tastes. So much of what they are trying to do would be a “solution in search of a problem”… except that their solution to the elusive problem doesn’t exist yet and won’t for a good while.
initng always seemed like a good solution to the real problem to me. We need a parallelized boot process. It’s not like SCO Openserver has not had parallelized boot for *10 years now*! If SCO can do it…
There’s no need to finish that last sentence, I hope.
Canonical’s “solution”, Upstart, is just too pie in the sky for my tastes.
I didn’t think much of it either, at first, but the more I hear about it the more I think it might actually have a shot at being widely adopted. It’s the first one being backed by a major distro, and more importantly it is backwards compatible.
I rather like Pardus, although it is nothing new or revolutionary. It will never be widely used, though.
I’m an Ubuntu convert and a Canonical fan. And I thought Upstart was too ambitious, at first. Then I started reading more about it and decided that, although overly ambitious, it was a good idea.
And then, after reading the latest propaganda, realized that the focus is on solving problems that have already been solved quite nicely with DBUS and HAL.
We need a parallelized boot. Good solutions already exist. Canonical is inventing problems that do not exist in an attempt to sell Upstart.
Edited 2006-10-07 01:39
Wrong init replacement?
The problem isn’t that we do not have plentyful of really, really good solutions as how to solve paralel boot process. We can run them in paralel, we can satisfy dependencies, we can go event-driven, all this has been thought of and done.
What is the real issue then?
The real problem is the huge momentum sysv init scripts system has. You have thousands and thousands of applications basically conforming to one standard approach; a dumb shellscript taking parameters in argv and starting stuff accordingly.
What’s wrong with this?
Firstly, shell sucks, performance-wise. We all know it. Of course, this part belongs to the Utopia land, but it’d be really nifty if it was rewritten to some saner language, preferably nothing like perl or python (which are just too impractical if they need 1MiB+ to work).
Second, linear startup sucks, too; we all know it and that’s why we want paralel startup, obviously. However, paralel startup won’t – ever – work with the current setup. Therefore, no matter what init system wins the general popularity contest in the wild, the init scripts will have to be adjusted. All of them, or at least all that are generally used. Can you imagine the ammount of manhours necessary?
Now imagine a whole distribution migrating… I am not saying it’s not possible, I’m saying it’s a huge pain in the ass and you’ve got to get a lot of people pulling together in one direction, which is something you do not see often in the world of opensource in general and Linux in particular.
They are starting to touch features not seen but in professional and commercial level OSs.
Boot time and I/O Wait Times are one of the most important performance areas all linux distros should concentrate on; then they should concentrate on HDD file system then Networking Performance via smbfs (or cifs).
These things feels snappy on windows compared with linux; but It’s not a big deal for non professionals who are not much demanding.
Nice move from linux world, and I wish every linux user a happy computing day.
These things feels snappy on windows compared with linux; but It’s not a big deal for non professionals who are not much demanding.
I think you got that mixed up. Professionals don’t give a shit about whether their system boots up in 30 or 60 seconds. Non-professional kids do.
>> I think you got that mixed up. Professionals don’t
>> give a shit about whether their system boots up in
>> 30 or 60 seconds. Non-professional kids do.
I agree with that on desktops, in fact it’s a good point in that realm – but I’d argue it on servers. Downtime, ANY downtime is bad, yet there are still times where the only REAL answer, even in the *nix world, is a good old-fashioned reboot. When you are doing “shutdown -r now” across an SSH session, every second that server is down for reboot is a nail biting, white knuckle, please let it come back up nightmare… Especially if you have any sort of traffic that’s suddenly IM’ing you en-masse “Did the server just go down?” despite a mass e-mail and announcement on the site(s) every day for three days.
they lost me in the part that says, it will improve application launches too, post-startup!
what r they saying and how is this possible, do they mean to cache most used apps like win_xp does?
/*Boot time is shortened only a bit, but since it can cache not only boot process but user session as well, typical launch time of an application like OpenOffice.org from cold start of the computer is significantly improved without even using preloading*/
Something done in Python, an INTERPRETED LANGUAGE, is faster than the alternative?
Sigh… That can’t be a good sign.
Sorry, but the last thing I saw this disturbing was with the whack-jobs claiming java could be faster than machine language. IF it works, it brings to question the entire boot system, to the point one begins to wonder if you wouldn’t be better off throwing it all out and starting over from scratch…
But then, I believe BeOS proves that about other operating systems every time it boots.
Edited 2006-10-07 04:34
“Low level languages like C or C++ are fast but also suffers from maintainability problems. Source codes become even bigger than shell scripts, and development time significantly increases”.
This is why they have chosen python.
suffers from maintainability problems
I think that argument just will not compute for even the greenest, ‘C’, rube.
The limiting factor with init was not the amount of CPU time the program consumed but rather the way it operated. Even if this program takes up 10x as much CPU/RAM it won’t even notice. Yes, a C/C++ program would be faster but not noticably so. That’s just not the issue here.
Well, the difference is this:
The current sysvinit script do a lot of stuff to deal with all eventualities. (checking the environment, creating directores …)
If they simply exec’d the binary (as pardus and other alternatives like initng mostly do), standard sysvinit would be much faster too.
I don’t want to discredit the new pardus init system, but each init replacement which does not provide good backwards capabilities is imho doomed to fail.
No major distro will bet on it (think of 3rd party apps like vmware, oracle etc.)
This is definitely a strong point of upstart, it uses the current sysvinit initscript and allows for a gradual transition.
> Something done in Python, an INTERPRETED LANGUAGE, is faster than the alternative?
>
> Sigh… That can’t be a good sign.
You do realize that the normal Linux init system is using the shell which is also an interpreted language?
As for you Java rant, there have been research done by HP which shows that in certain case, a JIT compiler can beat a normal compiler, you can search for it ‘HP dynamo’.
As for BeOS, yes it was great, but it is booting less and less often in the world these day.
Sorry, but the last thing I saw this disturbing was with the whack-jobs claiming java could be faster than machine language.
I think the keyword is Dynamic or Adaptive optimization. See http://www.hpl.hp.com/techreports/1999/HPL-1999-77.html
Contrary to intuition, we demonstrate that it is possible to use a piece of software to improve the performance of a native, statically optimized program binary, while it is executing.
From this it isn’t far fetched to think that Suns ‘HotSpot’ would be capable of a similar feat. (theoreticly speaking, I have no clue as to how performant Java is).
the Python install get’s borked. Oh oops you can’t boot now. This is a big downside to tying core system utilities to interpretative languages, you may get the power of those languages but at the cost of another dependency.
Good point, by making it a dependency it now should be statically linked and live entirely in the root filesystem like bourne shell too.
Well there is *always* a dependency for the startup scripts be it a libc, a shell, Python, etc..
And usually you use a *different* shell, Python for the install than what is used by the rest of the OS to avoid being unable to boot the system in case of error.
Why bother with scripts at all then?
Packages could put staticly linked init binaries in a particular place in the filesystem providing the required interface for init to handle them.
Or they could be modules loaded by the init process to do its job…
I use the old style init system and have got it to boot in 19 seconds, through various tricks. I simply ensure the KDM script is one of the first scripts to start, so it boots into X early on. The network script is put in the background. By the time I have logged in and the desktop is ready to use, the rest of the scripts have loaded. I also noticed that mounting a reiser3 formatted partition was taking about 4 seconds, where as ext3 would take about 1 second. I’ve not once had a problem, since making these changes. While doing all of this isn’t really speeding things up, it does allow me to get on with logging in and loading the desktop while the rest of the scripts are loading. I agree that Linux distributions need to look into using a new and faster replacement, but the changes above will do for me in the mean time.
Edited 2006-10-07 07:18
I am not sure what the metrics are for being a so called “professional”, but for me it is important that my laptop boots up fast when I am on the move. Does this make me a non-professional kid?
While speed is nice, I prefer stability over speed. After all, if my system boots up in 30 seconds or in 50 seconds is rather irrelevant for me, as long as it doesn’t crash and destroy my documents. IMHO we put too much “time-pressure” on ourselves and our operating systems without any reason. If you boot into the system 10 or twenty seconds or even two minutes later, what will happen? What will you loose? IMHO nothing.
Time is the biggest self-imposed slaver of humanity. (Uh… how philosophical!
)
Where does the myth come from that Linux boots slowly? I compared Linux’s and Windows’ boot times once, and it took half a minute longer to get to my Windows 2000 than to my Fedora Core 5 desktop (with all apps loaded). Only additional programs loading in boot in Windows were a firewall- and an antivirus-software.
(with all apps loaded)
Good point. Oftentimes, you get failry quickly to a desktop in Windows, but loading is still continuing for a while. Then if you add some server apps (smtp, ad, iis, mssql and so on) then it won’t be noticeably faster up then a Linux with similar apps.
A myth?
BeOS booted to a *usable* GUI in 15s on my old computer, on my (much more powerful) new computer it takes Kubuntu 6.06TS 1min to go from Grub to the login window + ~10s for KDE to start.
So Linux *is* slow to start, that’s a reality, who cares about Windows boot time? It doesn’t make Linux boot time faster or slower!
Thanks for your comments. After reading them, I wanted to clarify some issues.
Yes, Python seems a big dependency for embedded systems. But we are mainly focused on desktop users. Just like you build a custom kernel, you can build a lite python interpreter for such systems. Having same system boot on small embedded devices and bleeding edge desktop computers is an unnecessary constraint.
Customized shell scripts are not a good solution for us. Mudur is a generic system, which can handle harddisk, flash disk, live cd boots, different kernels, services, and configurations. It is used on Pardus distribution in production environments. First draft of it was bringing X in 2 seconds but wasn’t useful on anywhere other than my computer
@ashyanbhog:
You missed previous sentence. You start system with fcache in prime mode, login to your session, load up openoffice, then stop priming. Next time you boot up, openoffice will be loaded from fcache. This has nothing to do with mudur and can be used on everywhere with a fcache patched kernel. It has some drawbacks though, fcache currently only supports ext3 for example, and priming must be done manually.
And for last, we are just sharing results of our experiment with the community. It may not suit every distro out there. But for us, it works great.
First draft of it was bringing X in 2 seconds
But for what use since most apps can’t start in that short time.
“While speed is nice, I prefer stability over speed. ”
The subject is speed not stability.
But stability is an assumed prerequisite to speed. We want to speed up something that was otherwise running good and not change that something to such an extent that we have to restart and thus drastically increase the boot time(s).
Exactly, the subject is speed and the prerequisite is stability.
“While speed is nice, I prefer stability over speed.”
With reference to the above quote, nobody ever suggested people should sacrifice stability over speed. Some people just assume speed comes at the price of stability, without realising sometimes we find a better and more efficient way of doing things.
🙂