On Fri, 17 Mar 2000, Greg A. Woods wrote:

Greg-> [ On Friday, March 17, 2000 at 03:44:09 (-0500), der Mouse wrote: ]

Mouse: Ah yes, once again "you don't need to care about that, it just works,
Mouse: trust us".  I'll thank you to stop trying to tell me what I do and
Mouse: don't need to know about my systems!
# 
Greg-> It never fails to make me wonder why people will get all up in arms
Greg-> about silly sys-admin details and yet take for granted the thousands of
Greg-> obscure lines of code that make some of the most intricate and important
Greg-> internals of the system function the way they do....  Certainly you can
Greg-> see and feel the sys-admin things much more closely, and if your job is
Greg-> to maintain systems then such things might affect you far more than the
Greg-> rewrite of a filesystem or the VM system but I still don't see the
Greg-> difference.

You just answered your own question!  We, as systems administrators,
SEE AND FEEL the difference.  For all our sysV boxes, I implemented a
profile which, when run, would do the right thing with a control-D from
single-user mode as well as from a login shell.  You've heard that one
from me before.

When I worked with Autodesk, we were switching over to Solaris.  I hated
it.  The performance was abysmal, the shells crashed, and everything felt
suddenly quite alien.  EVERYthing.  From the way ps worked, to the way the
startup was handled, to where the host config was split across six or
eight files, to the fact that su didn't work right, to the STUPID GODDAMN
DEVICE STRINGS (the compat devices didn't work right, for some reason).
It was a blight on the face of UNIX (either that or BSD was a bit of
sandpaper on UNIX's face, which is a blessing in itself :-), and it was a
slap in the face of every sysadmin who'd ever touched a Berkeley or Sun
system.

Greg-> In each case there's a damn good chance that any such
Greg-> change will have been very closely considered by persons who've taken
Greg-> into account as wide a set of requirements and ways of doing things as
Greg-> they can without getting totally stuck on inevitable conflicts and other
Greg-> road-blocks.

Sorry, I think they missed the boat on this one.  Mind you, to give Luke
some credit, I think he put in quite a bit of work on this, and I credit
him for trying to take that "step forward".  Mandating it, though, was
not the right move.

Greg-> Being "*BSD-like" is not, IMO, about the sys-admin crud on top of the
Greg-> system -- it's about the innards and the APIs!

I beg to differ in a _very_ large way.  The thing that first tells me
I'm on a Berkeley system is the way the system responds to my commands;
ps ax doesn't give me an error message.  /dev/sd0a is there and not a (soft)
link to some long convolved path name.  MAKEDEV is there.  rc is there
and I can look to see how it's configured via whichever mechanism.  /usr
isn't required at boot time just to get into single-user mode.

The UI is a BIG part of what BSD is.  Yes, the innards and the APIs are
_equally_ important.  You can't just chuck what's been a consistent UI
and do a radical change like this, and then turn around and say, "oh,
the UI is not important".  That's the biggest double-speak I think I
have heard in AGES.

If you're expected to learn to admin a system, much less use one,
what's the FIRST thing you're gonna see...?

And I concur with der Mouse:  To be told that the details of administrating
a system are unimportant is an insult to my career as a systems and network
administrator.

We in the business are here because we are good at what we do.  We like to
be able to see what the hell the box is doing when it comes up (does anyone
else type 'sh /etc/rc' from a single-user prompt to do debugging?), or
at least we like to be able to see what the box is SUPPOSED to be doing
on its way up.

Greg-> ...The *BSD crowd, when I
Greg-> was not de facto a member, always seemed to be so caught up in the
Greg-> innards of their systems that they never paid enough attention to making
Greg-> the system administration tasks "production quality".

Define "production quality".  What's _really_ wrong with what we had?
"Couldn't be automated."  Bull[#@$(].  It could be.  Just takes some
more thought, is all.

Greg-> Now before anyone
Greg-> tries to claim that "production" and "research" systems are not
Greg-> compatible in their goals let me remind you that much of what's done on
Greg-> a research system has nothing at all to do with the sys-admin details in
Greg-> the first place and indeed the more attention that is paid to good
Greg-> production-quality sys-admin the more reliable and productive the entire
Greg-> system can be even when it's only used as an OS research platform.  Also
Greg-> please remember that research into what it takes to build a high-quality
Greg-> production system is just about as important as research into networking
Greg-> protocols or filesystems.

Production-quality sysadmin tools != dumbing down the tools.
Your first production-quality sysadmin tool had better be your systems
administrator!

Greg-> Given the trade-off between what's now possible in terms of additional
Greg-> functionality (status/stop/reload/etc) and of course the far more
Greg-> flexible dependency controls I think the extremely small amount of new
Greg-> code is well worth having.

I will agree that my idea (I proto'd it and it got zorched ("The disk ate
my homework") :-(...) jumped thru a few hoops, and I'm not sure how much
more or less code it had to it, but upon reading rc.subr, the functions
looked somewhat similar.  I just handled it a different way, but there
was functionality to start/stop/reload/status each daemon.

If I can get it rewritten, I'll post it.  If I can define a grammar for
add-daemon and remove-daemon properly, I'll post that too.

				--*greywolf;
--
BSD: We Come In Peace.  We're leaving in pieces.