
Debian considers merging /usr - dengerzone
https://dralnux.com/debian-considers-merging-usr/
======
bigbugbag
This move has been made a while ago by arch and didn't seem to cause any
trouble.

On the other hand, it does not change much compared to the revolution of
adopting the gobolinux filesystem that has been proposed more than 10 years
ago. [1]

[1]:
[http://gobolinux.org/index.php?page=at_a_glance](http://gobolinux.org/index.php?page=at_a_glance)
[http://gobolinux.org/index.php?page=doc/articles/clueless](http://gobolinux.org/index.php?page=doc/articles/clueless)

~~~
TheSwordsman
All of my Arch Linux nodes ate-shit when I did this upgrade years ago. Things
didn't like when their shared libraries got moved. I had to manually recover
every single one.

It was actually the straw that broke the camel's back for me as an Arch user.
This was around the time Arch Linux was going through lots of breaking
changes.

~~~
gnarbarian
It's what happens with any rolling release distro given enough time. We
thought it would solve the problem of having to upgrade the OS and migrate
every few years but it didn't really.

Now we have docker. Probably not solved until we write all our applications as
some sort of crazy monad to minimize maintenance pain. I think docker is a
meaningful step toward that.

~~~
toyg
_> until we write all our applications as some sort of crazy monad_

Desktop Linux seems to be finally moving towards self-contained formats like
AppImage and Flatpak. They are clearly not oriented towards server apps, but
who knows.

~~~
lisivka
OMG. Self contained apps were there starting from Linux 0.1. They are
reinvented every second year.

~~~
toyg
Yeah but they never got traction for this or that reason. This time it looks
like several big players actually agree on a common way forward. I guess time
will tell.

------
mastazi
HN's hug of death. Cached version is here:
[http://webcache.googleusercontent.com/search?q=cache:s8ApOo1...](http://webcache.googleusercontent.com/search?q=cache:s8ApOo1EgtUJ:https://dralnux.com/debian-
considers-merging-usr/&num=1&hl=en&gl=au&strip=1&vwsrc=0)

~~~
RKearney
It looks like a server-side misconfiguration.

The URL is 301 redirecting to itself.

My guess is the admin has a server side redirect to force http to https, but
has CloudFlare configured to use http to the origin.

------
jeena
So what are the arguments actually?

A couple of days ago I was reading some POSIX book from 1991 and there the
layout of /bin /lib /shared /usr/name/bin /usr/name/lib /usr/name/shared and
so on was much more logical than what we have now which is just weird as far
as I can see because I don't understand it.

~~~
hawski
The best explanation goes from Rob Landley:

[http://lists.busybox.net/pipermail/busybox/2010-December/074...](http://lists.busybox.net/pipermail/busybox/2010-December/074114.html)

Some fragment:

> When the operating system grew too big to fit on the first RK05 disk pack
> (their root filesystem) they let it leak into the second one, which is where
> all the user home directories lived (which is why the mount was called
> /usr). They replicated all the OS directories under there (/bin, /sbin,
> /lib, /tmp...) and wrote files to those new directories because their
> original disk was out of space. When they got a third disk, they mounted it
> on /home and relocated all the user directories to there so the OS could
> consume all the space on both disks and grow to THREE WHOLE MEGABYTES
> (ooooh!).

> Of course they made rules about "when the system first boots, it has to come
> up enough to be able to mount the second disk on /usr, so don't put things
> like the mount command /usr/bin or we'll have a chicken and egg problem
> bringing the system up." Fairly straightforward. Also fairly specific to v6
> unix of 35 years ago.

It was discussed here few times:

[https://news.ycombinator.com/item?id=3519952](https://news.ycombinator.com/item?id=3519952)

[https://news.ycombinator.com/item?id=9554134](https://news.ycombinator.com/item?id=9554134)

~~~
torrent-of-ions
Considering this, I wonder why the /usr would be kept at all, assuming we keep
/home. Why not just have /bin etc. since we can generally fit everything there
these days?

~~~
vbernat
/usr can be made read-only. It is more convenient to have everything in /usr
than to have /bin, /sbin, /lib, etc.

~~~
vbezhenar
I would argue, that it's better to mount / as RO and remount /var, /home as
RW.

~~~
lomnakkus
It's not just amount mounting as RO. It could _physically_ be RO (or use e.g.
dm-verity or similar)... which would be quite inconvenient if you wanted to
add-site-specific directories under /. (Or if a distro wants to add a
directory, or whatever.).

Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require
that they were actually on different file systems? I don't think you can have
a RW bind mount on a RO-mounted file system. (Haven't tried it, though.)

~~~
hawski
> It's not just amount mounting as RO. It could physically be RO (or use e.g.
> dm-verity or similar)... which would be quite inconvenient if you wanted to
> add-site-specific directories under /. (Or if a distro wants to add a
> directory, or whatever.).

You could use two partition update scheme as ChromeOS. I am working on Linux
distribution that have rootfs as a squashfs image and I want to have as
painless updates as on ChromeOS.

> Also, wouldn't mounting /var, /home etc. RW on top of a RO-mounted / require
> that they were actually on different file systems? I don't think you can
> have a RW bind mount on a RO-mounted file system. (Haven't tried it,
> though.)

You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.

~~~
lomnakkus
> You can mount RW fs on RO fs. Distributions on Live-CDs do it all the time.

Right, but that's with OverlayFS and such, right? (I.e. not just straight bind
mounts.)

Seems awfully complicated to solve what essentially should be a non-problem...
(I'm aware OverlayFS has other uses, but in _this_ instance it seems like
overkill.)

EDIT: I'll just note, I _did_ say "separate filesystem" (i.e. non-bind), but I
guess it might have been easy to miss.

~~~
hawski
> Right, but that's with OverlayFS and such, right? (I.e. not just straight
> bind mounts.)

Most probably yes, but there are probably distributions using ro rootfs +
specific mounts. I think that in many cases embedded devices would use such a
scheme instead of OverlayFS.

EDIT: But you probably have to mount workdir and upperdir somewhere over this
ro rootfs for OverlayFS to work.

> EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but I
> guess it might have been easy to miss.

I was hoping that you could read between the lines also :) I mentioned my WIP
distribution. I have mounted:

\- squashfs ro on /

\- ext4 rw on /mnt/rw

\- /mnt/rw/var bind on /var

\- /mnt/rw/home bind on /home

~~~
lomnakkus
> > EDIT: I'll just note, I did say "separate filesystem" (i.e. non-bind), but
> I guess it might have been easy to miss. > I was hoping that you could read
> between the lines also :) I mentioned my WIP distribution. I have mounted:

Oooh, burn! :) I honestly didn't see any relevant mention of the WIP-distro
you're talking about... but now that you mention it I had a look back. "I am
working on Linux distribution" (etc.).

> I have mounted:[snip]

So... separate file systems.

------
alexellisuk
The argument is not to remove all trace of /bin /sbin /lib - but to move these
folders into /usr/ and then sym-link back to the original locations. More of a
detailed response here:
[https://lwn.net/Articles/670071/](https://lwn.net/Articles/670071/)

------
marcoperaza
The linked email is pretty sparse on details. More information:
[https://lwn.net/Articles/670071/](https://lwn.net/Articles/670071/)

------
deadbunny
Personally I prefer the suckless[1] approach, but it's a step in the right
direction.

1\. [http://sta.li/filesystem](http://sta.li/filesystem)

~~~
JdeBP
As discussed at
[https://news.ycombinator.com/item?id=12591737](https://news.ycombinator.com/item?id=12591737)

------
SFJulie
The initramsf case and the embedded system case are good point.

Can Computer Science help us decide if some people are right?

The measure of Informational entropy : a state with more compartment as more
order, thus more information. By merging /usr you lose information, thus
making the one in need losing it, whereas the one without a need for this gain
nothing.

I laughed at the comment of philosophy by pitchforks of angry users, and I
would claim these pitchforks are the one from the Maxwell Daemons telling us
to remember that it is easy to lose information and that increasing entropy is
messy.

~~~
tobias12345
By splitting / and /usr you create problems for packagers: Where do all the
files need to go?

Does cryptsetup need to go into /sbin or /use/sbin? Does network code belong
into / or /use?

Must users will not care, but some might need either of them to set up their
file systems.

If you pace something into /, then you also need to put all libraries and
binaries that needs into /. That will rapidly blue up the size of /. It is
also not automatically testable, so distributions will get things wrong (as
they repeatedly did before).

You could have a script to only put the stuff your system needs into /... Most
distributions use such a script for their initrd, which contains everything
necessary to check and mount your root file system. So you could just extract
that into / and be fine with it:-)

Or just use your initrd as that rescue medium.

------
wtbob
Wouldn't it make more sense to merge stuff into / than into /usr, i.e., move
/usr/bin/* into /bin, /usr/share into /share &c.? The 'usr' portion of the
path is weird historical cruft which adds no real information.

While we're at it, why don't we add a real Plan-9-style bind and use union
mounts?

~~~
qb45
Some programs may have strings like /usr/share hardcoded in them. I once tried
renaming the root user to "boss" and it unearthed few issues of exactly this
kind.

~~~
kasabali

      # ln -s / /usr

------
45h34jh53k4j
This broke my debian live build! I couldn't work out why the process would
fail during build (it couldnt find the elf loader!) I was clobbering the
symlink /lib -> /usr/lib with a local included folder.

Gah!!

------
aargh_aargh
Page is down. Mirror:

[http://archive.is/i2Jsu](http://archive.is/i2Jsu)

------
pvaldes
So if your partition /usr fails and all that you have in /bin is a broken link
instead real programs; your entire system fails.

Can't see any real advantage in this.

~~~
Latty
And that's a likely scenario? You actually have them on different bits of
hardware or something? It's so arbitrary - why not split it further, what goes
where? If you want to achieve splitting important stuff off to special
storage, I'm sure that'd still be possible.

Also, why recover a system like that when I can just boot off a USB stick?

This is just a hack that's stuck around from when people had tiny drives and
needed multiple partitions for these things, as far as I understand it.

~~~
pvaldes
Yes, of course. Is the common scenario in all old-school linux users and had
saved me a lot of headaches. It simply works.

> Why recover a system like that when I can just boot off a USB stick?

Because I can. The basic parts of the system are still available and working.
I don't need to reboot to fix the problem, I could mount a different and
working /usr in seconds. Is not just "a hack", is a _design_.

------
d33
Given that server's under heavy load, here's a copy-paste:

"The bootstrap utility for the upcoming release of Debian 9 “Stretch” will
feature the ability to merge utilities from the root file system into the /usr
file system. This essentially means directories like /bin and /sbin will
simply be symbolic links to content stored in /usr/bin and /usr/sbin. Ansgar
Burchardt has suggested this file system layout might be made the default
behaviour for future versions of Debian:

“It has been previously suggested to make this the default for (at least) new
installations. I think Russ’ earlier mail explains quite well why the split
between / and /usr doesn’t really work out for Debian these days and that
trying to maintain it for some configurations (which are not documented) is
mostly busy-work. There is also a nice article on LWN summarizing earlier
discussions. I found these arguments convincing enough and would like to see
the default switched to merged-/usr for Stretch and later. Possibly also
switching systems on upgrade to the new scheme (not necessarily already in the
Stretch release cycle).”

Source: [https://lists.debian.org/debian-
devel/2016/09/msg00269.html"](https://lists.debian.org/debian-
devel/2016/09/msg00269.html")

------
anderskaseorg
“Considers” is old news—the Debian installer already merges /usr by default.

[https://lists.debian.org/debian-devel-
announce/2016/11/msg00...](https://lists.debian.org/debian-devel-
announce/2016/11/msg00006.html)

~~~
BuuQu9hu
That got disabled again:

[https://packages.qa.debian.org/d/debootstrap/news/20161116T0...](https://packages.qa.debian.org/d/debootstrap/news/20161116T074831Z.html)

------
reacweb
I use Linux (ubuntu gnome) on my main computer since many years. IMHO,
changing the FHS should be the lowest priority. The priority should be
"hardware support" and "education".

By education, I think mainly about the different way to use Linux compare to
Windows.

Imagine you are traveling and need a file that is at home on your desktop PC.
With your phone, you can wake up your PC, connect using ssh, convert the
document to pdf and copy it to your phone.

Imagine you are visiting a friend and want to show something running on your
PC, you wake up your PC, launch putty and a VNC client (portable applications)
and you are at home.

Imagine you want to keep your machine lean and clean. With docker you can
switch between images of preinstalled independent development environments.
With sshfs, you access your remote website without a local copy.

Imagine you want to change the hard drive. I copy very quickly the very few
files in my home directory that are not on NFS to a NFS backup directory. I
change the disk, reinstall Linux then uses the small installation diary I keep
on google drive to configure disk montages and to reinstall non default
applications.

~~~
ben0x539
I don't think adding symlinks to / takes away a meaningful amount of time from
the people working on drivers.

I think you're gonna have a hard time convincing people these days that the
answer to all the scenarios you listed shouldn't just be "lol cloud", too. :/

~~~
reacweb
Of course, the whole point is that my desktop is part of the network like any
remote server. You are not a client of servers, you are a member of a network.

AFAIK, rdesktop and logmein are far behind (more difficult to setup and to
use).

[https://code.google.com/archive/p/win-
sshfs](https://code.google.com/archive/p/win-sshfs) seems dead.

AFAIK, docker does not work on windows home edition.

My scenarios are not made up. These are my very usual and simple use cases of
linux. I do not know any windows user that do the same. Do you have a backup
copy of your 1TB hard drive on the cloud ?

~~~
ben0x539
I'm not saying your scenarios are made up and I sympathize with them, but I
think most people choose to store their stuff in the cloud so they don't need
to worry about the devices they physically touch.

