Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]
On 12 April 2017 at 09:38, Enrico Weigelt <enrico.weigelt@gr13.net> wrote:
> ..[snip]..
> So, at least anybody who maintains and systemd-free environment (eg.
> platforms that dont even have it) needs run behind them and keep up.
I think what you say there answers your own question at the end of your
email about "...why people spent so much time in init system wars,
instead of thinking clearly of the actual root problem to solve". It seems
reminiscent of the days when web standardization had to play catch-up
to Netscape and Internet Explorer, sorting the wheat from the (bloat) chaff.
I suspect that "running behind", as you describe it, would be a thankless
and frustrating task, especially when on the level of PID 1 (as opposed to
just a browser), and it may not ever gain adoption or even enough
attention in the first place. I think a lot of the holy war that happened was
due to people sensing that situation on the horizon.
> ..[snip]..
> So, why don't we just ask, what kind of functionality do applications
> really want (and what's the actual goal behind), and then define open
> interfaces, that can be easily implemented anywhere ?
I would be keen (and I am sure many others would too) to help thrash
out a consensus-document somewhere, even if I suspect it will be an
arduous and largely thankless task. The key is that a very open,
transparent, and steady process needs to be established - with a
*strong* emphasis on pragmatic engineering, and active avoidance of
unnecessary politics, echo-chambers, vested interests, etc. I say
"unnecessary" because of course politics will come into it a lot of the
time, but that needs to be managed/contained to avoid the
soul-destroying sense of futility which comes when people get angry
and petty. Also, in order to hold on to any degree of relevance it would
have to be very inclusive and accommodating of existing systems,
which would involve often yielding to legacy over optimality, even when
it hurts on an intellectual level (see html5 vs. xhtml). Due to the
adoption/momentum systemd now has, it would have to be especially
heavily catered to, more than many people would "like", because
otherwise any efforts would just create yet another "elegant but
ignored" standard. I doubt I even need to link to this xkcd, because
you probably already have it in mind ;-)
https://xkcd.com/927/
> All we need yet is an init-system/service-monitor
> agnostic API, that can be easily implemented w/o extra hassle.
> A simple reference implementation probably would just write some
> statfiles and/or log to syslog, others could talk to some specific
> service monitor.
>
> Having such an API (in its own library), we'd already have most of
> the problems here out of the way. Each init system / service monitor
> setup comes with some implementation of that API, and applications
> just depend on the corresponding package - everything else can be
> easily handled by the existing package management infrastructure.
> No need for recompiles (perhaps even no need to opt out in all the
> individual packages).
>
> The same can be done for all the other features currently used from
> libsystemd, step by step.
>
> Maintenance of these APIs (specification and reference implementation)
> should be settled in an open community (perhaps similar to
> freedesktop.org for the DE's), not in an individual init system /
> service monitor project.
I think the hardest part of all would be porting enough of the existing
systems to such an interface and *maintaining them* for long enough to
prove the endeavour is worthwhile, and to pressure them to do so
officially. Especially for systems under heavy development (like systemd)
that would involve an enormous amount of rebasing and merge-conflicts.
To put that in perspective, some of the systems according to wikipedia at
the moment are:
BootScripts, busybox-init, DEMONS, eINIT, Epoch, Initng, launchd,
Mudur, procd, nosh, OpenRC, runit, s6, Service Management Facility,
Shepherd, systemd, SystemStarter, Upstart.
I doubt any of them will voluntarily spend initial effort of their own
conforming to a new "proposal which hopes to become a standard some
day"...
On 12 April 2017 at 11:08, Jonas Smedegaard <jonas@jones.dk> wrote:
> Quoting Enrico Weigelt, metux IT consult (2017-04-12 08:38:26)
> > I really wonder why people spent so much time in init system wars,
> > instead of thinking clearly of the actual root problem to solve.
>
> Because the debate got derailed by remarks painting other contributors
> to the debate as idiots, perhaps?
As much as I agree with that sentiment, I suggest two things:
* If you intend to start such an effort I recommend doing it straight away,
before this thread devolves into yet another depressing trail of vented
frustrations (which inevitably leads to personal attacks and pettiness),
which would stop people even clicking through to the project, and in the
worst case just deciding to ignore the debian-dev mailing list completely
(like I did for the few months following the peak of the systemd
debate/flamewar)
* I beg whoever contributes to this thread to try really hard to not focus
on the frustrations and need-to-vent, and just try to help progress this
effort (if it happens) in a nuts-and-bolts way - as an engineer/designer,
and specifically not as a philosopher, politician, protester, etc.
I guess a good way to start would be:
* a design-document on a wiki (able to have wikipedia-style moderation
system if it gets defaced too often)
* an initially empty repo to house a reference implementation
* reference implementation should be *really* portable, e.g. C (ANSI?,
POSIX?) with as much abstraction as possible of system-specific libs
to aid maintainability.
--
Rowan Thorpe
Reply to: