Redpill me on systemd

Redpill me on systemd

Attached: serveimage (1).png (421x888, 52K)

Other urls found in this thread:

wiki.gentoo.org/wiki/Comparison_of_init_systems
iwf1.com/systemd-vs-openrc-which-init-system-is-the-best-for-you-comparison
without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_Stretch_installation
wiki.linuxquestions.org/wiki/Prevent_systemd_installation#For_Debian_based_systems
twitter.com/SFWRedditImages

Its garbage.

It's a big bundle of shit that you don't need on your home PCs. Not only is it incredibly buggy, it's also too big to audit (1m+ lines of code) with all sorts of insane defaults. You should replace it your systemd distro with Void, Alpine, Tiny Core, OpenBSD, NetBSD, Haiku OS, or the easiest systemd-free distro, Devuan.

Attached: fuck you pottering.png (1280x2084, 619K)

it won't go away so better get used to it

How do you "redpill" someone? The fuc k does that even mean?

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.
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.
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).

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.
The whole startup process was serialized. Also very slow. Systemd can parallelize it and does so quite well.
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.
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.
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.
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.
I could go on for hours, but this should be a good summary.

To teach them the truth about something. It's a matrix reference, idiot. How new are you?

it is alright. a bit bloated but alright.
people hate it because of this or that small issue but really it is a good step forward for loonix distros to have adopted it.

see for why

It means lurk more

Not OP, but I've seen all kinds of systemD hate threads since forever and finally someone did a good job explaining what it is, what it does, why it exists and why it has to be a bit bloated. And all of that in relatively simple words.
Doing god's work user, thank you.

>this or that small issue
id hardly call leaving mountains of poorly written code riddled with bugs and then saying "Dont like it? Dont use it!" so developers are now forced to use these bugs-as-a-feature if they want any chance of being used in distros that adopted poettershit.
And no, you can't just avoid it anymore. Want pulseaudio? Better get systemd. Want to use audio in the majority of good applications now? You need pulseaudio, they stripped out alsa support! Want to contribute to fix these things? Good fucking luck sifting through 1m lines of buggy, prototype-as-production modeling! And even if you do, poetterfuck is so sensitive about these things he'll probably reject your merge request.

Everything he described is not an issue with sysv or openRC. Hes describing the shortcomings of the Arch distro init system which was in fact fucking insane, and is why they switched to systemd as one of the first.
It in no way explains the shortcomings of systemd (bugs as features, all or nothing design, massive runtime bloat, forced developer design) or why its not necessary in the first place.
The head dev of systemd was banned from making contributions to the linux kernel for a very fucking good reason.

...

>pulseaudio still comes with flat volumes on by default

Attached: 1515985915783.png (882x758, 239K)

newfag

>someone just put a giant dildo into my rectum
>better get used to it lol

Not gonna argue on systemd or other init systems, as my knowledge on the topic is very limited.
He made some valid points. Isn't the linux kernel itself kind of bloated and horrible code quality in comparison to what it started as? There's not a single large project that contains of high quality and bug free code. Some are better maintained/leaded than the others, that's it.

Lennart was banned from committing to Linux?
I know Kay did something dumb once and Linus wished he was retroactively aborted, but AFAIK he can still contribute to the kernel

It's pretty shit.
It tries to do everything instead doing one thing and doing it well. (lmao grandpa, unix philosophy is deprecated lmao)
binary logs
dependency cancer propagated into a lot of other software. Most famous example is GNOME: you have to install systemd to use GNOME.
"not a bug"
rm -rf /foo/.* nukes your root. "It's a UNIX pitfall anyway bro!". Wrong.
Bricks motherboads.


Just checkin the GETS

Again, his points were exclusively on the (again, fucked up) Arch init system. It's also a copy+paste from the maintainers on why they moved to systemd.

Linux itself has bugs here and there but overall it's probably one of the cleanest, large scale FOSS projects if not *the* best. If you're not doing insane shit, then the init systems work without any issue. The main issue is that there was never any kind of standardized init system in place, it was just a bunch of scripts from ye olden days when that was acceptable.
Sysv and OpenRC both fix this issue without being blobby, cancerous piles of shit.
SystemD has a great premise: Be a middleware service manager for everything and now developers don't have to fuck around with it. Great idea. I'm not dispusting that. But it has a God fucking awful execution.

Poettering is a toxic developer, he and his entire team and notorious for being aware of bugs and just not fixing them because they realize the amount of work that it would take to actually fix them, and their responses are always flakey, deflective bullshit like "Well that's not our problem" even though it is *literally* their bug, in their codebase, exclusive to them and caused directly by them. Systemd would have none of the hate it does if it didn't chokeslam you against a wall yelling YOU HAVE TO USE ME AND I DON'T CARE WHAT THE FLAWS ARE, IT'S YOUR PROBLEM NOW!

You're right, it was Kay. Afaik he was blacklisted from commits for a while, I don't know if he ever shaped up his shit or just kept contributing broken garbage to poettering projects.

systemd is shit
refurbished thinkpad is best
install gentoo

> am i Jow Forumsay now?

Are there any downsides to using other init systems? I mean, isn't systemd required for some programs to run?

You might have to fiddle with configs a little more than you would otherwise, but that's the same downside to using non-stable packages in Debian or Ubuntu. Sometimes shit will break.
Honestly the only thing I can think of that's major and REQUIRES systemd is GNOME, which you shouldn't be using for effectively the same reasons (Toxic, buggy, fuck-you-its-your-problem mentality).

Basically no, not really, as long as you're willing to configure your machine (which I assume you are, since you're already using linux).
OpenRC is basically a more comfy Sysvinit, but either work fine, or even just generic init systems like the one Slackware uses. This was never an issue that systemd logistically needed to solve, it was always one of convenience, and they've fucked it up every step of the way.

When is systemd going to replace the linux kernel? Can't be more than a few years from now

Also you might find it actually works better, depending on your setup. I was having a fucking bitch of a time getting Bumblebee working correctly on my laptop until I switched to OpenRC. Turns out SystemD was enabling my powertop service before bumblebeed got a chance to grab hold of my discrete card, so powertop turned it off for power saving and bumblebeed could never take control and turn it back on.
Switched to OpenRC and it worked the first time I configured it because there wasn't that fat layer of abstraction I couldn't see and I knew how I wanted things.

Can someone do a comparison on systemd vs. runit. Especially since I hear runit is bretty good

wiki.gentoo.org/wiki/Comparison_of_init_systems
There's...just a lot of shit going on with these things, doing an in-depth comparison would take awhile.
Here's the main takeaway:
OpenRC/Runit/Sysvinit all have lots of *optionals*. You don't HAVE to use them for certain things if you don't want to, and you don't HAVE to use any of their preconfigured default services if you don't want to.
Systemd requires you to use systemd services, for systemd daemons, for systemd configurations, for systemd systemd systemd. Systemd is like a nasty bacteria. Systemd isn't just an init system, it wants to be in charge of your whole system, and this is where it's (gigantic) problems start to really become a major issue.

Try Runit, though I would vouch for OpenRC over it personally.

This article is relatively unbiased, to be fair
iwf1.com/systemd-vs-openrc-which-init-system-is-the-best-for-you-comparison

Systemd's issue is it wants to be more than just init, and as a result it's incompatible with the unix philosophy. Given how monolithic its scope is, it just reeks of bad design, forced usage, and polluting the ecosystem. It's developers are toxic and uncaring, and it has a lot of questionable designs.
These questionable design ultimately spill over onto the burden of developers, who now have to make the choice between semi-sane service management but having to deal with bugs-as-a-feature retardation, or getting lots of PEBKAC issue reports because somebody doesn't understand what an init script is.

Attached: 2018-04-15-202635_672x947_scrot.png (672x947, 107K)

Adding a bit more depth to my question
>(which I assume you are, since you're already using linux)
no, I'm actually not. Been tinkering a bit with a whole lot distros in the past, either for fun or because I needed to get some things to work.

This being said, windows is a sinking ship and it's been like this for a long time. I've been using it for the past 10+ years as my main OS and there's a really really comfy setup I have, made of both chances to the OS itself and cherrypicked (after going trough a large pile of shit) programs with non-default settings I use for productivity, both at home and at work.
I am aware that a setup that's just as good if not better is most certainly possible to achieve on linux, but it's probably going to take a long time before I'll feel at home.

So yeah, at this point in time I'm looking for a distro that will carry me trough the years to come. Having it use systemd or some other init system is yet another decision to make.
Distrohopping would be an option, but I've kinda become an old hag and I hate non necessary / counterproductive changes.

>make garbage software like consolekit and polkit
>software now depends on your garbage
>suddenly drop support for your old garbage and make it a component of your biggest garbage (systemd)
>everyone is fucked

Just make the jump. I was a lifelong Windows user until W10 came out and I kept bumping into obnoxious issues that were basically a "Fuck you, we're not letting you change that anymore" problem.
Slapped debian onto my desktop and started playing with it until I got comfy. Aptitude and apt-get make for really easy program installation and the walls and walls of Ubuntu help forums make it easy to troubleshoot anything you run into.
Once you're comfy enough faffing about with config files and the command line (I'd recommend customizing your bashrc as a starting point if you've never done so before), then I'd recommend re-installing Debian from a net install ISO and not installing any desktop environment.
Then
without-systemd.org/wiki/index.php/How_to_remove_systemd_from_a_Debian_Stretch_installation
wiki.linuxquestions.org/wiki/Prevent_systemd_installation#For_Debian_based_systems
Followed by apt-get xorg and your WM/DE of choice and wa-la. You now have a comfy, ready-to-customize install.

it just works, and that's why its garbage.

Leaking piece of shit, that makes working with a system easier for some people, but not me, since I'm used to init.d scripts and new version kinda shits them up.

Back to 9gag fag

>You wanted control over your init system?
>It'd be a shame if somebody
>PREVENTED THAT ENTIRELY

The "jump" itself is a problem, I've already sold my soul to the devil (.NET dev in 2nd (if not 3rd) world country, currently working from home). Maybe I'll get myself a month or so completely free of the job, grab some new pc parts, set up a GPU passtrough and some other shit that could be useful.
Sigh, I've been promising myself to do this for like 2 years now.

Anyways, I'm off to sleep now. Thanks guys for the talk, I hope this thread will still be alive when I wake up. It's less of a shitpost than usually.

yes

but if you add a "the" before "shit" I'm with you!
;)

It's a larger codebase than the full Linux kernel, it is garbage and you should feel bad if you're using it because your support of distros which contain it indirectly affects the security of the entire world.

If you don't need serious 3D rendering you can just throw Windows 8.1 onto a VM for .NET development. WINE and Passthrough are pretty mature now, I've been able to run pretty much everything without much issue.
Regardless. Give it consideration, maybe try running your linux install off a persistent liveUSB for awhile to see if you like it.

To be fair, why in the everloving fuck you'd want to run rm -rf over the root directory?

The issue is less "why would you rm / " and more "Why the fuck does rm / let me brick the physical machine"

user freedum

Attached: 1509848853561.jpg (600x400, 32K)

you don't need to know that, it's some Jow Forums shit.

Proud user of windows since 2001

>forgetting Gentoo/funtoo GNU + Linux (or their fsf endorsed fully libre analogs)
I’m really disappointed that you would list alpine or Devuan before the most powerful and efficient distribution of a foss OS to grace the world of computing.

Attached: C2BAD0AC-8BDB-43D4-B7AE-15BC0C2606B8.png (568x548, 88K)

No problem with it here, given pretty much everything higher level than basic drivers in modern consumer OSs' relies on a variant of the microkernel approach anyway.

The systemd init is probably either on par with or slightly better than runit at this point. The problem with systemd's init is bad, it's that I now have to say "systemd init" instead of "systemd" because the project has metastasized into a cancerous mass of interdependent code that does everything from bootloading to login management.

runit does everything better

Incompetent OEM, in this particular case, though I do agree Poettering is a massive dick for refusing to do anything about it. Linus would have worked around the issue, *then* bitched about it. God help us all once he dies.