Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[Anarchy]

History repeats itself

Yay! This sounds exactly like pulseaudio once again. He said, She said. And no one to fix the bugs.

I hope Greg know what he's getting himself into.

[stqn]

What Prodigy_ said.

[interested]

This one is easy. Everything that extends beyond service management is bloat (so about 90% of what systemd is today).

What you call bloat, I call great features that finally gives some Linux distros some baseline compatibility layer. systemd helps upstream developers develop for Linux by providing a uniform compatability layer, while the non-systemd distros makes no such concerted effort.

But that systemd is great software, that it is well programmed, well documented, backwards compatible, has extremely low impact on system resources, and makes many things possible that are impossible to do on non-systemd distros, isn't all. The fact that non-systemd Linux distros basically makes zero effort to address all the problems that systemd is tackling, shows that non-systemd Linux distros are a dead end.

It is convenient for systemd detractors to call its many features like "logind" for "bloat", since it covers up the fact, that non-systemd distros does nothing to solve such problems. But hey, who needs multi-user support and laptop suspend and....?

So you convince nobody by calling systemd for "bloated" or "Windoze like". Try instead to rally the non-systemd folks around some positive work like making all non-systemd Linux distros place the "os-release" file the same place and calling it "os-release" and not "os-version". It should be easy, it is just a text file, but for now there a dozens of variations of what to call the file and where to place it, making it hard for the upstream GUI developers to even show such basic information as the Linux distros name and version number on non-systemd machines.

[justmy2cents]

I know why upstart was never adopted beyond Ubuntu and derivatives. Though upstart has the benefit of simplicity, ultimately it's just as broken.

That's not what I was talking about though. Systemd isn't just a PID1 that starts daemons. Sadly, it's much more. As you said, it "covers all of the bases" forcing everything to depend on it (networkd, logind) and making things less transparent than they used to be (journald).

hmmm, if you go 2 or 3 threads before this one, where systemd is promoting dhcp client/server... check 1st post and few others. you'll find i share exact sentiment as you. they made really awesome init to start daemons and sockets, they made some things that just make sense... but, at some point you have to realize that if you reinvented and hardcoded everything, there was no point in making that awesome init, not to mention your project became bloated and hard to discern what his real function is

still, i don't even remotely say all services in systemd are wrong. i can't count how many times i was searching how this or that distro stores basic thing like hostname. hostnamed is a blessing and it is completely optional and reimplementable since it is basically d-bus spec on what your service should provide. what i want from systemd is simple unification and standards. more or less all services up until now were basically that... d-bus spec on how to provide information.

[Gusar]

This one is easy. Everything that extends beyond service management is bloat (so about 90% of what systemd is today).

So what would you do about the stuff I mentioned, like session tracking and relieving DEs from having to implement distro-specific backends for configuration GUIs? These features are desirable, DEs and distros saw value in them, that's why they adopted systemd. Would they still be "bloat" if they were provided by separate projects but did the same thing?

And how would you provide what journald does - capturing syslog, stdout and stderr of a service into a common place, and all the querying options (by process, by date, stuff like "since last reboot", and other neat stuff) without tight integration with the service manager? Saying "I'm perfectly ok with grepping text files" is not a valid answer, just because you might be happy with the status quo doesn't mean others don't welcome the additional functionality.

[Guest]

This one is easy. Everything that extends beyond service management is bloat (so about 90% of what systemd is today).

Could you explain why? systemd is not just shitty service management software. Following your logic sysvinit isn't suitable as systemd replacement, because it only supports about 10% of systemd features. Why would anyone want to use something that lacks important features and performance?

[gamerk2]

That's a pretty silly issue. I'd say the ideal thing to do would be to add systemd.loglevel=n where the default was 0 (no log output), 1 would output just a bit and something around 5 would start crashing the system.

That's the way most systems are built. The REALLY stable ones also start stripping messages based on priority if the buffers start to overflow, as an added safety valve. The kernel shouldn't crash because a buffer overflowed; the overflow should be handled.

[fscan]

So let me get this straight ... the root of the problem, to verbose logging in debug, was fixed in -git a long time ago (David)

The rest of the bug report is just nonsense because:
1) debug is exported in proc and therefore supposed to be used in userspace (Linus)
2) there ARE command line parameters to achieve what he wants but he doesn't want to use them. He just wants systemd to generally ignore debug.

yeah, the response in bugzilla wasn't that good, but it is basically NotABug(TM)

[ryao]

So, let's start with some obvious ones. What does sysvinit do better over systemd? I know, burden of proof...
First up, systemd provides a more sane and generic method of daemon startup to reduce boilerplate that was found in sysvinit. As a side effect, this also allows a bit of consistency when it comes to things like what the console actually says whenever a daemon is successfully started.

Systemd works fine for thousands if not hundreds of thousand. It's good enough to be adopted by the currently most popular distributions (Ubuntu, CentOS, Fedora) along with the lesser used (Gentoo, Arch Linux come to mind).

Even if systemd is a flop, what it does right now is more productive and consistent than what sysvinit was able to provide us. A replacement would look closer to systemd or upstart than it would to sysvinit.

I personally think systemd is doing fine. If things go sour, the nature of open-source will have its way like it always does.

EDIT: Also, it's generally not good to use something that's marked as deprecated, even if it does work.

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.

[prodigy_]

So what would you do about the stuff I mentioned, like session tracking and relieving DEs from having to implement distro-specific backends for configuration GUIs? These features are desirable, DEs and distros saw value in them, that's why they adopted systemd. Would they still be "bloat" if they were provided by separate projects but did the same thing?

No they wouldn't. See, systemd is modular in theory but in practice it's not because in practice it isn't a thing in itself. When you install a Linux distro most of the time you deal with sets of binary packages. Disabling components at the level where init operates means you'll have your own distro to maintain. So you either accept the wholesale deal or switch to another distro that doesn't use systemd. Having alternatives is little comfort when you can't really use them because their role is hijacked by the init system.

And how would you provide what journald does - capturing syslog, stdout and stderr of a service into a common place, and all the querying options (by process, by date, stuff like "since last reboot", and other neat stuff) without tight integration with the service manager? Saying "I'm perfectly ok with grepping text files" is not a valid answer, just because you might be happy with the status quo doesn't mean others don't welcome the additional functionality.

What's the journald equivalent of 'grep -R something /var/log/*'? Grepping isn't just OK, my friend, grepping is bread and butter for someone who needs to fix obscure issues and needs to fix them fast.