So, /usr really means "user", and the "Unix System Resources" acronym was put together afterwards. Interesting, thank you !
I knew it as "User Shared Resources".
Understanding the bin, sbin, usr/bin , usr/sbin split
41–50 of 158 posts
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#42Earlier quoted context omitted.
This is a little bit disingenuous. I can certainly see the point that all of this separation is unnecessary on a typical modern desktop system, but several of the paths you listed in support of your argument are not actually specified by the FHS, nor do they even make sense. Of the paths you mentioned, there is no such thing as: /usr/share/bin /usr/share/local/bin /usr/local/share/bin /usr/local/share/lib /usr/share/…
Every one of those paths I mentioned are paths I have encountered during my use of various unix distributions since 1991 (Solaris was the worst offender). And that's not even the complete list. I gave up trying to predict where software would install to a long time ago. My point is that what "makes sense" is subjective. Each developer/distro manager who made one of those paths thought to himself "it makes perfect sen…
Your encountering them doesn't make them part of FHS.
Their being included in FHS does.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#43I still have various partitions: /, /var, /usr, and /tmp (on a single slice). When I am in single user mode the only binaries I have available are in /bin. Unless I mount /usr that is all I have access to, so the split still makes perfect sense. A lot of Linux distributions by default suggest using the entire disk and creating a single partition named /. In that case it doesn't make sense to have the various differen…
If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)
'Nix allows mounts at any arbitrary point in the filesystem hierarchy. While you could symlink /var/tmp to /tmp, you could also dedicate a filesystem to it. Given that the strict definitions differ (/var/tmp does persist across reboots, /tmp may persist), you risk annoying/disapointing someone at some point if you do otherwise.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#44I still have various partitions: /, /var, /usr, and /tmp (on a single slice). When I am in single user mode the only binaries I have available are in /bin. Unless I mount /usr that is all I have access to, so the split still makes perfect sense. A lot of Linux distributions by default suggest using the entire disk and creating a single partition named /. In that case it doesn't make sense to have the various differen…
If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)
Except that /usr is where /usr/local lives (all software installed through the FreeBSD ports tree) and I don't want that on my / partition, so now I have to create a partition just for /usr/local? How about the various other files under /usr, they now have to be moved to / as well? On FreeBSD /usr also houses /usr/home. /home/ is a symlink to /usr/home!
/ on a FreeBSD system is generally kept small. It doesn't have softupdates on when using UFS2 since it is also the location where your kernel lives, along with rescue utilities and your main /bin. Nothing else.
The proposal as put forth is misguided (talking about Fedora's in this case) and I don't think that the system should be re-engineered just because that is the default use case these days. I remember when I first started using Linux and I created a separate, /boot, /, /usr, /home, and /tmp. Just because udev and others now fail to work correctly doesn't mean it isn't a good idea to keep those separate...
This is just going to cause more trouble, more fragmentation between unix/unix-like systems and Linux and it's various distributions.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#45Let's not forget the whole partition split situation due to the 1024 cylinder limitation. Once upon a time, you couldn't get to certain parts of the disk from your bootloader (using BIOS calls), so you had to make something like a tiny /boot which would hide This situation has only improved a little. There are still lingering bits of it here and there, depending on how deeply you poke and which distribution you have…
It annoys the hell out of me that people are still imposing the 486-era 1024Cyl and 8GB limitations in 2012. ArchLinux, for example, still really, really wants you to make a /boot.
These limits are chiefly imposed by the BIOS (int 10h) calls available to a boot sector program (the 512 bytes of machine code you get inside the master boot record of a disk), and require a lot of cleverness to escape from.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#46And why / /usr split still makes sense: If it's needed to boot, it goes in root: boot images (including root filesystem) can be initrds, bootp images, flash sticks, or other similar tools. Maintaining the discipline of keeping what you need in / and what you don't need to boot in /usr helps when you're trying to minimize boot images, troubleshoot, and/or just simply keep things comprehnsible. Different partitions can…
For those who haven't seen the proposal for the / /usr merge:
"Fedora (and other distributions) have begun work on getting rid of the separation of /bin and /usr/bin, as well as /sbin and /usr/sbin, /lib and /usr/lib, and /lib64 and /usr/lib64. All files from the directories in / will be merged into their respective counterparts in /usr, and symlinks for the old directories will be created instead"
http://www.freedesktop.org/wiki/Software/systemd/TheCaseForT...
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#47Earlier quoted context omitted.
If this proposal ends up being widely adopted, you're only losing the ability to keep /usr on its own filesystem. You still can (and very much should) keep /var and /tmp on dedicated volumes. (And should probably also symlink /var/tmp to /tmp, so that you don't have a world-writable directory on the filesystem you want to keep safe for writing logs to...)
'Nix allows mounts at any arbitrary point in the filesystem hierarchy. While you could symlink /var/tmp to /tmp, you could also dedicate a filesystem to it. Given that the strict definitions differ (/var/tmp does persist across reboots, /tmp may persist), you risk annoying/disapointing someone at some point if you do otherwise.
I am sure I have used systems with tmpfs /var/tmp.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#48Glorious. More history bits like this please. At the same time, makes you think about dropping FHS .. yeah I said it.
A distribution that does just that is NixOS ( http://nixos.org/nixos/ ). It has to, because it's purely functional (new stuff shouldn't overwrite any of the old stuff) and it has to support several different versions of the same package being installed at the same time. It is awesome, especially the easy rollback and that you can specify an entire system with a recipe. Still, it feels strange for us who are used to m…
GoboLinux does it too.
And for that matter, another "unixy" OS uses "bundles" to keep all of an apps files together instead of splattering them all over the OS: Mac OS X.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#49The Fedora changes are bikeshedding. They start with wanting to change something, and then find a justification. Why not just put all the executables files in /Program Files/? All this to save a few bytes in $PATH, to avoid problems with systemd, and to avoid fixing udev.
why not put all .txt files in /txt? we have .../man for man pages, .../lib for libs, .../src or source and .../include for C includes after all.
Re: Understanding the bin, sbin, usr/bin , usr/sbin split
#50The FHS (Filesystem Hierarchy Standard) [1] is the go-to reference for this sort of thing. It explains that `/bin` is for binaries that are essential before other file systems are mounted (e.g. in single user mode), and `/usr/bin` is for "most user commands" (all others). This allows you to keep a minimal local filesystem containing only the binaries needed for init to get the system running, and then `/usr` can be m…
The central thing about all these conventions is they developed in the absence of good union mounts. In Plan 9 there is no $PATH: all such things are bound into /bin. This works both because Plan 9 has very good union mounts, but also because those union mounts can be localized to a specific process and as a result are user accessible. I seem to recall some work was done to make this possible on Linux but It didn't get accepted into the main kernel because it is at odds with how we see how a Unix system should behave.
It would be interesting to see a Linux distro that embraced this.