|
|
|
|
|
|
by mindslight
2196 days ago
|
|
|
Ideally ordering would be assured by construction, as if units were listed out in one file. But that would not compose easily. I'd start by adding an optional priority number to each unit, which if supplied would form an ordering that units were always executed in. A unit having the priority number should also be less likely to be chosen for dropping, as they'd likely to be distribution-supplied units that were better debugged. This would make it much easier to narrow down the source of a logical conflict, and drop sensible units. That only addresses the one gripe I brought up as an example though, and not the general pattern. For instance another issue I've run into is this automagical hacks that parse fstab crypttab etc and make units at boot time, while not actually supporting all the customary options of those files. In general it feels like if systemd were written in a modern language, traditional distribution responsibilities (eg initrd/cryptoroot) could have been comprehensively replaced. But instead they bit off more than they could chew in C, so completeness and elegance were cast aside, and we're left with a hodgepodge of the old and new systems. |
|
|
Maybe the long term plan is to have these files dropped and replaced with something more systemd like?
> we're left with a hodgepodge of the old and new systems.
Same argument: if the long term goal is to completely overhawl the system, then at any point before that goal is reached there has to be old devices still in place.
That being said, I don't know much about systemd, not about the long term goals of systemd authors. I think that Poettering language of choice is C, so this explains that, but there's always room for other solutions in the FOSS world.