Originally posted by Stellarwind
View Post
Announcement
Collapse
No announcement yet.
Systemd Saw The Most Commits Ever In 2015
Collapse
X
-
Originally posted by Stellarwind View PostUntil 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
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.
Originally posted by Stellarwind View Post
Originally posted by Stellarwind View PostAnd you can't do much about this without someone, who is able to debug systemd itself, not just your tiny bash script.
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.
- Likes 1
Comment
-
Originally posted by Stellarwind View PostUntil 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.
Comment
-
Originally posted by winie View PostPeople 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
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.
Comment
-
Originally posted by pal666 View Postmore than 700 developers and still we got imbecile with "kokoko redhat kokoko"Last edited by SystemCrasher; 05 January 2016, 10:20 AM.
- Likes 2
Comment
-
Originally posted by Shiba View Post
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.
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.Last edited by finalzone; 05 January 2016, 03:06 PM.
- Likes 2
Comment
-
Originally posted by Stellarwind View Post
Originally posted by Stellarwind View PostAnd you can't do much about this without someone, who is able to debug systemd itself, not just your tiny bash script.Last edited by pal666; 16 January 2016, 11:39 AM.
Comment
Comment