Comments on: startup times

By: tredinertok

tredinertok — Tue, 10 Jul 2007 02:51:39 +0000

Hello

Very interesting information! Thanks!

Bye

By: avqiwsydnq

avqiwsydnq — Mon, 18 Jun 2007 10:37:54 +0000

Hello! Good Site! Thanks you! gludqbyfbeufjn

By: liberforce

liberforce — Mon, 11 Jun 2007 13:34:31 +0000

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 ?

By: tecosystems » links for 2007-06-11

tecosystems » links for 2007-06-11 — Mon, 11 Jun 2007 04:21:14 +0000

[...] Christopher Blizzard » Blog Archive » startup times i can’t say whether or not d-bus is *the* answer to startup time performance, or even *an* answer, but it certainly seems to me that some creative thinking is in order. it takes way too long now. (tags: startup time Linux desktop OLPC ChristopherBlizzard) [...]

By: spot

spot — Sun, 10 Jun 2007 20:52:48 +0000

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.

By: James Antill

James Antill — Sun, 10 Jun 2007 18:55:23 +0000

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.

By: Stephen Smoogen

Stephen Smoogen — Sat, 09 Jun 2007 16:47:14 +0000

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]

By: RubenV

RubenV — Sat, 09 Jun 2007 14:58:13 +0000

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

By: mdakin

mdakin — Sat, 09 Jun 2007 12:07:02 +0000

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.html

The init system is almost entirely written in Python.

By: Michael

Michael — Sat, 09 Jun 2007 11:22:06 +0000

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.