Linux Kernel Developers Fed Up With Ridiculous Bugs In Systemd

[Ericg]

It's not so much the disk space that's the issue, it's what the features do, maintaining the code of those things, and the other system resources those things end up consuming. With Canonical now supporting systemd, it will get bloated much faster. It might not hit 30MB in 5 years, but as long as any of the "unnecessary" features (such as systemd's networking capabilities) get screwed up, it could cause issues for distros like Debian, which will have to stick with a very old outdated version. By separating such things, a distro like debian could still use a much more up-to-date "systemd-core". It's all about maintenance, and something as critical as systemd needs to be fundamentally stable. You can't get that kind of stability out of features that don't HAVE to be there to begin with.

Almost, if not EVERY, non systemd-core component of systemd can be turned off at compile time with a --disable-$XYZ flag except MAYBE the journal. I think a barebones systemd is like 2mb's. Thats always why all of us who support systemd have wanted to strangle everyone who shouts "Systemd is bloated! Systemd isn't modular!" because the reality is you can customize and cut down systemd to WHATEVER you need it to be. Want everything? Bam. Done. Got an embedded system that you just want systemd, journal and networkd? Bam. done.

[ryao]

if you don't like /proc, fuck you. thats how unix works and its a lot better than windows system calls AND osx, solaris, openbsd system calls for this.
if you don't like Linus's way of handling things, fuck you. It works way better than anything else. If Linus were to die tomorrow, we'd have a serious problem. People don't filter bullshit enough.

And in case you wonder, bullshit-filtering is a very good use of swear words.

/proc is from Plan 9. It was not part of the original UNIX, although many UNIX systems adopted some form of it. Linux obtained it by virtue of being a System V kernel clone.

[schmidtbag]

Almost, if not EVERY, non systemd-core component of systemd can be turned off at compile time with a --disable-$XYZ flag except MAYBE the journal. I think a barebones systemd is like 2mb's. Thats always why all of us who support systemd have wanted to strangle everyone who shouts "Systemd is bloated! Systemd isn't modular!" because the reality is you can customize and cut down systemd to WHATEVER you need it to be. Want everything? Bam. Done. Got an embedded system that you just want systemd, journal and networkd? Bam. done.

I'm aware - I'm a supporter of systemd myself. But that doesn't change the fact that as long as it's monolithic, it becomes a burden on people who aren't verse in how to configure it, and a burden to people who pride in stable distributions. As someone who uses Arch, I don't really care either way, but I'm not focusing on my needs.

[RahulSundaram]

You might want to rethink when you consider the fact that I am at least willing to tolerate such things in the tree.

I wouldn't call that toleration. It is a basic requirement. In any open source community, no individual contributor should be allowed to dictate what others maintain. This is especially true of integration projects where there are no defaults.

[GreatEmerald]

Even though I don't mess with proc myself I gotta agree that having to write string parsers just suck, setting up parsing is one of the most asininely annoying tasks you can make a programmer do. That said if you format the output in JSON or XML then you retain the benefits of text based formats, while making the lives of programmers much much easier, and also allowing you to have a bunch of extra cool features.

I always assumed there were argument parsing libraries out there? Most command-line utilities seem to have pretty unified argument passing rules.
But yea, writing those is annoying. I usually end up with some pretty lame things, like (in D) if (args.canFind("-h")) writeln("Usage: -h Display this help string"); which means that having "-h" anywhere in the argument line would cause it to display a message and quit (and I usually can't be bothered to come up with more sophisticated methods for simple programs).

[IgnorantGuru]

Ts?o and Linus And The Impotent Rage Against systemd

A trackback for this discussion, and a must read for those who care anything about Linux. These kernel bug discussions are just scratching the surface. If nerds don't wake up to the world around them, the larger influences that the likes of Sievers and Poettering represent, and how the Linux community is being gamed by big government and big business, you're going to lose your 'free and open' toys - in fact you already have.

http://igurublog.wordpress.com/2014/04/03/tso-and-linus-and-the-impotent-rage-against-systemd/

[chrisb]

You do know that osx, solaris, and openbsd are all unix, while Linux is not, right?

OpenBSD is not Unix.

[curaga]

Even though I don't mess with proc myself I gotta agree that having to write string parsers just suck, setting up parsing is one of the most asininely annoying tasks you can make a programmer do. That said if you format the output in JSON or XML then you retain the benefits of text based formats, while making the lives of programmers much much easier, and also allowing you to have a bunch of extra cool features.

Did you hear the kernel oopses will be output as QR codes in the future?

[chrisb]

Even though I don't mess with proc myself I gotta agree that having to write string parsers just suck, setting up parsing is one of the most asininely annoying tasks you can make a programmer do. That said if you format the output in JSON or XML then you retain the benefits of text based formats, while making the lives of programmers much much easier, and also allowing you to have a bunch of extra cool features.

You have a problem. So you add XML to the kernel. Now, you have two problems.

echo 1 > /proc/sys/net/ipv4/ip_forward

It's simple, it works across languages, and is easy to do from an interactive shell. I don't want to have to write structured binary data, or well formed XML or JSON, in order to change a simple kernel setting.

[GreatEmerald]

I wouldn't call that toleration. It is a basic requirement. In any open source community, no individual contributor should be allowed to dictate what others maintain. This is especially true of integration projects where there are no defaults.

Exactly. The attitudes some of the Gentoo developers have had in the past (and some seem to still have, hint hint) are really disheartening. I've seen a case where a contributor was bullied into writing an init script for a package (that didn't even necessarily need it), on the grounds of "just because I don't accept packages without OpenRC scripts". On their IRC channels it used to be that if you have a problem, they'd ask about your init system, and if you happen to use systemd, then they would refuse to help (even if the problem had nothing to do with the init system).
Thankfully, the situation has changed to the better lately. systemd has been gaining support, it's been added to the installation guide and a convenience option for it added into gentoo-sources, people on IRC have started to be helpful even about systemd-related issues etc. Only when directly talking about systemd vs OpenRC do you get to hear them bashing systemd now.

Things like that do matter to me, since I'm a Gentoo contributor myself. I maintain the Snapper package in Gentoo Sunrise. It's a Btrfs snapshotting tool, and it just so happens that due to sufficient interest (including mine) Snapper just recently received better systemd integration. So if the attitudes were to switch back to what they were again, I would honestly consider moving to contributing to one of the Gentoo forks, instead...