On 01/09/2015 10:04, Tobias Hunger wrote:
> Now that is a really depressing outlook.

What can I say: the state of affairs with the systemd madness
*is* depressing.


> I am way more positive than about your chances than that. X11 used to
> be impossible to replace because of drivers and we are pretty close
> to getting Wayland anyway.

Eh, if you like systemd, it probably makes sense that you like Wayland;
but I don't. Wayland is yet another integrated, all-encompassing,
monolithic (despite otherwise claims) attempt at solving a problem, with
the exact same design issues as systemd.

Granted, the X problem is much more acute than the init problem, and
much harder; and it's probably impossible, given our technical knowledge,
to find a solution that accommodates both my desire for security and
modularity and a modern graphics system's need for performance and
support for stuff like 3D. But still, I don't think Wayland is the right
answer, and I'm not exactly impatient to see it released.


> Heck, windows was the future for ages

No, Windows was never the future. Windows was the present, because it
was all people had. Unfortunately, when it was released, Windows
was already 20 years behind the academic state of the art in
operating systems; so, a more accurate statement would be that
Windows was the past. :P

Windows was the future from a "market shares" point of view, and
you are reasoning in market shares terms - this is also exactly
what systemd is doing. And the reason why Linux eventually took
over is that it was designed right in the first place. In the
same fashion, we are getting things right first no matter what is
happening in the marketplace, and we will eventually take over.


> I do not see that happening anywhere at this time. So far it is
> mostly claiming everything used to be fine before systemd. It was
> not.

What you are saying is that the "anti-systemd" camp is lacking
communication effort. You're right. I can't talk for other people,
but as far as I'm concerned, I've been totally taken by surprise
by systemd's success. I've always found it so technically inept
that I simply could not see it spreading, so I just ignored it.
Boy, was I wrong: so many resources - time, money, energy - have
been poured into communicating about systemd that it has become
the most talked-about init system ever. If a quarter of the
resources spent in promoting systemd had been spent on hiring
experienced Unix programmers and designing a better init system,
we would all be in paradise right now.
And propaganda works: when you smother people with information
about a product, they tend to forget that this product is not the
only thing that exists.

What is important to realize is that the "alternatives to systemd"
community is not a company: it is mostly made of people who only
have an interest in the technical side of things (i.e. who like to
get things right before making big announcements) and it does not
have the resources of a company (i.e. getting things right takes
time, and communicating also takes more time).

So it's obvious why you're not hearing much about alternatives
yet. But the loudest voice is not necessarily the wisest;
actually, it very rarely is.


> I do not see why you would need the same socket for all daemons

It is possible to open as many sockets as there are daemons, but
this is only desirable if you're using the daemontools model, i.e.
one supervisor per daemon. And if you're using that model, opening
a socket to listen to daemon notifications is entirely unnecessary
and a waste of resources, so why would you do that? s6, for instance,
has a simpler notification model that does not need a socket. Using
the NOTIFY_SOCKET mechanism would require a deep rework of the
supervisor code for a net loss in simplicity and maintainability.
So, in practice, NOTIFY_SOCKET only benefits monolithic designs.


> SD_notify is so much simpler to do than double forking, so most
> developers will pick that on their own.
> Do something even simpler and they will use that instead.

I've already done it. Writing a newline to stdout is much
simpler than using sd_notify().
You haven't heard of it because I'm not in the "communication"
phase yet. I want to get s6-rc ready first: deeds before words.


> They do whatever makes their lives easier, just like any other open
> source project out there.

No, that's not the right way to look at it. Despite the licensing
terms, systemd *does not* have an "open source" approach; it has a
proprietary, company-driven approach, with the exact same political
and technical stunts as proprietary software to make people use it,
to make sure it grabs the market and holds it captive. As I said,
systemd does not play fair: it pretends to play the open source
game where projects are judged and adopted or ignored on mostly
technical merits - but it's heavily skewing the rules and behaving
in the open source world like a bully in a schoolyard.


> Which concrete problems did you, Jude and whoever solve recently?

Jude is solving the needless integration of a hotplug manager into
the init system.
I am solving parallel, dependency-based, supervision-based service
management.


> What is your (meant collectively here) proposal to manage cgroups
> consistently? That is the one core feature of systemd that make other
> software depend on systemd-PID1 - directly or indirectly via other
> services.

Have you read the article about CoreOS and Docker that was linked in
a previous post to this list? This is exactly why "managing cgroups
consistently", iow "having a centralized registry of cgroups", is a
bad idea.


> Please blog as much as you can so that developers can find out about
> what you are doing. Posting here won't get your message across I
> think.

Your wish for more communication has been duly registered.

I believe you are genuine; however, other posters on this list are
reacting badly to you, because you are giving advice in the form of
"just do that" and basically telling us how to do our job. In most
cases, we are already "just doing that", the devil being, as always,
in the details; and you can't see what the details are or why
"just doing that" is difficult because you are not as involved.
Unless you can make precise, constructive feature requests, or
- even better - actively going to help, please don't give that kind
of advice: it comes across as cavalier and dismissive, or in the
worst case, antagonistic.

--
Laurent