
Debian putting everything on the /usr - tambourine_man
http://www.theregister.co.uk/2016/11/24/debian_testing_merged_codeusrcode/?mt=1480127476882
======
Sanddancer
In my opinion, this is getting rid of a minor historical relic, instead of the
major relic of Linux booting. That ugly hack known as initramfs should have
been obsoleted at least ten years ago. It was useful back when you had to
worry about keeping all your boot files below the 2gb mark on a disk, but
these days, all it does is create a second, ephemeral, userland in a more
difficult to debug container. Put the various boot binaries into /bin and
/sbin, statically linked, and completely visible to even the running system.
Cleaning relics should start with getting rid of entire filesystems that just
make it harder to administer a system.

~~~
phs2501
initramfs isn't (and wasn't) at all about keeping your boot files below the
2gb mark on a disk. It's about actually mounting your root filesystem, either
on a fully-modularized kernel where all of your (hundreds of) block drivers
are in modules, or where root is coming over a network block device, or a USB
disk, or a SAN, or a complex RAID, or an encrypted disk where you need to
enter a password or use a hardware token or whatever.

Basically, rather than encoding tons and tons of crazy special-purpose logic
into the kernel to mount every insane iteration of root filesystem, you just
get the bootloader to stick a CPIO image in RAM for the kernel to get at and
then use the normal userland tools to do what you want.

IMHO, initramfs is the opposite of an ugly hack.

~~~
drvdevd
Though I take your point and mostly agree, is there any reason this _couldn
't_ be done with a static boot binary entirely in RAM? Since the kernel is
modular anyway, much of the special purpose cruft loaded by the initramfs
could just be loaded and unloaded with a boot script of some kind right? I
mean: it could all sit on the same filesystem without having a CPIO image on
disk? Grub supports pretty much every filesystem already so loading this
initial kernel image from the network or wherever could just start there.

~~~
dfox
Mounting root file system might nowadays conceivably involve some non-trivial
userspace code that never even was implemented in kernel space. Few examples:

\- Searching for root filesystem based on it's contents (in simple case UUID,
but mechanisms like "contains this file" are used sometimes) instead of
"physical" location \- Encrypted root filesystem (requires some kind of UI for
entering the passphrase) \- LVM2 (which is set of userspace utilities that
configure more general kernel modules that know nothing about the actual on-
disk format) \- while there is slightly hackish kernel support for configuring
network interfaces before having userspace and mounting rootfs from NFS, such
thing cannot possibly deal with all variants of network configuration (eg.
VLANs, 802.1x, ...) and possible network filesystems/block devices. \- root on
ramdisk, copy-on-write overlay filesystem or something like that.

To summarize: it's entirely possible to have the system boot of PXE,
authenticate via WPA-EAP on wifi and fetch it's own root filesystem into
ramdisk via HTTPS while storing writes onto NFS somewhere. Implementing all
which is required for that in kernel space is neither possible nor useful.

By the way, the point of initramfs is that it is loaded into memory by
bootloader using whatever means the bootloader has and the image does not have
to be on rootfs accessible to kernel (for PXE it typically isn't).

~~~
drvdevd
Ok. That's a great summary and good point about non-trivial userspace bits. I
hadn't considered how complex "booting" as a process has become...

------
parent5446
What's the point? Why not do it the other way around and put everything in
/bin? It almost feels like /usr is the new root.

~~~
duskwuff
1\. Less disruption. Most software is already installed to /usr.

2\. Installing all software to /usr means that /usr can be made read-only when
not installing/upgrading software. This isn't possible if installing to the
root, as directories like /etc and /var have to be left writable.

~~~
pkaye
Do you mean the partition containing /usr will be mounted ad read-only?

~~~
saalaa
He said _can be made_ , that's an option.

------
gkafkg8y8
So, I'm of two minds on this:

On one hand, I'd go farther. I like apt, but I wish that distros would use the
same packaging system and same package format. There is little value to them
being different between distros, it just causes more work for
repackaging/deployment/config. Even distros that build everything could all do
that the same way, so any distro and its apps could be fully built from
source, if the source is available.

On the other hand, this isn't great. Having variety in paths, although it's
basically security via obscurity like using non-standard ports, is still an
additional level of security. And think of all of the existing
config/repackaging scripts/etc. that will fail.

But, I'm not an admin nor in devops, so I'll defer to those that actually are
impacted...

~~~
daenney
_On one hand, I 'd go farther. I like apt, but I wish that distros would use
the same packaging system and same package format_

I agree however that's rather off topic. This is not about harmonising between
Linux distributions. The fact that other distros did it is merely used as an
argument to show it's possible and without any major issues for anyone
involved.

 _Having variety in paths, although it 's basically security via obscurity
like using non-standard ports, is still an additional level of security._

No, it isn't. The way you find binaries (when paths aren't hard coded) is by
looking through the $PATH environment variable. Both /usr/bin and /bin are
part of that on any Linux distro so there is no obscurity or any kind of
security gained from this. Though the advantage of having everything in
/usr/bin is that /usr can be mounted read-only meaning an attacker will have a
much harder time modifying the binaries initially (unless they can do some
local privilege escalation and remount the partition).

 _And think of all of the existing config /repackaging scripts/etc. that will
fail._

They won't. Even those with hardcoded paths to things in /bin won't be
affected since usrmerge will provide the symlinks for those binaries. And
anything properly written will be searching for binaries through $PATH and be
equally unaffected. There's a few crucial tools that will likely need to be
updated to be aware of this change but the Debian project will take care of
those.

~~~
gkafkg8y8
You seem convinced that $PATH handles everything. That's not accurate.
Deployment scripts can make automated changes to config files and need paths.
One package assumes a hardcoded path for another package- typically a symlink,
but if those symlinks are moving around, that could break.

And the package management system isn't off-topic if one of the reasons for
moving paths is to become more standard. Apt, Yum, Pacman, etc. all have
different ways of doing things, and if the goal is to become more standard,
then you have to wonder why the Linux community has not banded together on a
single packaging system standard.

~~~
daenney
_Deployment scripts can make automated changes to config files and need
paths._

And proper deployment systems can handle this. Or it's templated and can be
changed with a single variable. We're also not talking about every possible
binary ever, we're only talking about /bin which is a limited and well-known
set of things, for which symlinks will exist. It will not affect any piece of
software ever and associated configuration files, the blast radius is very
small and well understood.

 _And the package management system isn 't off-topic if one of the reasons for
moving paths is to become more standard._

That's not the reason. The reason the move is happening is because there is no
real point in having /bin and /usr/bin separate. It's a historical relic which
offers very little benefit to users and is largely confusing to newcomers.
Debian isn't making the move to standardise with what other distro's are
doing, they're doing it b/c it makes sense for their users. It just so happens
that others have come to the same conclusion and since they've made that
change before we can learn from how and why they did it.

 _then you have to wonder why the Linux community has not banded together on a
single packaging system standard._

You should read up on how dpkg and rpm were created, and why every other
package format and package manager ever has been too. Besides the history,
every single one of them has their flaws and issues. If we had one that was
perfect, that solved every single issue related to package management ever, in
a platform independent way that we can all agree on I'm pretty sure everyone
would be using it. I'm all ears for proposals though, but so far any time this
has been attempted it hasn't gotten anywhere. And this is a completely
different domain than moving /bin around.

