On Wed, Jul 18, 2012 at 7:04 PM, Olivier Crête <[email protected]> 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..
