There’s a lot of work in Fedora now to try and fix init scripts. Adding dependencies, hooking up event systems, lots of shell scripting, etc. In the desktop case, why isn’t the actual solution to start up times just starting up less stuff?
Here’s what we’re going to do for OLPC:
- Boot the kernel.
- Start udev.
- Start d-bus.
- Start X.
- Start the UI.
Based on that how fast do you think startup will appear to be? When you need something started up you ask d-bus to start it. This includes things like avahi, network manager, printing, etc. For desktop, isn’t this the right direction to go? Hughsie is working on the d-bus startup patch and once that’s in we can start ripping things out.
I have a macbook. It starts in 25 seconds. Linux on the same computer takes 2 minutes. I don’t think that dependencies will help that.
-
I’m pretty sure getting close to that 25 seconds would require more than just starting less; such as filesystem block reordering.
-
Hmm, Avahi needs to be run all the time, not just when it is needed to be really useful. Avahi is a bad example for your point I would say.
-
Chris, I totally agree with you.
And aside from start in the sense of execute applications, I’d say that we should avoid linking or depending on such a huge deal of things.
I know I’ll never use LDAP, MySQL, PostgreSQL or Keberos and most of libraries, so why some packages do depend on such things? Same for init scripts, I won’t run NFS or crypto fs, or avahi… why systems keep thinking that I should use it?
If you disable these stupid things, recompile packages without useless library dependencies, you’ll get faster boot and execution.
IMO these things happen due distros trying to fit all and offering no flexibility at all. Ubuntu did start with a good focus, but is now a mess. Well, these days I run Gentoo, but I’m a power user with good machine so I can choose these things myself, but my non-tech mates still have to wait a bit to get their machines to boot and applications to start. I hope that RH, due OLPC work, start to reconsider its options.
-
Imho starting system services via D-Bus is a bad thing.
nuff said. -
If you want to do it even faster, it is possible. Hard wire the UI to start first and expand the functionality it can offer within the next a few seconds while the rest of the kernel etc is still booting. It would require some serious problem solving but there shouldn’t be any really hard reason why you wouldn’t be able to seem to have booted (from user’s perspective) in 2 seconds flat.
-
Avahi, NetworkManager, CUPS all need to be started at boot for functionality expected from a desktop to work. I guess we could wait to find out if there is a network card in the computer before starting these 3 and also a printer attached for CUPS (thats probably the only one that could even be debated), but most people do have printers, and many have it shared, so its expected that if you select to share the printer, its started at boot.
Do you really think your macbook doesn’t start its networkmanager and avahi equivalents at boot time? If so, you’re crazy… it just needs to be better parallelized (there should always be something reading from the disk, and a seperate process using the CPU if there is deamnd for it, we shouldn’t sit there and read the entire disk in one stage, then let it idle and use the CPU or wait on the network in the next one, etc. Thats why I think Upstart is decent solution, its going to do this. Its probably not a good idea to duplicate the efforts for no reason, Fedora and the rest of the Linux distros should get involved and contribute to the development of Upstart, so that it can be the best init system around, better then launchd or anything else.
Gustavo: What distro/packages depend on mySQL and stuff that don’t use it? File a bug. Unless you’re using a sever oriented distro, they shouldn’t include mySQL, postgreSQL, LDAP, Kerberos, etc let alone start it up in the first place until you install something that needs them.
-
Avahi, NetworkManager can all be started – they are all just started via D-Bus instead of being started before the graphical boot. The main trick is to make sure that the GUI gets up as soon as possible. Someone here mentioned starting things in parallel, that’s exactly what I’m suggesting. But getting the desktop up as fast as possible is the goal. And you don’t need a lot of stuff to get it started.
Regarding the I/O that walter mentions, yeah, that’s a good idea. But if you can push everything out to on demand services I’ll bet that what you have to load changes quite a bit. Still worth doing, but I would do the services first.
-
“The main trick is to make sure that the GUI gets up as soon as possible.”
Yes and no, I think. Windows XP gets to the GUI on my machine much faster than Linux does, but it’s more-or-less unusable for a minute or two after that, as it loads all the stuff it needs. It’s actually more annoying that way – with Linux, I know when I can start using the computer, because the GUI is usable when it (eventually) appears, but with Windows, I’m not really sure.
I’m not totally disagreeing with you, but I do think the issue is a bit more complicated than just “get the GUI up as fast as possible.”
-
Using Archlinux here is my boot process: syslog-ng @alsa hal gdm network iptables netfs @sshd @crond @avahi-daemon @avahi-dnsconfd @esd @dnsmasq @fam @mono @nscd @ntpd splashy
dbus is started in the hal script, X with gdm and ‘@’ means ‘do in background’.
-
Christopher: I totally agree with what you’re saying here. Ignore the trolls, we need this.
It just seems to me that the “blah” guy doesn’t get it. The point Christopher is making isn’t to start less. It’s when to start it: You don’t need a printer daemon running unless there’s some application using it. Hence: only start the printer daemon when the first application requests printer status.
And DBus perfect for this. Hughsie really deserves more hugs from all of us, he rocks :-)
-
RubenV, you forgot one important thing with your cups example: What if you use network printers or others use your printer (via the network)? Then cups has to run all the time.
It’s also easy to optimize a fixed system like the OLPC one, where you know the hardware and the setup.
A custom distro must be much more flexible.Third, why is not a good idea to start services via D-Bus:
Because D-Bus was not conceived to be a service monitoring/starting daemon. Things like that belong into init, which has special semantics as process #1 (e.g. it gets all the signals of died processes, so it’s able to restart them etc.), so init is the right place to start and monitor processes.
If the D-Bus approach by Hughie only forward the start request to the init system, then I’m ok with it. If if tries to start the process directly, then this design is severly broken. -
Pardus team has been working on whole start-up problem. a faster, more manageable and simpler init system had been developed. It is now used in all Pardus releases.
There is an article about the project. “Speeding Up Linux: One Step Further With Pardus”
http://www.pardus.org.tr/eng/projeler/comar/SpeedingUpLinuxWithPardus.htmlThe init system is almost entirely written in Python.
-
Michael: you can do activation in both directions (and this is infact what Apple does with launchd [1]). If a local program needs printer information (doesn’t matter if it’s a local printer or a network printer, all of those use the same API, the cupsd), If a network client wants to connect to your computer, be it through broadcast or with a direct connection, you can activate it as well (remember inetd? [2]).
Even more: DBus already does activation, for user applications, which works just fine. Hughsie is extending it for system services.
Have a look at it, it’s really quite something. Besides: while init might do process monitoring, we don’t actually have a linux init system that does it, which is why I’m all for system activation through DBus (which has monitoring).
[1]: http://en.wikipedia.org/wiki/Launchd
[2]: http://en.wikipedia.org/wiki/Inetd -
My viewpoints on this…
1) avoid the Windows XP and in some cases MacOSX where I am sitting waiting for back-ground stuff to load before I can do work. Or at least tell me why I am waiting for stuff to work (which you can get out of MacOSX).
2) decide if Fedora does servers or desktops. The startups of each other are orthoganal. A desktop needs to give the feel that its moving quickly because a human is sitting there.. A server needs to have services up cleanly versus depending on some 3rd party service running them. [Running httpd from xinetd is not a fun experience if you have a load average]
-
RubenV: Yes, this is possible if you _only_ care about the very simple cases. As soon as you care about the real world you have problems like “cups on my desktop does announcements via. bradcast so needs to be up all the time”. In other words there are a lot of cases were it’s really hard to work out exactly when you start needing FOO.
-
On portables, I actually tend to be less interested in startup/bootup time than I am in resume time.
Linux seems to do a reasonable job of this on my IBM Thinkpad, but holy hell does Windows Vista do a TERRIBLE job on Pam’s fancy Dell laptop. We’re talking several minutes from lid-open event detection to actual useability of the desktop.
-
Pingback from tecosystems » links for 2007-06-11 on June 10, 2007 at 11:21 pm
-
I totally agree with the “load on use” logic, even if I don’t know if D-BUS is the solution for this. Federico Mena Quintero pointed out in GUADEC 2006 talk about performance that popular daemons could become a congestion point, because at some moment, many apps could fight to have access to it. I’d prefer to avoid seeing D-BUS having this fate.
The CUPS example above was a good one. Why should I have it eat my memory, while I only print a page once in a while. I only print to a network printer, so there’s no “you may act as a printer server” thing.
Other example: I had to put a Fedora on diet just to only have a clean, minimal system with programs I will use. So why the hell current distros installs by default support for: bluetooth, smartcard, wifi, printing, while I have no wifi card, no smartcard reader, no bluetooth support on motherboard, and don’t pretend to print with that machine…?
Couldn’t we have the same kind of stuff that Ubuntu tried for audio/video plugins, meaning asking to install them only when they are used for the first time ?
-
Hello! Good Site! Thanks you! gludqbyfbeufjn
-
Hello
Very interesting information! Thanks!
Bye
Become a Friend of Gnome!
Watch as I Grow
interesting stuff
- picard_seanmartell.jpg (JPEG Image, 983x724 pixels) - Scaled (90%) March 16, 2010
- On 1:1s :: dria.org March 10, 2010
- Streaming Media - Ogg, MPEG LA, and Submarine Patents March 9, 2010
- Opera Core Concerns - Everything you need to know about HTML5 video and audio March 4, 2010
- PdaNet -- USB Tether/Bluetooth DUN for Android March 2, 2010
20 comments
Comments feed for this article
Trackback link: http://www.0xdeadbeef.com/weblog/2007/06/startup-times/trackback/