What's behind the Jow Forums's hatred of systemd?

Does this convince you enough?

Attached: 1532021727695.jpg (1432x1700, 785K)

Or perhaps this?

Attached: 1532021790367.png (1280x2084, 619K)

Also, unironically, because muh unix philosophy

Attached: 8d2.gif (480x320, 3.49M)

honestly, I'm not really convinced by that website

>Bugs
that's quite common with any software, systemd is nowhere more bugged than what's normal.
Most bug discovered were quite low-priority (such as the local-access DoD that got everyone crazy some time ago). Especially in contrast with stuff like heartbleed, spectre, intel ME, any various browser bugs.

>Bloat
It's more like a shitton of different tools, most optional (how many people use bootd, reolved or networkd?), that just fall under the same "logo".
There is a lot of code sharing between them (so while optional, they can't be used stand-alone) but I don't see how that's a problem.
Some people talk about it like DNS resolving was happening in PID1 but that's just ridiculous.

>moron deletes efivars
>FUCK YOU POETTERING

>without-systemd.org/wiki/index.php/Arguments_against_systemd
Did those guys ever took a few minutes to disprove this?
0pointer.de/blog/projects/the-biggest-myths.html

For everyboda that speaks German:
cre.fm/cre209-das-linux-system

AS far as i can remember, he sounded quite reasonable overall.

>that's quite common with any software, systemd is nowhere more bugged than what's normal.
>Most bug discovered were quite low-priority (such as the local-access DoD that got everyone crazy some time ago). Especially in contrast with stuff like heartbleed, spectre, intel ME, any various browser bugs.

>but I don't see how that's a problem

Systemd flies in the face of the Unix philosophy: 'do one thing and do it well,' representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system, as it goes on to handle power management, device management, mount points, cron, disk encryption, socket API/inetd, syslog, network configuration, login/session management, readahead, GPT partition discovery, container registration, hostname/locale/time management, and other things. Keep it simple, stupid. Because systemd puts so many of a program's eggs in one system basket. There will now be tons of scenarios in which it can crash and bring down the whole system. But in addition, this means that plenty of non-kernel system upgrades will now require a reboot. Enjoy your new Windows 9 Linux system! Oh, and good luck with those binary log files.

sure it is quite ironic for the author of that pic to call anyone a crybaby.
(and just to make it clear I don't particularly like poettering as well)

github.com/tmux/tmux/issues/428

'nuff said

that's easy:
swallows unrelated projects - gummiboot, udev, etc.
dynamic boot order - if two units interact in a bad way, you can get random boot failures that are impossible to debug (this actually happened to me)
descriptive config - very inflexible compared to shell scripts and has a million different keywords to make up for it
binary logs - in my experience these get corrupted at every opportunity, making them useless
takes over cgroups - sometimes with unexpected results making you wonder what the fuck is happening
systemd has a few nice parts, but ultimately it makes my life harder while providing minimal benefits
I'd rather use openrc or runit, or even fucking sysv rc

>Systemd flies in the face of the Unix philosophy
somewhat true

>representing a complex collection of dozens of tightly coupled binaries1. Its responsibilities grossly exceed that of an init system
As I said, they are not part of the init system, that are part of the same project but completely optional and isolated.

>There will now be tons of scenarios in which it can crash and bring down the whole system.
such as? I know about a single bug that got somewhat to that point (but not really) and it was fixed quite fast.

>But in addition, this means that plenty of non-kernel system upgrades will now require a reboot.
Already fixed

>Oh, and good luck with those binary log files.
irrelevant, from 0pointer.de/blog/projects/the-biggest-myths.html:
>we carefully made sure when we introduced the journal that all data is also passed on to any syslog daemon running. In fact, if something changed, then only that syslog gets more complete data now than it got before, since we now cover early boot stuff as well as STDOUT/STDERR of any system service.

>dynamic boot order - if two units interact in a bad way, you can get random boot failures that are impossible to debug (this actually happened to me)
Less likely to happen with systemd than old inits.

>binary logs - in my experience these get corrupted at every opportunity, making them useless
So use text logs instead!

>but completely optional and isolated.
No, they are *definitely* not isolated BECAUSE they are tightly coupled.

>such as? I know about a single bug that got somewhat to that point (but not really) and it was fixed quite fast.
Have you read the thread? How about this Or, fuck it, a simple duckduckgo: github.com/systemd/systemd/issues/5644 Or, even this: serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime

>But in addition, this means that plenty of non-kernel system upgrades will now require a reboot.
>Already fixed
It would inevitably happen anyway because of muh unix philosophy. And it will continue to happen and grow into a monolithic, unmaintainable monstrosity. It's already breached a million lines of code and it's only growing. That shit is bloated. I don't want it anywhere near my company or even my personal computer.

>Oh, and good luck with those binary log files.
>irrelevant, from 0pointer.de/blog/projects/the-biggest-myths.html

Gut the fuck out of here with your bullshit.
reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/
docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs

It's a mix of herd mentality and using words you don't understand in order to look tech savvy.
There are things to dislike about systemd, but the hate is just stupid. Especially hating the developers (it's free software Jesus Christ).

Several NSA backdoors:
github.com/systemd/systemd/issues/5755
github.com/systemd/systemd/issues/6076
github.com/systemd/systemd/issues/6237

It removes my choice to not use it. Go ahead and count the distro's that don't have it. It's one of the reasons I use Slackware, and even they might be forced to adopt it in the future with more and more pieces of software requiring it as a dependency.

Did those guys ever took a few minutes to disprove this?
judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html

FUD

Mods Mods Mods

>0pointer.de/blog/projects/the-biggest-myths.html
see:

If you want services.msc so much, you should stick with Windows.

It is obscure, opaque, overly complex, error-prone, and wants to do everything. It's almost like running Windows.

Doesn't load for me. Does this site contain malware? It's all blank white.

SHUT IT DOWN

>No, they are *definitely* not isolated BECAUSE they are tightly coupled.
I mean modular, it's not a monolithic piece of software, if netword fucks up, nothing happen apart losing your connection.

>How about this
guy run rm -r where he shouldn't have, anyway IRC the brick was more related to a shitty EFI implementation in the mobo (may be wrong here).
>serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime
where is the bug report? might be a misconfigured system.
bugs happen in any software a some random report doesn't really prove anything.
I can find countless of kernel oops report, and I saw a stable kernel panicking myself, I won't call linux shit for that.
You have to point a precise design issues to call a project shit, not quote random bug reports (I'm sure that linux has more CVE that systemd for example).

>Gut the fuck out of here with your bullshit.
>reddit.com/r/linux/comments/1y6q0l/systemds_binary_logs_and_corruption/
>docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBAGRL6wl97tFxgjLUEHIX3MSTs
I don't get it, what's the bullshit? the fact that you can ditch the binary logs?

javascript BS, here:
pastebin.com/SU1WWgYs

Skip this entire thread and find out the valid criticism here:

>without-systemd.org/wiki/index.php/Arguments_against_systemd

Attached: Fuck_the_D.png (153x156, 14K)

>I mean modular, it's not a monolithic piece of software, if netword fucks up, nothing happen apart losing your connection.

No, it is modular, but it is also definitely monolithic. See point 1 in judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html And I quote:
> You cannot run journald without systemd, and cannot run systemd without journald (at least, not without losing logging for systemd-supervised programs). None of the *ctl programs work without systemd, nor do its collection of systemd-*d daemons
>By contrast, examples of modular, non-monolithic software include GNU coreutils, the s6 supervisor system, DJB's daemontools, and the GNU compiler collection. Not only are these applications broken into modules, but you can use the modules largely independently of one another in different contexts, composing them together to accomplish more complex tasks than the individual modules themselves can handle.

>bugs happen in any software a some random report doesn't really prove anything
That may be true, but it certainly is not a good indicator. Are you calling him a liar?

>You have to point a precise design issues to call a project shit
That's exactly what we are doing here. Fuck, look at the thread. The #1 thing most folk who hate systemd have an issue with is that it doesn't abide by UNIX practices. It's constantly being shoved down everyone's throat and tries to engulf everything, like all monolithically designed software does. Just look at this: news.ycombinator.com/item?id=11797075

>I don't get it, what's the bullshit? the fact that you can ditch the binary logs?
No, the fact that you *have* to. Systemd is piggy-backing off of unix, but it is definitely not unix-y. That's the only real reason it's thriving. But make no mistake. It is shit. And if the fact that it can brick your motherboard should be a huge red flag to you. But hey, go ahead and keep using it if you're so included. Just don't shove it down *my* throat.

Half of these are bugs that have been fixed in the meantime and the other half is criticism aimed at the author, not at systemd itself.

>half
even if I were to concede that (I DON'T) you would still be left with a list of 50 articles explaining why systemd sucks. lmao, brainlet

Attached: wrong.gif (220x199, 99K)

Here's the reason why much of the folk have an issue with systemd.

Red Hat developers decided to break the semantics of nohup/daemon(3), which are long established mechanisms for achieving the ability to run beyond user logout.

They then decided that, rather than encapsulate fixes for their breaking change in portable APIs like daemon(3) and PAM to allow user space to keep working as intended, it'd be easier to just outsource the labour onto the community by demanding every user space program that was working just fine do the work of adding a couple of hundred lines of systemd specific code directly, encapsulation be damned.

That's an insult to the tmux developers in particular, and disdainful of Open Source devs in general. Don't show up at my door telling me to do a bunch of work for you to fix your shit. You broke the contract; encapsulate the fix so I don't have to care.

Man db service is the man database service.
Man as in the command.
Also it runs once in a while only to update. It's not some shit that runs every startup. Also get a ssd and that time is decreased to seconds.

The d stands for dick cause lennart is a fucking faggots that insists on shafting people with his CIA penis and that's why Jow Forums hates systemd.

>No, it is modular, but it is also definitely monolithic. See point 1 in judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html
well, I said that most of systemd utilities won't work with systemd in my first post. I'm just trying to debunk the idea that systemd is an init system that also do [etc..]. it's not, all the other stuff is optional and doesn't play a role in PID1.

>That may be true, but it certainly is not a good indicator. Are you calling him a liar?
No, I'm sure that's true. But without an explanation that bug could be anything from an accidental memory leak (shit is written in C after all) to the result of a major bad code practice.

>The #1 thing most folk who hate systemd have an issue with is that it doesn't abide by UNIX practices
I kind of see the problem with that, but then are KDE, Gnome, LXQT, etc.. all bad because they try to offer a full desktop suite rather than a window manager only? is linux bad for being a monolithic kernel rather than a microkernel?

>No, the fact that you *have* to. Systemd is piggy-backing off of unix, but it is definitely not unix-y. That's the only real reason it's thriving. But make no mistake. It is shit. And if the fact that it can brick your motherboard should be a huge red flag to you. But hey, go ahead and keep using it if you're so included. Just don't shove it down *my* throat
systemd dons't brick mobos, removing everything in efivarfs might.
Also I'm not forcing anyone to use systemd, at best distro maintainers and a few programmers are doing so.

This. So much for linux having a secure audited code. Anything could be running down there.

it's an easily exploitable system level piece of software and until it's hardened enough it will be a common target for everyone.

theregister.co.uk/2017/06/29/systemd_pwned_by_dns_query/

also unix beards like simple and elegant. systemd is a clusterfuck.

Enjoy your NSA backdoors

Attached: archbotnet.png (1200x500, 32K)

You can disable it. ManDB is used for caching and it allows searching man pages

That is really stupid. You can't throw out glibc nor xorg, because it is standard! Why the hell should someone make a distro for a few special neckbeards, that is harder to maintain then a systemd distro?

>wiping the disk deletes the EFI vars
>you defended this
Fuck right off. Wiping a hard disk shouldn't brick the machine.

>people have to fight to replace glibc
>people have spent ten years to replace X11
So hey let's replace something perfectly replaceable with a huge blob of software that *will not age well*

systemd-resolve isn't a mandatory systemd component though it is still kinda shit. Best to use it behind a local DNS resolver and cache like unbound or dnsmasq though.

Meant for

What should we do instead?

It's basically Mac launchd or Solaris SMF for loonix without all the XML faggotry.

It's also got stuff like actual dependency management instead of random sleep(30)'s, cgroups, resource management, service level security sandboxing, lightweight container support with nspawn, per interface DNS support with resolved, super basic stripped down NTP with timedated, space and search efficient binary logs (or just configure it to output to rsyslogd if you prefer text)

so it's got enough code to have tons of bugs

systemd hater have to resort to lying because they don't have an argument.

Making efivars writable is part of the UEFI spec. The cause of the motherboard brick is a Linux bug, even admitted by Linux developers, combined with bad motherboard firmware. So both the motherboard manufacturer and the Linux kernel is at fault, systemd is not even involved, and yet anti systemd shills have to make up a lie to discredit systemd, because there are basically no valid arguments against systemd.

And what else do you have to disable so that you don't get systemdicked over?