Only load services when they're needed (or after gui is up)
I think that's what WinXP does.
It's not that simple.
For me to be able to log in (on my desktop in a LAN), I need at least NFS (ie portmap, nfslock) and autofs up and running. For a disconnected LDAP setup (see the article on mandrakesecure.net), I need LDAP up and running too (otherwise is is not possible to login, or show user lists if using user lists on the dm).
I'm guessing here, but when booting Mandrake on a reasonably fast machine (2.4GHz), the major delays I see are the depmod and activities which are looking for things which aren't there, such as NFS mounts from other machines which aren't up, or LAN adapters which aren't in use (e.g. a laptop NIC which is only used in-home or in-office).
When these things ARE there, startup proceeds quickly. The problem may be the timeouts involved in looking for things you're not going to find.
This is *definitely* a problem in shutdown. If, for example, my desktop mounts an NFS directory from my laptop, and I then shut the laptop down, shutting down the desktop will retry umount for the mount 3 times while shutting down NFS, and another 3 times during the final "unmounting file systems" phase. Each retry takes something like 90-120 seconds.
Granted, on the particular issue of NFS, it's probably possible to tweak things to make this better, but that doesn't hold in every case. My laptop, when used in-house, often has its on-board NIC plugged into my internal LAN. If it doesn't (when on the road), there is a delay of at least a minute trying to bring up eth0.
Part of the solution may simply be to revisit these timeouts, and adopt the philosophy that in today's networks, if you don't find it in a few seconds, it's probably not there, and you should either abandon the attempt or else background it.
Another part of the solution would be a way to let particular components "block" on the availability of others, so that one component's initialization can proceed asynchronously, and a second component only blocks from the time it decides it requires the service until the time it is ready. A partial solution would be to create a few parallel initialization streams each of which serially runs components which depend upon one another.
