New Group Calls For Boycotting Systemd

[0xBADCODE]

BoycottSystemd.org bashes systemd for its journal files in a "complicated binary format", it being "anti Unix",

Oh, these nuts should immediately delete tar/gzip/lzma/bz2 and of course in no event they should dare to try to gzip old logs. Because compressed data format is a binary stuff and you'll have a real headache decoding gzip with pen and paper back into text, because of adaptive huffman + LZ make it not so easy at all. I'm just amazed by amounts of bullshit thrown on systemd without even trying to turn on brain and think a bit.

Concluston? Binary formats are not evil. It's matter of tools to transparently access them. E.g. you can pipe compressed log to other tools and they will handle it. If systemd would permit same thing, it is not anyhow worse of gzipped logs, isn't it? And then binary format can allow efficient indexing. Let's assume we have 10 gigz of logs. Now I'm interested what IP 10.10.10.10 did on my system. Classic *nix solution assumes parsing whole 10 gigz and then discarding all entries not matching criteria. Needless to say it is not efficient at all and stinks when it comes to dealing with large log files. OTOH binary format can offer index, so I can quickly get idea what mentioned IP did without reading whole 10 gigz by only looking matching records as long as there is proper index built. Not to mention IPv4 takes 4 bytes to store as binary but up to 15 bytes as text. That is it - almost 4 times larger than it could be. So when it comes to dealing with large logs from busy servers, Lennart getting some point, huh?

[Delgarde]

I'm primarily in the "as long as it works and works well" camp, but if the "log files are binary" is true, now THAT seems a bit of a pain. But given that I just don't have any experience trying to dig into systemd logs nor know the reasons binary was the choice, maybe if I did I wouldn't react negatively about that.

They're binary for much the same reason that databases are binary - because while grep and sed are great tools for searching through text files, they're kind of clumsy when you want to do things like "show me all high-priority log items between 13:00 and 14:00 last Tuesday". You *can* do that with on text files if the file structure is clean enough - but it's essentially a programming task to read the files into a format that tools can work with. With a structured binary format, the logs are already in a form optimised for tools to work with, and while you can't use sed/grep, systemd provides excellent command line tools for querying the logs.

[Delgarde]

Now I'm interested what IP 10.10.10.10 did on my system. Classic *nix solution assumes parsing whole 10 gigz and then discarding all entries not matching criteria. Needless to say it is not efficient at all and stinks when it comes to dealing with large log files. OTOH binary format can offer index, so I can quickly get idea what mentioned IP did without reading whole 10 gigz by only looking matching records as long as there is proper index built.

Yeah, that's a good example. The point is, the binary form might not be human readable, but like any good database, it's optimised for searching for the entries your interested in. And if you just want to read the entire thing as a text file, you just tell systemd to query *everything*, and pipe it to your pager of choice.

[0xBADCODE]

Yeah, that's a good example. The point is, the binary form might not be human readable,

Gzipped log aren't human readable either. I do not know humans capable of rebuilding huffman trees and LZ dictionaries in their brain in efficient and working ways. So its really amusing to see how far some humans can go in their double standards, failing to recognize they use bunch of binary formats here and there every day. Even TCP/IP is binary and sends IPs as just fixed 4 bytes field, which is simple to parse, so packets can be routed in millions. Basically it is about transparent access. These days gzip is quite widespread so gzipped logs aren't big issue at all.

And if we're about corruption, text logs lack any integrity checks. Should data get corrupted or some intruder tampered log, it just goes undetected at all. Cool, isn't it?

[kringel]

Just my trouble as an average joe end user with systemd: I think systemd brings a lot of problems because it does too many things. I'm right now on Debian jessie. Try this:
1. Forced Shut down with the power button
2. Restart
3. systemd-fsck does nothing and says: ext4 filesystem is clean and perfectly fine (and that's wrong) (as a work around for safety I set the maximum mount count to 1 via tune2fs, "great")

Another example: Clean shutdown I always get some error messages (which I can't read!) about a "systemd: corrupted (systemd-)journal blabla" and that's it. Probably just ignore it. ^^

Ok, so systemd is actively bothering me, so please allow me to troll a little, ok? Thanks. I have a theory:
Maybe systemd is too much German. (Hey, I'm German too! ) No, really. Systemd is exuberant, it has this "prove something to the (linux) world". (off topic example for this: Germany is the only country shutting down all it's nuclear power, because of what happened in Japan. France didn't shut down anything, Poland didn't and so on. So either we are a bit crazy or the others are crazy – and I believe the first option to be true.)

I don't want to judge Mr Poettering, and he sure earned and deserves his respect as a programmer. But I personally *think* (in my head) that he is very proud of his project ("PID EINS!" on his website) but maybe got at least a bit narcissistic over it. Or at least in technical terms. Maybe that's absolutely cool and helpful for a software project. Maybe I'm narcisstic, too. Maybe I'm an idiot and Poettering is not. But...

What I want to say: What about the eco system of Linux? It's not good for it when a few people can dictate their "visions". An Poettering is talking about his visions actually quite often. In his latest blog posts for example. And too many people are forced (because of Red Hat) to follow his visions.

When I hear "visions" I think of, that former chancellor Helmut Schmidt once said, that a person who has "visions" should really go see a doctor. ;-)

[emblemparade]

Sigh. Every single point in this website's list has been refuted several times. But people seem to attached to their myths (like the one about Wayland not "supporting" remote UIs).

1. Too monolithic? Actually, no, the systemd tools are very narrow. systemctl only changes services, but you need a different tool to show the status. So, these are building blocks which can be used by a higher-level tool to, say, restart a service and then show its status. There's a lot of flexibility here, systemd doesn't tell you how to design your admin tools. As for the growing ecosystem of replacement services in systemd (a replacement for crond, logind, etc.) -- these are all optional components and by no means "required". So why are they there? Because these rewritten components are designed to integrate very strongly with systemd: this allows for much improved error checking and reporting, robustness and flexibility during the init processes. For example, you can have a login system that allows different secure network inits per user -- stuff that bubbles all the way up to the desktop environment (which is why GNOME 3 is considering standardizing on systemd, a different controversty). Again, no distro has to use the extended systemd ecosystem: you can just use the very minimal systemd core and continue using your existing crond if you really want to. It's up to distros to decide exactly how to integrate systemd and which components make the most sense. I can understand the anxiety some admins feel of getting too much change at once: but this issue needs to examined per distro, looking at exactly what choices they are making in packaging and integrating systemd. I'm sure some will be more radical in the changes than others: if you're conservative, pick the more conservative distro.

2. The log database. What, and a text file has ACID? This complaint makes no sense. And it's been repeated ad nauseum: systemd definitely supports logging to text files if you want that.

3. Too focused on Linux and anti-Unix. Except that every proprietary Unix out there has its own robust init sytem, different from others. It's about time that Linux had its own good init system, too.

4. udev/dbus. Choosing "udev" is political? I don't really understand that complaint. As for "dbus", this is subjective, but dbus has proven itself as an excellent standard for interprocess communication. It's merely a standard protocol on top of pipes. It has mature tools and wrappers for almost every programming language. So it seems like a good move to make it especially easy for devs to write tools that interact with the init system. And remember, dbus is being integrated into the Linux kernel, so it means it passed the very stringent requirements of that project.

5. Dumping to the journal. Wow, this seems bizarre. You don't need root acesss to use the journal. That's the whole point of user permissions. Anyway, this stuff is configurable.

6. SPoF. Any init system would be a single point of failure, not just systemd. This does mean that robustness and maturity are important (again, for any init system). But this goes back to the complaints about systemd being monolithic: actually, it has a minimal core, and the extra components are just that: they run separately.

7. Viral. Well, I for one (as a dev) prefer to have one popular init system, so I don't have to create 10 different init scripts for my software. (I do like Upstart more, but understand why it's a good idea to let it go and focus on systemd instead.) And did you forget that systemd actually supports traditional System V init scripts for legacy software? (with caveats, for sure, but it's still an important feature)

8. PID1. This is actually a fairly legitimate complaint, but there's a double-edged sword here: by managing PID1, systemd gets much improved error handling and recovery, at the same time as an attack on systemd can give the attacker a lot of power over the operating system. I can see admins falling on both sides of this camp. It would be interesting to see if the systemd project can satisfy the more security-minded admins in the future. (Of course, having a legitimate complaint doesn't justify the hysteric reaction against systemd...)

9. glibc. Well, even if the systemd devs aren't themselves interested in supporting other standard libs, if someone really needs it (a specialized embedded Linux?) then I don't see why the devs would reject patches that can support it. In the end, such distro makers aren't forced to use systemd at all, so this is a very bizarre complaint. For example, would Android switch to systemd? It's up to the Android team, but I have a feeling that we won't see such a switch for a very long time.

10. Too narrow functionality. Really? Even with an open dbus API? If there's an API that you feel you really need, well, that's the reason that systemd keeps developing and progressing and is inviting contributions from so many downstream projects. Really, the only reasonable complaint about systemd is that it is not mature enough: but there's a chicken-and-egg problem here, in that it won't mature until it's widely enough used. This means we will have an awkward few years of adoption. But that's how change works in software. systemd is trying its best to support the legacy, but there's only so much you can do. (The laughable claim in this point is that "conventional init" is "deterministic" and "predictable".)

11. Parasitism? Monolithic and post-modernist?! As I understand it, post-modernism is all about tiny unrelated fragments that can reassembled as pastiche to create new timespaces. If anything, "classic" Unix was always radically post-modern, while a "monolithic" approach is more vehemently, classic Englightenment modernist. But any way, this is all upside down: I'll repeat, systemd has a minimal core, and all the "bloat" people complain about is an optional ecosystem that reimagines classic operating system components as more tightly integrated. systemd is not monolithic software. It is, however, part of a big project, with many components and lofty goals. But you don't have to use all of it! For example, I love the Ubuntu project, but dislike Unity, so I use Xfce on Ubuntu. The systemd gives you the same ability to pick and choose what you want to use.

12. systemd doesn't know what it is. Ha! You can accuse Poettering of many things, but having a narrow vision is not one of them.

[kringel]

I also agree with that: "I ended up writing my own ?Fuck Systemd? service file hack, which starts the shell script /root/startup.sh on every boot." http://adrian.holfter.de/blog/2013/05/systemd-sucks/

Nice! ==> "[systemd is] vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and just a huge anti-pattern in general. If your goal is to pander to the lowest common denominator[*], so be it. We will look for alternatives, however." (#11, http://boycottsystemd.org/) *)we call this "alternativlos" by the way

True: "4. udev and dbus are forced dependencies. In fact, udev merged with systemd a long time ago3. The integration of the device node manager that was once part of the Linux kernel is not a decision that is to be taken lightly. The political implications of it are high, and it makes a lot of packages dependent on udev, in turn dependent on systemd, despite the existence of forks, such as eudev. Starting with systemd-209, the developers now have their own, non-standard and sparsely documented sd-bus API that replaces much of libdbus's job, and further decreases transparency." (http://boycottsystemd.org)

"#systemd implementing a ntp client now. They could have told us from the beginning they wanted to compete with #emacs" https://twitter.com/Donearm/status/471708084466110464

"After implementing its own ntp client, --according to rumors-- systemd is going to be renaming itself to Skynet in Q4 of 2014." http://blog.fefe.de/?ts=ad78a99e

And a rant from 2010 about this whole freedesktop, hald, udev, systemd which would turn Linux in this philosophy "from a single user system to a zero user system" http://blog.fefe.de/?ts=b53326b6 (in German)

PS: Oh, I forgot the the friggin GNOME dependencies.

[mirex]

Germany is the only country shutting down all it's nuclear power, because of what happened in Japan. France didn't shut down anything, Poland didn't and so on.

Maybe because Poland doesnt have any nuclear power plants ?

Anyway 90% guys here are bashing that boycott site without any knowledge.
Truth is that systemd will fall like a Roman empire in few years, just w8 and see.

[finalzone]

Just my trouble as an average joe end user with systemd: I think systemd brings a lot of problems because it does too many things. I'm right now on Debian jessie. Try this:
1. Forced Shut down with the power button
2. Restart
3. systemd-fsck does nothing and says: ext4 filesystem is clean and perfectly fine (and that's wrong) (as a work around for safety I set the maximum mount count to 1 via tune2fs, "great")

Could the issue be related to Debian Jessie?

[mike4]

On Ubuntu my CH Pedals don't work anymore since 12.04 probably because of UDEV? Even after adding this crappy udev rule thing it only works sometimes!-