Hi Laurent,

Am 31.08.2015 9:24 nachm. schrieb "Laurent Bercot" <ska-devel@???>:
>
> On 31/08/2015 20:56, Tobias Hunger wrote:
>>
>> Oh, I am pretty happy with systemd and won't lie about that. I would
>> still like to see some competition going.
>
>
> That's pretty much the crux of the problem here. Nothing can compete
> with systemd

Now that is a really depressing outlook.

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. Heck, windows was the future for ages and now its Linux
that rules everything but the desktop.

Keep on hacking, you can make a difference:)

> on the same grounds, because systemd covers so much ground
> and does so many things (that *it should not* be doing) that any good
> engineer who wants to design an alternative will see a lot of insane
> features and immediately say "Nope, I'm not doing that, it's not the
> init system's job"; and systemd proponents will always answer "See?
> systemd is the only one that does that stuff, and all the competition
> is inferior".

Go talk to other developers, find out what bothers them about the
non-systemd and systemd status quo and address those issues one by one.
Then blog about that solution and try to get developers to use it. Act on
their feedback when they provide it.

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.

> Even where competition *can* happen, systemd likes to fudge the odds.

So solve the same problem in a better way. Superior solutions *do* get
adopted by developers. Most do not care a single bit where that solution
comes from!

> For an example that I know because I had to deal with it not long ago:
> the sd_notify() protocol was made so that a process' supervisor has to
> be listening on a Unix domain socket, which ultimately favors the model
> where the supervisor for all the daemons is a single program performing
> all the service management tasks: so in order to implement a server for
> sd_notify, you basically have to adopt the systemd monolithic
architecture,
> which means, in essence, rewrite systemd - and, obviously, no sane
> person wants to do that.

I do not see why you would need the same socket for all daemons, but you
probably know that matter better than me, so I have to trust you on that
statement.

> So by this single design choice, systemd ensures that it's the only
> service manager that can actually implement sd_notify. And systemd
> enthusiasts actively try to make daemon authors use sd_notify, saying
> "Oh, but it's a good notification protocol; and the protocol is free,
> and it's all open source, so people who want to write an alternative
> server are free to do so!" with a bright smile and big, innocent
> eyes; but it's nothing short of misleading and dishonest.

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.

Developers want to solve the problems that interest them and will use the
simplest possible solution for the others:-)

> systemd does not play fair by *any* measure;

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

> the only way to provide
> healthy competition is to ignore everything it's doing, and design
> a sane, Unixish init system, as well as sane, Unixish administrative
> tools, from the ground up.

Yes, please! A reimplementation is no alternative and not a serious
competition.

> I'm working on it with s6-rc. Jude is working on the udev system
> with vdev. Other people are working on the other parts of the Linux
> userspace that systemd would love to phagocyte. And we are not
> getting the kind of money or resources that the systemd lead
> developers are, so it's a longer, harder task; but don't worry, the
> competition exists and is getting better everyday.

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

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.

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.

Best Regards,
Tobias