Re: [gentoo-dev] Opinion against /usr merge

[Matthew Marlowe]

On Wed, Jul 18, 2012 at 7:04 PM, Olivier Crête <tester@g.o> wrote:
> On Wed, 2012-07-18 at 18:24 -0700, Matthew Marlowe wrote:
>
>> - It would be nice if the rootfs used a snapshot based filesystem and
>> if the bootloader was intelligent enough to easily allow admins to
>> boot to older snapshots as an expectation for any standard modern unix
>> system.
>
> One of the reasons to put everything in /usr is to allow using a
> snapshot based FS, so you can run a system where /usr is read-only and
> where when you can do all upgrade atomically by writing your changes to
> a read-write snapshot and then switch all at once. So you never have any
> half-upgraded package on your system.
>

I understand that RHEL is promoting this system management model, but
I'm not sure it is any way superior than other models that do not
require RO /usr.  Many enterprises today solve the same issue via
automation with puppet, active traffic management via LVS/HA/Load
Balancers, or replace /usr snapshots with virtualization where a new
VM snapshot or clone is upgraded and then replaces the active VM.
Therefore, I'm not convinced we should promote /usr/bin and /usr/sbin
over /bin and /sbin.  It is a point in their favor to give more
flexibility but the simplicity of also just removing /usr would also
be compelling if our goal afterall is to simplify the FHS.

>
>> - OK with merging / and /usr, but in that case...why not just move
>> everything in /usr to /...but limit /sbin to system binaries and /bin
>> to user ones?  This would be horrible for migrations though and
>> possibly confuse many scripts.
>
> The idea of putting everything in /usr instead of / is that you can then
> make /usr read-only and you can share /usr between multiple systems,
> while / is read-write and contains /root and /etc.
>

Most enterprises that need the ability to make /usr RO for canonical
server configs  could just as well get by with automated configuration
management tools (e.g. puppet) and smart hypervisors/SAN storage.
This allows deployment of new servers within minutes and it reflects
at least the true reality that a true controlled system state is a
snapshot of server config files, virtual hardware, and all binaries.
Just making /usr RO is a cheat that might work well for long lived
binary distributions that require major version upgrades anytime
software packages update their config behavior dramatically.  I
haven't found it very helpful for source type systems like Gentoo.  Of
course, others may disagree.

>> - NOT OK with making systemd the default init system anytime in the
>> next few years, it is way too immature and like most major system
>> software changes...probably will take much longer before it really has
>> the standing to propose being a new standard.
>
> I fully expect systemd to be the init system of the next iteration of
> RedHat Enterprise Linux, which is probably the most "enterprise" of all
> distributions, with the most QA and support and everything. It's not a
> side project of dude of his basement, it has the full support of a large
> team of people at RedHat. There has probably already been more testing
> done on systemd today than on OpenRC...
>

Well, we know that systemd will be in the next RHEL release - it was
in their recent roadmap presentation.  However, that release would be
RHEL7 and most established servers are RHEL5 now and RHEL6 is still
relatively early in deployment.  It will be a few years before most
RedHat customers can say whether systemd was a good move for RHEL.
And, RedHat has made changes in the past that while supported might
not become the default config for other distributions (e.g. SE Linux).
 I don't see that we need to assume now that systemd will define the
default Linux ecosystem in the future, even if it becomes widely
deployed on RedHat systems..