the unix I work with may take > 30 minutes... depending on the version and hardware of HP-UX/server... ;-)

Undoubtedly I will be downvoted for saying this, but I'm getting really tired of blanket statements like "Linux rarely needs to be rebooted" at the start of articles like this.

Frankly it's a myth for most desktop Linux users, and server boot times don't really mean much anyway.

* I have 4 different laptops currently with Linux installed, none resume reliably from suspend or hibernate.

#3 Change your desktop

#5 Change your OS

#6 Change your hardware

#10 is the only interesting one and it isn't explained at all.

# Specify method used to enable concurrent init.d scripts.
# Valid options are 'none', 'shell' and 'startpar'. To enable the
# concurrent boot option, the init.d script order must allow for
# concurrency. This is not the case with the default boot sequence in
# Debian as of 2008-01-20. Before enabling concurrency, one need to
# check the sequence values of all boot scripts, and make sure only
# scripts that can be started in parallel have the same sequence
# number, and that a scripts dependencies have a earlier sequence
# number. See the insserv package for a away to reorder the boot
# automatically to allow this.
CONCURRENCY=none

To test dependency based reordering of the boot sequence, install the
package, enable parallel booting, and run update-bootsystems-insserv
to make a backup of the boot sequence and reorder the boot scripts.
Be careful to verify the boot sequence before rebooting, as an
incorrect boot sequence can render the system completely unbootable.

In short:

# Enable parallel booting
echo CONCURRENCY=shell >> /etc/default/rcS

# Update boot sequence
update-bootsystem-insserv

# At this point, I recommend examining the order in /etc/rcS.d/ and
# /etc/rc2.d/ carefully, to verify that the configuration actually
# will boot. Update /etc/insserv/overrides/ or
# /usr/share/insserv/overrides/ with better dependency information
# if the boot order is incorrect, and run insserv -v to update the
# boot order.

# Ready to reboot
shutdown -r now

The next boot should then start services in parallel, as early as
possible during the boot process based on the dependency information
provided.

To monitor the boot sequence, the bootchart project is a good choice.
Debian packages are available in etch and sid. The project itself is
available from http://www.bootchart.org/.

Background info on alternative boot systems in Debian is available from
http://alioth.debian.org/docman/view.php/30730/38/debconf2-initscri....

I'd like to see day when there would be only one chipset, only one type of hdd connectors (why we need drives at all is beyound me- petabytes of non-volatile RAM is available already), only one type of hot-swappable PSU, only one type of CPU cards that is upgradable just by throwing other(s) card(s) into ONE TYPE of socket, only one video card.

ONLY ONE F***** OS THAT WORKS!?

BTW, ctrl-alt-delete restarts the x-server

The main content of the article is useful, however!

[q#7: Avoid dhcp: This one I was wondering what the heck was the author thinking? The answer to dhcp requests arrives in milliseconds (unless there's something terribly wrong with your system) and it allows for much more flexibility.

[q#7: On my systems it takes sometimes a few seconds to get an address, especially wirelessly. If it fails to get an address (for whatever reason), it may take 30 seconds or so before it gives up. Depending on the OS/Distro, if these task are done serially that can be a significant slowdown.

To me, the biggest speed-up is for most of these tasks to be done in parallel - thus our case of a failed dhcp request wouldn't matter.

"10 Ways To Make Linux Boot Faster"

What's this, Digg?

Most of these steps are the Linux equivalent of deleting keys in HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run