Why haven't YOU accepted systemd as our lord and savior?

Why haven't YOU accepted systemd as our lord and savior?

>declarative and easy service system
>standardized system administration
>standardized networking
>standardized date and time settings
>standardized hostname settings
>standardized locale settings
>standardized login
>standardized logging
>standardized device management through udev
>standardized job scheduling (timer services)
>standardized audio through pulseaudio
>standardized factory reset
>standardized containers through "portable services"
>ip traffic accounting per service possible with ease
>dynamic users are now also possible
>stateless, reproducible and verifiable systems
>on-demand services
>systemd is the new system stack between kernel and userspace
common myths dispelled: 0pointer.de/blog/projects/the-biggest-myths.html

It's no surprise at all that all major and relavant distributions moved on to systemd. If you are against systemd, then you are against making linux a competitive operating system.

Attached: lord_and_savior_of_linux.png (728x546, 450K)

Other urls found in this thread:

0pointer.de/blog/projects/the-biggest-myths.html
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
judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html#!
twitter.com/SFWRedditVideos

I like the interface it provides, but its just too damn buggy to take its developers seriously. Unfortunately it feels more like a tech demo than a released package.

>binary logs self corrupt
heh, nothin personal kid

I use s6 + libcg

All software have bugs. With something as ambitious as systemd, trying to become a whole new system layer between kernel and userspace, bugs are bound to happen. If they do happen, it's more obvious because it's one of the most crucial components of the system, next to the kernel.

Maybe they would have been better off going with a language like Rust. Then again, the C and conservative Unix fags would have been up in arms about that as well, so who knows, it seems like lose-lose either way.
I have been using systemd on my server and desktop systems for over 4 years now. I haven't had many issues with it.

Attached: serveimage (1).jpg (2000x1308, 639K)

>common myths dispelled: 0pointer.de/blog/projects/the-biggest-myths.html
>Myth nobody cares about
>Myth nobody cares about
>Myth: Yeah that's pretty much true
>Myth nobody cares about
>Myth: Yeah that's pretty much true
>Myth: Okay you got us there
>Myth nobody cares about
>Myth: Sure that's true but let us spin you some convoluted bullwinder on why it's fine everything is fine this is fine

Really makes those brain neurons think huh

Attached: Screenshot_20190203-165358_Chrome.jpg (1430x1543, 214K)

Many of those points you state as "nobody cares about" were criticisms by the conservative linux community. You may not care about it and neither do I, but many did make those claims back in the day.

>Myth: systemd's fast boot-up is irrelevant for servers.
>Myth: Yeah that's pretty much true
Not irrelevant, especially if you run multiple services on a single cheap VPS like I do.
Less downtime is undenyably better.
>Myth: systemd is difficult.
>Myth: Yeah that's pretty much true
I've written daemon shell scripts in the past and also systemd unit files. systemd unit files are way easier, especially if your service has multiple dependencies.
[Unit]
Description=service_description
After=network.target, my.other.1.service, my.other.2.service, my.other.3.service
[Service]
ExecStart=path_to_executable
Type=forking
PIDFile=path_to_pidfile
[Install]
WantedBy=default.target

>Myth: systemd was created as result of the NIH syndrome.
>Myth: Sure that's true but let us spin you some convoluted bullwinder on why it's fine everything is fine this is fine
There is a lot of times a company has NIH syndrome, this is not the case. systemd is fundementally different and it's about creating a standardized linux system stack, not just replacing a simple init system.

?

... user, did you think I was going in order, as opposed to snarkily summarizing the entire article? I may as well have typed out "blah blah blah".
I'm afraid you've vastly overestimated my level of caring.
user, sometimes I think you don't KNOW ME, at ALL...

Attached: 1518983772210.png (946x675, 370K)

Poe's law strikes once again.
I assume anons are well intentioned until proven otherwise.

Attached: 1511980490695.jpg (992x975, 113K)

It would be a good idea if it didn't massively increase the attack surface of a system when compared with initd

that being said, I like the convenience it offers and can see why it's widely adopted

Where do you think we are, user?
Some bastion of informed and civil discussion?
You don't even know my real name...
I'm the fucking lizard king.

Attached: 1529073250795.png (673x623, 268K)

based OP not a faggot for once

Why should I? It's a giant combine and I don't feel it'll do me any good. Unlike things like ZFS, which is also quite huge and entangled, but at least its complexity comes along with some actually useful features.

>Why haven't YOU accepted systemd as our lord and savior?
i use solaris

Because while it is a great idea for a new init system systemd is a piss-poor implementation of it.
Poorly documented code with bugs having gone unfixed for 100+ versions plus Pottering being behind it.
When we have better options like runit or openrc then why deal with corrupted files and feature creep.

This.

Pootering is a shit coder.

>Literally worse than OpenRC and runit in every way
>has had long standing issues that have existed since it was first introduced that have yet to be fixed because "not a bug"
>iz moduler because it has 69 binaries so I can increase my package count and have a shit init system, everyone else does it with one. A lot of those binaries are required, delivering them as """seperate""" doesn't make your shit system modular
>I (((standardized))) every part of our """modular""" initaudionetworkeverythingmanager system for you and baked udev into the kernel so you have no choice but to use my shitty code. Because what we had before was too much like unix and not enough like a shittier clone of windows
>slower, buggier, and more bloated than runit
>but those aren't bugs those are features ;)
>bricks motherboard
Thanks Poettering I hope you tickle your brain with a fucking bullet

and I am the gizzard wizard

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

The funny thing is, systemd's design would anger probably at least 95% of GNU/Linux users (probably including you too) IF it was anything but the init system.

I know some of you think the "Unix Way" is just a meme, but it's actually the reason you can do shit like pipe terminal commands into each other. It's THE reason you have components you can wrap your brain around which can all be pieced together and managed in a simple and flexible way. That's what the Unix Way does.

You want another great example of the Unix Way? Ironically systemd is a GREAT example of the Unix Way. Not in its design though, but in its mere existence.
Have you ever realized how absolutely amazing it is that a new piece of software as fundamental as PID 1 could be swapped out in all of our major distros (even "stable" ones) in only a few years time?
The significance of that cannot be overstated. And yet, although systemd owes its success to the Unix Way which made it so easy for them to step in, it undermines the Unix Way in its own design.

Do you think 20yrs from now when systemd is old and busted that it will be so easy to swap it out with something better? Well not only is the scope of this thing which needs to be replaced now _massive_ compared to what it used to be, but you'd also probably have to rewrite a lot of other software, or beg the developers to change their dependencies.
It doesn't matter if systemd works. You didn't start using GNU/Linux because it "works" did you? You started using it because it allowed you to be the master of how your data flows, and it allowed you to combine things in ways nobody else on GNU/Linux was doing to get exactly what you want.

Quit being led astray by the "just works" argument when it comes to systemd just because init systems aren't something you care to play around with and customize all that much. That shouldn't matter, and we should stick to the tried and true design principles that have served us so well all these years.

Attached: 1382311214638.png (750x850, 735K)

Upstart was better.

>All software have bugs
>he thinks bugs are an inevitability rather than something that should be avoided and eliminated

Attached: unhackable-kernel-sel4.jpg (982x552, 64K)

Based.
I don't care if this is pasta or not, it is now.

on that note:
judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html#!

That page would be 100% correct if it didn't claim Xorg is anything but a monolithic pile of shit.

you know how I know that you don't know what you're talking about?
because systemd isn't a single binary and it's modular. take your time to actually look into how it works before posting bullshit.

nice straw man

>systemd isn't a single binary and it's modular.
see:

Formal verification is still limited to the things defined in the software specification. There might be bugs that the formal spec doesn't guard against.

>Fallacy #1
The whole premise is already wrong. systemd isn't just an init system, it's supposed to be a layer between the kernel and userspace.
In that context, it's not wrong to have tight coupling between its modules, the same can be said about the kernel.
Now IF you couldn't replace the modules, then I would say you're right in complaining about that, but that's not the case.
If you don't like the implementation of ANY of the systemd modules, then you can replace it, which is good design. Don't like journald's binary format? Fork it, change it, release it. If people like your version better they will use it.

This is basically the same argument that linus and tannenbaum had about modules, but in this case it's about a system layer. In the end, you can argue both ways and both ways have each their pros and cons, but in the end, all that matters is a successful implementation that people want to use, as software without users is pointless.
>Fallacy #6: "Systemd is open source, so if you don't like it, you can fork it!"
>Some people are working on that, despite the fact that systemd is a large moving target.
all those forks are dead now kek, what a surprise.

>all those forks are dead now kek, what a surprise.
this is usually what happens when people anger fork.

Poettering and Sievers are unironically CIA assets via google.

>all those forks are dead now kek, what a surprise.
Goes to prove exactly what everyone's been saying, you CAN'T fork it. Mostly because they move so fast precisely to PREVENT forks from forming.
>The whole premise is already wrong. systemd isn't just an init system,
If you change what you claim to be, you can then look at people who were arguing your original claim was wrong and call them retards because, having changed your claim, their argument no longer applies to your new made-up claim. Genius!!1

>Why haven't YOU accepted systemd as our lord and savior?
Because you're a heathen and a subhuman shill.

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

systemd is the devil

>Security threats in the wild

Did you read this part user?
>Have you ever realized how absolutely amazing it is that a new piece of software as fundamental as PID 1 could be swapped out in all of our major distros (even "stable" ones) in only a few years time?

How the fuck do you expect me to believe systemd adheres to the same principles when even RIGHT NOW distros can't replace it with anything else, let alone 20yrs from now.
Did you know that the ONLY reason there are any modern non-systemd distros today at all is because the Gentoo devs worked hard to fork udev? That's what it fucking took to just be able to avoid systemd.
What do you think it'll take in the future for distros that are deeply rooted in systemd for decades to be able to replace it? Do you think this situation is going to get worse or better?
If you don't think worse then I think you're a fool.