On Thu, Apr 7, 2016 at 10:44 PM, M. J. Everitt <m.j.ever...@iee.org> wrote: > 2) "Today, a separate /usr partition already must be mounted by the > initramfs during early boot, thus making the justification for a > split-off moot." - no, not all gentoo users have an initramfs and > need/want one .. so this is a false assumption.
You only need an initramfs (or some other mechanism to mount /usr during early boot) if /usr is on a different filesystem than /. If /usr is a separate filesystem, then Gentoo does require that it be mounted during early boot, at least as a supported configuration. While it is true today that with some configurations you can probably get away with not mounting it during early boot, there is no requirement that package maintainers support this. That includes system packages. So, #2 applies to Gentoo as much as to any other distro. That was a topic of some debate a few years ago now. > 3) I still believe there is merit in distinguishing between binaries > that can/should be run as root, and those that can/should not. Those > that run as root 100% of the time, or use VMs, don't really 'use' linux > in the original sense of the OS .. Duncan already explained much of this, but if you're relying on a user's PATH setting to prevent security issues you're doing it wrong. There are a number of binaries in /sbin which are completely appropriate for a non-privileged user to execute. Besides non-privileged operations of binaries like btrfs or rpcinfo, there are a bunch of misc binaries in there like usleep or zdump. Really though the main point of merging these paths into /usr is to get all the static content of a distro into a single path, which can then be maintained as a read-only filesystem, mounted across multiple systems, protected using tripwire or signature checking, and so on. As has been pointed out the rolling release nature of Gentoo reduces some of these benefits somewhat. To truly get these benefits we would also need to rethink how post-install configuration gets managed as was already pointed out. However, the principle is still a potentially useful one even if we never follow-up with some of the things Fedora/etc are doing. After a merge the package manager has free rein over /usr, full config management is the policy in /etc, and /var is a place for persistent state that generally belongs to the applications themselves (but management of this is a bit of a mix still with stuff like /var/www and /var/bind alongside mail spools and mysql database files). -- Rich
