> Well they should. Otherwise, what’s the point of them?
If the distribution is supposed to micromanage everything from upstream then what's the point of upstream?
> Of their own volition. And btw, distributions could patch them to work with systemd. None of this is systemd’s fault. Since when is it upstream’s job to make sure downstream properly integrates their software?
Since when does everything have to integrate with the init system at all?
> There’s no DNS server in systemd core. It just lives under the same umbrella.
It isn't a matter of which repository it's in, it's a matter of how much work it is to swap it out. Can I just run dnsmasq or dnscache and change an IP address somewhere, or do I actually have to change the code because it's expecting something more than a general purpose DNS resolver?
> Why would you need “many choices” for a simple timer? What are you going to do, invent new type of time?
An existing implementation has poor code quality and I can do better, but my new implementation is less feature complete, so some people prefer the one with more features while others prefer the one that has fewer bugs and uses less memory etc. etc.
> Because old style init did so little and so poorly, cron used to be a de facto service manager. Also don’t forget inetd.
Which they still are, because they're still there and there is nothing stopping people from using them in that way as ever.
But runit et al don't require that either, so let's not pretend that there is no third way.
> Why? If you can’t point to where the line is then what’s the point.
Your argument was that it's hard to know where to draw lines. But it's more important that you draw them somewhere than the specific place where you choose to draw them. Otherwise everything mushes together into a single piece of spaghetti that can't be disentangled from itself.
> Anyway most of systemd’s components communicate over a common system bus. You could provide alternatives just by speaking the same API.
Where are the RFCs for these APIs, so that I can write my application against the spec and be assured that it will continue to work against future versions of the software on the other end?
If you don’t like systemd so much then write something better. I mean you’ll find literally anything to dislike about it, I don’t get it. You can still use cron or rsyslog if you like. Or don’t use systemd. This is stupid. I’m done. The default makes sense for 99.99999% of users, literally the only point I was trying to make.
> If you don’t like systemd so much then write something better.
Writing something better doesn't get rid of the dependencies other projects now have on pieces of systemd, which pieces then have dependencies on other pieces until you need the whole thing.
> I mean you’ll find literally anything to dislike about it, I don’t get it.
This thread is about one specific complaint: It has too many interdependencies without well-specified stable interfaces between them, and actively encourages things to take on more of them, as with replacing SIGHUP handling with systemd-run.
> The default makes sense for 99.99999% of users, literally the only point I was trying to make.
This doesn't make any sense. Most applications don't handle SIGHUP and are terminated by the default handler. Applications that do handle it continue to run. If they used systemd-run instead they would also continue to run. Where is the benefit from forcing applications to do something systemd-specific and breaking existing things that don't?
If the distribution is supposed to micromanage everything from upstream then what's the point of upstream?
> Of their own volition. And btw, distributions could patch them to work with systemd. None of this is systemd’s fault. Since when is it upstream’s job to make sure downstream properly integrates their software?
Since when does everything have to integrate with the init system at all?
> There’s no DNS server in systemd core. It just lives under the same umbrella.
It isn't a matter of which repository it's in, it's a matter of how much work it is to swap it out. Can I just run dnsmasq or dnscache and change an IP address somewhere, or do I actually have to change the code because it's expecting something more than a general purpose DNS resolver?
> Why would you need “many choices” for a simple timer? What are you going to do, invent new type of time?
An existing implementation has poor code quality and I can do better, but my new implementation is less feature complete, so some people prefer the one with more features while others prefer the one that has fewer bugs and uses less memory etc. etc.
> Because old style init did so little and so poorly, cron used to be a de facto service manager. Also don’t forget inetd.
Which they still are, because they're still there and there is nothing stopping people from using them in that way as ever.
But runit et al don't require that either, so let's not pretend that there is no third way.
> Why? If you can’t point to where the line is then what’s the point.
Your argument was that it's hard to know where to draw lines. But it's more important that you draw them somewhere than the specific place where you choose to draw them. Otherwise everything mushes together into a single piece of spaghetti that can't be disentangled from itself.
> Anyway most of systemd’s components communicate over a common system bus. You could provide alternatives just by speaking the same API.
Where are the RFCs for these APIs, so that I can write my application against the spec and be assured that it will continue to work against future versions of the software on the other end?