Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[Gusar]

you can, read last post
if you still are thinking about API, think about how you can make a wrapper for it instead

Well, ok, but two things: One, like I mentioned, in practice such wrappers are the exception (the example I gave with libedit/readline; gnutls has an openssl compatibility wrapper; while there might be a few more, I'm not aware of any).

And two, the original point was that it's supposedly bad for software to directly depend on systemd. If we take wrappers as a valid option and as an argument that everything is exchangeable, then the original point is moot - because with the magic word "wrapper", a software's dependency on systemd is no more.

[Guest]

Blackcat still doesnt get the point, cups doesnt try to be anything other than it's purpose, fully featured printing server (and damn good one, scaling from smartphones to corporate network environment).
It doesn't make applications depend on cups to be running or present.
Also, you are not just talking API compatibility, you talking ABI compatibilty for your "plug and play" to work.
And having multiple libraries to do the same thing is 'curse' of OSS system, I would argue it's a good thing, if you want one way to do it all, just get Windows.

[Gusar]

Blackcat still doesnt get the point, cups doesnt try to be anything other than it's purpose, fully featured printing server (and damn good one, scaling from smartphones to corporate network environment).

And systemd is a damn good service manager, scaling from smartphones (SailfishOS) to corporate environments (RHEL 7). There are other, separate parts to it, but aside from the service manager itself they're pretty much all about doing things through dbus, and therefore you can use something else, provided it exposes a compatible dbus interface.

[xiando]

systemd is in our tree because 1 developer likes it, but Gentoo has not adopted it as its default. My opinion is that hell will freeze before we do. The general experience that we have had with the systemd developers is exactly what Linus said. A group of us started eudev when we decided that we could no longer tolerate it.

By the way, you are thinking of sysvrc, not sysvinit. sysvinit is nothing more than /sbin/init and /etc/inittab. /etc/init.d is part of sysvrc. Quite frankly, I agree that sysvrc is awful. Gentoo uses OpenRC to replace sysvrc and it works very well for us. Many things systemd claimed to achieve over sysvinit were already done in OpenRC.

Thank you very much for Gentoo and OpenRC and resistance to the SystemD world order gang.

I see all these chicken little stories how systemd "tacles problems" that are somehow not solved and how we really need this big pile of donkey dung. I really honestly don't get exactly what it is supposed to do that OpenRC does not. As I see it systemd does not solve anything (exactly what is there that needed to be solved anyway?), it just merges a whole lot of good small programs into one big barely-working non-configurable blob.

It is kind of sad that Gentoo is the only distribution that refuses this garbage and I really hope the Gentoo developers make a huge effort to keep OpenRC. As I see it the RedHat people who seem hell-bent on destroying GNU/Linux (just look at what they are doing to gtk+ etc) really want systemd everywhere (RH just happens to be a huge DoD contractors, backdoors anyone?) will try to make as much as possible depend on it in ways that are impossible to avoid. I hope the RH drones fail but it really depends on people doing their own research and thinking and that's not happening.

[Chousuke]

This post contains too much fun (FUD) not to bite...

Thank you very much for Gentoo and OpenRC and resistance to the SystemD world order gang..

I see all these chicken little stories how systemd "tacles problems" that are somehow not solved and how we really need this big pile of donkey dung..

The scope of systemd is beyond OpenRC, and the problems it tackles are clearly defined. I am not an expert in OpenRC, but I am quite skeptical that anything based on shell scripts could robustly achieve what systemd does. Technically, you could emulate declarative configuration with shell scripts, but if the logic to actually launch processes is still imperative, the benefit is questionable.

I'm not much of a fan of unit file syntax (some things look a bit ugly), but the idea behind them is superior.

I really honestly don't get exactly what it is supposed to do that OpenRC does not. As I see it systemd does not solve anything (exactly what is there that needed to be solved anyway?), it just merges a whole lot of good small programs into one big barely-working non-configurable blob.

Several things in the above bit are not even wrong: systemd works, The "systemd suite" consists of several small programs (one of which is called systemd), and systemd (again, the suite) is extremely configurable. More so than sysvrc in fact, since it does not consist of brittle scripts with ill-defined dependencies. Want to launch two instances of a service? copy the script and hack away! Urgh.

The thing is, systemd approaches the entire problem of system, service and resource management instead of suffering from tunnel vision and going "I just want these proccesses to run". I personally want the services to be managed by the system.

I want my services to run, and thanks to systemd, I can reliably tell each process that is related to a service, I can stop services reliably (sysvinit can't, I don't know about OpenRC) and thanks to journald I don't have to wonder where the hell the log files are, what they are called and how they are rotated. This is of course just a small part of what systemd can do, but for me it's the most relevant.

It is kind of sad that Gentoo is the only distribution that refuses this garbage and I really hope the Gentoo developers make a huge effort to keep OpenRC. As I see it the RedHat people who seem hell-bent on destroying GNU/Linux (just look at what they are doing to gtk+ etc) really want systemd everywhere (RH just happens to be a huge DoD contractors, backdoors anyone?) will try to make as much as possible depend on it in ways that are impossible to avoid. I hope the RH drones fail but it really depends on people doing their own research and thinking and that's not happening.

Blah blah conspiracy theories and (not-so) vague references to malicious intent. Destroying GNU/Linux? Red Hat is probably the most powerful driving force behind Linux adoption in enterprise systems nowadays, and the benefits trickle down to everyone.

[Vim_User]

This post contains too much fun (FUD) not to bite...



The scope of systemd is beyond OpenRC, and the problems it tackles are clearly defined. I am not an expert in OpenRC, but I am quite skeptical that anything based on shell scripts could robustly achieve what systemd does. Technically, you could emulate declarative configuration with shell scripts, but if the logic to actually launch processes is still imperative, the benefit is questionable.

I'm not much of a fan of unit file syntax (some things look a bit ugly), but the idea behind them is superior.



Several things in the above bit are not even wrong: systemd works, The "systemd suite" consists of several small programs (one of which is called systemd), and systemd (again, the suite) is extremely configurable. More so than sysvrc in fact, since it does not consist of brittle scripts with ill-defined dependencies. Want to launch two instances of a service? copy the script and hack away! Urgh.

The thing is, systemd approaches the entire problem of system, service and resource management instead of suffering from tunnel vision and going "I just want these proccesses to run". I personally want the services to be managed by the system.

I want my services to run, and thanks to systemd, I can reliably tell each process that is related to a service, I can stop services reliably (sysvinit can't, I don't know about OpenRC) and thanks to journald I don't have to wonder where the hell the log files are, what they are called and how they are rotated. This is of course just a small part of what systemd can do, but for me it's the most relevant.



Blah blah conspiracy theories and (not-so) vague references to malicious intent. Destroying GNU/Linux? Red Hat is probably the most powerful driving force behind Linux adoption in enterprise systems nowadays, and the benefits trickle down to everyone.

Systemd is not able to reliably start services that are dependent on each other without those services specifically being coded against systemd-libraries and/or DBus. So it is a fail by design, unless you make yourself dependent on those technologies.

[Chousuke]

Systemd is not able to reliably start services that are dependent on each other without those services specifically being coded against systemd-libraries and/or DBus. So it is a fail by design, unless you make yourself dependent on those technologies.

This is incorrect.

[Vim_User]

This is incorrect.

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

[Chousuke]

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

For robustness, daemons need to be modified, no matter what the design is. Any init that wants to provide asynchronous or dependency based service startup will need something similar.

sd_notify is a light dependency (it does nothing when systemd isn't actually running, and certainly a dependency on dbus is not required) and actually implements Option 1 in that blog post. (internally, it sends a datagram to a UNIX socket, so if you really wanted to avoid linking against libsystemd, you could reimplement it yourself)

The rest of the options are there for daemons that can't be modified. In any case, systemd still handles dependencies better than sysvinit.

[Nobu]

Please read this, it explains what I mean. Afterwards, please be so kind tell me where exactly it is incorrect: http://ewontfix.com/15/

The whole idea of systemd's service supervision and activation system is built on being able to start services asynchronously as soon as their dependencies are met (and no sooner). However, none of the above choices actually make it possible to do this with a daemon that was not written specifically to interact with systemd!

In the case of simple, there is no way for systemd to determine when the daemon is actually active and providing the service that subsequent services may depend on. If using "socket activation" (a feature by which systemd allocates the sockets a daemon will listen on and passes them to the daemon to use), this may not matter. However, most daemons not written for systemd are not able to accept preexisting sockets, and even if they can, this might preclude some of their functionality.

So, how do the clients (or, "subsequent services") find out that the service is available normally? Is it a PID file? Does it listen on a SOCKET? How does OpenRC determine when the service is "ready"? The answer may be surprisingly similar to what you would have to do if you use systemd...but I couldn't tell you without a concrete example.

I find all of the systemd documentation and publications helpful, regardless, for my simple usecase (a "user").