Gentoo Archives: gentoo-user

From: Volker Armin Hemmann <volkerarmin@××××××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim
Date: Sun, 29 Sep 2013 22:47:50
Message-Id: 5248AE0A.5070603@googlemail.com
In Reply to: Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim by "Francisco Blas Izquierdo Riera (klondike)"
1 Am 29.09.2013 18:41, schrieb Francisco Blas Izquierdo Riera (klondike):
2 > El 29/09/13 18:03, Volker Armin Hemmann escribió:
3 >> Am 29.09.2013 17:12, schrieb Greg Woodbury:
4 >>> On 09/29/2013 07:58 AM, Volker Armin Hemmann wrote:
5 >>>
6 >>>> things were broken way before that. As much as I hate systemd, it is not
7 >>>> the root cause of the problem.
8 >>>>
9 >>>> The problems were caused by people saying that seperate /usr was a good
10 >>>> idea, so / would not fill up and similar idiocies. The problems were
11 >>>> caused by people saying that lvm is a good idea - for desktops. Those
12 >>>> people who are fighting against the kernel auto assembling raids are to
13 >>>> blame too.
14 >>>>
15 >>>> Systemd is just another point in a very long list.
16 >>>>
17 >>> The usr filesystem was separate from root from the very early days of
18 >>> UNIX. Disks were *tiny* (compared to today) and spreading certain
19 >>> things across separate spindles provided major benefits. Certainly,
20 >>> the original need to require a separate usr went away fairly quickly,
21 >>> but other benefits continued to encourage a seperation between root
22 >>> and usr.
23 >>>
24 >> in the very early days /usr did not exist in the first space and was
25 >> only created because someone added a harddisk.
26 >>
27 >> Not really a good reason to keep it around.
28 > I'm going to show the lack of sense of this argument:
29 > in the very early days linux did not exist in the first space and was
30 > only created because someone got a 386.
31 >
32 > Not really a good reason to keep it around.
33
34 wrong analogy and it goes down from here. Really.
35 >
36 > in the very early days GNU did not exist in the first space and was
37 > only created because someone jammed a printer.
38 >
39 > Not really a good reason to keep it around.
40 >
41 > in the very early days Gentoo did not exist in the first space and was
42 > only created because someone added a processor.
43 >
44 > Not really a good reason to keep it around.
45 >
46 > in the very early days hardening did not exist in the first space and was
47 > only created because someone added security.
48 >
49 > Not really a good reason to keep it around.
50 >
51 > in the very early days Gnome did not exist in the first space and was
52 > only created because someone got a graphics card.
53 >
54 > Not really a good reason to keep it around.
55 >
56 > I'm sure you'll be able to figure out the pattern there.
57 >
58 > Ohh and BTW, /usr was not just added because someone added a harddrive,
59 > in most cases it was used to allow machines contain a very small system
60 > on / which was enough to just boot and mount a networked system (/usr)
61 > containing most of the software. This allowed for cheaper deployment of
62 > machines since the hard drive could be smaller as it wouldn't need to
63 > have all the data locally. Yeah, if this sounds familiar is because this
64 > was later moved to initramfs.
65
66 no, network'ed file systems came a lot later.
67 Initially /usr was added because one harddisk was full. Really, that is
68 the whole reason for its (broken) existance.
69
70
71 >
72 >>> The var filesystem was for variable system data, and was never
73 >>> terribly big and its inclusion on the root volume happened. The home
74 >>> filesystem became traditionally separate because data expands to fill
75 >>> all availab;e space, and users collect *things*
76 >> and a seperate /home does not create any problems.
77 >> /var is much more prone to accidentally fill up then /usr ever was.
78 > You are jst getting it wrong, /var was kept locally as the data there
79 > was supposed to change from machine to machine.
80
81 no, you just don't understand what I wrote.
82 People told other people to keep /usr seperate so / may not fill up by
83 accident.
84
85 That advise always was murky at best. Outright stupid is a good
86 description too.
87
88 /usr is not prone to much changes. So if your / fits the contents of
89 /usr just fine, there is pretty much no risk.
90 /var on the other hand tends to explode - but a lot of people never got
91 told to put /var on a seperate disk.
92
93 If you ever realized that a tens of gigabyte logfile just made your box
94 unbootable, you learnt a lot that day.
95 >>> Networking made it possible to have home entirely off system, and
96 >>> diskless worstations ruled for a while as well.
97 >>>
98 >>> By the time Linux came along, it had become common for boot volumes to
99 >>> not be mounted during normal system operation, but the three
100 >>> filesystem layout was common and workable. As Linux continued to be
101 >>> like Topsy (she jest growed!) fragmentation started to occur as
102 >>> "distributions" arose. The "balkanization" of Linux distributions
103 >>> became a real concern to some and standardization offorts were
104 >>> encouraged.
105 >>>
106 >>> The "File System Standard" (FSS) was renamed to the Filesystem
107 >>> Hierarch Standard (FHS) and it was strongly based on the UNIX System V
108 >>> definitions (which called for seperation of usr and root.) POSIX added
109 >>> more layers and attempted to bring in the various BSD flavors.
110 >>>
111 >>> THe LSB (Linux Standards Base) effort was conceived as supersceeding
112 >>> all the other efforts, and FHS was folded into the LSB definition. Yet
113 >>> even then a separate root and usr distinction survived. Then things
114 >>> started falling apart again - POSIX rose like a phoenix and even the
115 >>> Windows/wintel environment could claim POSIX compliant behavior. The
116 >>> fall of the LSB effort really became evident when the FHS was gutted
117 >>> and certain major players decided to ignore the LSB recommendations.
118 >> too bad POSIX is much older than LSB or FHS.
119 > Too bad separate /usr is much older than initramfs.
120
121 too bad that initramfs and initrd are pretty good solutions to the
122 problem of hidden breakage caused by seperate /usr.
123 If you are smart enough to setup an nfs server, I suppose you are smart
124 enough to run dracut/genkernel&co.
125
126 >>> As a result, the GNOME Alliance has shattered. The main GNOME army
127 >>> marches on its unfathomable path, and various large chunks have broke
128 >>> off in their own directions (e.g. Cinnamon and Mate) seeking to remain
129 >>> flexible and not incompatible with the KDE and other lesser DE folks.
130 >>>
131 >>> It is truly layable at the feet of the GNOME folks, the breakage of
132 >>> the root and usr filesystem separability is all derived from the GNOME
133 >>> camp.
134 >>> These changes may not, in fact, be deliberate or intended to "defeat"
135 >>> Microsoft, but Ockham's Razor cuts and intentionality is the simpler
136 >>> explanation.
137 >> that gnome is very hostile when it comes to KDE or choice is not news.
138 >> And their dependency on systemd is just the usual madness. But they are
139 >> not to blame for seperate /usr and the breakage it causes.
140 > True, fingers here should be pointed into another direction like systemd.
141
142 systemd is not the first package to break.
143 >>> To come back to the thesis: robustness and flexibility are required
144 >>> for good "health" and we are witnessing a dangerous challenge.
145 >> what? that you need an initrd? That is so bad?
146 > It may be, there is people which may not have enough free space ob /boot
147 > for example.
148
149 and now we are deeply into kidding territory. How small is that boot? 3mb?
150 >> Are you kidding me?
151 > I doubt it, instead you seem to be just trolling, see your own arguments
152
153 well, I haven't seen any arguments from you so far. So who is the troll
154 again?
155
156 >>> [PS} If anybody cares, I was trained in both Computer Science and
157 >>> Biological Science. and I can expand on the parallels if so desired.
158 >>>
159 >> no thank you. But if I might add one: you are making an elephant out of
160 >> a gnat.
161 > To me it looks like youu are making a gnat out of an elephant.
162
163 what is the elephant? Running an extra command on kernel updates?
164 >

Replies

Subject Author
Re: [gentoo-user] Re: Flexibility and robustness in the Linux organisim "Francisco Blas Izquierdo Riera (klondike)" <klondike@g.o>