Re: why are there /bin and /usr/bin...
I want to make it clear, btw, that I don't think that getting rid of
/usr is something worth fighting for. I just think that there is no
reason to keep it other than the fact that years of experience say
people will irrationally fight for it endlessly, and the minimal
benefits of getting rid of it aren't worth that fight.
On Mon, 16 Aug 2010 14:43:04 +0200 "Giacomo A. Catenazzi"
<cate@debian.org> wrote:
> As you can easily check, there is a lot of Debian installation
> who use networked disks.
> In this case the separation of /usr and / is still important.
I managed such systems for years. There is no reason to separate / and
/usr on an NFS based system either.
The fact that you're running diskless makes pretty much no difference
that I can see whether awk is located in /bin or /usr/bin
When I managed diskless machines in the 1980s, it was still vaguely
useful to keep / and /usr distinct. People thought that you needed
each machine to mount its own /etc and /var in order to have local
manageability, while mounting a common /usr to save server disk
space. As it happens, and as we didn't understand back then, you can
easily handle this with a couple of symlinks without needing a
distinct root partition, but we can be excused for being somewhat
blinded by lack of experience. We'd only had real LANs for a few
years.
> And Debian still don't have a live distribution to be used for
> rescue, so a minimal / is essential,
I agree, having a minimal rescue disk is a fine thing to want, but
what does this have to do with / vs /usr segregation?
If all your binaries on your rescue media are in /bin etc., simply
don't put more in /bin than you have space for. If you want sed but
don't want perl, then put sed in your /bin rescue disk and don't put
perl there.
It makes no difference what the directories are called in order to
keep the space usage down -- you keep space down by not including
things, not by giving them different names.
The arguments for keeping a /usr are all, in the end, "Onion" over and
over again.
> If you don't use it, or if there are alternatives (but
> it is still to prove that such alternatives are easier) don't
> mean that who use it, used it as your onions. Probably with
> time it will become useless, but your "early 1990" should be
> read "late 2010 (or later)".
It really was insanely obsolete 20 years ago. People are just attached
to the whole /usr thing, the way they used to be insanely attached to
keeping binaries in /etc before we created /sbin and the way they used
to really, really want to put sendmail into /usr/lib
The arguments for / and /usr being distinct are all really about /sbin
and /bin vs /usr/sbin and /usr/bin and all come down to this:
1) "I don't have enough space for everything in root because I'm using
some sort of expensive media!" -- well, then, it doesn't matter what
pathname the binaries are in, if you only have so many bytes, you
won't get more by putting some binaries in /usr on your flash drive
and some in /. Your embedded system isn't going to have more space
because you put awk into /usr/bin instead of in /bin
2) "I am running machines with file systems on the network!" -- so,
why does putting some files in /usr and some in / improve this? See
above for more on this one.
3) "I'm on an old architecture! I have little disk space!" -- well,
how does keeping some files in one partition and some in the other fix
this? Unless your root disk is unable to store your binaries (and no
disk made in the last couple of decades is that small) there is no
real issue. I can see this being a problem for someone who is keeping
an authentic PDP-11 or Vax alive with entirely original equipment, of
course.
4) "I'm using an SSD boot drive!" -- well, I've never seen one of
those that isn't larger than pretty much all the app binaries anyone
ever runs.
The most reasonable argument against altering such things is that
after decades, people are used to the whole /usr thing and the fight
to change it isn't worthwhile. That I will agree with -- see the
emotional reactions people get when you suggest their preferred layout
is an "onion". Fixing things so that /usr goes away would not bring
much improvement (other than some reduction in mental baggage,
eliminating wasted time deciding where things go, etc.) even though
/usr is long since obsolete, while dealing with people's emotional
reaction to the "necessity" of /usr wastes lots of time and causes ill
feeling.
Still, /usr has been obsolete for decades, and if I were starting over
again today, with a brand new flavor of Unix, I'd dump /usr entirely,
leaving perhaps a compat symlink the way we left compat symlinks
around for things like /usr/spool and other "ghosts" in the old days.
Perry
--
Perry E. Metzger perry@piermont.com
Reply to: