[OpenIndiana-discuss] Familiarity, was Re: Help with website

[Richard L. Hamilton]

On Oct 10, 2011, at 9:25 PM, Dan Swartzendruber wrote:

> 
> Gregory, I can second that.  I have a friend who is very experienced in
> Linux and BSD and I was mentioning at dinner how I was using a SAN appliance
> that was based on ZFS, and started extolling its virtues.  He asked me
> (totally seriously) "ZFS is still around?  I thought all that stuff died
> when Oracle bought Sun?"  This is the barrier we have to deal with.  Somehow
> because I grumbled about commands being somewhat different, I got branded as
> "one of them", when my original point was that we need to get people using
> OI (or any other flavor for that matter), or it will end up a fringe system,
> and ultimately die.  The technical merits don't matter in a lot of ways,
> when perception comes into it (for you old fogies, think Betamax vs VHS -
> think which was the better implementation, and which one ended up winning
> the marketing battle...)  I've had this same fight some years back before
> linux had plug and play desktop support - I tried to use some random distro
> and was having incredible hassles getting X to work right.  I was on some
> forum or other, and people were telling me what juju I had to perform on
> various config files, and when I made the innocent remark that "with
> windows, all I have to do is boot it, and it comes up with a usable
> desktop!", and was flamed into the next county by the residents of that
> forum.  I really like ZFS, and like I said, that was my only motivation in
> getting involved in OI (I have enough stuff on my plate without learning yet
> another flavor of Unix, but one even farther away than Linux variations or
> even *BSD).  That said, I've had no real choice if I want ZFS, so I'm
> learning the ropes.  I will say that the previous exchange I had here about
> the absense of /etc/rc.local was a perfect example (albeit a minor one) of
> the point I was thinking of.  Yes, in pretty much any of the flavors of Unix
> using the /etc/init.d script system, you can get this to work.  Every Linux
> distro I've used in the last N years provides the /etc/rc.local method for
> those corner cases that don't go anywhere else, yet not one person here said
> "yeah, you know, that IS a useful thing to have, maybe we should consider
> it".  

While it may be useful, it was eliminated (SunOS 4.x used to have it) for what seemed good reasons at the time.  Separate rc files (/etc/rc[S0123].d/[SK]*, with links to /etc/init.d) can be replaced rather than edited, which is more maintainable (think patches, etc).  SMF largely replaced rc files because SMF can track stuff and restart it if it dies.  etc.  The differences aren't arbitrary, they're there for a _reason_.

Now, someone could always add an /etc/rc3.d/S999rc_local, which simply runs /etc/rc.local if it exists.  I could do that, so could you.  Looks just like

#! /bin/sh

if [ start = "$1" -a -f /etc/rc.local ]
then
	sh /etc/rc.local
fi

Easy, right?  I don't mind that…much…except it does encourage throwing all the "corner cases that don't go anywhere else" into one big sloppy file, the whole reason it was gotten rid of (along with /usr/local) in the first place.

You would perhaps view familiarity as more important.  Having seen people come and go, and continuity of experience lost, I'd prefer maintainability, and something that could be put under configuration control (think CFengine (open source) or Opsware (commercial), or similar).  Separate rc files, or for that matter SMF methods and manifests, lend themselves to that better than does a single optional rc.local file; or at least, that's AFAIK among the reasons rc.local was done away with.

Again, one could do both; include the hook for rc.local but publicize that it was deprecated and that there were drawbacks to using it in certain circumstances.

Similar considerations may apply to a number (by no means all) of other differences.

You may find the least resistance to something that's a clean superset of traditional Solaris - won't break anything those already used to it are depending on, and the most to that which is incompatible (can only do it one way or the other, but neither tool will handle both ways).