What is Wrong with Systemd?

As someone who doesn't understand the controversy, what are the legitimate arguments against systemd?

Does it have binaries in it's core??

And are the binaries created on startup from the systemd code (which is FOSS, and publicly auditable)?

Other urls found in this thread:

en.m.wikipedia.org/wiki/Inspur_K-UX
github.com/tmux/tmux/issues/428
linuxquestions.org/questions/slackware-14/i'm-back-after-a-break-from-slackware-sharing-thoughts-and-seeing-whats-new-4175482641/#post5054861
wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#systemd
twitter.com/NSFWRedditGif

Autism

Dumb people that don't understand GNU and that any change is somehow bad for something they don't even get in the fucking first place.

>MAH UNIX PHILOSOPHY
GNU's Not Unix.

But there's not actually any part of Systemd, that is not FOSS, correct?

It's completely FOSS and works better than the old system.

So the hate is just conservatives who don't want to adopt the better system?

Yep.

The vast majority of leenux users didn't even notice the change. Muh cron jobs written in Perl3 two decades ago need to be faffed with, to work again. Why did we switch, sysvomit just workz gais.

The only thing it changes is what they copy-paste from the linux stackexchage / archi wiki whey they search "Y broke, wat do".

GNU is pretty simple to understand

Stallman and friends are retarded when it comes to software design and just mimicked UNIX because it was popular

Every UNIX userland clone made before GNU was better
Every UNIX userland clone made after GNU was much better

GNU sucks. The coreutils suck, the shell sucks, nano sucks, emacs sucks, info sucks, gcc sucks, glib sucks, gnutls sucks, gtk sucks, it all sucks. It's a shame systemd depends on glib. If it weren't "THE linux Clib", poettering wouldn't even use it. But it is, and he just wants to be spiteful towards BSD, so some of GNU will live on.

And that's the worst thing potheadring did with regards to systemd

There's nothing wrong with systemd as far as functionality goes but Linux should be about muh freedoms and some people feel systemd is being pushed too hard onto users. It's also not POSIX compliant, which basically means it only works on Linux instead of other Unix-like operating systems such as BSD.

Make your own distro without it. Should be a big success, considering how much hate system D gets?

Isn't that whole open source and making your own branch shit part of the freetard philosophy?

>GNU's Not Unix.
This was Richard thinking he made a cleaver joke. It was never meant to be taken seriously you aspie fuck.
Greater complexity for the end user. Easy to read and edit shell scripts being replaced by a binary application. Surely you can already detect some greater complexity in the VS image you uploaded. There are benefits in that added complexity, but it has pissed off quite a few people as well. Poettering's attitude of coming in and announcing he's taking over someone else projects adds fire to the flames. Now that he has pounded his chest and suggested anyone else not using Systemd will be left behind, everyone else has flipped him the bird and branched off with their own projects. Slackware and Gentoo never committed, and Debian has Devuan. Fedora is Redhat Jr so it was pretty obvious which way they were going.

My big problem was this.

I use this weird USB multi card reader on a headless machine to read a bunch of cards at once when I get back from a weekend photo trip.

All of the local drives in that machine are mounted via labels.

When I tried to boot with the card reader attached, systemd would freak out when it tried to enumerate the devices in the USB card reader.

I ended up just switching to FreeBSD. Everything just works.

Systemd takes longer to boot than the old init system did, and the binary logs are useless. I've managed to trigger some kernel crashes in recent versions of Linux, and every time I attempt to check the binary logs for what happened before the crash, they are corrupt.

Are there any good minimal distros without systemd that have a good package manager? I'm using arch but I'd prefer to switch to something without systemd if there's anything comparable

gentoo/funtoo

It's a foss software and it has NO binary in the core. Its a spicy meme that hippies came up with

Aww, this damn thread again..?

Systemd is against the linux philosophy of "doing one thing well". It turns Linux (slowly but inevitably) into a monolithic system. If you read "the cathedral and the bazaar" you'll know what I mean, systemd is turning the bazaar into a cathedral..
This may not sound like much, but it's a important step. What will be the next step? A unified GUI in 5 years? Why not just buying Win then?

Furthermore it will be hard to replace in the future. Even guys who think systemd is a good thing will admit it has flaws. It will be pretty much impossible to write a completely differnt programm for startup in the future, with systemd being so ingrained.

Next problem is that systemd creates a single point of failure, it's a high value target. Once ou have a backdoor in systemd your whole system is compromised. This is even more of an issue since almost every linux uses systemd.

Also the devellopers are not very nice people. They insulted many guys, they didn't care about any criticism, they just did it "their way" and gave no flying fuck about what the community thinks.

Last but not least:
You can't avoid it. Linux was always meant as alternative, as system where you can choose your distro or even your components. Systemd killed that freedom* (*= with free as in "free to chose if you want to use a programm or not").

>avoid Sup Forums for a year
>visit it to see what's up
>systemd still exists
>people are still having the same stale argument
>freedesktopfags & gnufags still don't give a shit about program design
i despair

software just gets worse and worse

It is an init system, container manager, auto mounter, boot loader, syslogger, ntp daemon, etc. There is nothing wrong with systemd, but IMO it is a confused product with no real scope so I will not be using it on my systems.

>kdbus
haha, glad that shit is gone

>Systemd is against the linux philosophy of "doing one thing well"
So is Linux itself.
So is Emacs.
So is KDE.

>what are the legitimate arguments against systemd?
systemd user here, these are legitimate arguments against systemd:

1. It's new and less tested, therefore it will contain more bugs per line of code on average compared to existing software

2. Most components are very interdependent, which limits your choices somewhat. You can't get rid of dbus or logind*, for example. (Though most components can be easily replaced, e.g. journald → syslog, timers → crond, timesyncd → ntpd, resolvd → unbound, ...)

* Don't quote me on this, I've never tried

3. Due to its novelty, there's a general lack of understanding about best practices etc., which can sometimes bite people in the ass who are new to systemd but used to older software. Not as much of an issue these days though, but it was a wild ride during the transition period.

4. Since most existing init files are written against OpenRC or sysvinit, many distros go the route of using hacky systemd⇔sysvinit bridges to start services instead of actually writing and shipping systemd unit files. This mostly affects e.g. ubuntu/debian. Other distros, notably arch and fedora, use systemd unit files for everything.

Apart from this, the heavy backlash seen in practice seems to be mostly focused around the fact that distro users don't have a say in the matter, and forced change is bad. Switching from e.g. debian to devuan or arch linux to void linux is mostly an act of self-assertion as to the user's relevance in a system. (Other distros, like Gentoo, don't suffer from this problem because the user is given a choice to begin with)

>Systemd takes longer to boot than the old init system did,
but thats wrong, its way faster on every single machine i tried to compare them
>and the binary logs are useless. I've managed to trigger some kernel crashes in recent versions of Linux, and every time I attempt to check the binary logs for what happened before the crash, they are corrupt.
agreed, fuck binary logs

The thing you have to realize about systemd is that it's an umbrella project of red hat for anything that can be considered part of the base operating system as opposed to user software.

The “systemd” project consists of many independent components: init, journald, timesyncd, resolvd, logind, networkd, coredumpctl, machinectl, udevd, etc.

It's not one “big bad binary” like most people seem to believe, and it actually follows the unix principle fairly well: everything does one thing and does it well, and existing infrastructure and code is reused as much as possible.

The only reason it's all mantained as part of a single source tree is because it enables a consistent release cycle and API (which is especially important during a project's rapid development phase).

Would you be as offended if all of the above named projects were kept in separate git repositories instead? There would be no difference in practice except greater maintainer overhead, yet I personally suspect this simple change would make it much less controversial for more people out there: because then it wouldn't be “oh no, systemd ate NTP!!!!” but rather “oh look, red hat made an ntp replacement”

Use syslog instead of journald if you want text logs at the cost of losing journalctl's functionality

(Personally, I value journalctl more than text logs, so I pick the former, but it's your choice)

The only argument that matters to me is that I still keep finding bugs that hinder me in some way or another, issues that I don't have with any other init system.

This though, "muh philosophy" is mostly bullshit mumbling from the community that can't come up with actual legit arguments.

How? Can i turn off journald somehow?
Is there configuration parameter somewhere to turn on syslog instead or something?

systemctl disable journald (or uninstall it)
systemctl enable rsyslog (or whatever)

Then configure your programs to log to syslog (or files) as usual instead of configuring them to log to journal/stdout

Also, see system.conf's “LogTarget” option

Systemd is backwards compatible anyway. The old commands are symlinked.

>Easy to read and edit shell scripts being replaced by a binary application
Init scripts aren't easy to troubleshoot at all.
And what the hell do you mean by "binary application"?

>1. It's new
Oh shit, innovation. Stop that right now!

>2. Most components are very interdependent
>most components can be easily replaced
Which is it?

>3. Not as much of an issue these days

>4. Many distros use hacky crutches instead of doing things the way they're supposed to be done.
Not a fault with Systemd.

>Distro users don't have a say in the matter.
Depends on the Distro. On Arch/Ubuntu, you don't. On Debian, you do. They vote on stuff like this.

By the way, thank you for the detailed analysis!

GNU's not Unix was intentional. The Unixes were proprietary at the time.

Also, old init scripts work in systemd. It's a shit argument.

this thread again

>autists
check
>normalfags crossboarders calling others autistic
check
>bunch of stupid follow-up questions which have been answered at least 200 times in the last month
check
>muh philosophy
check
>muh fast boot
check
>give me one good reason
check

It takes over 3 minutes to boot with systemd on my i586 compared to just 50sec-1minute without it installed.

>w-w-w-hy are you still using unsupported pentiums, user-kun?
Shut up, I'm using a K6-2.

>oh shit innovation
that was clearly not his point but rather that for something new it's getting accepted faster than expected which generally is not a good thing
won't even bother reading the rest of your post if the beginning managed to be this stupid

>inb4 obviously it',s so good everyone wants it lol
kys

People who take Gnu's Not Unix literally don't really understand what it means.

See

>single source tree
Nobody cares if their udev daemon shows up as systemd-udevd in top or if they find Lennart mentioned in their man pages. The problem is systemd components are designed as an all or nothing deal unlike Xorg or even GNU programs, things like logind communicate over mostly undocumented/unstable APIs and are a real chore to use anywhere else.

Yes, Linux still is technically a unix system though.

No, it's a Unix-like system.
It isn't certified as Unix.

Who cares about the official certification, that's just corporate balooney. Linux was at the time it was being made, designed from code from other unix kernels.

A binary application is one that has been compiled from, say, source code, into a binary format.

A non-binary application would be one that is written as a script and is not compiled, but rather interpreted at runtime.

The advantage of the former would be potentially faster speed, while the advantage of the later would be the ability to modify the code on the fly (just open it in a text editor and hack away), without having to download the source code and compile your own binary.

>what are the legitimate arguments against systemd?

the problems with systemd aren't with huge glaring problems but more so the developers attitude when problems occur with the design, and while it's extremely easy to dismiss this criticism of systemd if you're complacent with systemd taking on a lot of responsibilities outside of what an init system should be doing, it is still a valid concern for those who don't want an answer akin to "works on my machine" after being forced into using systemd

literally, the official answer (by devs on the bug listing, at least) to the binary log corruption problem was akin to "works on my machine" and "there's nothing we can do" -- or just use text based logs next time (not default) which helps a ton when you need those corrupted logs to be readable

>Easy to read and edit shell scripts being replaced by a binary application.

the result of this is you don't have to write huge long often undocumented shell scripts to init stuff (often lacking proper support for showing status, etc) as systemd init scripts are so easy a pleb could do it and get the same equal good functionality of 90% of other systemd init scripts

>Slackware and Gentoo never committed

slackware doesn't support systemd because it has a very small dev team (maybe only the creator plus a few volunteer contributors), however the creator has stated he'll switch to systemd as soon as the development time to switch is less so than is required to continue supporting sysvinit

gentoo fully committed however, systemd is fully supported, it's just not default, however pretty much all the documentation on the wiki and forums assume you'll be using systemd so if you want to use gentoo without systemd you better know your shit

the binaries people are talking about are compiled programs replacing shell scripts, NOT non-free binaries as often talked about in open source firmware/drivers; quit being a fucking autist

>Which is it?
Both? Do you understand how dependencies work?

If A depends on B depends on C depends on D, you have a chain like this:

A → B → C → D

This means that to get A you need to pull in B, C, and D

But that's not mutually exclusive with replacing C by something else

>slackware doesn't support systemd because it has a very small dev team (maybe only the creator plus a few volunteer contributors)

Nope, Pat doesn't like systemd at all.

This is a shill thread.

Fuck RedHat. Fuck systemd.

>>what are the legitimate arguments against systemd?
>systemd user here, these are legitimate arguments against systemd:
>1. It's new and less tested, therefore it will contain more bugs per line of code on average compared to existing software

on the contrary, systemd receives *far* more contributions and development/bug testing time than the init systems it's replacing (or competing with)

larger projects introduce more complexity but I don't think you realise just the sheer amount of man hours going into developing and testing systemd

>4. Since most existing init files are written against OpenRC or sysvinit, many distros go the route of using hacky systemd⇔sysvinit bridges to start services instead of actually writing and shipping systemd unit files. This mostly affects e.g. ubuntu/debian. Other distros, notably arch and fedora, use systemd unit files for everything.

if that's true it's more a criticism of debian/ubuntu than anything

You can just ignore it and move on with your life. Oh sorry, I forgot that this board is your life.

wrong
en.m.wikipedia.org/wiki/Inspur_K-UX

they're kept togheter because they're tightly coupled
you won't be able to compile or run timesyncd standalone, no matter how "independent" that component look
it's full of systemd event communication code, hardcoded systemd paths and so on

functionally it's very much one "big bad binary", even tho systemd-timesyncd sits on its own inode

>larger projects introduce more complexity but I don't think you realise just the sheer amount of man hours going into developing and testing systemd
Can it compete with the decades of testing and widescale mass deployment that software before systemd has seen?

See The dependency is one-way only. You can run systemd without timesyncd, which was the claim here.

>functionally it's very much one "big bad binary", even tho systemd-timesyncd sits on its own inode
Clueless idiot. I'm literally running a system without timesyncd as we speak, how the fuck is this a big bad binary again?

It's a pretty good bootloader.

>however pretty much all the documentation on the wiki and forums assume you'll be using systemd

that's wrong though, also the only reason gentoo supports systemd is because they value choice (even dpkg and pacman are supported)

>gentoo fully committed however, systemd is fully supported, it's just not default, however pretty much all the documentation on the wiki and forums assume you'll be using systemd so if you want to use gentoo without systemd you better know your shit
This is very wrong. OpenRC is pretty much still the #1 init system both by recommendation, by popularity and by package availability.

Gentoo+systemd works but you'll often find yourself e.g. stealing unit files from archlinux because gentoo doesn't package them yet.

nobody understands or cares about the details of init systems. But people notice that more and more projects have "systemd-" in front of their name and find it worrying.
Why exactly did the project concerned with user space process things have to get hold of the bootloader?
The reasons are probably political (red hat exerting control over the whole stack or something like that), cause technologically they don't make any sense in the eyes of many people.
Regarding the adoption of systemd by debian, wasn't there some thing where I think some part of gnome suddenly had a systemd dependency? Well, who's controlling gnome? RedHat. I say this was planned.

And they do actually break certain things that have been working for 3 decades: github.com/tmux/tmux/issues/428

>The reasons are probably political (red hat exerting control over the whole stack or something like that), cause technologically they don't make any sense in the eyes of many people.
What component of systemd do you think is unjustified from a technological point of view?

A kernel is not an operating system.

The subject was about GNU.

>And they do actually break certain things that have been working for 3 decades: github.com/tmux/tmux/issues/428
The amount of salt over the inability of people to configure their systems properly is amazing

Yes, if you configure logind to kill all user processes when logging out, logind will kill all session processes when logging out. How is this surprising?

systemd added a new feature that some people *do* explicitly want (for example, we use it on our shared multi-user machines to ensure people don't leave behind nohup'd processes or other bullshit when logging out), and this new functionality is supposed to somehow be bad?

It's stricly optional. Don't need it, don't enable it, don't complain about it..

>Nope, Pat doesn't like systemd at all.

I am aware patrick (and some other slackware devs) have expressed dissatisfaction with systemd as far back as 2011 ish when it was introduced with fedora (but come on, everyone was hating on systemd until all it assimilated all major distros by mid 2014-2015 ish)

however in 2013 patrick made a post which was arguably the strongest position made on what direction slackware would have taken towards systemd:

linuxquestions.org/questions/slackware-14/i'm-back-after-a-break-from-slackware-sharing-thoughts-and-seeing-whats-new-4175482641/#post5054861

>If that happens, the choice will be whatever will be likely to cause the least future trouble, such as requiring yet-another init change due to a collapse of support for the current choice. Don't see that ever being OpenRC, sorry.
>>I'd rather have [what systemd is not]
>Yeah, me too.
>Let's not have another one of those threads, OK? Save it for when we switch to systemd.

however it appears that in december 2015 slackware introduced eudev into the testing branch (and has been released into stable as of last month) which means for the foreseeable future slackware won't be touching systemd at all, as eudev is a gentoo fork of udev in response to udev becoming a systemd project, this is new to me and I'll have to check slackware out again now that there's a fairly recent stable version

I'll accept that my generalisation of the post made wasn't completely accurate, I apologise, going off of memory of a post I read a few years ago

sure it can, systemd is literally on every major distribution that matters as far as where the development funding is going and what is being ran on enterprise servers when they update (rhel/centos 7 uses a bit of systemd for example, by the time rhel8 comes along it'll have had years of testing on server distros and literally almost every desktop distro)

The Tmux devs/users are in the wrong. They were misusing background processes when it should have been a daemon.

Systemd's change was that it enforces closing background processes that are not daemons when someone logs out. This is the sane thing to do.

>that's wrong though
>This is very wrong.

what's wrong? that the documentation/forum posts assumes you'll be using systemd? the few times I've actually had to look at the documentation or forums to find help for something I've had trouble finding the non-systemd instructions and I've had better luck only displaying results on google up until about 2013-2014 odd

granted this could be my very niche uses cases but I don't think it's an unreasonable claim to make, but I'll take it back and will do a little more research in the future

>OpenRC is pretty much still the #1 init system both by recommendation, by popularity and by package availability.

I fully understand openrc is fully supported and is default, which is why I made a point of mentioning systemd was non-default, but it just seemed in my experience the documentation was geared towards providing instructions for systemd machines outside of the installation guide and more generic problems

>The reasons are probably political (red hat exerting control over the whole stack or something like that)

it's more a case of it's easier to fund development of a single project and it's easier for that project to function if it has a lot of co-dependencies that are generally managed and needed by a typical system, but of course it is in red hat's best interest to be at the forefront of the init system used by almost everything these days

>And they do actually break certain things that have been working for 3 decades

was the kernel debug spam causing systems to not boot, requiring a fucking KERNEL patch to fix systemd, not an indication that the devs do not give a shit about breaking userspace? lol

>It's stricly optional. Don't need it, don't enable it, don't complain about it..

I'm genuinely surprised it wasn't pushed by default which seems to be the systemd way

it's definitely a nice feature to have for the reasons you listed

That is a GNU distro though.

>So is Linux
doStallmanSpam();
>So is Emacs/KDE
agreed, that's why they are shit and I don't use them.

>A kernel is not an operating system

Stop fucking around mate. First it's "No Unix certification, then not Unix" now it's "Linux is not a le operating system". Also just to blow your ass, the unix certification refers to the kernel.

Stallman copypasta doesn't apply when someone is referring to the kernel as Linux.

>the unix certification refers to the kernel.
that's wrong, SUS does require userspace components like specific libc functions and command-line programs

they still do it anyway

In that case it makes no sense because linux (the kernel) actually does its one thing (being a kernel) very well.

it's badly designed, bloated, goes agaisnt the UNIX way and can be used to spy on you.

If you're using a distro with systemd as your daily driver you're literally no better than a Winkid who's traded privacy and usability for "cool" flat menus and minor QoL improvements.

Which are found in linux.

Not in the kernel.

But you can use it with linux.

What?

Forget it. You're worthless.

Linux (the kernel) is a bloated monolithic mess.
The Unix philosophy demands a microkernel like Hurd.

Source? The only GNU software I can find is the compiler.

>userspace components are not in the kernel
no shit

it's RHEL

I prefer systemd over sysvinit. My biggest complaint about systemd is.

> its "fat"; it does more than be an init system.

However, it's still better than the shit sysvinit

I wasn't the one who changed the subject from operating systems to kernels. GNU or GNU/Linux is Unix like but is not compliant with any standard of Unix. This guy randomly brings up Linux as a kernel.

It's based on RHEL. That doesn't imply it's running on GNU software instead of something else that would make it Unix certified.

>The Tmux devs/users are in the wrong.
That's easy for systemd to say, because it looks wrong from their point of view.

From the point of view of tmux, forcing everything to be a daemon is wrong.

Anyway, who's wrong and who's right is irrelevant. What matters is that it's only a default, and one that can be easily changed. Most distros actually preserve the old style of not killing processes, simply because it breaks stuff like tmux/nohup and those haven't been updated to play nice with systemd.

See e.g. wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#systemd

systemd is currently a “special” profile in gentoo, not part of the base profiles like “desktop” etc.

Usually, systemd is just mentioned as a sub-section like this, rather than being part of the main instructions.

>I'm genuinely surprised it wasn't pushed by default which seems to be the systemd way
The default behavior is a compile-time setting. Some distros (e.g. fedora?) enable it by default, some (e.g. gentoo) disabled it by default.

The “default behavior if you don't specify any configure options” is pretty much just the same as fedora's defaults, but that's pretty much just because red hat makes systemd so obviously their defaults would be in line with their idea of what's right and what's wrong.

This is hardly the only time that distros like gentoo disagree with what red hat thinks the right default is, and it's hardly the most controversial.

Devuan

I use OpenRC.

To be honest, although I've had problems with other Pottering software (pulse audio), SystemD has never been a problem for me.

I do dislike the guy who make it though. Him and his crew seem to have a "we're going to do what we want, and we don't care what projects we break. We are the most important and the only thing that matters, so you have to work around us." attitude, which is a pretty shitty attitude for something that's primarily community driven and based.

Shit that thing where they stomped right into the Linux kernel namespace, and basically told Linus and everyone who had a problem with it to eat shit, was pretty fucked up.

They act like they're the leaders of Linux and what they say goes, or else.

>To be honest, although I've had problems with other Pottering software (pulse audio), SystemD has never been a problem for me.
Same. Poettering is pretty hit and miss with his approach to software.

For example, PulseAudio is a living nightmare because it follows this weird “randomly autospawned by random programs” philosophy, which just completely breaks. If it was instead an actual daemon that just ran statically, it would probably work much better.

systemd seems much better designed from the get go.

It's an effort to unify the Linux distros, so I guess a lot of people don't like that. I don't mind it to be honest, it works and Linux is not that great anyway. Wish there was a better alternative.