Re: Survey answers part 3: systemd is not portable and what this means for our ports
On Sun, Jul 21, 2013 at 05:59:25PM -0400, The Wanderer wrote:
> On 07/21/2013 05:04 PM, Josselin Mouette wrote:
>
> >Le samedi 20 juillet 2013 à 19:21 -0400, The Wanderer a écrit :
> >
> >>[I am almost certainly going to regret this.]
> >
> >I hope so.
>
> Please don't be a jerk.
>
> >>Making the switch away from the entrenched sysvinit is visibly very
> >>difficult, at least as a social matter, even in the environment we
> >>have. systemd et al., by virtue of the integration which is
> >>apparently one of their selling points and the "proprietary"[0]
> >>interfaces they seem to use, look like they would create an
> >>environment where a similar switch to "whatever comes next" would
> >>be even harder - at least partly as a technical matter, rather than
> >>a social one.
> >
> >Hey guys, I know this “Linux” thing is better than Minix, but it
> >brings a lot of new features that we will be growing accustomed to.
> >If we ever want to switch to Hurd one day, this is going to be much
> >more complicated.
>
> My objection has nothing whatsoever to do with "growing accustomed to
> features". (The line further down about "without losing other
> functionality" might have hinted at that fact.)
>
> It has to do with A: lock-in to the interfaces of the current proposed
> solution, even if those interfaces might not suit "whatever comes next",
> and B: potential interdependency between the current proposed solution
> and other (theoretically distinct) elements, such that you can't replace
> one of them without replacing all of them - unless your replacement
> exactly matches all of the interfaces of the current proposed solution.
Hi,
I think that in the end you are worried about lock-in due to features,
not anything else. Replacing systemd, in part or in whole, is hard
only because of compelling features, not found in other systems. There
is no classical lock-in in the sense of e.g. undocumented and brittle
interfaces, APIs or syntax, or the inability to retrieve existing
data. The unit syntax is trivial to parse, meaning of various items is
documented, and in general it is pretty easy to substitue one provider
of a dbus interface for another. A similar situation is true in the
case of the journal, which (for producers) provides just a few simple
C functions.
And there *are* examples of piecewise replacement:
- Ubuntu is using just logind, without using systemd. Probably
the hardest part is building journald cleanly, without the
rest of systemd. And if you were implementing a replacemnt,
this problem wouldn't exist.
- rsyslog provides a replacement of the journal logging API,
allowing one to use journal logging functions on systemd-journald-less
systemd.
- rsyslog slurps journal files, so if for whatever reason you
wanted to stop even using journalctl, you could pull in
the data into another logging solution from disk without any
trouble. (There are other ways to retrieve this data, but I
mention this one because it is a different program reading the same
data, i.e. a reimplementation.)
Zbyszek
--
they are not broken. they are refucktored
-- alxchk
Reply to: