Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Enrico Weigelt, metux IT consult]

On 13.04.2017 11:27, Vincent Danjean wrote:

>   For me, the first argument explain in the first mail is not this one.
> systemd is not portable on lots of system (hurd, kFreeBSD, ...), 

This is just one of many arguments for not making applications
depending on it. (and they shouldn't depend on any other init system
either).

Regarding service status reporting, systemd folks indeed make a good
point. There is some demand for that, and they solved the problem for
their audience (unfortunately only for *their* audience), and moved
one to the next topic. For a prototype that's really fine, but not
for long term maintenance over dozens of different platforms.

Now stating, everybody should just implement their interfaces is just
like asking everybody to implement it in the windows way (NT came up
with it's entirely own service management system, which works quite
well, as long as you're confined within the windows world)

> systemd is not interested in making its code portable, nor to stabilize
> its interfaces so that other system init can easily implement them,

Well, that's their choice, and I respect that. It's just not mine.
I don't wanna be forced into their ways (as I wouldn't ever try to
force them into mine). So, I'm looking for a *generic solution* for the
actual problem, which that functions ins libsystemd aimed to solve,
so applications can just use them, w/o ever having to care which init
system might be installed (or if there even is one at all)

> lots of applications are now using libsystemd to get 'classical' information
> (status, ...) because they do not want to have to deal with several init
> system 

Exactly. They're just looking for some API for that stuff, not caring
what it actually does under the hood. And systemd just happens to
provide one. From the application developer's pov systemd is filling
some gap, and they dont even wanna care about the consequences.

So, it's up to us, to provide a better solution - just telling how bad
systemd is, isn't just enought (from their perspective).

> and porters of platforms not supported by systemd have a really hard
> work to follow systemd developments and patch all things.

Exactly. For some arbitrary application developer (who usually doesn't
even know much about packaging, etc), it's hard to understand the
underlying problem - they just want something they can set their code
ontop (that's also the reason why all these strange proprietary
platforms can even exist). So, it's up to us, who know better, to give
them something they can work with, and that doesn't cause all the
trouble that Lennartware does.

>   From your mail, you seems to deny this issue ("everybody can be pleased
> with systemd" and/or "this is not a general problem, just a problem
> from people that dislike systemd"). For what I see, it seems a problem
> also for people that like systemd but cannot use it on their plate-form
> (Hurd, ...)

Right, it's basicly the same old "shut up and go away" attitude.
Actually, many people already went away, and more will follow.

If it goes on that way, we'll end up w/ an own OS called systemd, which
is as far away from GNU/Linux as Android. Do you folks really want that
or did you just ran out of better ideas ?

>   I'm persuaded that ignoring this issue will lead to an unmaintanable
> Debian distribution on platforms that do not support systemd in the
> middle/long term. But, perhaps, it is what the project wants.

That, in turn, would lead to Debian step by step defeating its own
original goals. I'm pretty sure that it won't take long for lots of
other things (beginning w/ other kernels) are dropped, just because
nobody is willing to keep it compatible w/ systemd.

>   Enrico is proposing something else. I'm not sure if his proposal is
> good and doable (ie with enough support from various parties and
> manpower).

If we get out of the ideologic war (including the upstreams, too),
it wouldn't be such a big deal. A minimal implementation the proposed
library is quite simple and small. We'd just have to touch a bunch of
applications and rewrite a few lines there - and once it works and
included in a major distro, we have good chances for convincing
upstreams to take our patches in. And I'm sure, Devuan folks, which
had been driven out of Debian, will help here, too.

Yes, somebody needs to maintain the systemd-version/branch - but as the
library interface will be stable (it's scope is quite limited, so there
wont be much desire to add anything new). So, we at least have the
overhead of keeping up w/ systemd minimized and centralized in one
small lib. Maybe even someday systemd folks have some moment of insight
and take that part into their hands.


--mtx

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Russ Allbery]

Vincent Danjean  writes:

>   I'm persuaded that ignoring this issue will lead to an unmaintanable
> Debian distribution on plateforms that do not support systemd in the
> middle/long term. But, perhaps, it is what the project wants.
>   Enrico is proposing something else. I'm not sure if his proposal is
> good and doable (ie with enough support from various parties and
> manpower).
>   I'm not pleased at all with arguments to stop this discussion nor
> with arguments that try to deny the issue. I do not know what can
> really be done to solve the issue.

To be clear, I would be very happy to have the above conversation.
Figuring out portability is important to the project, and we should be
constantly looking for good ways to maintain and improve our portability,
particularly given that this was the primary downside of the systemd
decision we took (and we knew that when we took it).

This is an important discussion, and I don't want to shut it down.

What I want to shut down is iteration N of "you all are looking at this
problem in the wrong way and if you would just look at it my way, it will
be immediately obvious that you're wrong."  Or "systemd is obviously not
the correct architecture, so let's get together and design a better one as
a project."  People have been trying both of those approaches continuously
since the original discussion, and, to be quite frank, they no longer fill
me with a desire to collaborate.

Rather the opposite; it's very hard to resist the (I believe incorrect,
but still very human) reaction of "well, I did care about the use cases
systemd doesn't support well, but since everyone who talks about those use
cases seems way more interested in lecturing me and attacking me than
solving technical problems, let me go lower this on my personal priority
list even farther."

I think there's a lot of room here for technical discussions focused on
*specific* technical problems or possible solutions, as opposed to broad,
sweeping generalities about "open standards" (aimed at a fully open-source
project with very comprehensive documentation!) and "actual root
problems" that don't spell out (a) what's wrong with the current state,
(b) how we propose to fix it, and (c) at least some vague start at an
actionable plan to achieve that.  Or that aren't at least *trying* to
spell out those things.

One thing that would help considerably would be to have a clear set of
requirements from the non-Linux ports in what they actually want from the
rest of the archive in this area (assuming they are seeing real
portability problems in the current state).  Specifically, a constructive
list: "please support this," as opposed to "please don't support that."
Then we can start diving into the details of improving integration code
and build helpers to fix the problems they're seeing, with some concrete
feedback on whether we're getting it right or wrong.  I think this would
be more motivating than vague statements about portability issues that
aren't actionable.

-- 
Russ Allbery (r...@debian.org)   

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Tollef Fog Heen]

]] Vincent Danjean 

>   For me, the first argument explain in the first mail is not this
> one. systemd is not portable on lots of system (hurd, kFreeBSD, ...),
> upstream systemd is not interested in making its code portable, nor to
> stabilize its interfaces so that other system init can easily
> implement them, [...]

While it's correct that systemd isn't catering to portability, large
chunks of it is covered by the interface stability promise (see the
table on
https://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/)
so other init systems are free to implement them if they so want.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Vincent Danjean]

  Hi,

  I do not have any strong position on this subject.

Le 13/04/2017 à 02:13, Russ Allbery a écrit :
> I guess I'm confused about what you think this email will accomplish.  I
> feel like it's just another round of being convinced that, since you
> dislike systemd, everyone else must also somehow dislike systemd too, deep
> down inside, and if you just find the right argument, all those people who
> think they like systemd will realize that they actually don't and will
> come help you build something else.

  For me, the first argument explain in the first mail is not this one.
systemd is not portable on lots of system (hurd, kFreeBSD, ...), upstream
systemd is not interested in making its code portable, nor to stabilize
its interfaces so that other system init can easily implement them, lots
of applications are now using libsystemd to get 'classical' information
(status, ...) because they do not want to have to deal with several init
system and porters of platforms not supported by systemd have a really hard
work to follow systemd developments and patch all things.

  For me, this seems a real issue (and, again, I do not know the good
way to deal with this).
  From your mail, you seems to deny this issue ("everybody can be pleased
with systemd" and/or "this is not a general problem, just a problem
from people that dislike systemd"). For what I see, it seems a problem
also for people that like systemd but cannot use it on their plate-form
(Hurd, ...)

  I'm persuaded that ignoring this issue will lead to an unmaintanable
Debian distribution on plateforms that do not support systemd in the
middle/long term. But, perhaps, it is what the project wants.
  Enrico is proposing something else. I'm not sure if his proposal is
good and doable (ie with enough support from various parties and
manpower).
  I'm not pleased at all with arguments to stop this discussion nor
with arguments that try to deny the issue. I do not know what can
really be done to solve the issue.

  Regards,
Vincent

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Brian May]

On 2017-04-13 10:13, Russ Allbery wrote:

> It would be nice if people would stop doing the same thing over and over
> again and expecting different results.

Maybe this illustrates the core of the problem: https://xkcd.com/242/

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Russ Allbery]

"Enrico Weigelt, metux IT consult"  writes:

> 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 ?

Who's we?

The people who are happy with systemd are, err, happy with systemd.  Most
of them aren't particularly interested in reinventing those wheels yet
again, given that they already have wheels that work pretty well.  Also,
the systemd interfaces look pretty open to me; you're entitled to
disagree with me, but I'm also entitled to disagree with *you* (and I do).

If you're trying to put together a development team of people to work on a
new init system, well, knock yourself out I guess, but I'm not sure this
is the best forum from which to try to recruit people.

I guess I'm confused about what you think this email will accomplish.  I
feel like it's just another round of being convinced that, since you
dislike systemd, everyone else must also somehow dislike systemd too, deep
down inside, and if you just find the right argument, all those people who
think they like systemd will realize that they actually don't and will
come help you build something else.  You're not going to get any farther
with this than the last dozen people who tried, and the constant attempts
are honestly kind of tiring and, human psychology being what it is,
probably make it even less likely that people will be willing to work on
some partial systemd replacement.

It would be nice if people would stop doing the same thing over and over
again and expecting different results.

-- 
Russ Allbery (r...@debian.org)   

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Rowan Thorpe]

On 12 April 2017 at 09:38, Enrico Weigelt  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  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

Re: init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Jonas Smedegaard]

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?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

init system agnosticism [WAS: how to remove libsystemd0 from a live-running debian desktop system]

[Enrico Weigelt, metux IT consult]

On 17.02.2015 18:49, The Wanderer wrote:

Hi folks,


just digging out an older thread that was still laying around in my
inbox - w/ about 2yrs distance, I hope it was enough cool down time
so we discuss it more objectively about that.



> libsystemd0 is not a startup method, or an init system. It's a shared
> library which permits detection of whether systemd (and the
> functionality which it provides) is present.

>From a sw architects pov, I've got a fundamental problem w/ that
appraoch: we'll have lots of sw that somehow has 'magically'
additional functionality if some other sw (in that case systemd)
happens to run.

The official description is: "The libsystemd0 library provides
interfaces to various systemd components." But what does that mean ?
Well, more or less a catchall for anything that somehow wants to
communicate w/ systemd. What this is actually for, isn't clear at all
at that point - you'll have to read the code yourself to find out.
And new functionality can be added anytime, and sooner or later some
application will start using it. So, at least anybody who maintains
and systemd-free environment (eg. platforms that dont even have it)
needs run behind them and keep up.

Certainly, systemd has a lot of fancy features that many people like,
but also many people dislike (even for exactly the same reaons).
The current approach adds a lot of extra load on the community and
causes unnecessary conflicts.

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 ?

After looking at several applications, the most interesting part seems
to be service status reporting. Certainly an interesting issue that
deserves some standardization (across all unixoid OS'es). There're lots
of ways to do that under the hood - even without having to talk to some
central daemon (eg. extending the classical pidfile approach to
statfiles, etc). 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 really wonder why people spent so much time in init system wars,
instead of thinking clearly of the actual root problem to solve.


--mtx