

Fedora to simplify filesystem hierarchy - beza1e1
http://www.itworld.com/print/218847

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

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

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

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

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

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

~~~
viraptor
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"

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

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

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

------
rwmj
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...](https://lists.fedoraproject.org/pipermail/devel/2011-October/thread.html#158599)

------
haldean
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?

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

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

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

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

~~~
viraptor
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?

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

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

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

