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" <c...@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 pe...@piermont.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100816142116.41610...@jabberwock.cb.piermont.com
