Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/22/2013 02:52 AM, Tollef Fog Heen wrote:
]] The Wanderer
If someone implementing a new alternative wanted to retain the
other tools with which systemd integrates, that person would have
to match their interfaces, which might limit the functionality the
new alternative could be able to provide - much as having to match
the sysvinit interfaces would seem to limit the functionality
systemd can provide.
systemd isn't limited by sysvinit interfaces in what kind of
interfaces it can implement. It just means a subset of the
functionality is supported for sysvinit scripts. (No socket
activation to take an obvious example.)
Yes, that's what I was referring to; living within the limitations of
the sysvinit formats, rules, and assumptions restricts the functionality
systemd can provide. (If you look at the phrasing, I used "provide" vs.
"implement" somewhat carefully, although maybe not carefully enough.)
The sysvinit support is actually optional and can be compiled out.
As for the concerns that a new tool would require a lot of work if it
were to replace systemd, well, yes, it would. Systemd does cover a
lot of ground and if you want to feature match/feature exceed it
everywhere, that's not an easy task. Zbigniew pointed out some bits
that can be broken out piecemeal and used independently, though.
My concern was that the integrated nature of it would make it harder to
replace any one part, especially if desiring to extend rather than just
reimplement. Having it made clear that it's more compatible with being
split out "piecemeal", as you put it - with being essentially modular -
than I'd thought does help somewhat in that regard, however.
Part of it is also a matter of sense of fairness; systemd faced certain
obstacles in implementing an alternative to the established sysvinit,
but its design seems to place even more obstacles in front of something
looking to implement a future alternative to an established systemd,
especially one which (as with systemd vs. sysvinit) does not use the
same assumptions as what it's looking to replace. That imbalance is a
large part of what bothers me about this, I think.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Every time you let somebody set a limit they start moving it.
- LiveJournal user antonia_tiger
Reply to: