Why is systemd so hated on Jow Forums?

Why is systemd so hated on Jow Forums?

Attached: 1555345245516.png (432x432, 200K)

Other urls found in this thread:

anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=28640752854
bugzilla.redhat.com/show_bug.cgi?id=1170765
bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720
mirrors.dotsrc.org/cdn.media.ccc.de//events/all_systems_go/2018/webm-hd/asg2018-192-eng-State_of_systemd_Facebook_webm-hd.webm
github.com/systemd/systemd
twitter.com/AnonBabble

find out yourself

systemd = bloat

Because it is maintained by an asshole who closes legitimate bug reports with wontfix or notabug

because it is a technical placebo solving non-existing "problems" - 1,2M LOC fucking bloatware imposed on us by a total failure called Novell/Suse

basically, it is an insult to human intelligence

deceptive middle-man business scam at its best

Are there better init systems? Yes runit
Is systemd bad? No
Some people want their libreoffice others just want to use small utilities. Pick your poison.

Anyone who complains about bloat in 2019 are just retards still clinging to 20 year old PCs

boomer delusion

this is the only valid complaint I've heard about systemd. Poettering is an asshole, and he should not be in charge of the project.
I spent about a year on Devuan but lately I've been making the move back to Debian. I'm all for software minimalism but other inits are slow as fuck, and I'm tired of having to fiddle with scripts just to make shit work right.

It spits in the face of the Unix philosophy
It probably has a CIA backdoor (as CIA supposedly had trouble getting a backdoor into the Linux kernel)

>bloat is only about performance.
NO complexity leads to more and larger bugs.

muh unix philosophy but unironically

binary logs are an unnecessary complication

It's not built modular enough and depends on their own toolset like pulseaudio logind ect.

It tried to cover too much userspace like process management and containers, and login managers and even the TTY.

One of the main critiques was that it was going to expand with feature creep.
The detractors said "it's just a init system" calm down.

Well they were wrong.
You can do some stop gaps utilizing apulse+logind+sysvinit-core+openrc+getty but it's hacky and not supported.

I guess you should move away from GNU Utilities then, since it’s more bloated and complex than openbsd’s or any others
Oh but wait GNUs are much faster than any others
It’s almost like simple isn’t better

Sorry I mean elogind to replace logind

systemd suffers from scope creep.
systemd is an init system
systemd provides an UEFI boot loader, systemd-boot (previously gummiboot)[1]
systemd provides a login manager, systemd-logind
systemd provides a syslog daemon, systemd-journald, see Introducing the Journal
uses a binary format
systemd provides a mount front-end, systemd-mount[2]
The udev sources were merged into the systemd source tree.[3]
systemd provides systemd.timer timer units, which can be used to replace cron and at
systemd provides a D-Bus client library, sd-bus (see sd-bus)
systemd developed an in-kernel D-Bus implementation, kdbus.[4] They tried to get it merged into the kernel, failed, and are now trying again with BUS1.[5]
systemd provides automount via systemd.automount to substitute autofs
systemd provides a caching DNS resolver, systemd-resolved
systemd provides a network manager and DHCP client, systemd-networkd
systemd provides a HTTP server for journal events, systemd-journal-gatewayd (can be disabled with remote compile option)
systemd provides a containerization system systemd-nspawn (see lwn - Systemd vs. Docker)

having 1000 different tools with poorly defined interfaces, then leaving users with the task of making sure they remain stitched together properly is just as bad. That's what we used to have. At least systemd doesn't decide to shit the bed randomly every time I do a dist-upgrade (looking at you, sysvinit).

systemd has a legitimate reason for having a ton of tools- it's a message passing system in pid 1, so it's gonna need to be able to pass messages for, well, everything. However, the systemd developers failed to design and document a solid interface for each component before implementing it.
systemd works better than other inits because all of the utilities are tightly integrated. systemd still isn't a great solution, though, since it lacks well-defined interfaces between components that would allow parts to be swapped out as needed.

fsck cannot be cancelled (used to be possible via C-c or c on the console). 7f110ff9b8, Fedora#719952
systemd defaults to Google's DNS nameservers. e16cb2e4ef, Debian#761658
systemd defaults to Google's NTP servers, which serve leap-smeared time. GitHub#437
systemd by default uses Predictable Network Interface Names, which are actually less predictable when you only have one interface per type.
systemd by default kills background processes after the user logs out. 97e5530cf2, Debian#825394
"In my view it was actually quite strange of UNIX that it by default let arbitrary user code stay around unrestricted after logout." -Poettering[6]
As systemd depends on many files on a rootfs, in case of any problems with rootfs, it is not able to control processes and (cleanly) shutdown/reboot when Crtl-Alt-Del is pressed.[7]
systemd-resolved breaks the traditional glibc behavior by skipping a DNS server in all following queries, if it does not respond once. GitHub#5755, [8]

systemd has a filename that starts with a hyphen! - This causes all sorts problems as it will usually be interpreted as the start of a command option when used on the command line. You don't even need to specify the filename for it to cause problems as it will affect commands that use globbing. Not to mention that the file in question, "-.slice", they refer to as the "root slice" which causes confusion as the term "slice" has been used for decades as an alternative way of referring to a disk partition yet their usage is completely unrelated.
systemd mounted efivarfs read-write, allowing motherboard bricking via 'rm' See also No POST after rm -rf / - Lennart's argument for mounting /sys/firmware/efi/efivars as read/write as a default behaviour doesn't hold water. Yes it's true that some tools may need to write to it but those tools are not needed for the general running of a system. efivars should not even be mounted as read-only by default. Those tools that need to write to efivars will generally only be invoked by a system administrator. A competent sysadmin will know how to mount efivars with read/write permissions when they need to to use those tools. The only reason to mount efivars by default is for convenience. This is by no means a good reason. From a security perspective, mounting efivars by default should be strongly discouraged as it breaks the principle of least privilege. Lennart goes on to state that systemd needs to write EFI variables. This demonstrates yet another example of scope creep and thus poor design.
anonscm.debian.org/cgit/pkg-systemd/systemd.git/commit/?id=28640752854
bugzilla.redhat.com/show_bug.cgi?id=1170765
bugs.debian.org/cgi-bin/bugreport.cgi?bug=784720
systemd units are started with zero context. This eliminates most of the functionality of inotify and makes systemd.path unusable for virtually any purpose.

>systemd provides a syslog daemon, systemd-journald, see Introducing the Journal
uses a binary format

THIS FUCKING SHIT!!!
Why not plaintext?
RAAAAAAAAAAAAAAAAAAa

Attached: 13632.png (739x914, 1.35M)

it bricked my desktop. systemd is like MCP in Tron. Trying to take ownership of everything in the system. feels a lot like Red Hat trying to steer things in a direction so that they can dominate and own linux as a whole.
>
distributions that implement this shit are bitches.

>uses a binary format
It uses whatever it's configured to use, with binary being an option. If systemd uses binary logs on your distro, it's because your distro maintainers configured it to do so and you should take it up with them. Debian for example still uses plaintext logs with systemd.

Filtering reliably, see journalctl -o verbose

because i dont know what it is

but there's no BSD/Linux user

>binary logs
this the dumbest design decision ever

because muh unix way trumps the convenience of uniformity
>bricked my desktop
no it didn't you're just retarded and you bricked it out of stupidity

>but other inits are slow as fuck
really makes me think

>t. facebook
mirrors.dotsrc.org/cdn.media.ccc.de//events/all_systems_go/2018/webm-hd/asg2018-192-eng-State_of_systemd_Facebook_webm-hd.webm

not watching some thirty minute video, if you've got a point make it yourself

they backport systemd and want to keep it at all costs because they can "restart services without any downtime"

>feels a lot like Red Hat trying to steer things in a direction so that they can dominate and own linux as a whole
This is entirely what it is. Same with Gnome.

Developer keeps breaking userland stuff and blaming everyone else even though it was his software that broke everything.
One time he had the hall to suggest user login persistence on a SERVER OS isn't needed when systemd started killing screen and tmux upon ssh disconnect.

I'm willing to bet systemd gets attacked because i don't see a CoC here.
github.com/systemd/systemd
Otherwise systemd is just fucking fine, and you're holding it wrong.

>systemd is just fucking fine
It's way too big and insecure to be useful.

I don't believe you. I make use of systemd to great effect all the time.

It is literally Red Hat's embrace, extend and extinguish strategy for all of the other Linux distributions. Every distro that adopts it is now fully dependent on a group of asshats from Red Hat to fix issues in an every growing section of low level utilities.

Jow Forums hates systemd because they've never written a service file or an init script

Good on Red Hat
Saving Linux from itself

a complex, monolithic blob, that everything else has hard dependencies on, complicating the task of replacing or just patching it when it inevitably fucks up

Scope minimalists aren't enthused about being creeped on