Fedora to simplify filesystem hierarchy | Hacker News Reader

Fedora to simplify filesystem hierarchy

itworld.com

23 pointsbeza1e128 comments

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.

Yep. But I think that was just a fortuitous side effect, not the original reason for the split.

Agreed, I tried to get that across with the "split continuing" bit. :-)

> 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.

Correct, but his point was that the sentence says built-ins can be relocated, which makes no sense.

I think it was just a mistake, or a mental shortcut for:

"If the full path is used and the [binary or script reimplementing said] built-in has been relocated"

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."

That's why I said "reimplementing" not "implementing": "/bin/true" script and "true" built-in being examples.

Yeah, that wasn't clear to me on my first reading, which is why I think it's better to phrase it similar to how I did above.

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.

This is not definitely going to happen. In fact it's the subject of lengthy and colourful arguments on Fedora-devel list[0].

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...

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 /.

What is /opt historic for? I usually install 3rd party software there.

"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.

Not sure this is a good idea. I would side with separating system executables from user level executables.

How do you define a "system executable"? And why would you keep them separate?

In case you mean "apps" and "system management utilities" - isn't that what start menu links are for?

Indeed .. is /sbin/ifconfig a system executable.

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.

That is what file permissions are for, 755 vs 750.

I can see the benefit to this, but as file systems become more transparent to the user, does it really matter?

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.

Reply on news.ycombinator.com