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 1SrfUo-00037v-03 for garchives@archives.gentoo.org; Thu, 19 Jul 2012 01:25:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 74E8FE0453; Thu, 19 Jul 2012 01:25:23 +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 6B4F6E02F0 for ; Thu, 19 Jul 2012 01:24:40 +0000 (UTC) Received: by pbbrr13 with SMTP id rr13so3895225pbb.40 for ; Wed, 18 Jul 2012 18:24:39 -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:x-gm-message-state; bh=Sw483UrbBmumM3wl0+MjYDipa3tMrZeklo1HLPsyB3c=; b=R5b4Q3I4VJEaPrhlEs9tfpRofdgsuT7lEQtAX71Lkfux/QPRxrr6BrJYH8lhEguQm9 VLoNABKPJcIW5WKWi1pmPD5IYBT6Efqgn0GvLzfoKqgePu3rLUvIcODdqEClEI2rxAGr 8c6JJGQpIKH3ORyl5bDVymKuqF965N4NpV+uxncxIiH1I10Y80LP91evRjBQqFKcSv4n 4Ry0Z1eOLvlorG5aGBdBhuk+18l/64Tq5kwh09WLL2VoPL3gtsTQdX8WUf1uL1UvsAUE W43244SC0EKIhU+kMrueRPd3dkUQVkQgyWVT1UQ5lDNAtujWdKIaEssAnQ3MfY5F9Mc8 8IaQ== 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.238.68 with SMTP id vi4mr619751pbc.123.1342661079671; Wed, 18 Jul 2012 18:24:39 -0700 (PDT) Received: by 10.142.148.1 with HTTP; Wed, 18 Jul 2012 18:24:39 -0700 (PDT) In-Reply-To: <500729AA.1000309@aol.com> 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> Date: Wed, 18 Jul 2012 18:24:39 -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 X-Gm-Message-State: ALoCoQmEdiGYD9SkwVtoonF3YPkGSNyLU1lgErwBCmfk/nLqoDaUMv7omkeDSAmkbGQl+I5gdkXp X-Archives-Salt: 31772bf7-408c-4166-a250-be14aa6f18f1 X-Archives-Hash: e2d1ce6525327fe61e9a3bc00751e746 > It would be nice if a sensible structure could be proposed and > agreed by ALL Linux distributions (coordinated with BSD). > +1 If a new file system standard is required, my preferences based on a history of what is worked and changed over the last 20-30 years would be: - OK with requiring / and /usr on the same FS. This has become common practice with virtualization and small system deployments, and I haven't seen any compelling advantage for keeping separate on larger boxes. - NOT OK with limitation on allowing /var, /opt, /home, or any other common server mount points to require use of initramfs/initrd. There is enough disagreement as to the reliability and ease of maintenance of initramfs/initrd that it should not be needed for common server deployments. - 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. - Ideally, server motherboards would come with flash based storage where sysadmins could install rescue environments as part of a normal unix install, and that the boot loader or bios would be smart enough to provide the option to boot from it automatically whenever a normal boot failed. - NOT OK with removing the distinction between user and system binaries. Essential binaries required to boot and troubleshoot system problems should be located separately from user binaries. Security sensitive or paranoid admins should be able to make the system binary path read-only or completely remove the user binary directory from roots PATH if they so wish. - 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. - 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. - What other elements can new filesystems like btrfs offer that should be considered? ext3/ext4 has worked great with the older standards...but it essentially mimicked the capabilities of older file-systems that the original unix standards were based on. Btrfs might change our expectations. I'm assuming that btrfs will be the standard production fs in a few years.