On 07/26/10 09:32 AM, Peter Memishian wrote:

  >  Seeing yet another involvement of /etc/ symlinks brought by Darren leads
  >  me to question the architectural value of the proposed changes.
  >  I like cleanlyness.  I also like compatibility.  This seems architecturally
  >  to me like change for changes sake.  Bigger tail fins on this years car.
  >
  >  What is the compelling reason for making an incompatible change?
  >
  >  -1

Though I'm not a voting member, I strongly agree.

This proposed change solves no architecural problem with the system that I
can find (the directory is aptly named "/etc", though our use of it has
become more refined with time).  However, it may well require customers to
retrain fingers and update scripts that have worked for decades.  If even
one customer is inconvenienced by these changes, I'd argue the cost has
already exceeded the benefit.  Yes, we can break things, but that doesn't
mean we should do so frivolously.

I was inclined to agree that this change seemed gratuitous. But then I looked at /etc and discovered that the cleanup value is larger than I would have guessed - this case would remove fully 20% of the entries in /etc on my system.

I think it's significant that we moved all of these programs out of /etc years ago, leaving behind the symlinks to help ease the transition. Because we haven't been adding new administrative commands to /etc, I'm willing to believe that administrators have updated their PATH long ago to replace /etc with /usr/sbin. [1]

So while I agree with Meem's notion of avoiding frivolous change, I think this one is worth it. Of course, as others have already pointed out:

* /etc/rmt needs to stay because it's part of an external protocol.

* The PATH setting in /etc/skel files needs to have /etc (and /usr/ucb) removed and /usr/sbin added (perhaps /sbin too).

* Any existing invocations of these commands in Solaris (not just ON) need to be fixed.

        Scott


[1] Just the zfs and zpool commmands, which do not exist in /etc, are sufficient to convince me of this point.

--
Scott Rotondo
Senior Principal Engineer, Solaris Core OS Engineering
President, Trusted Computing Group
Phone: +1 650 786 6309 (Internal x86309)
_______________________________________________
opensolaris-arc mailing list
opensolaris-arc@opensolaris.org

Reply via email to