| 1 |
Am 29.09.2013 00:36, schrieb Alan McKinnon: |
| 2 |
> On 28/09/2013 22:58, Alon Bar-Lev wrote: |
| 3 |
>> As far as I read, the problem is with bluetooth keyboards? and some |
| 4 |
>> other devices and locales, which are minor for this decision of |
| 5 |
>> removing supportability. Especially for servers and for most of |
| 6 |
>> workstations. Most sane configuration can be supported with separate |
| 7 |
>> /. |
| 8 |
>> |
| 9 |
>> And of course there is the hidden systemd agenda, which is what I |
| 10 |
>> suspect had more impact. |
| 11 |
> No, the problem is not bluetooth keyboards per se. That just happens to |
| 12 |
> be a convenient example of the kind of problem anticipated. There is a |
| 13 |
> tendency to use it as the only example, which reinforces the idea that |
| 14 |
> BT keyboards are problem to be solved. |
| 15 |
> |
| 16 |
> The actual problem is better stated something like this: |
| 17 |
> |
| 18 |
> In the early stages of user-land setup (around the time when udev is |
| 19 |
> getting it's act together), arbitrary code can run and that code can be |
| 20 |
> in any arbitrary place, but there is no guarantee that that code is even |
| 21 |
> accessible at the point when it is needed. The actual cause of this mess |
| 22 |
> is the lack of standards on where to put stuff on Linux systems, and it |
| 23 |
> forms a classic bootstrap problem. |
| 24 |
> |
| 25 |
> There has only ever been one way around that problem - define an exact |
| 26 |
> entry point that is guaranteed to be in a specific state. For current |
| 27 |
> userland this effectively means that everything that has traditionally |
| 28 |
> been in bin, sbin and lib in / and /usr must be available as step 1. |
| 29 |
> Technically, you could include /var/lib/ and maybe even /opt in there. |
| 30 |
> but we can safely exclude those at this time as only a brain-dead moron |
| 31 |
> would ever put init-critical code there. |
| 32 |
> |
| 33 |
> It's a fact of history that Linux packager and package devs have never |
| 34 |
> managed to make up their minds where to put stuff. Just have a look at |
| 35 |
> coreutils binaries - why are 60% of them in /usr? It's coreutils! And |
| 36 |
> core isn't in the name because of a whim. |
| 37 |
> |
| 38 |
> So you have two choices: enforce a decent separation so that the problem |
| 39 |
> doesn't happen, or enforce that all binaries are in one place where we |
| 40 |
> can call it "the system". Every major OS out there does the latter, it's |
| 41 |
> only Linux that tolerates this free for all wild wild west approach of |
| 42 |
> stick anything anywhere and still expect it to work. Hint: it doesn't |
| 43 |
> work. Duct-tape and bubblegum don't actually hold stuff together, no |
| 44 |
> matter how much we try convince ourselves it does. |
| 45 |
> |
| 46 |
> This should actually have been done when MAKEDEV was phased out in |
| 47 |
> favour of the now-defunct devfs, but it's never too late to fix design |
| 48 |
> flaws that date back 30 years or more. |
| 49 |
> |
| 50 |
> So this brings us back to the essential technical problem that still |
| 51 |
> needs to be solved on your machines: |
| 52 |
> |
| 53 |
> /usr needs to be available (and not only for BT keyboards) at the |
| 54 |
> earliest possible opportunity - this is a technical constraint. To |
| 55 |
> guarantee that, you need to either merge /usr with /, or use an |
| 56 |
> initramfs to guarantee that /usr is available before anything else |
| 57 |
> happens in userland. |
| 58 |
> |
| 59 |
> It *really* is that simple. If you have a better solution than my last |
| 60 |
> two choices, then I am all ears. |
| 61 |
> |
| 62 |
> |
| 63 |
|
| 64 |
the correct and simple solution would be to deprecate /usr and move |
| 65 |
everything into / . |
Archives