> I see no significant difference between modifying a system file (by
> which you presumably mean the likes of /etc/rc) and modifying a system
> directory (/etc/init.d, /etc/rc2.d, etc).  In either case, you have to
> keep careful notes elsewhere of what you did so as to be able to roll
> it forward next time you do an update that destroys your local mods.

I see one big difference, which is that the changes made to the directories
can be tracked by the package system for later un-installation. Changes to
flat text files are more dangerous because of diff issues, unless you want
to go the .INI route like they did on WinBlows -- really just a specialized,
space-compact type of filesystem.

Your point about updates blowing things away is valid, but I submit that
virtually _any_ startup configuration system is going to be vulnerable to
this; I suppose you could argue that rc files make it easier to repair the
damage afterwards, but I think that only works in the sense that you have
less files to backup and restore.

> I've used such systems.  I dislike them.  The vendor's idea of what I'm
> "supposed to go modify" rarely (never, in my experience) includes
> enough flexibility to get the behavior I want - and I am *not* willing
> to put up with being told that the vendor knows better than I how my
> system is supposed to act.  Not from SGI, not from Sun, and most
> definitely not from NetBSD.

For a while now, I have been convinced that as long as people keep trying
to use armies of shell scripts for startup/shutdown, we will be dissatisfied
with everything they invent. The problem demands new primitives before it
can be properly fixed.

My server doesn't care about run levels. It only knows which kernel options
it needs, and which other services it needs to have started before it can run.
A "service" might actually be temporary exclusive access to a file, which is
going to be used or modified by code that was derived from an rc file hack.
And a run level, in this model, is just a "null" service that contains
nothing but dependencies on other services. Change the 'run level' and you
allow some services to shut down but require others to be started.

In fact, when I think about how I want startup and shutdown to work, most
of the sentences sound like they could have been part of the pkgsrc and
system package discussions here recently. This is because the same sort of
dependency tracking and resource management is going on. Instead of adding
or deleting a package, you're starting or stopping a service.

When you boot a kernel you are declaring a set of pre-loaded kernel modules,
each of which might be a dependency to a dynamic service, daemon, or LKM.
Each dynamically startable/stoppable thing has a list of stuff that must be
running when it is running, and perhaps a list of things that it is mutually
exclusive with (this might require finer resolution, for instance starting
pppd on a port implies disabling getty, if both are enabled for that port).

To me, single-user means that only the stuff in the kernel is active --
everything else is shut down (possibly including LKMs but I'm not sure).
Multi-user means that my 'default' list of desired runnables is started,
in any order which is valid given the DAG established by the dependency
statements of the system services (does this sound like make -j ? it should!)
... and alternate lists of desired runnables should be easy to activate,
perhaps by HUPping a daemon or something.

Obviously the above is more ramble than proposal, but I remain hopeful that
a robust and usable system can be devised which is also easy to diagnose
and troubleshoot. I applaud any research in this direction and volunteer
my -current machines for testing.

Even something that splits up rc scripts and runs them in parallel in some
sane manner would be helpful. The last time I tried to activate pcvt, I kept
locking myself out of the damn system because it bombed while trying to set
up the fonts for 80x50 screen mode, and the keymap was not yet initialized.
A system that let the independent keyboard initialization finish would have
saved me a lot of time.

Todd Whitesel
toddpw @ best.com