Bug#1035904: What does merged /usr bring us
Hi.
Off list, I wanted to try to explain what I think merged /usr has
brought us that is positive.
I want to stress that I'm not a huge fan of merged /usr, and I know
you've encouraged me not to argue from a devil's advocate position in
the past.
All the things I cite here are things I actually think are a positive
value, but I fully agree they do not justify the change to me.
* Normalization of paths. Whether things ended up in /usr/bin or /bin
tended to vary between unixes and especially between linux distros.
That has produced a lot of complexity over the years in build systems.
But it's also produced a lot of non-portable software--stuff written
either for Redhat or Ubuntu that manages to get the path wrong for the
other, and doesn't have the complexity of something like autoconf to
detect the change.
It's kind of nice to ignore all that.
* There's work, from people related to the systemd crowd, to effectively
get to a place where the initial state of a system is very close to
empty with a few symlinks and a read-only /usr. And then possibly
things get filled in a bit on first boot if necessary. So, for
example the systemd style split of /usr/lib/systemd/system vs
/etc/systemd/system where the /etc path generally gets to be empty at
least initially is part of this.
In some ways it reminds me of how AIX dealt with diskless
workstations. (I realize that's based on how Sun did it, but I never
dove into SunOS or Solaris as deep as AIX).
The goal is more for containers or for deploying updates to EOT
devices than for diskless.
The ideais kind of cool.
The updater/installer/container creater knows very little and can
start with an initial state.
It's easy to figure out what has been customized because anything in
/etc is a customization.
doing a factory reset is fairly easy.
It works well with signed OS images and ostree for deploying updates/the
sort of thing Endless does.
And yet there are probably other ways to get all the same benefits.
--Sam
Reply to: