From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1Sri4Z-0001X3-HN for garchives@archives.gentoo.org; Thu, 19 Jul 2012 04:10:43 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1C654E055B; Thu, 19 Jul 2012 04:10:19 +0000 (UTC) Received: from mail-pb0-f53.google.com (mail-pb0-f53.google.com [209.85.160.53]) by pigeon.gentoo.org (Postfix) with ESMTP id 5348DE050E for ; Thu, 19 Jul 2012 04:09:41 +0000 (UTC) Received: by pbbrr13 with SMTP id rr13so4125120pbb.40 for ; Wed, 18 Jul 2012 21:09:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding:x-gm-message-state; bh=AzkC89g0Lmek+36gcVVpX7DE9t07K+55ED1af8aRzHs=; b=kTzuXbtmeVWFybLl6pC9bWybPsIniLDuSnNkXDEtXO4YNnT0R5It/0LVGuCM6SPtVv fcAiq0L4CfVCND5BR8dsjXdxeoFL3m/BBsG7uAa6RDpGFv+rNjbngAixkN0Whq57B+WO smfjRG4XD4eeNKVFToHmqqQ0mHB5wuh6gtDvYujnWoQlB0R9nBFqDkZl1oEFI8QgKFAC WCxhIUcqFPPKt6S1UKowqtsNZaJ+p7cDX/ISGEBOKdPlX9Dr8V1Tqt0bvh4GJJ9FbGpj W4KEasfrQHgPU+Sjqq5bHc3ELWS/YfXqaUTHeRD1LVdyNihjQDfn0ZHSJUGWCliFEkpH gOXg== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.68.225.9 with SMTP id rg9mr1595316pbc.137.1342670980610; Wed, 18 Jul 2012 21:09:40 -0700 (PDT) Received: by 10.142.148.1 with HTTP; Wed, 18 Jul 2012 21:09:40 -0700 (PDT) In-Reply-To: <1342663455.18313.71.camel@TesterTop4> References: <5005D70D.3060108@gentoo.org> <1342566449.18313.38.camel@TesterTop4> <50063368.8080106@gentoo.org> <20120718101027.55dd00fe@pomiocik.lan> <5006B7A4.6010202@gentoo.org> <20120718161351.GA19044@serenity.o.westcall.spb.ru> <500729AA.1000309@aol.com> <1342663455.18313.71.camel@TesterTop4> Date: Wed, 18 Jul 2012 21:09:40 -0700 Message-ID: Subject: Re: [gentoo-dev] Opinion against /usr merge From: Matthew Marlowe To: gentoo-dev@lists.gentoo.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQnwAy5/AYV+hmaBGuwbVhJu73C/iCZ6/04c+GSIHbHL3/36zcBN1kyWWawOb5tQ0RTHL+9l X-Archives-Salt: ab39a9c8-967c-4291-9355-6eaed33c9a7a X-Archives-Hash: 93292ed5d711de7e3836d15bffd5f10e On Wed, Jul 18, 2012 at 7:04 PM, Olivier Cr=EAte 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..