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.60) (envelope-from ) id 1S7GSU-0005Fn-Lq for garchives@archives.gentoo.org; Tue, 13 Mar 2012 01:23:26 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 831EAE0AB0; Tue, 13 Mar 2012 01:23:16 +0000 (UTC) Received: from qmta10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by pigeon.gentoo.org (Postfix) with ESMTP id 1539CE0A7F for ; Tue, 13 Mar 2012 01:22:40 +0000 (UTC) Received: from omta04.emeryville.ca.mail.comcast.net ([76.96.30.35]) by qmta10.emeryville.ca.mail.comcast.net with comcast id kpMG1i0020lTkoCAApNgYh; Tue, 13 Mar 2012 01:22:40 +0000 Received: from [192.168.1.13] ([76.106.69.86]) by omta04.emeryville.ca.mail.comcast.net with comcast id kpNd1i01S1rgsis8QpNfz2; Tue, 13 Mar 2012 01:22:40 +0000 Message-ID: <4F5EA152.80604@gentoo.org> Date: Mon, 12 Mar 2012 21:22:26 -0400 From: Joshua Kinard User-Agent: Mozilla/5.0 (Windows NT 6.0; WOW64; rv:10.0) Gecko/20120129 Thunderbird/10.0 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 To: gentoo-dev@lists.gentoo.org Subject: [gentoo-dev] Let's redesign the entire filesystem! [was newsitem: unmasking udev-181] References: <20120311022706.GA26296@linux1> <4F5C1BE9.3040609@gentoo.org> <20120311173355.GB6599@linux1> In-Reply-To: <20120311173355.GB6599@linux1> X-Enigmail-Version: 1.3.5 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8B87D8CA36592EA54C655E58" X-Archives-Salt: 58cb04d9-878f-4f21-9eac-42007005a082 X-Archives-Hash: c1abc6544b2a47c4faaf665e56517458 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8B87D8CA36592EA54C655E58 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 03/11/2012 13:33, William Hubbs wrote: > I highly discourage moving more things to /. If you google for things = > like, "case for usr merge", "understanding bin split", etc, you will > find much information that is very enlightening about the /usr merge an= d > the reasons for the /bin, /lib, /sbin -> /usr/* split. >=20 > I'll start another thread about this farely soon, but for now I'll say = > that even though Fedora is a strong advocate of the /usr merge, it > didn't start there. Solaris started this 15 years ago, and I think it > would be a good thing for gentoo to implement the /usr merge at some > point to make us more compatible with other unixes. Another thing to ad= d > is that it appears that at least Fedora and Debian are doing this. On a somewhat sarcastic note, why don't we just deprecate /usr and move everything back to /? Isn't that, largely, what is being accomplished he= re? Solaris at least keeps some kernel stuff in / off of /stand (I believe).= Linux, after this /usr thing is fully complete, about the only thing left= in / that is of any value will be /etc. Kernels were moved into /boot ages = ago. I mean, what really is / in the literal sense? It's the first filesystem= that the kernel mounts. If you put everything into /usr, including the i= nit scripts and /etc, create a few stub mount points for /var, /tmp, etc (assuming those are separate partitions), then told the kernel that /usr = is /, what's the real difference? So I think Fedora's approach, while copyi= ng existing behavior from Solaris, is partially broken in this regard. We should be working to getting rid of /usr and bring it all back into /,= then create temporary /usr symlinks to point programs in the right direction. After all, /usr was originally for user data, not system data= , until someone cooked up /home (I don't know the full exact history here, = so feel free to correct me). Heck, why not redesign the original root filesystem layout while we're at= it? / - Root. /boot - Kernels, bootloader. /apps - Installed, non-system critical applications. Merges /bin, /sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and all of its multilib variants. /core - System-critical apps needed to get the system into a MINIMAL, usable state (core device detection, mounting disks, etc) /conf - System configuration data. /dev - Device nodes. /home - User stuff. /data - Variable data. /var's new name. /tmp - System-wide temp dir. /virt - virtual filesystems (proc, sys, ramfs). /svcs - Data dir for services (Apache, LDAP, FTP, etc). /ext - holds mount points for external devices (merges /mnt & /media). /root - Superuser's /home. =46rom that, for the new proposed directories: /apps/sys/bin - System binaries. Only non-critical, system-wide binaries= go here. /apps/sys/lib - Like /apps/sys/bin above. Except this can also be duplicated for multilib (lib32, lib64, lib128, etc). /apps/std/bin - Standard program binaries for all non-system, non-critica= l binaries. /apps/std/lib - Like /apps/std/bin above. Ditto for multilib. /apps/local - If on a stand-alone system, this is a symlink to /apps/st= d. otherwise, this holds a bin/lib folder that is only for a= pps installed locally, while /apps/std might be a network mou= nt that holds apps common to multiple systems of the same/similar type of install. /core/bin - Critical system, binaries needed to get the system into a= minimally-usable state. Predominantly occupied by variou= s filesystem tools. /core/lib - Libraries, usually static, to support /core/bin. Can be multilib, but a system should have a single ABI that can successfully boot the userland components of the system. /core/inf - Holds minimal information to identify and locate boot-critical devices, typically in the form of a small database of some design, but which can be parsed with no additional dependencies. /core/init - Home of your init system of choice, including all the information needed for various run levels, etc. Its sub-layout is dependent on the particular init system tha= t is installed. /conf - Basically a rename of /etc. The "etc" name doesn't convey any useful information to a user anymore about its= true purpose. /conf, however, does. Files stored here will largely be comprised of text files that configure various system services. Like /etc, it's sub-layout will= probably be a complete, unrestrained mess. /virt - Everyone loves virtual filesystems. When there was just /proc, everything was alright. Then /sys comes along, an= d now we've polluted the / namespace with two virtual filesystems. /virt provides a home for those (so /virt/p= roc and /virt/sys), in addition to others like /virt/shm, and /virt/pts, or even /virt/ramfs if you want. Anything= in here doesn't physically exist, and either changes rapi= dly or is lost once the system loses power. /data - Like "etc", /var's original function has been largely overridden and hardly contains "variable" data anymore. thus, it is reborn as /data, which conveys *exactly* what= it is for -- data of some kind, whose presence may be permanent or transitory. Mail spools, caches, print spoo= ls, whatever. Fill it with data from /dev/urandom if you wan= t! /svcs - Like /srv, which some people are resistant to using. The= original idea is quite a marvel, though, because it never= really made any sense to stick Apache into /var/www, or h= ang the TFTP boot directory off of /, or chroot BIND inside o= f /etc or /var (or both). /ext - A place for external mounts, either filesystems or device= s. NFS, CD-ROMs, thumb drives, Samba/CIFS, etc, it goes here= =2E This replaces both /mnt and /media, the only difference between the two being the same as the difference between two shades of purple. The only exception to this rule is= /apps/local above. All other directories retain their original, standard functionality. I thought this up on a whim, it hasn't been tested nor vetted. It's larg= ely meant as a joke, but also to provoke discussion on the current filesystem= design and the direction we're getting pulled in with Fedora's declaratio= n that separate /usr is broken. I don't think it is and I don't find their= argument very convincing, and probably never will. At some point after this change becomes fully adopted (and it will, trust= me), the difference between the / of old and /usr will be so minor, that = you could probably move a few files around, chop /usr off into a separate partition, and then pass root=3D/dev/, and bring a system = fully online, *without a /usr*. And then, after that, someone will come along = and propose "the new /usr", and the cycle repeats. But I do, hesitantly, agree that the standard UNIX filesystem has a lot o= f "traditions" to it that don't make a lot of sense anymore. It's a hallma= rk of an era where machines usually kept a local copy of stuff needed to sta= rt or stop themselves. Now we're in an era where machines aren't even physi= cal anymore. The location of actual data is somewhat meaningless, if you wri= te a program correctly and don't hardcode filesystem paths. So it's probably time to have some kind of a discussion on the filesystem= , and what would need to change to bring it up to date with the era of large-scale virtualization and embedded systems that run on your wristwat= ch, in addition to the standard black (or beige) box sitting on a desk somewh= ere. Food for thought. And yes, I've already tested out udev-181 on a VM with= a separate /usr. With devtmpfs, the system fully boots just fine, no initramfs needed. Guess what the only piece of software to mess up is? Udev. I largely think it's a timing issue in OpenRC, however, because /u= sr DOES get mounted fairly quickly, but not before udevd starts. But udevd does restart itself and everything looks to work fine. If you aren't watching the terminal, you wouldn't even notice the failures. Cheers, --=20 Joshua Kinard Gentoo/MIPS kumba@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. A= nd our lives slip away, moment by moment, lost in that vast, terrible in-bet= ween." --Emperor Turhan, Centauri Republic --------------enig8B87D8CA36592EA54C655E58 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (MingW32) iQIcBAEBAgAGBQJPXqFZAAoJENsjoH7SXZXjZzkP/1UDi27bgXsb5fdS6ItBeAxL kFpidN0efIA4FPkGIFsHSh69Q4zdEwz5NRLB349s2PUQCDqv8SQ7Q5Mwr+tTOHBU nqfur8g4dyyldVfzsXG0w8FeJFc8zlqOA0Fi97FDcl8TWGk7uJAyUBxgLVAXQxQy BJfVBGhCucNQyzM7DTNKqWWKM/N91VaJdW3BN3oE1EwVG6ChS0igFlrYdxW/mVz+ x/7barhTBXZ9cZ0uuFJHm1nh9xm05h+RqirHzzZQbKI9x4Ksdc7p3/ZA7+ep4UBf QVOT0pYE1QYQNfIOx8Rkr3YW/JQs4nzqOnjTSmpCSjK4tL0LDMzn+2p1O9yj+Cml WOOt/yjmfkro8V7jnHvycsiutQ5jSDLGtiIluWV7A9iaGE4zwThG1Gij+SqCmtk2 g8sXWMr7LBVbrFksjxtjpy/n8r7WxgJ4zV0NM9jTVawN5VST4SVnPnSyrVw6+/oS rxI6NyiHHKqZL1iyLtTvAMnfXXldoztEoaonM6+02sAmUdijhhSm4nSodxoD9tRS zeI/BRN5QwwDraScM/QN4pzJV/1/IdSVrQSf1YUUuMN4IvUX7pOekA2RQBXOgFyq 0kTlFoSgxyOOuAj+ezuXz0Wl0CqT+kUCFSoHWrvVnZvmStloVppx1q7vfcKNDPch LwISqL7V2CQy5iKlXuW7 =Dijf -----END PGP SIGNATURE----- --------------enig8B87D8CA36592EA54C655E58--