The strangeness called `sbin'

[Doug Barton]

On 11/13/2011 01:19, Ed Schouten wrote:
> * Doug Barton <dougb at FreeBSD.org>, 20111113 00:23:
>> Except for the hash tools (md5, etc.) those are all properly located in
>> sbin.
> 
> So this is where the sbin <-> bin separation already causes troubles.
> Even in a discussion between two people it is impossible to determine in
> which of the directories it should be placed.

"Agreement" is not a feature if one of us is wrong. :)

> I think John Doe would agree a compiler suite is something more
> `administrative' than an application to send emails, yet they are placed
> in bin and sbin respectively.

I think that your perspective may be skewed towards a single-user and/or
developer-centric model. Those of us who operate multi-user systems have
a different set of criteria.

However, there are 3 possibilities here:

1. You're right
2. I'm right
3. Lack of "agreement."

Since in 2 out of 3 of those scenarios the status quo prevails, can we
drop it now?

> This is actually one of the reasons why I proposed the merge. The
> separation between /bin and /usr/bin is easy to reason about: if the
> system boots fine without it being placed in /bin, just put it in
> /usr/bin. This does not hold for bin and sbin.

Actually I think a much more interesting, and likely more useful change
would be to put everything into /bin. For years now I've been running
with a partition layout like this:

/		3 G (this includes /usr/)
/var		2 G
/usr/local	*

Throw in a tmpmfs and you're done. This gives a nice clean separation
between things that should be written to and things that shouldn't. The
home, ports, src, and obj directories are all in /usr/local/, with
symlinks in the regular places. In spite of the fact that I run -current
on an everyday basis, and have a non-trivial number of panics due to
testing new stuff, this layout has allowed my "system" to be spared and
permitted me to quickly recover after a panic; vs. the bad-old-days when
the fact that /usr was being written to during the panic caused a key
system file to be corrupted, resulting in hours of hilarity ensuing.

On my system currently, with one old kernel, / + /usr is only 430 M,
about 270 M of that in /usr (I don't have everything installed, but I
also have some dross, so the numbers should compare favorably to a newly
installed full system). I make the / slice large enough that it can hold
a full system, plus several old kernels, and still have room to spare.

If we're going to talk about making a change that's actually worth
making, let's just move everything into / and get rid of /usr
altogether. It served its purpose back when it came into being, but with
modern disk sizes and the (unfortunate) prevalence of the "one big /"
layout model, it's time in the sun is long past.

>>>> For those individual tools, yes. But you're discounting the collateral
>>>> damage.
>>>
>>> Being?
>>
>> User confusion, conflict between how things are done in the base vs. how
>> they are done in ports, problems for users who install stuff in /sbin
>> and/or /usr/sbin, and the other problems that have been mentioned in
>> this thread.
> 
> This is not a problem, because of the symbolic links we add.

I think you're way, way too optimistic about this. I also think your
logic is fuzzy. If the change is worth making, the symlinks shouldn't be
necessary. If the symlinks are necessary, the change shouldn't be made.

> If people
> install stuff in /sbin, it gets placed in /bin. About the user
> confusion, all the directories they need are added to $PATH. Also, if
> they ls(1) around a bit, they'll figure it out.

.... and then they write to the mailing lists and ask why the heck is
something that's always been in sbin now in bin, and what are these
symlinks about, and why did you make this gratuitous change?!? And our
answer is?

>>> Unrelated to that, `make installworld' already deletes existing files
>>> from the DESTDIR:
>>>
>>> - /.profile
>>> - /.cshrc
>>
>> Do you have a reference? I had to add code to mergemaster to handle
>> installing updates to them, fixing the symlinks, etc.
>>
>>> - /sys
>>
>> Are you sure that this happens on an already installed system? I know
>> I've had to update this link on systems where I've moved my src tree.
>>
>>> - Some man/nls-related files.
>>
>> Not sure about these.
> 
> This is all done in etc/Makefile. 

I see. However I would argue that these are sins of the past. I still
haven't seen a clearly articulated benefit to making this move. (Note, I
understand your argument that it fits some specific standard of "better
organized," I just don't agree, and even if I did I wouldn't agree that
it's sufficiently beneficial to justify the drama that it would create.)


Doug

-- 

		"We could put the whole Internet into a book."
		"Too practical."

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/