Redpill me on systemd

redpill me on systemd

Attached: serveimage.gif (1968x639, 40K)

Other urls found in this thread:

serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime
phoronix.com/scan.php?page=news_item&px=systemd-2017-Git-Activity
suckless.org/sucks/systemd
web.archive.org/web/20170724100245/https://muchweb.me/systemd-nsa-attempt/
without-systemd.org/wiki/index.php/Arguments_against_systemd
twitter.com/mjg59/status/693494314941288448
without-systemd.org/wiki/index.php/Arguments_against_systemd
without-systemd.org/wiki/index.php/List_of_articles_critical_of_systemd
troubleshooters.com/linux/diy/suckless_init_on_plop.htm
twitter.com/SFWRedditVideos

Okay OS, but lacks a good init system

redpill me on redpilling redpilly pill


red


>can't meta-motor
>2019

my distro doesn't use it.

There's a LOT of reasons why people don't like it, and I think the people who don't like it all likely have their own reasons for not liking it.

Here's a posting about someone discovering a massive memory leak that used up 4GB of ram. While I have yet to see something this massive, I have definitely noticed Systemd using more memory than the alternatives, and some leakage here and there as well.
serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime

Some see it as an unnecessary security risk due to its massive attack surface. It recently hit 1 million lines of code.
phoronix.com/scan.php?page=news_item&px=systemd-2017-Git-Activity

Some don't like it because they dislike its habit of scope creep. The project ends up assimilating things that historically should not have anything to do with init. gif related.
suckless.org/sucks/systemd

There's also some other design decisions that people have an issue with, such as using Google DNS by default (because of course systemd can handle DNS), using binary logs, etc.

Lastly there's the conspiracy theory side of it, which alleges that systemd is an NSA attempt to compromise GNU/Linux, and due to Systemd as a project moving way too fast, it can't be properly audited.
web.archive.org/web/20170724100245/https://muchweb.me/systemd-nsa-attempt/

For more links and arguments, see:
without-systemd.org/wiki/index.php/Arguments_against_systemd

Attached: Systemd_anigif.gif (200x133, 772K)

For more on the DNS issue, see pic related

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

quality pasta

fpbp

But wait, there's more. Here's the motherboard bricking.

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

A common argument in Systemd's defense is that it shortened script length considerably. However, that's only true when comparing Systemd to Sysvinit. Other solutions make this point moot.
This is a common tactic of poettering shills. They'll find the worst possible thing to compare their trash to that makes it look most favorable, while COMPLETELY ignoring all other alternatives.
This same thing happened with PulseAudio, with poettering comparing it to OSS, even though that was already depreciated and replaced with ALSA

Attached: systemdlength.png (1711x1492, 539K)

>arguments
Literally just fud.

Oh noes now the automated systems at Google are going to know what you jack off to. No one cares. You are not special or important in any way.

And of course, systemd just has really, really bad code quality. See pic related and the recent System Down issue as well.

Attached: systemdhcp.jpg (3456x2304, 2.54M)

Opinions discarded

But Poettering is gonna rewrite it in rust, so it's ok /s

Attached: systemdrust.png (629x418, 92K)

And that’s only if you don’t configure your own resolver which is really hard to do.

>2019
>still spreading the "systemd bricked my motherboard" lie
twitter.com/mjg59/status/693494314941288448
Matthew Garrett admited that systemd isn't the one to blame.

>dns issue
For trigger it you literally need to meet 4 conditions that only can be present on a unmodified systemd without the proper configuration on the part of distro mantainers.

Butthurt poettering is butthurt

Stop spreading lies, Kike.

You're the only kike here.

Attached: behindthispost.jpg (491x491, 42K)

systemd is shit, but so is C. He is right on that one.

You didn't have a single argument. Literally the only things you ever said in the entire thread is "n-no it's n-n-not my fault look I'm telling you guys I'm t-totally right b-believe me!". You never accept responsibility for your crap which is why you CLOSE-WONTFIX everytime CRITICAL problems are uncovered in your crapware.
Despite having fixed tremendously by people who actually know what they're doing, neither pulseaudio nor networkmanager still work acceptably well TO THIS DAY, and they're not critical parts of the system that can open the very anals of the computer to an attacker, unlike an init system. Software also generally isn't hard-dependent on it for no reason unlike systemd.
You've always been crap at what you do, a real cancer in linuxland. But now you're going way too far. Off yourself, lennart, it's the only positive contribution you can possibly provide linux at this point.

>buttmad this hard

>it's ok to fail-deadly instead of fail-safe
>it's not like it's every gonna happen
>r-right guys?

>i can't configure my shit properly
>lets blame others instead

There's a LOT of reasons why people don't like it, and I think the people who don't like it all likely have their own reasons for not liking it.

Here's a posting about someone discovering a massive memory leak that used up 4GB of ram. While I have yet to see something this massive, I have definitely noticed Systemd using more memory than the alternatives, and some leakage here and there as well.
serverfault.com/questions/755818/systemd-using-4gb-ram-after-18-days-of-uptime

Some see it as an unnecessary security risk due to its massive attack surface. It recently hit 1 million lines of code.
phoronix.com/scan.php?page=news_item&px=systemd-2017-Git-Activity

Some don't like it because they dislike its habit of scope creep. The project ends up assimilating things that historically should not have anything to do with init. gif related.
suckless.org/sucks/systemd

There's also some other design decisions that people have an issue with, such as using Google DNS by default (because of course systemd can handle DNS), using binary logs, etc.

Lastly there's the conspiracy theory side of it, which alleges that systemd is an NSA attempt to compromise GNU/Linux, and due to Systemd as a project moving way too fast, it can't be properly audited.
web.archive.org/web/20170724100245/https://muchweb.me/systemd-nsa-attempt/

For more links and arguments, see:
without-systemd.org/wiki/index.php/Arguments_against_systemd

I'd just like to interject for a moment. What you're referring to as redpill,
is in fact, GNU/redpill, or as I've recently taken to calling it, GNU plus redpill.
Redpill is not a meme unto itself, but rather another free component
of a fully functioning GNU meme made useful by the GNU pills, red paint and GNU/stale matrix references comprising a full meme as defined by the hacker know as Jow Forums.

Why systemd is somehow "a big surface attack" but the kernel itself isn't an issue?

The problem is that's it's a hidden, unconfigured, undiscoverable feature. You expect that you fail to contact a DNS => connection failed. If your DNS is configured as an internal service but it's down so you're now pinging google for your internal resources, you're leaking what could be internal secrets, and even if it's not that important, you still have to deal with confusing diagnostic reports ("why are we hitting 8.8.8.8? did the dns config get reset?"). It happened in real life when I worked at microsoft (we were using microsoft-provided ubuntu machines for the whole group and IT was in a panic).

The kernel has a reason to be as big as it is: drivers. Kernels have to have drivers to support all the hardware you can use on it. Systemd does not have such an excuse.

well technically kernels don't have that excuse either, but we're still quite far from having a usable modern microkernel OS.

The kernel is necessarily large. Also, most of its code consists of drivers, which won't be loaded unless necessary (not to mention that you can easily exclude them altogether when compiling it).
systemd, however, has no reason to be as large as it is.

But still is giantic, so its a an issue then.
Systemd has the excuse of literally managing the system by itself, doing things that weren't common in the times where UNIX was "designed" that we expect of modern systems now.

The kernel IS an issue. Everyone agrees. But while systemd fixes no problem that has ever existed and is of the poorest code quality you can possibly find, the kernel is scrutinized more, kept at a higher standard, supported by multiple layers of mitigations in userspace and ring-0 alike (which systemd tries to defeat on purpose), and it's a compromise between performance and security. It's still something that people are very aware of and would like to find solutions to, but while the kernel is like that kind of out of necessity, systemd is like that in spite of logic, let alone necessity.

>systemd fixes no problem that has ever existed
The fact that I can avoid all race conditions that I had in my systems with init scripts tells me the otherwise.
Just admit you are doing special pledging to the kernel.

>Systemd has the excuse of literally managing the system by itself,
But init can be written in less than 20 lines of C code, so it does NOT have that excuse. Nevermind previously existing real-life init systems, none of which have that issue.
The fact that it gobbled up 500 services that existed completely independently of the init is even LESS of an excuse since the separation is proof that systemd never needed to gob them up in the first place, while the opposite is true for the kernel.

Systemd has known issues with race conditions. None of the other init systems do. So what the fuck are you even talking about?

systemd is a system and service manager for Linux operating systems. When run as first process on boot (as
PID 1), it acts as init system that brings up and maintains userspace services.

For compatibility with SysV, if systemd is called as init and a PID that is not 1, it will execute telinit
and pass all command line arguments unmodified. That means init and telinit are mostly equivalent when
invoked from normal login sessions. See telinit(8) for more information.

When run as a system instance, systemd interprets the configuration file system.conf and the files in
system.conf.d directories; when run as a user instance, systemd interprets the configuration file user.conf
and the files in user.conf.d directories. See systemd-system.conf(5) for more information.

>Systemd has the excuse of literally managing the system by itself.
no it doesn't, because it doesn't need to manage the system all by itself. We've had more modular systems in the past that worked just fine. Not to mention other *nixes like OpenBSD that are arguably more reliable without using such a bloated "system management" program. Way less featureful due to theo's autism and the system's relative obscurity, sure, but definitely more secure.

>race conditions.
But wasn't systemd made to solve it?
The whole dependency graph and all that

That is the entire point of a doomsday machine, yes?

Attached: dr strangelove.jpg (1600x917, 52K)

Wait, are you implying that all systemd consists in a single giant pid1 binary?
No, its not like that.
The fact that you can write a init in 20 lines doesn't mean you should do in that way. For example, in 20 lines you can't implement interfaces to connect to the process monitor, signal handler (heh, I remember when sysvinit hanged and you had a kernel panic because that) socket activation, etc, etc.

I installed Mint a year ago to try Linux (coming from windows 7). It's been very enjoyable since, but I want to move on to a systemd-free distro
What should I use? Devuan? Artix? I can't decide

>no one has issues with race conditions
You started using linux when Ubuntu was popular if you didn't have issues with sysvinit waiting shit.

Why you want to move to a systemd-free distro in first place?
He's lying, lad.

Not at all. Other systems like openrc already had dependency graphs, and it was always more popular to run services serially instead of in parallel, which mitigated that.

Yeah, but systemd isn't shit because of C, they can rewrite in any language they want and it will still be a bloated piece of shit filled with bugs and retarded design.

>openBSD
>reliable
Kek. That shit believes that my system is a static box from the 80's

Try MX Linux.

That's just a small part of what systemd does, for example, why the fuck does it need to handle DNS and NTP? That's way beyond what init should do, and it's not a requirement for the "advanced" features like socket activation, that's why people complain about it.

I would like to have a nice and simple system. From what I understood, systemd is suffering from scope creep and keeps growing in complexity.
Maybe I've been memed on, but even if it is the case, I think it would be a nice experience and allow me to see something else

I'll look into it, thanks. Why do you recommend it?

It looks to be one of the most polished and user-friendly systemdless distributions out there. Plus they have lots of documentation available on their site.

>why the fuck does it need to handle DNS and NTP?
Because:
>its an option you can enable o disable at compile time
>you can log it
>you can enable socket activation, useful for server farms and shit like that
>integration with udev, useful if you need a network set after the system configuration changes
systemd isn't only an init. Its a complete suite of the userspace innards for a linux system.
These things, per se, aren't an issue. Those are objections made from ideological points about what an Unix system should be.
Yes, you have been memed. Yes, I like you open mindness
Try GuixSD, its my favorite non systemd distro. The fact that can atomically manipulate the system gives me a hard on.
I believe systemd will do this in the future, if their package manager project prospers.

>an observation of scope creep is an ideological point.

It is. Those technical points aren't that technical as you think.

>>its an option you can enable o disable at compile time
Not if you want any other piece of software on your distro to actually work. Stopped reading here, shill.

Choose a distro that doesn't enable systemd ntp or dns at compile time then.

I run gentoo. You can keep your malware to yourself.

>attack surface.
For FUD brought to you by haters of freedom and their useful idiots.

>systemd
>freedom
Choose precisely one, paid shill.

Attached: lennart.png (640x480, 289K)

nsa backdoor. they're trying to compromise the linux world

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

It’s NSA spyware.

I've read all the redpills in this thread and now I am redpilled on systemd

Thing is, how do I AVOID systemd now?

Install FreeBSD

Then stop crying.
Also
>nobody can provide proof that the NSA is behind systemd besides speculation.

And you're completely omitting the convenient fact that the systemd version provides way more functionality than the others. Try adding cgroup jailing, socket activation, and other features and all of a sudden those "other solutions" will take hundreds of lines of code.

Your level of derp doesn't even make sense.
This idiots even worse.
Are these the shills behind this fud?

it's SHIT
>faster boots
NOPE, try to reboot, it REGULARLY HANGS - MOTHER FUCKER JUST KILL THE PROCESS

AND THEN IF YOU DO GET TO THE REBOOT PART IT HANGS AGAIN FUCK SYSTEMSHIT

Go down the rabbit hole and learn how to manage services on Linux:
troubleshooters.com/linux/diy/suckless_init_on_plop.htm

Hi, Lennart

>Jow Forums spacing

Systemdeez nuts ayy goooot hiiim what are those damn daniel

It falls back to 8.8.8.8 only if resolv.conf is empty, it won't just redirect to google if configured server is down.
The whole post is bullshit, I doubt you have ever had a job, let alone in microballs, but if you did, you would know the true meaning of "hidden, unconfigured, undiscoverable feature".

8.8.8.8 is an ad company

Attached: festering nigger diarrhea.png (1038x1015, 121K)

It ultimately comes down to it not embracing the Unix philosophy. Most of the complaints stem back to that. In essence, it's bloated, but it doesn't bother me that much.

go back to Jow Forumsedit

that makes clear Rust is shit

cuck d
linux fags like to pretend they are free but they are cucked to oblivion with that shit
buy a macbook

There's still plenty of fully featured distros that don't have system dicks.

Attached: images.jpg (189x267, 7K)

which "fully-featured" distros don't have systemd?

It does an ok job compared to what came before it. Overall rate it 6/8 m8. It's not great, but it works.

German engineering is the best in the world. Only angry muttcels hate systemd.

Any articles for ripping systemd out of ubuntu 18.04?

We had the Cloud memes, and people fell onto that jewish data harvesting enterprise

We had the VPN memes, and gullible snime lovers fell for it even if every single vpn has been demonstrated to be a polished turd

We had audiopulse and systemd memes, pushed like hell on multiple articles on jewsmedia outlets and (((you))) silly shabboz fell onto those shits

I mean, it's always the same: shit appears out of nothing - heavily pushed by Die Luegenpresse - random Untermenschen become starlets (See: Corey Dale Ehmke, Lennart "I Like to such Cocks" Poettering) and the goym fall on every damned single jewish corporation data-mining memed bullshit

>systemd

It's shit and we all know it.

Attached: amandakleinman.jpg (2048x2048, 530K)

Extra sandboxing capabilities is really the only actual feature systemd has over other init systems. The rest of it are memes or """features""" like journald. Overall, it's not worth it.

How is journald a meme? All the logs are basically in one place, you can append metadata that can be used to index specific logs, it handles log rotation for you, fully works as a syslog implementation, including remote sending and also send to file. Journald is probably one of the greatest things about systemd.

>All the logs are basically in one place
I already had this.

>append metadata that can be used to index specific logs
Completely retarded. Just use grep.

>it handles log rotation for you
I can use cron. It's not a feature.

>fully works as a syslog implementation
So do plenty of other logging daemons

>including remote sending and also send to file
There's already a million different ways to do this in a shell.

Journald is annoying garbage that gets in the way. Plus binary logs. The only way to use systemd sanely is to redirect that shit to syslog as soon as you can.

GNU and Linux are build around the GNU philosophy. And don't think that this is some abstract garbage that doesn't matter. Don't take me for a GNU fag who will not stfu about Ganoo linux and such bullshit. Honestly I couldn't give less of a fuck about the abstract part and ideology that retards use to feed their nerdrage. The GNU philosophy is not the best or the only philosophy. It's all up to personal opinion. The problem is that if you try to build a system in a certain way, everything along with it is expected to work in that certain way as well. Messing it up and adding things that are against the "founding" concept will usually simply lead to countless problems and issues of the "unsolvable" type.
One of the key concepts of the GNU philosophy is that creating bloated and big software of the kind "One program to rule them all" is almost illegal. The way things are expected to be done is with more independent, straight-forward programs. "It's better if a program does one thing perfectly than a lot of things well". And almost everything in the linux world is build around this concept including linux itself. Long story short - SystemD is the EXACT opposite. It started as a humble idea to change the init script which rapidly evolved into the idea of creating a piece of code that is expected to literally own almost everything in the system. It literally became one program to rule the all. And I'm not saying this is bad in all cases but in the linux case this is not how things are supposed to work and it backfires brutally.

I am personally not against SystemD as it really is an evolution to the way things used to be. On top of all we have already seen something similar happening with GNOME (another Fedora abomination... like everything coming from fedora devs). It makes life easier for certain linux users and so on. But the way things are going we should soon be calling it GNU + LINUX + SYSTEMD

Ya, excuse me while I implement a logrotate rule for all these files. Ya let me just grep out lines I want, because ERE is semantically complex enough to parse for specific instances of events for specific daemons. Being a binary format is literally not even an issue given almost everything you use likely uses sqlite3 or similarly complex binary representations of data. You're a retarded faggot.

>Ya, excuse me while I implement a logrotate rule for all these files. Ya let me just grep out lines I want
Why do you act like these are complicated or taxing tasks to do?

>Being a binary format is literally not even an issue given almost everything you use likely uses sqlite3 or similarly complex binary representations of data
Logs should never be binary. That is completely retarded. The purpose of a log is to be human readable. If your log gets corrupted, the answer from upstream is "lol well good luck and hope it doesn't happen again."

If your log gets corrupted, you restore from backup, but realistically if it happens the filesystem is trashed or there is a bug in the daemon that created it. Also it can syslog to file anyhow so this argument is completely moot and retarded, like you.

Logrotate is fucking terrible garbage and much more effort to set up than telling journald an appropriate retention policy in a single config value. Also enjoy that buggy signalling and all the other retarded broken shit logrotate has to do to make sure the daemons figure out they need to reopen their logs.

How the fuck is "restore from backup" an answer to corrupted logs? What if the process I wanted to capture happened after the last process?

>Also it can syslog to file anyhow
Right because even the systemd developers knew that binary logs were too retarded for them to force onto people, so they had to at least force you to work around it.

>Logrotate is fucking terrible garbage
I'm sorry that you are a fucking retard and logrotate is too complicated for you. Literally all you do is set the config values you want and then run a cronjob.

>after the last process
After the last backup*

It's quite fine. I came from SystemD year (approximately 150 SystemD's from now) on my SystemD, and everything is SystemD, so there's no confusion, except when SystemD does SystemD hard, but SystemD fixes it so it's all SystemD.

this but metaphysically

Daily reminder that Torvalds and Stallman approve of systemd. If you really respected these two people, you would approve of systemd too.

I'm gonna need a source for this claim

Stallman thinks it’s OK because it’s open source, he has never approved it in any technical sense, and Linus has been replaced by a globohomo pod person.