All you need to know about systemd is that, ironically, systemd

File: Void_Linux_logo.svg.png (62KB, 1200x989px) Image search: [Google]

62KB, 1200x989px

Not a problem with Void Linux.

>>61726119
As someone who actually develops services and drivers for a living, systemd is fucking awesome.

>>61726175
I'd really like to know how many of the people that make systemd threads have written, debugged, and maintained traditional init scripts.

I haven't but everything I've read says it's an enormous pain in the ass.

>>61726175

Yeah, it not that -your- data or systems are at stake here. Just your company's customers.

>>61726229
>I'd really like to know how many of the people that make systemd threads have written, debugged, and maintained traditional init scripts.
About 0, at least here on /g/.

>I haven't but everything I've read says it's an enormous pain in the ass.
I mean, traditionally you would follow some form of convention, but basically every vendor did their own thing. Before systemd, there were plenty of efforts to make a unified framework for how to manage services, that's why Upstart was invented, but still it was possible to entirely circumvent everything, which made it a pain in the ass to maintain.

The beauty of systemd isn't only the unification, though. It's has also introduced a standard format for logging, so you can actually expect to see something meaningful in the logs rather than just praying that the vendors bothered with writing messages to the systemlog, which was the old way.

Also, dependency declaration in systemd is a lot nicer.

>>61726293
My void linux boots faster than any distro with systemd.
Systemd is garbage.
/thread

File: lIAWr.png (88KB, 700x451px) Image search: [Google]

88KB, 700x451px

I always wondered about dbus ten years ago.

>>61726275
What exactly do you think is at "stake" here? That users finally have a standardised way of controlling services? That they can expect a sensible information in system log? That they can expect their services to be loaded in a defined order, instead of arbitrary workarounds and hacks?

People who oppose "systemd" and voice their opinions about the "unix way" are absolute morons. The "unix way" is an intangible "catch all" phrase people in the NIX community blurt out when they run out of technical arguments.

Do you want to know what the unix way is? It's acting hostile towards any form of unification and Doing It Your Own Way[tm] whenever you disagree with something. This is why you end up with a billion different BSDs, and angry autistic people. The unix way is the bullshit that gives you Go and it's broken "include directly from github but screw versioning" inclusion system as well as C-style error handling. Because "it's the unix way".

It's also what gives you cat-v.org, a hostile and toxic community that posts satirical and critical texts about stuff they disagree with, rather than actually contribute to code.

>>61726175
>>61726293

They only reason systemd exists is to smuggle an enormous amount of exploits into as many systems as possible.

>binary logs that get fuck more often than OP's mom.

>>61726321
>My void linux boots faster than any distro with systemd.
Nice anecdote, but without any real numbers (on the same hardware), I call bullshit.

>>61726175
And as someone who does system programming for a living, I find systemd to be horrific. If you want to do it their way, they fuck you, and if you want to avoid writing systemd-specific code it still finds a way to fuck you.

>>61726354
test it yourself faggot, you don't have to have real numbers, it's night and day.

>>61726406
You're either one of those "hacker" types who actually preferred hacking together some shitty scripts or you don't know what you're talking about.

systemd's declarative config syntax and predefined system objects is infinitely better than searching for a bunch of environment variables that might or might not be set, depending on which version of upstart you were running.

>>61726454
Cool story bro.

>>61726476
I'm not talking about its fucking configuration system -- that's the most superficial thing to complain about.

I'm talking about the fact that they've decided to reimplement core OS functionality as DBus services which they recommend every developer use.

Want to query DNS? Use DBus.
Want to create a cgroup? Use DBus.
Want to run a daemon? Use DBus.
Want to change the current time? Use DBus.

And if you _don't_ use DBus to tell systemd what you're doing, then systemd will ultimately revert your decisions arbitrarily. We had a bug in container runtimes where systemd would *remove the cgroup limit that we explicitly set even if we told systemd about it*. If we worked around systemd, it worked out fine. But if you work around systemd, it finds other ways to fuck you.

By the way, did you know that systemd doesn't respond to SIGPWR? They require you to use SIGRT_13 which literally no other fucking init system does.

>>61726644
>By the way, did you know that systemd doesn't respond to SIGPWR? They require you to use SIGRT_13 which literally no other fucking init system does.
Can you expand on that?

>>61726644
>And if you _don't_ use DBus to tell systemd what you're doing, then systemd will ultimately revert your decisions arbitrarily. We had a bug in container runtimes where systemd would *remove the cgroup limit that we explicitly set even if we told systemd about it*. If we worked around systemd, it worked out fine. But if you work around systemd, it finds other ways to fuck you.
This is a good thing

>>61726724
Sure, fa.m

>>61726736
It is. It forces devs to do it The Right Way[tm] rather than making their own custom hacks. Just because you didn't manage to look up the documentation, doesn't mean your users should suffer for that.

>>61726229
I did it once. Easier to write a bash script, basically, than dig into the systemd documentation, because shell syntax is already known.

>>61726744
>...doesn't mean your users should suffer for that.
My users shouldn't even be aware what init system I use.

>It forces devs to do it The Right Way[tm] [...] the documentation [...]
Both are fast moving targets. I don't feel like redoing my config everytime systemd changes its APIs or bug/workarounds are fixed/broken.

>>61726229
>>61726293
>muuh shell scripts mimimimi

Clearly the better way to pretend config files are Turing complete when they aren't:

[Brainlet]
DoAfterBrainletPostsRetardedShitInSystemdThread=kys

>>61726744
>rather than making their own custom hacks

Ah of course, that makes sense. TIL that doing a DNS lookup using libc is a "custom hack", as opposed to doing it the (((correct))) way by using a completely separate protocol to communicate with a daemon that will resolve an IP for me.

Absolute genius. Turns out those idiots that made UNIXv7 didn't realise that libc should actually just be a wrapper around DBus. Because that's how you make stable software, you add more layers of RPC.

systemd does solve problems people had in the past, but pretending that creating DBus APIs for existing system functionality is a good thing is just being stupid.

File: 1500983097852.jpg (54KB, 480x590px) Image search: [Google]

54KB, 480x590px

what does linus think about systemd?

>>61726850
He doesn't trust it because they've done so much stupid shit in the past.

>>61726835
>>61726843
Butthurt hackers

>>61726787

This. sysvinit for example was pretty much self-explanatory.

systemd however. . .

>>61726867
systemd fanboi without arguments

>>61726850
Criticizing RedHat hurts his net worth

>>61726713
If you want to power off your machine gracefully, init systems have a special signal (SIGPWR) that is used to tell them that exact message. Every init system supports it.

Except systemd. systemd requires you to use SIGRT13 (one of the realtime signals) and it ignores SIGPWR. LXC had to add hacks to their code in order to handle this particular case where systemd decided to ignore that there already exists a special snowflake signal _just for them_ and went and used SIGRT__.

As an aside, has anyone else noticed that "reboot" and "poweroff" don't work in a systemd recovery shell? I should check this, but I'm fairly sure it's either because of this signal bullshit or that they might actually be using DBus for sending poweroff messages.

>>61726867
I hope Lennart gives you a reacharound, it's the least he can do after you've rimmed him so much in public.

>>61726145
fpbp

>>61726145
t. Luke Smith.

>>61726910
>As an aside, has anyone else noticed that "reboot" and "poweroff" don't work in a systemd recovery shell? I should check this, but I'm fairly sure it's either because of this signal bullshit or that they might actually be using DBus for sending poweroff messages.
Ah, I always wondered about that one, and always end up using the power button

>>61727486
Now if only they had strace in the recovery shell...

>>61727905
You can add it yourself

>>61726454
Solus is also very fast and uses systemd.

>>61726119
shitstemD actually just fucked my install again last night.
Currently the score is 3 for systemD, 1 for KDE, and 1 for myself.

>>61726783
what a cunt

>>61726644
>tfw when someone really knows what is going on gets only two replies:
>>61726713
>>61726724
Is this board really that full of kiddos as >>61726867?
Really makes me think.

>>61728447
This.