3 ms·
systemd is, in some sense, a very modern-day product - a mess of different "alien" concepts and functionality stuck together into one project with an intention
by dschiptsov 13y ago
systemd is, in some sense, a very modern-day product - a mess of different "alien" concepts and functionality stuck together into one project with an intention to show other the only true way of doing things. It like some (freedesktop guys, perhaps) will come to Plan9 and would say that all they need is gconf* -like registry to have a uniform configuration, or something of the same level of absurdity.
The movement out of shell-based initscripts for non-specialized (non-mobile/embedded) distributions is a cancer.) Remaining BSD guys are much more sane and "conservative" in this respect.
There is absolutely no necessity to break what is good-enough and well-balanced - having a standard shell scripts to do the job they were designed to. FreeBSD's rc.d system is a very good example.
- Jasper_ 13y agosystemd has one purpose: to be about system and service management. It will replace everything that deals with services: starting them (whether based on traditional init, scheduling, socket activation, or from a desktop user session), logging the stdout/stderr in a consistent and well-defined location, and about giving you flexible tools to manage, debug, and inspect system services. Besides that, yes, it does have a few things (hostnamed, timedated), which are mostly about some POSIX infrastructure that wasn't there already: notification when the system hostname or timedate changes (yes, it happens quite often on desktop systems, due to NTP, user setting, and VPN). They're just utilities they needed along the way, and systemd can be built without them. If the system or service fails to start, instead of hunting around in /var/log/, syslog, dmesg, etc. for anything that looks relevant, you simply use the journal which aggregates most everything. It's already a very good breakthrough. I've debugged countless bad Debian service scripts (which usually comes down to bash's terrible whitespace and quote management), and inserted echo statements into my Arch Linux to debug why it wouldn't boot when I upgraded, hacking out clear statements here and there designed to make the boot pretty. Shell scripts aren't a good solution for robust system and service management.
- dschiptsov 13y agoWe have no services in UNIX-like systems, we have daemons and it is perfectly OK to use a templated shell script to start/stop restart it, modified according to the nature of a daemon, as needed. That other operating system from which the concept of a "service" came from (along with lots of other crap) have different philosophy and founded on different design decisions, so blindly trying to bring stuff from it here is not always reasonable. And, of course, shell scripts are OK when well-written - there are other UNIX-like systems beside Linux.)
- Jasper_ 13y agoI don't know why you think "service" is a word that systemd got from Windows. The name "service" actually came from the usage of the "service" script to run initscripts, like "sudo service httpd start". A systemd "service" is just a declarative description of a daemon that allows systemd to start and stop it.
- bkor 13y agoSuggest to change the way you word things. For one, your post is attacking people indirectly by suggesting that systemd people are absurd and their idea is a cancer and that there is no need to change at all. That is what I see as the main message from your post. If you wonder why people move to something else and your ideas are ignored: try coming up with real arguments ("X is better" is a bit light on details!) and ignore the need to rant about abusrd, cancer, etc.