1 |
On Sun, Aug 28, 2016 at 8:34 AM, Patrick Lauer <patrick@g.o> wrote: |
2 |
> |
3 |
> Then tools forgot to properly update mtab because hurr why u no symlink |
4 |
> to /proc/mounts (oh wait, /proc/self/mounts ) |
5 |
> |
6 |
> So everyone migrated to /etc/mtab as a symlink (even OpenRC, because |
7 |
> everyone does it) |
8 |
> |
9 |
|
10 |
I think containers were the final straw here (which strangely you do |
11 |
not mention). Good luck running openrc in a container with /etc/mtab |
12 |
as a file, especially if you want to share /etc across multiple |
13 |
containers. |
14 |
|
15 |
Ultimately though this all comes down to the fact that files are a |
16 |
pretty lousy way to store state of a running system, especially when |
17 |
there are system calls to retrieve this state. |
18 |
|
19 |
Sure, files are a nice place to store static configuration that gets |
20 |
loaded into the state of a running system, since they're persistent. |
21 |
The problem comes when software reads the files and assumes that they |
22 |
ARE the state. |
23 |
|
24 |
/etc should be for storing static configuration. Processes shouldn't |
25 |
generally be writing to anything there. You should be able to mount |
26 |
/etc read-only without much issue. With the rise of containers and |
27 |
configuration management and software-defined infrastructure and so on |
28 |
this becomes increasingly important. |
29 |
|
30 |
There is value in neither changing for the sake of change, or |
31 |
remaining the same for the sake of the past. Many historical |
32 |
practices in the Unix world are inconsistent and it makes sense to |
33 |
keep moving in the direction of making them consistent (like mtab, |
34 |
having dhcpd modify /etc/resolv.conf, and so on). Gentoo should make |
35 |
similar sorts of changes (like not sticking the Gentoo repo in /usr, |
36 |
and we probably shouldn't name it portage either). |
37 |
|
38 |
There are also many historical practices in the Unix world that maybe |
39 |
aren't pretty, but we probably ought not to change them just for the |
40 |
sake of doing so without driving the change across distros (and I |
41 |
think /etc/hostname strikes me as one of these; having more of the |
42 |
host-level configuration in one place does make sense, but moreso if |
43 |
everybody does it the same way). Lots of distros actually try to move |
44 |
configuration to one place, but they do it inconsistently and it seems |
45 |
like somebody should be able to fix this (though you may find the |
46 |
demand for consistency ends up getting satisfied by systemd to some |
47 |
extent, simply due to its ubiquity). |
48 |
|
49 |
I think williamh's approach of using hostname if it exists, and |
50 |
falling back to conf.d is a pretty sane compromise. |
51 |
|
52 |
-- |
53 |
Rich |