I'm not 100% sure about the reasoning for the original split, but wasn't it something like: /bin, /lib and others provide enough functionality to do some more interesting startup actions that can mount /usr from other storage? [edit: just found in the proposal that it was indeed the idea]
Was there some other big reason? If this is the one, it doesn't seem as relevant today as it would be a couple of years ago, so maybe that change is good...
The argument in Fedora is that split /usr doesn't work.
It does in Debian, because they actually test that configuration. But you need to keep testing it because it keeps getting broken.
In any case, just about any minimal embedded device has enough space to put /usr on the root partition. I'm sure you'll point to a BeagleBoard or whatever where this is not true, but then off-the-shelf Linux desktop distros don't run on these either.
My /usr is 6.7GB large. That does not fit into any minimal embedded device. By far.
Of course, you can strip /usr to make it fit into a 128MB root device (which seems a bit more typical to me). Hell, you should be able to remove it, that's the whole point of having it in the first place.
> It does in Debian, because they actually test that configuration. But you need to keep testing it because it keeps getting broken.
And more and more programs and libraries end up getting moved to /bin, /sbin, and /lib, because udev scripts and other parts of the root filesystem process keep needing more and more functionality. All that for functionality that people don't necessarily care about, and for which people can't seem to provide any useful justification beyond "historical reasons".
The original split was because the disks on Ken and Dennis' PDP11 were too small to hold the entire operating system. The solution was to put enough bits on the first disk to allow it to find and mount the second disk.
I think it's safe to say this particular reason isn't as relevant today as it was 40 years ago.
Another benefit from the split continuing was the smaller the root filesystem, the bare bones needed to get up and running, the less chance of filesystem or data corruption occurring. This meant your had a bootable system with which to repair the other bigger filesystems instead of having to boot from tape.
Yes, it still matters, even if the filesystem is completely transparent to the user. System services may expect particular files to live in particular places.
> Then there's the convention used to override shell built-ins by calling the full path to the non-built-in version. If the full path is used and the built-in has been relocated, that's going to break, too.
I don't understand this part. If you specify any path then you will not be running a shell built-in. Relocating a built-in makes absolutely no sense since built-ins have no path. That's what makes them built-in.
There are some built-ins which also have a corresponding command. For example "true" is a built-in in bash, but there's also "/bin/true". So some people might prefer to use /bin/true for whatever reason. I believe this is what that quoted fragment referred to.
Built-ins don't call a separate binary or script - they are literally implemented as a part of the shell. That is, if you look at the shell source code, you will see functions that implement the built-ins. As I pointed out elsewhere, I think they mistakenly said "built-ins."
You're right, I assume they meant to say "If the full path is used and the program that was meant to be called has been relocated, that's going to break, too."
They plan to symlink /bin -> usr/bin, sbin -> /usr/sbin, and possibly /usr/sbin -> bin, to preserve compatibility with absolute paths. Those symlinks will almost certainly stick around forever.
Out of curiosity, does anyone know why they want to bring everything into /usr/ instead of bring everything in /usr/ out? While we're simplifying, it seems counterintuitive to put everything deeper in the filesystem. Why not move /usr/bin into /bin, /usr/lib into /lib, etc?
Because it provides a nice top-level split between /etc (configuration), /usr (package-manager's domain, read-only), /var (persistent read-write data), /home (user data), and /run (temporary runtime data). /usr contains a pile of directories other than /usr/bin and /usr/lib, which shouldn't necessarily spread across /.
"stuff outside the domain of the package manager". Almost entirely redundant with /usr/local, except that /usr/local works for relatively well-behaved software that uses the standard directories like bin and lib, while /opt mostly contains software so broken that it wants to install in one big directory named after the software package.
28 comments
[ 2.9 ms ] story [ 65.9 ms ] threadWas there some other big reason? If this is the one, it doesn't seem as relevant today as it would be a couple of years ago, so maybe that change is good...
It does in Debian, because they actually test that configuration. But you need to keep testing it because it keeps getting broken.
In any case, just about any minimal embedded device has enough space to put /usr on the root partition. I'm sure you'll point to a BeagleBoard or whatever where this is not true, but then off-the-shelf Linux desktop distros don't run on these either.
Of course, you can strip /usr to make it fit into a 128MB root device (which seems a bit more typical to me). Hell, you should be able to remove it, that's the whole point of having it in the first place.
And more and more programs and libraries end up getting moved to /bin, /sbin, and /lib, because udev scripts and other parts of the root filesystem process keep needing more and more functionality. All that for functionality that people don't necessarily care about, and for which people can't seem to provide any useful justification beyond "historical reasons".
I think it's safe to say this particular reason isn't as relevant today as it was 40 years ago.
In case you mean "apps" and "system management utilities" - isn't that what start menu links are for?
Well, yes because the sysadmin can use it to modify interfaces.
Or is it a user executable. Well yes too, it is frequently used by non-root to list interfaces.
In any case it makes no sense since in Fedora for about 4 years the PATH has contained /sbin, /bin, /usr/sbin and /usr/bin for everyone.
Personally I think it's a good idea, but I'd like to see agreement across the major distros first.
[0] https://lists.fedoraproject.org/pipermail/devel/2011-October...
I don't understand this part. If you specify any path then you will not be running a shell built-in. Relocating a built-in makes absolutely no sense since built-ins have no path. That's what makes them built-in.
"If the full path is used and the [binary or script reimplementing said] built-in has been relocated"