| 1 |
On 29/09/2013 13:58, Volker Armin Hemmann wrote: |
| 2 |
> Am 29.09.2013 13:03, schrieb Greg Woodbury: |
| 3 |
>> On 09/29/2013 06:55 AM, Volker Armin Hemmann wrote: |
| 4 |
>> |
| 5 |
>>> why do you bring up udev and systemd AT ALL? |
| 6 |
>>> |
| 7 |
>>> They are not the problem or the reason why seperate /usr is prone to |
| 8 |
>>> break. |
| 9 |
>>> |
| 10 |
>> Except that systemd *is* why a seperate /usr is broken now. |
| 11 |
>> Parts of the libraries that systemd depend on we *deliberately* placed |
| 12 |
>> in /usr despite the fact that they are needed to bbring the system to |
| 13 |
>> an operational state. For *years* things required to boot the system |
| 14 |
>> were defined to be in the root file system, and items not required |
| 15 |
>> until after mounting had been accomplished were to be placed in /usr. |
| 16 |
>> |
| 17 |
>> BTW: There is a standard (The File System Hierarch Standard - FSS) |
| 18 |
>> that existed and described this behaviour. It was killed off by |
| 19 |
>> deliberate vendor refusals to support or adhere to it. In |
| 20 |
>> frustration, the folks involved simply gave up. |
| 21 |
>> |
| 22 |
> |
| 23 |
> things were broken way before that. As much as I hate systemd, it is not |
| 24 |
> the root cause of the problem. |
| 25 |
> |
| 26 |
> The problems were caused by people saying that seperate /usr was a good |
| 27 |
> idea, so / would not fill up and similar idiocies. The problems were |
| 28 |
> caused by people saying that lvm is a good idea - for desktops. Those |
| 29 |
> people who are fighting against the kernel auto assembling raids are to |
| 30 |
> blame too. |
| 31 |
> |
| 32 |
> Systemd is just another point in a very long list. |
| 33 |
|
| 34 |
Volker, we agree. |
| 35 |
|
| 36 |
The problem as I see it is that we have an artificial, arbitrary |
| 37 |
separation between "boot time" stuff and "something that happens later" |
| 38 |
stuff. There is no clear definition of what these things are and the |
| 39 |
only real technical criteria advanced thus far is quoted above: "after |
| 40 |
mounting had been accomplished" |
| 41 |
|
| 42 |
That worked in the 80s when SysV came out. But times move on, new |
| 43 |
methods and hardware were developed and computing is now a very |
| 44 |
different beast to what it was 30 years ago. Nowadays we have a boatload |
| 45 |
of actions that can/may be needed to happen before fstab can be read to |
| 46 |
mount the rest of the system. |
| 47 |
|
| 48 |
/usr has become, whether we like it or not, an indespensable part of the |
| 49 |
userland start up process, and the only way out of this is to have some |
| 50 |
guarantees in place. We already have a perfectly good one - the root |
| 51 |
file system is guaranteed to be mounted by the kernel before init is |
| 52 |
called. If that filesystem does not contain /usr then a rather |
| 53 |
sophisticated hack is available to ensure that /usr is available, and it |
| 54 |
is an initramfs. |
| 55 |
|
| 56 |
I do beleive the choice really is that clear - provide that guarantee or |
| 57 |
be stuck forever with old code, hardware and methods. Just because SysV |
| 58 |
worked well for ages does not mean it's rules must persist through time. |
| 59 |
Everything changes in this worls, and our game changes faster than most |
| 60 |
other things. Let's not cling to sacred cows when the world has |
| 61 |
observably moved on. |
| 62 |
|
| 63 |
None of this means I think systemd is good (or bad). Maybe it's |
| 64 |
over-engineered, but at least someone has the balls to stand up and try |
| 65 |
deal with the actual problem. |
| 66 |
|
| 67 |
|
| 68 |
-- |
| 69 |
Alan McKinnon |
| 70 |
alan.mckinnon@×××××.com |
Archives