Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

[Delgarde]

Can somebody explain to me why a desktop app should have a hard (!!!) dependency on a particular system daemon?

Is there ANY technical reason for this?

An *application* shouldn't, in most cases, and I think it unlikely that Gnome apps will start depending on systemd (though they might use APIs for which systemd is the only implementation).

It's the desktop itself where hard dependencies on systemd would occur - particularly if they go down the path of using systemd as the user session daemon, as has been discussed and experimented with in both Gnome and KDE.

[Delgarde]

Thank you all for detailed responses.

I understand why systemd is useful for login managers and starting the environment. I still think they should be soft dependency, but here the integration makes perfect sense.

The problem with making such things soft dependencies is that you now need two sets of code - one that supports the case where the dependency is met, one supporting the case where it's not. And since we're talking about using systemd as the user session daemon (i.e a user-level equivalent of PID1), the second case basically means "write something that isn't systemd but provides the same functionality". And of course, the developers are almost all using systemd, so the second option receives only minimal testing, and keeps breaking because the one or two people maintaining it can't keep up.

Short version - choice is a wonderful thing, but it comes at a cost. And often, that cost is more than the choice is worth.

[Chousuke]

Can somebody explain to me why a desktop app should have a hard (!!!) dependency on a particular system daemon?

Is there ANY technical reason for this?

Some GNOME features depend on services provided by systemd or its subcomponents, via documented and stable DBUS interfaces.


Nothing else provides these services, and the GNOME devs would rather disable features than work around the shortcomings of inferior systems.

Where's the hard dependency?

[finalzone]

For me, as a user, Linux is about diversity. If I don't like something, I use an alternative. It's not a "choice" but a real choice. Now, if you are telling me that I will be forced to use systemd, because the applications I like depend on it and won't work without it, then THAT is a "choice", an illusion of choice from those who defend something. That's what prodigy_ meant with "Windowisation", I think: you have "alternatives", but they are not real alternatives.

Ah the word "forced" used on every argument against systemd. It is the distrubitors decision to use systemd because it fulfills their needs. You can choose to switch your operating system or build your own as you wish. As mentioned, choice always comes with cost, you are free to maintain your own system and handle the burden while other collectives move on. Windowisation would mean proprietary environement without access to the core source.

[TeamBlackFox]

Ah the word "forced" used on every argument against systemd. It is the distrubitors decision to use systemd because it fulfills their needs. You can choose to switch your operating system or build your own as you wish. As mentioned, choice always comes with cost, you are free to maintain your own system and handle the burden while other collectives move on. Windowisation would mean proprietary environement without access to the core source.

He obviously meant Windowsisation in terms of everything being monolithic and tightly integrated so as to make the entire system fail. As I said earlier systemd is a massive security risk if it gets an exploit in the main binary.

[Ericg]

He obviously meant Windowsisation in terms of everything being monolithic and tightly integrated so as to make the entire system fail. As I said earlier systemd is a massive security risk if it gets an exploit in the main binary.

Luckily the entire thing is open source. Also, given that its not the kernel the barrier-to-entry for review is significantly lower. AND if there IS an exploit the wonderfulness of git makes it extremely easy to track down who put the exploit in and figure out if it was accidental or intentional.

[asdfblah]

Ah the word "forced" used on every argument against systemd. It is the distrubitors decision to use systemd because it fulfills their needs. You can choose to switch your operating system or build your own as you wish. As mentioned, choice always comes with cost, you are free to maintain your own system and handle the burden while other collectives move on. Windowisation would mean proprietary environement without access to the core source.

Great, I'll study CS and waste time either maintaining someone else's pile of code, or coding my own init system just because someone thought that booting in 30s was too much (but my computer boots in <2s, it's called "suspend to RAM". Microsoft got a similar idea, they call it "hibernate". Those things have been there for decades already..) and decided to reinvent the wheel (is there anything NEW at all in systemd? this article suggests there isn't: https://lwn.net/Articles/389149/). Who knows what surprises will we get in the future.

And lets not forget that sales of desktop PCs are nose diving... meanwhile, devs could be hacking ARM, and giving us stardardized useful, cheap, multi-purpose, multi-architecture systems. We will have to re-learn and re-do many things, in a moment in which Linux users could be helping people that comes from the microsoft walled garden. You (and I) criticize canonical for reinventing the wheel. Suddenly, if Red Hat does it, the new wheel is cool!

Here, a pic of Poettering offering a solution for our desktops to boot faster:


I wonder if this guy, Poettering, is trying to justify is salary with this mess...

[TeamBlackFox]

Luckily the entire thing is open source. Also, given that its not the kernel the barrier-to-entry for review is significantly lower. AND if there IS an exploit the wonderfulness of git makes it extremely easy to track down who put the exploit in and figure out if it was accidental or intentional.

You do realise how stupid you sound right? Yes it is open, but its encumbered by the GPL, which ranks at the bottom of free licenses. A lot of developers, like myself, do not contribute to GPL licensed programs because by doing so we are supporting a foundation we don't agree with at all and also giving our hard work away to never be used in a commercial venture, or better yet, a truly free project. OpenBSD has a lot more security auditing because it is so freely licensed that technically you retain your right to the code you contributed. systemd is plainly a single point of failure for many roles which can be distributed amongst several smaller programs. While I agree git makes it easier to figure out how the hole got there, that's not important as that doesn't help you find it at all. What's important is finding it and patching it. systemd will be the glory hole for script kiddies who get a shell on a Linux server. Too bad for that person running the server.

[asdfblah]

Luckily the entire thing is open source. Also, given that its not the kernel the barrier-to-entry for review is significantly lower. AND if there IS an exploit the wonderfulness of git makes it extremely easy to track down who put the exploit in and figure out if it was accidental or intentional.

Have you ever heard the concept of "Attack Surface"? here you can read about it: http://en.wikipedia.org/wiki/Attack_surface
A system deamon that has lots of features, runs as system process, and has its own built-in network services is a intruder's wet dream.

[Gusar]

[ranting...]

By making it all about boot times, as if that's all systemd has to offer, your argument loses a lot of merit. It loses even more merit by your attack on Lennart.

Making cheap pot shots will not stop distros and DEs from adopting systemd.

A system deamon that has lots of features, runs as system process, and has its own built-in network services is a intruder's wet dream.

Well, it's good then that systemd does not have built-in network services. networkd is a separate daemon, it's not in PID1. PID1 basically just contains the service manager, which includes cgroup handling. The rest is outside PID1.