6 ms·
> However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks. I'm curious what functionality
by korethr 10y ago
> However, linux is missing basic functionality other os's offer, and systemd is showing up and trying to fill in those blanks.
I'm curious what functionality other OSes had that Linux did not before systemd came along. It seems to me that it has been subsuming functions of other systems on Linux that were already present, as opposed to offering anything new.
Socket activation? inetd/xinetd.
Timed start of programs? Cron and At
Logging? rsyslog/syslog-ng/etc.
DNS? -- dnsmasq, powerdns, bind, etc.
Honestly, I think if system had stopped at doing init, and focused solely on that and doing the best damned possible job of it, there'd be less hate. I think what's pissing off a lot of the systemd haters is the scope creep of the project has undergone. I was personally fine with the idea of systemd when all it was promising was init and service management. But then oh, were going to take over /dev, and cron and logging, and logins and DNS and (to be determined). Ahh, thanks, but no thanks.
- bjourne 10y ago> I'm curious what functionality other OSes had that Linux did not before systemd came along. Uniform daemon/service handling. Just look at the scripts in /etc/init.d (or wherever they are located in your particular SysV init setup). It's a total mess. The rest of what systemd offers I can't comment on because I'm not familiar with it. But it is clear to me that systemd's declarative .service files are a billion times better than shell scripts.
- sp332 10y agoDidn't upstart and launchd cover this before systemd?
- justin_vanw 10y agoI don't know launchd, but upstart was a piece of crap that didn't even implement it's own documented functionality.
- Daviey 10y ago"piece of crap" really isn't fair. It powered many Ubuntu releases and Red hat 6. I liked upstart.
- rocqua 10y agoTrue, upstart wasn't good. It's existence rebukes the claim that systemd won because it was the only replacement for sysv.
- lsh 10y agoI liked upstart!
- rspeer 10y agoUpstart also had inscrutable crashing bugs, kind of like what this article describes about systemd, and it didn't even do as much.
- loeg 10y agolaunchd was for OSX.
- 5ilv3r 10y agoYou refuse to look, and thus have clarity. Dude that is not a good argument. What is not uniform about the previous service handling implementation in debian?
- bjourne 10y ago> You refuse to look, and thus have clarity. Dude that is not a good argument. What? Should I have to know everything about systemd to comment on one specific part of it? I don't know about alternative init systems either, all I wrote is that for service management: systemd >> SysV. > What is not uniform about the previous service handling implementation in debian? I can't tell you since I don't use Debian. I can tell you that in Ubuntu there are lots of inconsistencies. Like different service scripts respond differently to the help command. Even the "status" commands output varies between scripts. This means there is no way to introspect a service to know if it supports things like the "restart" command or if "stop" and then "start" should be used instead. This also means that making a robust GUI tool for handling services becomes hard/impossible.
- 5ilv3r 10y agoUbuntu has used a different init system each time for the last 3 LTS releases. It's only bad because they keep changing it!
- pdkl95 10y ago> systemd >> SysV Why are you framing the conversation as if these were the only options? > I don't know about alternative init systems either Oh, so you are speaking from ignorance. I suggest learning about the alternatives such as OpenRC and the management tools such as daemontools, runit, and s6. There are many solutions to these problems, although they may not be supported (by default?) in your favorite distro. Judging the Linux ecosystem by the failings of one distro isn't helpful.
- bjourne 10y agoDon't be obtuse and don't misunderstand on purpose. It is very clear that I compared SysV vs. systemd in their service/daemon management capabilities and nothing else.
- regularfry 10y agoIt might be better than the shell scripts that were there. It's not better than the shell scripts that could have been there.
- justin_vanw 10y agoSince shell scripts are Turing complete...
- pdkl95 10y agoWhile it is very important to avoid Turing completeness in some areas such as anything going over a network, daemon start needs flexibility for non-standard use cases. Limiting startup scripts wouldn't protect against much anyway, because it would only defer problems into the daemon you are starting up.
- dijit 10y agoI'm definitely not claiming that openBSD has an awesome init system but _all_ my init files look like this: #!/bin/sh # # $OpenBSD: apmd,v 1.1 2011/07/06 18:55:36 robert Exp $ daemon="/usr/sbin/apmd" . /etc/rc.d/rc.subr rc_reload=NO rc_cmd $1 there's also SMF, or runit, or any of the other dozens of init systems which solved the issue you have with consistency, they also solved other problems like socket activation which people wanted in init for some reason.
- kakwa_ 10y agoThe messier part of the old sysinit V was dependency handling, LSB headers are just an horrible hack and do a very poor job at it. However, imho, shell scripts are great for that kind of work. Services come in all sort of shapes, some are proper daemons (fork, cd /, close([stdin, stdout, stderr]) and the rest), some are a little worse to say the least. And more often than not, the later is your super business critical important app built in house by incompetent developers. The point being that services comes in all forms and shapes, and having a scripting language for integrating them and, if needed, compensating for crappy software is extremely useful. Another aspect is that programs contain bugs, and the more complex a program is, the more bugs it contains. Keeping PID 1 as simple as possible should be a goal, nobody needs an http server inside its init system (or a dhcp client, or a dns resolver or...). For some years now, the Gentoo Project has OpenRC/runscript (specialized shell for init scripts). It works really really well and it's quite simple to write an init script in it. It's a bit sad that it wasn't more considered in other distributions.
- justinsaccount 10y ago> proper daemons (fork, cd /, close([stdin, stdout, stderr]) and the rest), some are a little worse to say the least. And more often than not, the later is your super business critical important app built in house by incompetent developers. "proper daemons" are broken by design. Perhaps your "incompetent developers" know something that you don't? https://cr.yp.to/daemontools/faq/create.html https://cr.yp.to/daemontools/faq/create.html How can I supervise a daemon that puts itself into the background? When I run inetd, my shell script exits immediately, so supervise keeps trying to restart it. Answer: The best answer is to fix the daemon. Having every daemon put itself into the background is bad software design.
- bjourne 10y agoAre you saying that there are a lot of daemons out there that doesn't fit into systemd's declarative architecture? If so, the daemons could be fixed or systemd could be extended to cater for "not perfectly written" daemons. On the other hand if the daemon is written by incompetent developers and is doing very stupid stuff then it is a good thing that it doesn't fit. The developers will have an incentive to fix their broken code. And even with systemd it is possible to run arbitrary shell scripts at startup (afaik) which could start the daemon so they aren't totally out of luck. > For some years now, the Gentoo Project has OpenRC/runscript (specialized shell for init scripts). But is a scripting language really needed for daemon management? If the answer is no, then a more limited configuration language (systemd's .service files) is better.
- JdeBP 10y ago> > I'm curious what functionality other OSes had that Linux did not before systemd came along. > Uniform daemon/service handling. As others have pointed out, Linux did not lack this, and there were quite a number of systems that provided such on Linux.
- deleted 10y ago[deleted]