Systemd Saw The Most Commits Ever In 2015

[Daktyl198]

"Hard to parse and maintain shell scripts" are in fact quite easy. Change few lines in the template - done. If some service needs network to be configured when it starts, I'd just put it last - I don't care that much if it takes few more seconds for it to go up.

With systemd you end up wondering why the fuck requiring network.target is not enough and then dive into documentation to find out that there is some other obscure shit, possibly requiring some copy-pasting from interwebs to actually make it wait for the network scripts to finish. There are other stupid issues with systemd, like silently ignoring incorrent lines in unit files. Ok, I made a typo - tell me about it, don't just assume the default.

In the end, systemd might be good for maintainers. For someone just writing occasional service file, it is not. Maybe when I'll finally be forced to give up and live with it, I'll take my time to learn all the pitfalls, but for now apt-get install upstart-sysv is good enough.

"I know how to drive a car. The fact that I'm falling off the motorcycle is your fault for building the motorcycle, not my fault for refusing to learn how to ride... thus the car is better"

[interested]

Until there happens to be a bug in systemd and it just doesn't work for some reason.
Something like this: https://github.com/systemd/systemd/issues/1505

That bug has nothing to do with the systemd config file format.
In any case that bug is a show case for how great the systemd project is: the developers track down a rather obscure bug and makes a permanent fix. Hurray for developers that takes RFE's and squash bugs.

Or this: https://github.com/systemd/systemd/issues/2099

Really, Bash etc. is full of similar limits. Make a command line too long or make eg. "rm" remove too many files at a time and the script will fail. A single extra file in a temp dir may cause the entire SysVinit script to fail at boot. I like Bash and shell scripts, but like most people I think it is a bad choice for writing an OS with.

And you can't do much about this without someone, who is able to debug systemd itself, not just your tiny bash script.

You are confusing things here; neither SysVinit nor OpenRC are written in Bash. In order to debug them you have to know C, just like systemd.

SysVinit scripts are Turing complete executable config files and can have basically any form and content. That makes them hard to read for humans, and almost impossible to generically parse for machines: you can't have a lint-like static code check of SysVinit scripts since they basically can have any form.

systemd service files are structured key-value text files and are therefore easy to read and parse for both humans and machines. And if sticking to the systemd-directives, they can't accidentally wipe out the entire OS like a failed "rm -rf" in a SysVinit script can.

[unixfan2001]

Also from a developer standpoint working with .desktop-like config files is a cancer.

That sentence alone proves you aren't a developer but a skript kiddie.

[arokh]

Until there happens to be a bug in systemd and it just doesn't work for some reason.
Something like this: https://github.com/systemd/systemd/issues/1505
Or this: https://github.com/systemd/systemd/issues/2099
And you can't do much about this without someone, who is able to debug systemd itself, not just your tiny bash script.

Uhh you have some sort of need to fit more than 512 chars in an input line, and that somehow proves sysv is better?

Again and again, systemd opposers prove that they are actually full on retards with no ability to back their opinions with technical reasoning.

[SystemCrasher]

People leave linux because of systemd? I guess those morons must love services.msc.
and why stop there? go on windows forums and nag microsoft to use AUTOEXEC.BAT exclusively for init like the old days

On other hand, isn't it nice morons are going to use something else? Let 'em go BSD and dualboot to windows or mac os, like they always do, while praising "unix way". At the end of day, unix is an ancient proprietary system. Taking some good ideas is ok. But not more than that. Linux is cool enough to have its own way. Furthermore, Linux is just a kernel, and usermode can be everything. Dullard admins not capable of understanding basics of system inner working and mumbling BS are really better off somewhere else.

And in no way I'm going back to bugged halfassy shell scripts instead of brief unit files. Good luck to track service start timeout via shell scripts in meaningful ways. Even more luck to ensure it does not breaks when ntp suddenly adjusts clocks. Sure, in sysv init nobody gave it a fuck. So if service has locked up during start-up, who cares, right? Let it hang indefinitely, ensuring massive service outage. And of course I can set up service supervision. But since it is not a facility of sysv init, I have to set up service launch in 2 different places. Sounds cool, isn't it? To the hell with it, systemd does it far more logically.

[SystemCrasher]

more than 700 developers and still we got imbecile with "kokoko redhat kokoko"

On other hand, we're getting some most stupid, annoying and incompetent pests lost. Let them hurt system development somewhere else. I wish sysv init lovers good luck to e.g. track service start timeout in shell script. Difficulty bonus: ensure it does not fells apart if ntp adjuts clocks. Have fun coding it in shell. As well as two gazillions of other system management features meant to keep systems running and make system management logical and convenient. E.g. watchdog/startup notification apis, detecting non-zero error codes and logging program output, etc, setting up users, priorities, schedulers, limits...

[finalzone]

Yeah, they are modular and replaceable with... nothing. Most got absorbed (udev anyone?) and the rest doesn't work in other combinations (have you tried systemd+ConsoleKit? OpenRC+logind? ecc).
Also from a developer standpoint working with .desktop-like config files is a cancer.

ConsoleKit was unmaintained for years despite the warning from desktop developer to find a maintained, no one on the non-systemd development side setup until it was too late. OpenRC still uses the old sysv method which is why it is only used on Gentoo and its derivate. Logind is part of systemd.
The cancer is the very vocal minority unable to provide real technical feedback against systemd, their limited knowledge and their refusal to properly inform themselves.

[pal666]

Or this: https://github.com/systemd/systemd/issues/2099

i hit line length limit in openssh's config. do you stop using openssh now?

And you can't do much about this without someone, who is able to debug systemd itself, not just your tiny bash script.

your undeciferable bash script is run by bash and there are bugs in bash sometimes. also it uses gazillion of buggy cli utilities instead of few lines of c code. i hear your cry in the corner