Linux command comparison

Blake Barnett shadoi at
Fri Dec 8 11:40:44 MST 2006

On Dec 8, 2006, at 8:48 AM, Michael Torrie wrote:

> On Fri, 2006-12-08 at 06:56 -0700, Hans Fugal wrote:
>> I heartily agree, although it bears mentioning that some distros are
>> making the long-overdue migration away from System V init schemes  
>> (the
>> symlinks in /etc/rc.d or similar places) to something better. e.g.
>> Ubunutu is using upstart, which looks very cool, and Debian has  
>> optional
>> support for upstart and other systems like runit.
> For a desktop distro this is probably a good idea, but for servers,
> nothing beats System V in my opinion.  Having well-defined custom
> runlevels (something most of us probably should do but don't)  
> allows for
> much better system administration.  For example, if your server
> applications are layered, you can use runlevels to add layers in a
> controlled fashion.  Runlevel 5 could be everything up full, and
> runlevel 4 could be everything but the web interface, runlevel 3 could
> be just the sql server running, and runlevel 2 could be standard
> multi-user, network, but the apps are shut down for maintenance.
> Having messed with Tiger's new LaunchDaemon, I can see some definitely
> benefits to it over the older pseudo-rc system.  But it seems to not
> have any real concept of runlevels, although there Mac does support a
> single-user mode, so I don't know how it fits in.

launchd doesn't do runlevels, it's mostly designed with the desktop  
in mind, and so usually prefers to load things ondemand.  But it can  
support dependencies, the WatchPaths and QueueDirectories can be used  
to enforce the order that things load up.  And in a lot of ways, it's  
more reliable than init scripts because you can ensure that a service  
does not attempt to load until it's dependencies have fully loaded  
and written the file that launchd is watching for.  It's quite  
different, but all the other features of launchd are well worth  
adjusting to.  (Even though I usually hate XML config files)


More information about the PLUG mailing list