(c) Matthias S. Benkmann <m.s.b@gmx.net>

The classic SysVinit boot concept, which uses numbered symlinks (lots of
them), has several drawbacks:

-It's ugly! If you feel that that "K123dostuff" is a pretty name, count
 yourself lucky, but do me a favor and take advice from your relatives when
 you name your children ;-)

-Unless you're a black-belt in Mikado, you soon get lost in a SysVinit setup. 
 Most scripts have at least 3 representations in
 the filesystem: the script itself, an S* symlink and a K* symlink. A higher
 symlink count is not uncommon, though.
 
-You have to manually specify 
 the order in which boot scripts are to be executed. And you have to do this
 for *all* boot scripts, even though it would be more natural to only specify 
 the order for those scripts where it matters.
 You may be able to fool yourself into believing this is a matter of being in 
 control, but honestly, do you really care if the keymap is loaded before or 
 after the system clock is set ?
 If you want that control, that's okay, but the problem is that SysVinit forces
 it on you.
 
-It doesn't have dependency management. Sure, giving service A the number 100
 and service B the number 200 will guarantee that A is started before B, but
 sometimes that's not enough. What if service B needs service A running ?
 SysVinit doesn't help you with this. It starts A before B but if A fails 
 SysVinit will still try to run B. If mounting filesystems fails, it will
 still attempt every remaining service, even those that need to write to disk.
 In the end you have a system with nothing running but SysVinit's runlevel
 program will happily tell you that you're on runlevel 5, running the X
 Window System and full network.

-It's hard to modify. Why do people write fancy GUI programs to add and
 remove scripts from/to runlevels ? Because manually creating or deleting
 half a dozen symlinks, all with different names where even a single mistyped
 letter can cause the system to break is just madness. Tell me truthfully,
 wouldn't you just prefer to do a "mv runlevel.3/telnetd unused/" to
 deinstall the telnetd service and a "mv unused/telnetd runlevel.3/" to
 add it back again ?
 
-It doesn't scale well. Look at LFS: It uses *three* digits for the sequence 
 numbers and every service has a number in the hundreds. Makes a lot of sense
 on a system with only 10 boot scripts, doesn't it ?
 The trouble is that whenever you add a boot script you need to fit it into
 the sequence and should you ever have to start a boot script between a
 script with number N and a script with number N+1, there is only one
 solution: Reindexing all your boot scripts. It reminds me of a long forgotten
 past, when I still wrote programs in a BASIC interpreter with line numbers.
 From time to time I would need to insert more than 9 lines between
 line N and line N+10. Fortunately there was the "renum" command that would
 do it for me. But of course you can write a shell script to do this for
 your symlinks. No problem. SysVinit admins love exercise.

-It doesn't work well with automatic installations. If you want to build an
 installation tool that allows the user to select the packages he wants to
 install and only installs those, you will inevitably run into trouble with
 packages that come with a boot script (e.g. an ftp daemon). Your only
 chance is to assign every script your installation tool supports a unique
 sequence number, working under the assumption that the user installs all
 packages. And what if the user installs only part of the packages, adds his 
 own scripts and then wants to install more of your packages which 
 unfortunately use numbers the user's scripts already occupy ?
 The worst thing is that this problem exists even for scripts whose order
 in relation to the other scripts doesn't matter at all (the usual case).

-No user space testing. To test SysVinit boot scripts and runlevel setup
 you have to be root and execute potentially dangerous commands. Sometimes
 you have to reboot multiple times before you get it right. Especially people
 obsessed with the aesthetics of the boot script output will prefer an easy
 and safe way to work on the scripts in user space.
 
-Unsafe shutdown. SysVinit installations rely solely on boot scripts to ensure
 unmounting of file systems and killing of processes. This is very unsafe and 
 can result in data loss if worst comes to worst. A good shutdown program has
 a safety net to deal with this.
 