| 1 |
On Mon, Dec 24, 2012 at 6:31 PM, Bruce Hill |
| 2 |
<daddy@×××××××××××××××××××××.com> wrote: |
| 3 |
> On Mon, Dec 24, 2012 at 05:23:13PM -0500, Michael Mol wrote: |
| 4 |
>> |
| 5 |
>> Then came the decision to move udev inside /usr, forcing the issue. |
| 6 |
>> Now, it'd been long understood that udev *itself* hadn't been broken. |
| 7 |
>> The explanation given as much as a year earlier was that udev couldn't |
| 8 |
>> control what *other* packages gave it for rules scripts. OK, that's |
| 9 |
>> not strictly udev's fault. That's the fault of packages being depended |
| 10 |
>> on at too early a stage in the boot process. And, perhaps, hotplug |
| 11 |
>> events for some devices _should_ be deferred until the proper |
| 12 |
>> resources for handling it are available. I can think of at least a few |
| 13 |
>> ways you could do that. And, yes, this was a problem systemd was |
| 14 |
>> facing, and wasn't finding a way out of. (Why? I still don't know. |
| 15 |
>> Maybe they didn't want to implement dependency declarations or demand |
| 16 |
>> that packages impement partial functionality to reduce initial |
| 17 |
>> dependencies.) |
| 18 |
> |
| 19 |
> You're stumbling upon it ... just keep hashing it out. |
| 20 |
|
| 21 |
No, I'm pretty sure I understand most of what's going on. I don't |
| 22 |
understand why systemd and udevd couldn't settle on a standard |
| 23 |
interface for each other (rather than tightly integrate), and I don't |
| 24 |
understand why neither systemd nor udevd could implement a |
| 25 |
dependency-aware system that understands problems like circular |
| 26 |
dependencies and accounts for it; every package manager since the dawn |
| 27 |
of the thing has had |
| 28 |
|
| 29 |
The purpose of my email was to try to be as neutral as possible while |
| 30 |
laying out the history of the thing over the past year and a half. I'm |
| 31 |
stopping short of calling the lead admins lazy, because you don't get |
| 32 |
where they are by being lazy. The most generous thing I can think of |
| 33 |
to say is that Lennart has deadlines to meet in order to meet Red Hat |
| 34 |
release schedules, and trying to corral a bunch of packages with |
| 35 |
lazily-defined dependencies into would be extraordinarily difficult. |
| 36 |
|
| 37 |
And...huh. I think I just realized why Lennart and Red Hat are pushing |
| 38 |
systemd...it's because of Amazon's EC2. In EC2, you spin up more |
| 39 |
copies of a system image in order to scale your site to handle |
| 40 |
additional load. Reducing boot time for new system images means you |
| 41 |
can scale your computational capacity that much more quickly...and Red |
| 42 |
Hat wants in on the scalable cloud action. |
| 43 |
|
| 44 |
> |
| 45 |
> The decision to write a new init system (systemd) and do things altogether |
| 46 |
> differently is exactly what caused your previously referred to train wreck. |
| 47 |
> And Kay Sievers collaborating with Lennart on this corrupted udev. Take those |
| 48 |
> two prima donnas out of the udev destruction, and no such init problem exists |
| 49 |
> today ... just as it didn't exist before then, for so many years. |
| 50 |
> |
| 51 |
> Linus didn't tolerate what they did to module and firmware loading: |
| 52 |
> |
| 53 |
> https://lkml.org/lkml/2012/10/2/303 |
| 54 |
> |
| 55 |
> and he placed the blame squarely on Lennart and Kay where it belongs. To quote |
| 56 |
> Linus Torvalds: |
| 57 |
> |
| 58 |
> "What kind of insane udev maintainership do we have? And can we fix it?" |
| 59 |
> |
| 60 |
> Bank on it ... he *will* keep these prima donnas from destroying it. There's |
| 61 |
> quite the historical precedent for such. |
| 62 |
|
| 63 |
That's what forks accomplish. The original project can die, but a |
| 64 |
useful thing can take its place. So I'd venture a guess eudev will |
| 65 |
replace udev in Linus's eyes. And some functionality has been pulled |
| 66 |
into the kernel to avoid depending on the rogue userland project. |
| 67 |
|
| 68 |
-- |
| 69 |
:wq |
Archives