New Group Calls For Boycotting Systemd

[Paul Frederick]

It's default in RHEL 7, and will be in Ubuntu 16.04, and, I think Debian 8.
Regardless of how you feel, systemd has already won.

Based on the content of your brief comment it is clear to me that you lack even a rudimentary grasp of Linux. I mean how can you use numbers to declare winning on an OS that does not even have a fraction of a percentage point of market share to begin with? Linux was never about numbers, it is about excellence. Even Linus doesn't like systemd! For now I'm siding with him on the issue too. Although just based on what I know about systemd it is a total disaster. Systemd is an order of magnitude more complex than the present init system for marginal gains at best, and some definite loss of functionality, and transparency too. In other words the more I learn about systemd the less I like what I'm hearing about it.

But you go ahead and run systemd big winner. Eat shit 50 billion flies can't be wrong! Fuck it, just go run Windows if big numbers are what does it for you.

[Paul Frederick]

That's not the primary feature of systemd. It certainly is _one_ feature of systemd.



The systemd results are not terrible at all. Getting rid of terrible, bloated, duplicated init scripts is a nice thing.

So, you like less files do you? You do realize that systemd needs more than 10 times as many files as init does don't you? As in init takes about 75 and systemd needs over 900! Oh but you'll be saving on a few duplicates so you'll be way out ahead. fscking moron.

[kringel]

It will be "fun" the next years: http://techfun.eu/de/news/4020-lenna...en-mit-paketen
"Lennart Poettering: Systemd and Brtfs instead of Linux distributions with package managers"

Have you seen how Poettering bitches when someone criticize his code? Usually he says "File a bug!", because he looks to me like he might be too lazy for a real debate. Ok, so if people actually DO file a bug, he recommends to just ignore it. And it gets closed with NOTABUG. This bug report was about fixing journal corruptions. Poettering closes the bug with: "Yupp, journal corruptions result in rotation, and when reading we try to make the best of it. they are nothing we really need to fix hence." https://bugs.freedesktop.org/show_bug.cgi?id=64116 via: http://boycottsystemd.org/ (you actually read this last page, or not?)

Poettering points during a debate are often on very thin ice. He uses cheapest rhetoric "Have you filed a bug?", "Do you hate handicapped people?" (it was about the login manager), just take a look: http://www.youtube.com/watch?v=_ERAXJj142o&t=1021 Or this: http://www.youtube.com/watch?v=_ERAXJj142o&t=1380 and here he even hijacks the stage because of his whatsoever ego: http://www.youtube.com/watch?v=_ERAXJj142o&t=3225 He is a full-blown narcissist. He should fork the Linux kernel for his own distribution or become a rock star or something. But such egocentric like him hurt the entire Linux eco system.

He also argues about "customers with all kinds of interesting wishes" to justify his bloatware. Remember, both Kay Sievers and Lennart Poettering and Greg Kroah-Hartmann are all employees of Red Hat. Not just some "talented" developers. And Red Hat of course has an agenda (which is fine for a company -- well, and probably is infiltrated by the NSA, and the NSA is surely not interested at all in this whole "one linux" thing, surely not, of course not...).

Remember Torvalds in his age? Or Theodore T'so? They were different. It's astonishing how Poettering suceeds in spreading his crap through the entire eco system. Oh, by the way here is a good quote from T'so: "It's not entirely fair to charge all of this to Systemd's account, but I think one of the reasons why this happens is because +Kay Sievers and +Lennart Poettering often have the same response style to criticisms as the +GNOME developers --- go away, you're clueless, we know better than you, and besides, we have commit privs and you don't, so go away." https://plus.google.com/+TheodoreTso/posts/4W6rrMMvhWU

Poettering on another issue: "screw the BSD guys" http://linuxfr.org/nodes/86687/comments/1249943 What an arrogant *******!

You REALLY want this person determine the very next and long term future of Linux? Seriously?

Poettering is forcing down Red Hat's current goals and agenda down everyone throat. And everyone seems to apply to that. And you know what? "Fragmentation" is a damn good thing. That is what made Linux successfull and free. F**k systemd.

One general observation:
The pro-systemd crowd is most often a bunch of pragmatists. And the others are evil "ideologists". Ideology is basically a combination of principles. Nothing bad technically. Poettering doesn't have any principle, technically in terms of programming he is a lazy opportunist. Portability? Who needs it?

Hey fanboys, (and also the paid fanboys), you will be deceived. Red Hat is not at all in ties with the military complex or in bed with the US government. Not at all. ^^ And such egocentric people like Poettering or Sievers are just tools.

Let's talk again in five years. I really believe Poettering's ambitions are spiteful and/or lazy.

PS: Read the comments there: http://igurublog.wordpress.com/2014/...ainst-systemd/ Especially the one(s) by pdkl95

Also nice discussion: "Wie w?re es, wenn Poettering seinen Kram mal POSIX-kompatibel baut?
gweihir (mehr als 1000 Beitr?ge seit 04.12.00)

Dafuer ist er nicht schlau genug.

Ich denke, die NSA hat Poettering da gezielt ausgewaehlt, weil er das
grosse Ego und die maessigen Skills hat, die es braucht um ein
komplexes und einfach angreifbares Monster wie systemd zu bauen. Dann
gibs noch Hilfe dabei das Teil mit Mitteln aus der psychologischen
Kriegsfuehrung ueberall reinzuwuergen (funktioniert anscheinend
erstaunlich gut, den kein guter Softwerker wird diese Machwerk fuer
eine Verbesserung halten, aber die meisten kuschen oder bekommen
sogar Stockholm-Syndrom), und fertig ist der einfache "Zugang" zu
jeder Linux-Installation ueberall. Etwas so komplexes with systemd
wird tausende von Verwundbarkeiten enthalten und kann prinzipiell
nicht repariert werden." http://www.heise.de/open/news/foren/...24864565/read/ (please go to Google Translate, thanks)

[0xBADCODE]

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.

I can't remember any stable Debian releases including systemd so far. Hence you're running TESTING version of distro. And therefore it would be better for you to go report bugs to BUG TRACKER if you can identify reason behind bug. Complaining on forums about bugs in testing versions of software without filing bug in bug tracker is, ahem, rather futile. When you're using TESTING versions of programs you CAN face breakage here and there and you have to expect it, even if it may or may not be a case.

Basically, average joe should not use testing versions of programs unless being ready to face consequences. Systemd-related bugs are just one of them. I've seen far worse things. For example, GRUB fallout, where system remains completely unbootable if you happen to be unlucky enough and do upgrade of testing at certain time.

[WizardGed]

Can I have poorest arguments i've ever read for 500 Alex.

I don't mind that. Feel free to use systemd, I really don't mind that either.

But I don't want to use systemd, and it need go no farther than that. You need not know or understand my reasons - they may matter to me, but they don't have to do you. When someone comes out and says, "systemd has won" as was posted earlier in this thread, it's not far to imagine some glee in the idea that I too will be forced to run systemd soon.

Why do you care! Is your life that boring that you have to try to control my computer, too? Get a life!

(The next thing someone else on this thread will do, besides schooling me on how stupid, backward, and retarded I am, will be to tell me to "get a life" and just go ahead and use systemd, already.)

Guess what, most of the people who were working on nearly all the projects systemd absorbed are were working on systemd and decided it would be easier to target 1 platform. Don't get butthurt if those developers decide they want to merge into systemd and no one:
A) has the skill
or
B) simply dont care about

supporting X other awful init system. If you have a problem step up and fix it or pay for somone else to fix it. otherwise all your doing is acting like a 2 year old who doesnt like the new safer toy thats replacing his old dangerous toy.

[BSDude]

753bc to 395ad.

1453ad actually. The Byzantine Empire was Eastern Roman Empire proper.

[Krejzi]

Could the issue be related to Debian Jessie?

I don't think so. I can confirm the behavior on vanilla systemd-216 (and any earlier version).

For rootfs, it always says it's clean (as a matter of fact, rootfs contains everything but /home).

However, it does check /home partition and finds/fixes some errors/orphaned inodes.

Then again, I don't think that there was anything being written to at the time of shutdown that was on the rootfs. All runtime data (in /run, /tmp) are on tmpfs which leaves journal logs that could've been written to. IIRC, journald only writes something when there's a need for it (not sure, but I know it's not keeping the log file always open) so it could be possible that nothing on rootfs suffered any damage, that's why it didn't check anything.

Still, systemd-fsck runs the real fsck tools, so you can't blame systemd for fsck.ext4 saying the ext4 fs is clean. Instead you can blame the e2fsprogs crew, because their tool is being used :-)

[BlackStar]

I don't think so. I can confirm the behavior on vanilla systemd-216 (and any earlier version).

For rootfs, it always says it's clean (as a matter of fact, rootfs contains everything but /home).

However, it does check /home partition and finds/fixes some errors/orphaned inodes.

Then again, I don't think that there was anything being written to at the time of shutdown that was on the rootfs. All runtime data (in /run, /tmp) are on tmpfs which leaves journal logs that could've been written to. IIRC, journald only writes something when there's a need for it (not sure, but I know it's not keeping the log file always open) so it could be possible that nothing on rootfs suffered any damage, that's why it didn't check anything.

Still, systemd-fsck runs the real fsck tools, so you can't blame systemd for fsck.ext4 saying the ext4 fs is clean. Instead you can blame the e2fsprogs crew, because their tool is being used :-)

This is *certainly* a problem with Debian Jessie, because I don't encounter this on my Arch installation (neither bare metal nor virtual machine, just tested.) Fsck runs correctly and repairs the filesystem on next boot.

[Krejzi]

This is *certainly* a problem with Debian Jessie, because I don't encounter this on my Arch installation (neither bare metal nor virtual machine, just tested.) Fsck runs correctly and repairs the filesystem on next boot.

Well, I said vanilla systemd-216, so I wasn't using either Archlinux or Debian. I didn't say it was never properly checked, it's just that I've never noticed any other fsck messages than "Clean". I still could be guessing right that nothing was damaged because rootfs was rarely written to.

Now that I'm on Arch again, I've noticed something. rootfs is being checked in initramfs stage (maybe before it's even mounted), so that's why it's being able to properly check it. The non-initramfs systems and systems that preform the check after rootfs has been mounted are less likely to get that done because it could be possible that errors can't be detected or fixed properly while rootfs is mounted (just guessing).

[Isedonde]

So, you like less files do you?

Actually, no. I like clean code without duplication. If you had used systemd for any serious work, you'd know that if anything, a systemd service requires more files than sysvinit. Like: one service unit and one socket unit. Or one service unit and one timer unit. Heck, you even need one file for every partition instead of having them all in fstab. The number of bytes in a code base are more important than the number of files. Systemd could probably cut down their file count by a lot, but then you'd have a big mess with very big files.

You do realize that systemd needs more than 10 times as many files as init does don't you? As in init takes about 75 and systemd needs over 900!

I couldn't care less about how many source files the init system needs. I care about configuration of the init system. Configuration of sysvinit is a real PITA. It's not even configuration, it's scripting. And every single init script contains the same ~100-150 lines of code with just a few important lines, the rest is boilerplate. I can't wait for Ubuntu to drop the 6890 lines of crap in my current /etc/init.d directory.

Judging by your post, you've never actually used sysvinit or systemd for anything that is not starting or stopping a service. I understand that doesn't really show why systemd is so much better. Unless one of the daemons misbehaved and then sysvinit lost track of it so you couldn't even stop the daemon using sysvinit. killall `pidof daemon` for the sysvinit win? Or simply trust systemd to be in control of daemons and to do what you tell it to do.

Anyway, if you ever developed some software that needs to run as a daemon, or even packaged software that someone else coded, then you'd know how init scripts suck. And if you did the same using systemd, then you'd know how easy it is to write a systemd unit file. Specify which binary to run, under which user/group, for which target, and you're basically done. Of course, there are a lot more useful options just one declarative config setting away. As opposed to sysvinit, where you need helper scripts, helper tools, helper pidfiles and helper everything because sysvinit can't do anything. Have you added the number of code lines e.g. in the "start-stop-daemon" tool to your 75 file count? Hint, that tool alone is close to 2000 lines of code. A SINGLE POINT OF FAILURE! HIDDEN IN SOME DEBIAN SOURCE FOR DPKG! And have you considered the number of source lines in daemons required just to maintain a PID file? And the number of bugs in PID file management in daemons?

Oh but you'll be saving on a few duplicates so you'll be way out ahead.

I also save a few hours for writing and debugging init scripts. And reading my syslog by date. And checking daemon status. And making sure minidlna restarts automatically when it crashes (that would require adding ugly infinite loops to its init script, but only 2 settings in the systemd service file). And so on.

fscking moron.

Yeah, it's really moronic to use a tool that saves my time. Any sane sysadmin, developer and distro packager loves to spend time hacking on init scripts, after all!