Can you explain what's wrong with systemd without shouting memes and acting like an alt-right weirdo?

Can you explain what's wrong with systemd without shouting memes and acting like an alt-right weirdo?

Other urls found in this thread:

catchlinux.com/what-is-systemd-for-noobs/
reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
lkml.org/lkml/2012/7/6/495
twitter.com/NSFWRedditVideo

Googled it just now, looks like something that everyone in the Linux world hates because everyone else in the Linux world hates, for no other reason than the bandwagon effect.

Sounds like you learned nothing on your three minute google trip

cause its the windows way of doing things
not the unix way

dats why systemd id hated on

feature creep

Meanwhile bunch of consumer router running busybox all over the world.
And nobody said it's a windows way of doing thing.

>alt-right weirdo
Yeah, okay, "Anonymous". Kike.

Way it was explained to be is that it tries to be way more than it should be and ends up not being as modular as people would like.

Systemd will integrate a de next.

>(((user)))

It's not that it's bad, it's that distro faggots are forcing it because a few DEs depend on it (logind) for multiuser features

1: Nobody fucking uses DEs, they break harder than piecemeal environments and are harder to beat into usability than piecemeal environments. DE = you're going to waste more time just to use more RAM. And more crashes.
2: A linux computer with multiple local desktop users? Surely, you're fucking joking.

For an average user, it's not worth learning a new massive, poorly documented init system when they already know old-style ones.

And then there's the udev thing that suddenly reminded all sorts of neckbeards that linux was already dead and bloated thanks to your friends at the X desktop group aka freedesktop.org aka notredhat.

it's the Red Hat/Poetteringware svchost.exe port for Linux

>UNIX application following the kiss principle breaks
>replace it and your system keeps running

>something in systemd breaks
>can't replace it easily because the architecture is completely different from any other init/daemon/service structure on unix
>not only is that one application broken, but possibly other systemd programs which relied on it
>if you're using GNOME, that's broken too, now

>muh UNIX way
>muh """bloat"""
Just autists feeling elite because they spent years learning how to do hacks around init scripts for no legitimate reason

catchlinux.com/what-is-systemd-for-noobs/
Go educate

Do this! Do this next!

> something in the kernel breaks

>It's not that it's bad, it's that distro faggots are forcing it because a few DEs depend on it (logind) for multiuser features
Wrong, a few DEs started to depend (optionally) on systemd since it was seeing mainstream use in distros.

>1: Nobody fucking uses DEs, they break harder than piecemeal environments and are harder to beat into usability than piecemeal environments. DE = you're going to waste more time just to use more RAM. And more crashes.
Wrong. I am using a DE as I can't be bothered to put together a piecemeal desktop that feels right to me (and it just so happens that the DE I use feels right out-of-the-box)

>2: A linux computer with multiple local desktop users? Surely, you're fucking joking.
- user, can you let me use your PC? I need to check the local bus schedule.
- Sure, let me just login as the guest user and you're free to use it however you like.

>For an average user, it's not worth learning a new massive, poorly documented init system when they already know old-style ones.
1. It's actually quite well documented. At least it's better documented than the atrocity Debian had back when I had to write an init file for a daemon we developed at work.
2. Why would an average user have to learn how the init/service system works of all things? That's what the distro maintainters are for. The most the user would have to do is start/stop/add/remove service. Which in this case means using the arcane command of systemctl start/stop/enable/disable service_name

>And then there's the udev thing that suddenly reminded all sorts of neckbeards that linux was already dead and bloated thanks to your friends at the X desktop group aka freedesktop.org aka notredhat.
Okay, I'll concede that merging udev into systemd is a male reproductive organ move. There's gentoo-maintained eudev but that's goentoo trying to save the situation, not systemd guys trying to work with others

>something in systemd breaks
>can't replace it easily because the architecture is completely different from any other init/daemon/service structure on unix
As opposed to what?
Are OpenRC config files usable on any other init system? Upstart config files? GoboLinuxs BootScripts? InitNG scripts? GNU Shepherds configs?

>user, can you let me use your PC?
- Where do you think we are?
and
- What normie in their right mind would ask to use a linux desktop

...

It goes against unix philosophy

I was the primary maintainer for Arch's init scripts for a while and I can share a couple of thoughts.

Arch's initscripts were incredibly stupid. In their first phase, there was a static set of steps that would be performed on every boot. There was almost no way to adjust the behaviour here. In their second phase, the configured daemons were started in order, which only meant that a init scripts were called one after another.

In the early 2000s, that seemed like a good idea and has worked for a while. But with more complex setups, the shortcomings of that system become apparent.

[1] With hardware becoming more dynamic and asynchronous initialization of drivers in the kernel, it was impossible to say when a certain piece of hardware would be available. For a long time, this was solved by first triggering uevents, then waiting for udev to "settle". This often took a very long time and still gave no guarantee that all required hardware was available. Working around this in shell code would be very complex, slow and error-prone: You'd have to retry all kinds of operations in a loop until they succeed. Solution: An system that can perform actions based on events - this is one of the major features of systemd.

[2] Initscripts had no dependency handling for daemons. In times where only a few services depended on dbus and nothing else, that was easy to handle. Nowadays, we have daemons with far more complex dependencies, which would make configuration in the old initscripts-style way hard for every user. Handling dependencies is a complex topic and you don't want to deal with it in shell code. Systemd has it built-in (and with socket-activation, a much better mechanism to deal with dependencies).

[3] Complex tasks in shell scripts require launching external helper program A LOT. This makes things very slow. Systemd handles most of those tasks with builtin fast C code, or via the right libraries. It won't call many external programs to perform its tasks.

>svchost.exe port for Linux
inetd are svchost equivalent.
inetd is the (old) unix way to run network service.

>What normie in their right mind would ask to use a linux desktop
They're not asking for a linux desktop. They're asking for a web browser. Those usually work the same regardless of the underlying OS, but I'm not letting them use a web browser where I have autologin on some webpages.
Sometimes they ask for Office, but usually LibreOffice is sufficient (I was mostly asked to print stuff and just told them to export the .docx to .pdf)

continued

[4] The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well.

[5] No indication of whether a certain daemon was already started. Each init script had to implement some sort of PID file handling or similar. Most init scripts didn't. Systemd has a 100% reliable solution for this based on Linux cgroups.

[6] Race conditions between daemons started via udev rules, dbus activation and manual configuration. It could happen that a daemon was started multiple times (maybe even simultaneously), which lead to unexpected results (this was a real problem with bluez). Systemd provides a single instance where all daemons are handled. Udev or dbus don't start daemons anymore, they tell systemd that they need a specific daemon and systemd takes care of it.

[7] Lack of confiurability. It was impossible to change the behaviour of initscripts in a way that would survive system updates. Systemd provides good mechanisms with machine-specific overrides, drop-ins and unit masking.

[8] Burden of maintenance: In addition to the aforementioned design problems, initscripts also had a large number of bugs. Fixing those bugs was always complicated and took time, which we often did not have. Delegating this task to a larger community (in this case, the systemd community) made things much easier for us.

I realize that many of these problems could be solved with some work, and some were already solved by other SysV-based init systems. There was no system that solved all of these problems and did so in a realiable manner, as systemd does.

So, for me personally, when systemd came along, it solved all the problems I ever had with system initialization. What most systemd critics consider "bloat", I consider necessary complexity to solve a complex problem generically. You can say what you want about Poettering, but he actually realized what the problems with system initialization were and provided a working solution.

reddit.com/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc

Busybox is a set of unix tools while Systemd is a tightly coupled init system, bootloader, binary file logger, login manager, network manager, device manager, etc.

Because
>Muh UNIX philosophy
Despite the fact systemd isn't really against the UNIX philosophy
Also because
lkml.org/lkml/2012/7/6/495
Kay Sievers can't fucking code. Lennart Poettering can code, but he's a fucking faggot.

So are busybox. What do you init in busybox do?
This is output from my Debian box.

Currently defined functions:
[, [[, acpid, adjtimex, ar, arp, arping, ash, awk, basename, blockdev, brctl, bunzip2, bzcat, bzip2, cal, cat, chgrp, chmod, chown, chroot, chvt, clear, cmp, cp, cpio, cttyhack, cut, date, dc, dd, deallocvt, depmod, devmem, df, diff, dirname, dmesg,
dnsdomainname, dos2unix, du, dumpkmap, dumpleases, echo, egrep, env, expand, expr, false, fgrep, find, fold, free, freeramdisk, fstrim, ftpget, ftpput, getopt, getty, grep, groups, gunzip, gzip, halt, head, hexdump, hostid, hostname, httpd, hwclock, id,
ifconfig, init, insmod, ionice, ip, ipcalc, kill, killall, klogd, last, less, ln, loadfont, loadkmap, logger, login, logname, logread, losetup, ls, lsmod, lzcat, lzma, lzop, lzopcat, md5sum, mdev, microcom, mkdir, mkfifo, mknod, mkswap, mktemp, modinfo,
modprobe, more, mount, mt, mv, nameif, nc, netstat, nslookup, od, openvt, patch, pidof, ping, ping6, pivot_root, poweroff, printf, ps, pwd, rdate, readlink, realpath, reboot, renice, reset, rev, rm, rmdir, rmmod, route, rpm, rpm2cpio, run-parts, sed, seq,
setkeycodes, setsid, sh, sha1sum, sha256sum, sha512sum, sleep, sort, start-stop-daemon, stat, strings, stty, swapoff, swapon, switch_root, sync, sysctl, syslogd, tac, tail, tar, taskset, tee, telnet, test, tftp, time, timeout, top, touch, tr, traceroute,
traceroute6, true, tty, udhcpc, udhcpd, umount, uname, uncompress, unexpand, uniq, unix2dos, unlzma, unlzop, unxz, unzip, uptime, usleep, uudecode, uuencode, vconfig, vi, watch, watchdog, wc, wget, which, who, whoami, xargs, xz, xzcat, yes, zcat

>Nobody fucking uses DEs
grVIII bVIII mVIII

busbox equivalent
>init system
init
>logger
syslogd (it store in ram), read it with logread
>network manager
ifconfig
>device manager
mdev

age