Re: Survey answers part 3: systemd is not portable and what this means for our ports
On 07/21/2013 07:06 PM, Matthias Klumpp wrote:
2013/7/22 Russ Allbery <rra@debian.org>:
Игорь Пашев <pashev.igor@gmail.com> writes:
We are locked in sysvinit.
Except we're not: both systemd and upstart support sysvinit
scripts. Which is why we can do a gradual migration, or even switch
back and forth between various alternatives. However, the native
formats of both systemd and upstart (and, for that matter, OpenRC)
are mutually incompatible, so migration from one to another is much
more difficult than migration from sysvinit to any of the
alternatives once a substantial number of init scripts are written
in the new format and the old init scripts are dropped.
That's the point.
I can certainly see why people may not consider that a significant
drawback, or may consider other advantages more than worth that
tradeoff, and indeed we do make tradeoffs like that all the time.
I'm not horribly worried about it personally. But that doesn't
change the fact that it *is* a potential drawback.
Thank you for understanding the idea.
I don't know if I'd even consider it a critical, fatal drawback myself;
if we do end up moving to systemd without this concern having been
addressed, I'm not likely to raise a screaming fit or go tearing my hair
out over it or anything.
But I would probably still go forward with a niggling sense of
discomfort, a sense that things aren't quite right, that my world
doesn't quite fit me the way it should - "there's a screw loose
somewhere, there is a leak in the tank", if that conveys the idea.
If we adopt a single alternative and move a substantial number of
the current init scripts to the new format, we have locked
ourselves into that alternative in a more substantial way than we
currently have (where we're using a portable, if horrible, init
format that is supported by all the alternatives).
Well, if a new alternative is written in future, and there already is
a substantial number of scripts in $format, it will almost certainly
support these, and we can migrate away to the new system.
My concern in that context is that having to support that format could
impose a limitation on the ability of the new alternative to provide
added functionality, just as having to live within the constraints of
sysvinit would (and, for the fallback case, ISTR allegedly does) impose
limits on the benefits that systemd can provide.
The potential need to also interoperate with the various other things
with which systemd apparently integrates (e.g. journald, and I think
other things - which may eventually include udev) *in the same way that
systemd then does* seems like it could also impose an even stronger
limitation on potential functionality; either you'd have to limit your
functionality to what that interoperation would support, or you'd have
to either fork those "other things" or implement replacements for them
as well. Either would make the process of implementing a new alternative
much bigger than just implementing a new init system; any new
alternative would then have to jump over considerably bigger hurdles
than systemd did.
It will be the same situation as we currently have sith SysV-Init.
So I wouldn't worry about this at all :-)
Isn't the current situation with trying to migrate from sysvinit plenty
bad enough?
--
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: