1 |
On 03/11/2012 13:33, William Hubbs wrote: |
2 |
|
3 |
> I highly discourage moving more things to /. If you google for things |
4 |
> like, "case for usr merge", "understanding bin split", etc, you will |
5 |
> find much information that is very enlightening about the /usr merge and |
6 |
> the reasons for the /bin, /lib, /sbin -> /usr/* split. |
7 |
> |
8 |
> I'll start another thread about this farely soon, but for now I'll say |
9 |
> that even though Fedora is a strong advocate of the /usr merge, it |
10 |
> didn't start there. Solaris started this 15 years ago, and I think it |
11 |
> would be a good thing for gentoo to implement the /usr merge at some |
12 |
> point to make us more compatible with other unixes. Another thing to add |
13 |
> is that it appears that at least Fedora and Debian are doing this. |
14 |
|
15 |
|
16 |
|
17 |
On a somewhat sarcastic note, why don't we just deprecate /usr and move |
18 |
everything back to /? Isn't that, largely, what is being accomplished here? |
19 |
Solaris at least keeps some kernel stuff in / off of /stand (I believe). |
20 |
Linux, after this /usr thing is fully complete, about the only thing left in |
21 |
/ that is of any value will be /etc. Kernels were moved into /boot ages ago. |
22 |
|
23 |
I mean, what really is / in the literal sense? It's the first filesystem |
24 |
that the kernel mounts. If you put everything into /usr, including the init |
25 |
scripts and /etc, create a few stub mount points for /var, /tmp, etc |
26 |
(assuming those are separate partitions), then told the kernel that /usr is |
27 |
/, what's the real difference? So I think Fedora's approach, while copying |
28 |
existing behavior from Solaris, is partially broken in this regard. |
29 |
|
30 |
We should be working to getting rid of /usr and bring it all back into /, |
31 |
then create temporary /usr symlinks to point programs in the right |
32 |
direction. After all, /usr was originally for user data, not system data, |
33 |
until someone cooked up /home (I don't know the full exact history here, so |
34 |
feel free to correct me). |
35 |
|
36 |
Heck, why not redesign the original root filesystem layout while we're at it? |
37 |
|
38 |
/ - Root. |
39 |
/boot - Kernels, bootloader. |
40 |
/apps - Installed, non-system critical applications. Merges /bin, |
41 |
/sbin, /usr/{bin,sbin}, /usr/local/{bin,sbin}, and /lib and |
42 |
all of its multilib variants. |
43 |
/core - System-critical apps needed to get the system into a MINIMAL, |
44 |
usable state (core device detection, mounting disks, etc) |
45 |
/conf - System configuration data. |
46 |
/dev - Device nodes. |
47 |
/home - User stuff. |
48 |
/data - Variable data. /var's new name. |
49 |
/tmp - System-wide temp dir. |
50 |
/virt - virtual filesystems (proc, sys, ramfs). |
51 |
/svcs - Data dir for services (Apache, LDAP, FTP, etc). |
52 |
/ext - holds mount points for external devices (merges /mnt & /media). |
53 |
/root - Superuser's /home. |
54 |
|
55 |
|
56 |
From that, for the new proposed directories: |
57 |
|
58 |
/apps/sys/bin - System binaries. Only non-critical, system-wide binaries |
59 |
go here. |
60 |
/apps/sys/lib - Like /apps/sys/bin above. Except this can also be |
61 |
duplicated for multilib (lib32, lib64, lib128, etc). |
62 |
|
63 |
/apps/std/bin - Standard program binaries for all non-system, non-critical |
64 |
binaries. |
65 |
/apps/std/lib - Like /apps/std/bin above. Ditto for multilib. |
66 |
|
67 |
/apps/local - If on a stand-alone system, this is a symlink to /apps/std. |
68 |
otherwise, this holds a bin/lib folder that is only for apps |
69 |
installed locally, while /apps/std might be a network mount |
70 |
that holds apps common to multiple systems of the |
71 |
same/similar type of install. |
72 |
|
73 |
/core/bin - Critical system, binaries needed to get the system into a |
74 |
minimally-usable state. Predominantly occupied by various |
75 |
filesystem tools. |
76 |
/core/lib - Libraries, usually static, to support /core/bin. Can be |
77 |
multilib, but a system should have a single ABI that can |
78 |
successfully boot the userland components of the system. |
79 |
/core/inf - Holds minimal information to identify and locate |
80 |
boot-critical devices, typically in the form of a small |
81 |
database of some design, but which can be parsed with |
82 |
no additional dependencies. |
83 |
/core/init - Home of your init system of choice, including all the |
84 |
information needed for various run levels, etc. Its |
85 |
sub-layout is dependent on the particular init system that |
86 |
is installed. |
87 |
|
88 |
/conf - Basically a rename of /etc. The "etc" name doesn't |
89 |
convey any useful information to a user anymore about its |
90 |
true purpose. /conf, however, does. Files stored here |
91 |
will largely be comprised of text files that configure |
92 |
various system services. Like /etc, it's sub-layout will |
93 |
probably be a complete, unrestrained mess. |
94 |
|
95 |
/virt - Everyone loves virtual filesystems. When there was just |
96 |
/proc, everything was alright. Then /sys comes along, and |
97 |
now we've polluted the / namespace with two virtual |
98 |
filesystems. /virt provides a home for those (so /virt/proc |
99 |
and /virt/sys), in addition to others like /virt/shm, |
100 |
and /virt/pts, or even /virt/ramfs if you want. Anything |
101 |
in here doesn't physically exist, and either changes rapidly |
102 |
or is lost once the system loses power. |
103 |
|
104 |
/data - Like "etc", /var's original function has been largely |
105 |
overridden and hardly contains "variable" data anymore. |
106 |
thus, it is reborn as /data, which conveys *exactly* what |
107 |
it is for -- data of some kind, whose presence may be |
108 |
permanent or transitory. Mail spools, caches, print spools, |
109 |
whatever. Fill it with data from /dev/urandom if you want! |
110 |
|
111 |
/svcs - Like /srv, which some people are resistant to using. The |
112 |
original idea is quite a marvel, though, because it never |
113 |
really made any sense to stick Apache into /var/www, or hang |
114 |
the TFTP boot directory off of /, or chroot BIND inside of |
115 |
/etc or /var (or both). |
116 |
|
117 |
/ext - A place for external mounts, either filesystems or devices. |
118 |
NFS, CD-ROMs, thumb drives, Samba/CIFS, etc, it goes here. |
119 |
This replaces both /mnt and /media, the only difference |
120 |
between the two being the same as the difference between |
121 |
two shades of purple. The only exception to this rule is |
122 |
/apps/local above. |
123 |
|
124 |
All other directories retain their original, standard functionality. |
125 |
|
126 |
|
127 |
I thought this up on a whim, it hasn't been tested nor vetted. It's largely |
128 |
meant as a joke, but also to provoke discussion on the current filesystem |
129 |
design and the direction we're getting pulled in with Fedora's declaration |
130 |
that separate /usr is broken. I don't think it is and I don't find their |
131 |
argument very convincing, and probably never will. |
132 |
|
133 |
At some point after this change becomes fully adopted (and it will, trust |
134 |
me), the difference between the / of old and /usr will be so minor, that you |
135 |
could probably move a few files around, chop /usr off into a separate |
136 |
partition, and then pass root=/dev/<where /usr is>, and bring a system fully |
137 |
online, *without a /usr*. And then, after that, someone will come along and |
138 |
propose "the new /usr", and the cycle repeats. |
139 |
|
140 |
But I do, hesitantly, agree that the standard UNIX filesystem has a lot of |
141 |
"traditions" to it that don't make a lot of sense anymore. It's a hallmark |
142 |
of an era where machines usually kept a local copy of stuff needed to start |
143 |
or stop themselves. Now we're in an era where machines aren't even physical |
144 |
anymore. The location of actual data is somewhat meaningless, if you write |
145 |
a program correctly and don't hardcode filesystem paths. |
146 |
|
147 |
So it's probably time to have some kind of a discussion on the filesystem, |
148 |
and what would need to change to bring it up to date with the era of |
149 |
large-scale virtualization and embedded systems that run on your wristwatch, |
150 |
in addition to the standard black (or beige) box sitting on a desk somewhere. |
151 |
|
152 |
Food for thought. And yes, I've already tested out udev-181 on a VM with a |
153 |
separate /usr. With devtmpfs, the system fully boots just fine, no |
154 |
initramfs needed. Guess what the only piece of software to mess up is? |
155 |
Udev. I largely think it's a timing issue in OpenRC, however, because /usr |
156 |
DOES get mounted fairly quickly, but not before udevd starts. But udevd |
157 |
does restart itself and everything looks to work fine. If you aren't |
158 |
watching the terminal, you wouldn't even notice the failures. |
159 |
|
160 |
Cheers, |
161 |
|
162 |
-- |
163 |
Joshua Kinard |
164 |
Gentoo/MIPS |
165 |
kumba@g.o |
166 |
4096R/D25D95E3 2011-03-28 |
167 |
|
168 |
"The past tempts us, the present confuses us, the future frightens us. And |
169 |
our lives slip away, moment by moment, lost in that vast, terrible in-between." |
170 |
|
171 |
--Emperor Turhan, Centauri Republic |