Initd was forcing people to process management the single box (Unix / NT) way.
WOW, no. Init was/is happy to get out of the way if you want to do process management. It even got out of my way when I built bproc clusters (global pid space, signals work across nodes, executables reside on the master and actually fork onto their assigned node. I do know a bit about this.
The rc scripts for those nodes actually ran on the master starting system daemons on the slave nodes.
Init wouldn't even get upset if systemd wanted to actually be a process manager and have init start it.
No. Changing runlevels is shutting process down and breaking potential dependencies. That isn't suspending or hibernating them.
So systemd is entirely inadequate? Because that's all it currently offers.
I don't agree it can't replace syslogd.
One day, it might, but for today syslogd can log remotely and journald can't.
If forward looking statements are good enugh, I claim that space goilg faeries will soon enhance inity so that it actually reads your mind and writes and runs programs to do exactly what you want, when you want it:-)
But in the real world, things systemd is "going to do one day" don't count today.
As for failing to innovate you can't see the irony here in your defense of initd?
You keep missing that I do advocate for a better system, and only claim that init does well enough today that we're better off sticking with it until it's all sorted out. Mostly, I just want an init that won't actively hinder development of a superior solution by insisting that only it can be in control at all times.
Ultimately I would like a well designed management system and that is not systemd.
The problem is, most of those 'features' are actually missing from systemd. They might be planned but they are conspicuously absent today.
I have seen that some of the dependencies are also not really there. My bad for believing the systemd project's claims.
So why were you so happy to have gtk depend on gimp? It is both silly and counterproductive.
But it seems you found sysvinit's power management (or should I say it's non-management, it just passes the events along to something that's good at it) to be acceptable at least. And it sounds like the older, simpler distros worlked better than the ones with dbus and gnome and such with consolekit and policykit. One like I am advocating, in fact (though I don't mind console and policy kit so much, they stay out of my way).
Consider, what will you do if systemd makes a bigger hash of it on your preferred hardware? Go back to the older stuff that worked, of course. But for some reason you can't get the GUI desktop to come up any more. I guess it depended on systemd which fails miserably on your laptop.
So logind has managed to do what sysvinit does? That doesn't sound like a reason to screw up the whole system. Why do you claim that power management on sysvinit sucks but suddenly you think it's great when systemd does the same thing no better?
It seems to me that all of the great things systemd 'does' are forward looking statements and can be done better and less intrusively.
Sort of. Process need to start and stop around power, that's process management.
So change runlevels? If only sysv could change runlevels...
Well first off the log is queried if things are going reasonably well. Also it can forward via. a systemd daemon.
Too bad people typically need to diagnose failure when the system has failed. Seems like a good reason to just use syslogd. Now ask yourself, they clearly know how to speak syslogd's language, and clearly journald can't actually replace syslogd in the scenarios they claim excellence in, so why not speak syslogd all around and make journald a separate and optional component?
The commercial Unixes failed because the sellers demanded too much money for them and failed to innovate. Linux didn't piss in the well by coercing distros into switching. Linux didn't come up with a dirty deal to make gcc depend on the Linux kernel and make X depend on gcc in order to make it too much work to maintain solaris without the linux kernel. Linux (along with *BSD) won on merit. Perhaps systemd needs more merit and less pissing.
As for Gnome1, it didn't do any such thing. Gnome 1 was reasonably interoperable. Gnome apps worked fine in other desktop environments. Non gnome apps worked (and still work) in Gnome. Nothing broke if you installed it. For all the faults in Gnome 3, KDE/Qt apps still run and Gnome/GTK apps still run in KDE.
Systemd could clearly go that route but has deliberately chosen the obnoxious route. It is either incompetence or political in nature. Take your pick. I suspect political.
I used to be able to say that. My 2012 rMBP doesn't boot at all with most distributions and when I can get it to boot all sorts of software doesn't work. Mind you this one of the most popular x86 laptops around. But more importantly power management didn't work well ever.
An Apple product meant for OSX doesn't work perfectly with linux? What makes you think systemd will fix it?
If you think your laptop is challenged now, I can only imagine how fast it would crap out if GTK required gimp (note, GTK = Gimp Tool Kit, Gnome came later) I can just see it now, you wait for half an hour while a paintbrush renders the desktop by painting it with a brush. Cool demo, crappy GUI.
Systemd and free desktop need to just go off and finish their Windows 8 clone and leave the Linux community.
They design a search engine that implements their wet dream for them and then because they are what they are, they make sure nobody will use it by slapping a patent on it! They are their own worst enemy!
No it didn't. Power management has been a consistent problem with Linux for 2 decades. Even when shutdown and restart work reliably, which is not guaranteed, the best distributions on the best hardware still run for less time due to making poor power choices. Power management is the kind of legacy of failure that is driving people to abandon the initd approach.
I don't see systemd doing any power management at that level. None at all, in fact. That would be a 'forward looking statement'. Perhaps they'd care to give a call when it actually does something. But more to the point, power management is orthogonal to init.
If you want the logger to know more, then tell it more. But a logger is supposed to LOG messages, not generate them. If you want to know node status, you don't dig through logs, you run something like ganglia that tells you the current state of the node. I use that on a number of clusters and get quite detailed information without making anything dependent on it. BTW, if the logger can't log to something outside of the node, it is worthless for diagnosing a failure of the node.
I can see some value to a database of logs in some cases. I even wrote a log server that accepts events from syslog-ng and puts them in a database in addition to the text file form. Naturally, it is completely init system agnostic, as a logger should be.
If you want to dispatch jobs, use SLURM or similar. The HPC world has been doing that for a long time. Cluster schedulers can even power nodes off when not needed and on when there is work to be done.
How is that different than anything else in open source? That's what Linux did to the commercial Unixes.
How so? I can't think of a single instance where any part of GNU/Linux threatened to break something working fine in (for example) Solaris. All it did is say, we're here, check it out if you want, and then waited. Nobody tried to cram Linux down anyone's throat.
That's what Gnome and KDE both tried to do.
GNOME certainly has tried such crap (what a surprise, it's also associated with systemd!). That's why there are now two forks. You might have noticed that there isn't a lot of love for gnome 3. As far as I know, KDE hasn't drunk that particular cool aid.
As hor the rest, to paraphrase, it will be crammed down your throat and fuck you if you don't beg for more.
That's why there's a group ready to say fork you!
I want a well designed management system for my servers, workstations and embedded devices. That's why I will not be using systemd in it's current form. You may just want feature, feature, feature even if it is crappy in implementation and brittle, but that won't cut it for me. Fingers out of my pie.
There is no way he SHOULD have, but SHOULD and DID are different things. I have seen bizarre things happen when a minor government official finds hhimself in a position of power.
I have no idea if that was or was not the case but the era of assuming government officials must know what they're doing and and be doing what's right died a long time ago.
Funny thing, my Linux desktops boot right every time. My laptop boots right every time. My embedded linux systems boot right every time (and they better, I can't exactly plug a crash cart in if they don't come up). My Linux servers come up fine every time. The only reason they don't do it every day is that I don't boot them every day. Where are these systems that won't boot?
The problem with systemd is that it refuses to be a framework, it wants to be all or nothing. Had they designed a framework and the system that uses that framework (think gtk and gimp), both could have been something. Do you thing gtk could ever have become the popular GUI toolkit that it is if it had a dependency on gimp?
I don't expect systemd to magically understand a new cgroups API, but I do expect it to get out of the way long enough to develop something that can handle the necessary API change. It's a good thing sysvinit exists because systemd won't even give you the opportunity to mount the new cgroup fs. Being able to at least boot a test system helps a great deal.
But as far as that goes, the systemd project wants to push cgroups to allowing only one process in the system to work with it. Imagine that, they nominate systemd for that role. They speak of it as if it is fait accompli. There are good reasons to re-do the API, but none to make systemd the only writer. Looking at the latest kernel, it looks like cgroup is instead moving to provide greater ability to independently manage subgroups (as it should be)
But just to be quite clear, I only support staying with sysvinit for now. It is currently adequate and won't get in the way of an appropriate framework.
Sure, anything could have happened including alien abduction (yes, kidding:-) but in this case it was an inflexible fire marshal. Why not escourt the parent to the child and then escort both from the building?
Lame excuses at BEST. The dependency in logind was hacked out by a third party. I gotta wonder, power management worked when sysvinit was on the job and there wasn't a logind at all. What happened? The actual existence of another less dependency laden way to do it suggests that such a way exists, yes?
That's how all of it has gone so far. Functionality isn't going away, just the hairball.
The logger isn't supposed to know or care about the status of the system, it's clients know and they send messages about it which the logger logs.
The purpose of udev is to add and remove device nodes and links in/dev in response to kernel messages about hardware being plugged in and out and in accordance with rules. It has been doing that since before systemd was an idea and should continue as it was. It doesn't care about processes at all and it shouldn't.
Note that systemd does not have any node management. It only knows what it is doing on that one machine. There is no cluster management in systemd. So if node 56 can't keep T running, all systemd can do is keep kicking T and have it fail again. Unlike systlog-ng, journald doesn't do remote logging, so it can't tell anyone about the failures.
But again, uselessd isn't losing functionality, it is moving it to where it belongs (that is, NOT in init). The architecture of systemd is piss poor and needs major revision. The first step is to cut things down to essentials.
A final point with the political nature, even knowing fully well that external dependencies are a sore point, rather than playing them down, the systemd supporters are talking them up to give the impression there will be an unacceptable amount of breakage if you don't switch to systemd now (switch now or kittend gets it!). That's disgusting.
Which action burns more developer time? Staying the same or making changes to accommodate systemd?
I'm betting that one notice that packages relying on systemd would go to the if someone gets around to it dungeon, a lot would decide against dependency.
Actually, unlike a lot of the think of the children crap, separating parents and children that way is a really really bad idea. It is a bad idea for perfectly rational reasons.
Systemd replaces them poorly and incompletely at a huge cost.
I would rather see a neater more standardized framework for process control and dependency management if it is that important (how important can it be, millions of systems boot fine every day). Those can work as long as systemd doesn't munge it up by getting in the way (for example, by deciding that/sys/fs/cgroup belongs to it exclusively the way they are trying to steer things). Imagine, if I want to mount cgroups with the new unified hierarchy, systemd won't even try to boot the system. It's a good thing sysvinit is there!
Now you're starting to see one of the reasons the hairball in systemd is so well despised. There are MANY choices available in Debian right now that cause no problem at all because the dependencies are well managed and kept to a minimum.
Done right, it should be possible to switch by changing the kernel boot command setting init=/sbin/sysvinit or init=/sbin/systemd. Note that switching an existing system from one to another might fairly be considered an experts only option due to the likely need for some fix-ups, but should be possible. Unless, that is, systemd demands or strongly encourages (one might say insists) that a bunch of system utils and software bow to it and become co-dependent such that hardly anything works if systemd isn't there.
It shouldn't be necessary to fork it to avoid systemd, but if that's what it comes to, I do support a fork. I don't think that's very hard to understand.
It would be a lot easier to leave Debian as was and just have an add-in repo for those who want a systemd setup than it is to do it the other way.
Better still would be to make systemd a true option and make sure nothing depends on it specifically. Hopefully the GR to that effect will carry the day.
No, but it does move the day underneath the PHB who's not happy till you're not happy. That is the actual problem, employers who believe changing business hours will bring a plague of locusts and the end of time.
Actually no. It was a list of ways it knows/guesses that the service being started has actually finished starting. Presumably, it knows a service stopped when it's assigned cgroup is empty but has no idea if the daemon gets wedged without crashing.
There is nothing irrational about rejecting complexity for complexity's sake nor with rejecting kitchen sink style dependencies in software.
But speaking of irrational, every time I try to pin a systemd supporter down on why the architecture is at all acceptable or what benefits it actually offers over less intrusive changes, they never seem to come up with an answer.
They may not automatically restart or reconnect. They don't get notified E has restarted.
If they can't tell the services are down, then they must not depend on them.
That won't work either. Remember F and D are communicating in this scenario. I think if we go enough rounds you will come up with a working solution. But what you would be doing is building the requirement for process management in the init system. Once you accept that process management needs to be in the init then init is out.
If that can't work, then the machine could never have booted in the first place.
Given the large number of people who support one of OpenRC, upstart, or just keep what we have, there are plenty to choose from. The only reason there is any question of choice is that systemd is designed to be a glueball th stick it in place. Note that OpenRC is certainly not dead. Upstart is effectively abandoned at this point, but it's not like it no longer exists.
The thing is, the dependencies don't actually make any sense. They only exist because of coding for political purposes. It's like requiring a degree in zebra training before you can get your drivers license.
Actually, launchd is quite different and nowhere near as objectionable from an architecture standpoint.
You should know that the debate continues in Debian.
Slashdot Mirror
Initd was forcing people to process management the single box (Unix / NT) way.
WOW, no. Init was/is happy to get out of the way if you want to do process management. It even got out of my way when I built bproc clusters (global pid space, signals work across nodes, executables reside on the master and actually fork onto their assigned node. I do know a bit about this.
The rc scripts for those nodes actually ran on the master starting system daemons on the slave nodes.
Init wouldn't even get upset if systemd wanted to actually be a process manager and have init start it.
No. Changing runlevels is shutting process down and breaking potential dependencies. That isn't suspending or hibernating them.
So systemd is entirely inadequate? Because that's all it currently offers.
I don't agree it can't replace syslogd.
One day, it might, but for today syslogd can log remotely and journald can't.
If forward looking statements are good enugh, I claim that space goilg faeries will soon enhance inity so that it actually reads your mind and writes and runs programs to do exactly what you want, when you want it :-)
But in the real world, things systemd is "going to do one day" don't count today.
As for failing to innovate you can't see the irony here in your defense of initd?
You keep missing that I do advocate for a better system, and only claim that init does well enough today that we're better off sticking with it until it's all sorted out. Mostly, I just want an init that won't actively hinder development of a superior solution by insisting that only it can be in control at all times.
Ultimately I would like a well designed management system and that is not systemd.
The problem is, most of those 'features' are actually missing from systemd. They might be planned but they are conspicuously absent today.
I have seen that some of the dependencies are also not really there. My bad for believing the systemd project's claims.
So why were you so happy to have gtk depend on gimp? It is both silly and counterproductive.
But it seems you found sysvinit's power management (or should I say it's non-management, it just passes the events along to something that's good at it) to be acceptable at least. And it sounds like the older, simpler distros worlked better than the ones with dbus and gnome and such with consolekit and policykit. One like I am advocating, in fact (though I don't mind console and policy kit so much, they stay out of my way).
Consider, what will you do if systemd makes a bigger hash of it on your preferred hardware? Go back to the older stuff that worked, of course. But for some reason you can't get the GUI desktop to come up any more. I guess it depended on systemd which fails miserably on your laptop.
The what?
So logind has managed to do what sysvinit does? That doesn't sound like a reason to screw up the whole system. Why do you claim that power management on sysvinit sucks but suddenly you think it's great when systemd does the same thing no better?
It seems to me that all of the great things systemd 'does' are forward looking statements and can be done better and less intrusively.
Sort of. Process need to start and stop around power, that's process management.
So change runlevels? If only sysv could change runlevels...
Well first off the log is queried if things are going reasonably well. Also it can forward via. a systemd daemon.
Too bad people typically need to diagnose failure when the system has failed. Seems like a good reason to just use syslogd. Now ask yourself, they clearly know how to speak syslogd's language, and clearly journald can't actually replace syslogd in the scenarios they claim excellence in, so why not speak syslogd all around and make journald a separate and optional component?
The commercial Unixes failed because the sellers demanded too much money for them and failed to innovate. Linux didn't piss in the well by coercing distros into switching. Linux didn't come up with a dirty deal to make gcc depend on the Linux kernel and make X depend on gcc in order to make it too much work to maintain solaris without the linux kernel. Linux (along with *BSD) won on merit. Perhaps systemd needs more merit and less pissing.
As for Gnome1, it didn't do any such thing. Gnome 1 was reasonably interoperable. Gnome apps worked fine in other desktop environments. Non gnome apps worked (and still work) in Gnome. Nothing broke if you installed it. For all the faults in Gnome 3, KDE/Qt apps still run and Gnome/GTK apps still run in KDE.
Systemd could clearly go that route but has deliberately chosen the obnoxious route. It is either incompetence or political in nature. Take your pick. I suspect political.
I used to be able to say that. My 2012 rMBP doesn't boot at all with most distributions and when I can get it to boot all sorts of software doesn't work. Mind you this one of the most popular x86 laptops around. But more importantly power management didn't work well ever.
An Apple product meant for OSX doesn't work perfectly with linux? What makes you think systemd will fix it?
If you think your laptop is challenged now, I can only imagine how fast it would crap out if GTK required gimp (note, GTK = Gimp Tool Kit, Gnome came later) I can just see it now, you wait for half an hour while a paintbrush renders the desktop by painting it with a brush. Cool demo, crappy GUI.
Systemd and free desktop need to just go off and finish their Windows 8 clone and leave the Linux community.
They design a search engine that implements their wet dream for them and then because they are what they are, they make sure nobody will use it by slapping a patent on it! They are their own worst enemy!
No it didn't. Power management has been a consistent problem with Linux for 2 decades. Even when shutdown and restart work reliably, which is not guaranteed, the best distributions on the best hardware still run for less time due to making poor power choices. Power management is the kind of legacy of failure that is driving people to abandon the initd approach.
I don't see systemd doing any power management at that level. None at all, in fact. That would be a 'forward looking statement'. Perhaps they'd care to give a call when it actually does something. But more to the point, power management is orthogonal to init.
If you want the logger to know more, then tell it more. But a logger is supposed to LOG messages, not generate them. If you want to know node status, you don't dig through logs, you run something like ganglia that tells you the current state of the node. I use that on a number of clusters and get quite detailed information without making anything dependent on it. BTW, if the logger can't log to something outside of the node, it is worthless for diagnosing a failure of the node.
I can see some value to a database of logs in some cases. I even wrote a log server that accepts events from syslog-ng and puts them in a database in addition to the text file form. Naturally, it is completely init system agnostic, as a logger should be.
If you want to dispatch jobs, use SLURM or similar. The HPC world has been doing that for a long time. Cluster schedulers can even power nodes off when not needed and on when there is work to be done.
How is that different than anything else in open source? That's what Linux did to the commercial Unixes.
How so? I can't think of a single instance where any part of GNU/Linux threatened to break something working fine in (for example) Solaris. All it did is say, we're here, check it out if you want, and then waited. Nobody tried to cram Linux down anyone's throat.
That's what Gnome and KDE both tried to do.
GNOME certainly has tried such crap (what a surprise, it's also associated with systemd!). That's why there are now two forks. You might have noticed that there isn't a lot of love for gnome 3. As far as I know, KDE hasn't drunk that particular cool aid.
As hor the rest, to paraphrase, it will be crammed down your throat and fuck you if you don't beg for more.
That's why there's a group ready to say fork you!
I want a well designed management system for my servers, workstations and embedded devices. That's why I will not be using systemd in it's current form. You may just want feature, feature, feature even if it is crappy in implementation and brittle, but that won't cut it for me. Fingers out of my pie.
There is no way he SHOULD have, but SHOULD and DID are different things. I have seen bizarre things happen when a minor government official finds hhimself in a position of power.
I have no idea if that was or was not the case but the era of assuming government officials must know what they're doing and and be doing what's right died a long time ago.
Funny thing, my Linux desktops boot right every time. My laptop boots right every time. My embedded linux systems boot right every time (and they better, I can't exactly plug a crash cart in if they don't come up). My Linux servers come up fine every time. The only reason they don't do it every day is that I don't boot them every day. Where are these systems that won't boot?
The problem with systemd is that it refuses to be a framework, it wants to be all or nothing. Had they designed a framework and the system that uses that framework (think gtk and gimp), both could have been something. Do you thing gtk could ever have become the popular GUI toolkit that it is if it had a dependency on gimp?
I don't expect systemd to magically understand a new cgroups API, but I do expect it to get out of the way long enough to develop something that can handle the necessary API change. It's a good thing sysvinit exists because systemd won't even give you the opportunity to mount the new cgroup fs. Being able to at least boot a test system helps a great deal.
But as far as that goes, the systemd project wants to push cgroups to allowing only one process in the system to work with it. Imagine that, they nominate systemd for that role. They speak of it as if it is fait accompli. There are good reasons to re-do the API, but none to make systemd the only writer. Looking at the latest kernel, it looks like cgroup is instead moving to provide greater ability to independently manage subgroups (as it should be)
But just to be quite clear, I only support staying with sysvinit for now. It is currently adequate and won't get in the way of an appropriate framework.
Sure, anything could have happened including alien abduction (yes, kidding :-) but in this case it was an inflexible fire marshal. Why not escourt the parent to the child and then escort both from the building?
Lame excuses at BEST. The dependency in logind was hacked out by a third party. I gotta wonder, power management worked when sysvinit was on the job and there wasn't a logind at all. What happened? The actual existence of another less dependency laden way to do it suggests that such a way exists, yes?
That's how all of it has gone so far. Functionality isn't going away, just the hairball.
The logger isn't supposed to know or care about the status of the system, it's clients know and they send messages about it which the logger logs.
The purpose of udev is to add and remove device nodes and links in /dev in response to kernel messages about hardware being plugged in and out and in accordance with rules. It has been doing that since before systemd was an idea and should continue as it was. It doesn't care about processes at all and it shouldn't.
Note that systemd does not have any node management. It only knows what it is doing on that one machine. There is no cluster management in systemd. So if node 56 can't keep T running, all systemd can do is keep kicking T and have it fail again. Unlike systlog-ng, journald doesn't do remote logging, so it can't tell anyone about the failures.
But again, uselessd isn't losing functionality, it is moving it to where it belongs (that is, NOT in init). The architecture of systemd is piss poor and needs major revision. The first step is to cut things down to essentials.
A final point with the political nature, even knowing fully well that external dependencies are a sore point, rather than playing them down, the systemd supporters are talking them up to give the impression there will be an unacceptable amount of breakage if you don't switch to systemd now (switch now or kittend gets it!). That's disgusting.
I plugged a laptop into a dumb TV and I get all of that and no Big Brother.
Take it back anyway because it must be defective. The voice commands don't work, you see...
Which action burns more developer time? Staying the same or making changes to accommodate systemd?
I'm betting that one notice that packages relying on systemd would go to the if someone gets around to it dungeon, a lot would decide against dependency.
What they are doing now is paying the danegeld...
Unless it wasn't actually overcapacity to begin with...
I have no idea if that's the case but it is a plausible explaination.
Actually, unlike a lot of the think of the children crap, separating parents and children that way is a really really bad idea. It is a bad idea for perfectly rational reasons.
Why did logind depend on systemd?
It apparently wasn't necessary since it was possible to rip that dependency out (by a third party).
Why isn't journald API compatible with syslog-ng? That would eliminate a lot of objections.
Why isn't it OK to just call systemd from sysvinit's /sbin/init?
Why is udevd being sucked into the repo with systemd?
Meanwhile, the uselessd project has managed to carve dependencies out left and right. It is not currently a large project.
Why in the world would PaaS need any of them?
Systemd replaces them poorly and incompletely at a huge cost.
I would rather see a neater more standardized framework for process control and dependency management if it is that important (how important can it be, millions of systems boot fine every day). Those can work as long as systemd doesn't munge it up by getting in the way (for example, by deciding that /sys/fs/cgroup belongs to it exclusively the way they are trying to steer things). Imagine, if I want to mount cgroups with the new unified hierarchy, systemd won't even try to boot the system. It's a good thing sysvinit is there!
Now you're starting to see one of the reasons the hairball in systemd is so well despised. There are MANY choices available in Debian right now that cause no problem at all because the dependencies are well managed and kept to a minimum.
Done right, it should be possible to switch by changing the kernel boot command setting init=/sbin/sysvinit or init=/sbin/systemd. Note that switching an existing system from one to another might fairly be considered an experts only option due to the likely need for some fix-ups, but should be possible. Unless, that is, systemd demands or strongly encourages (one might say insists) that a bunch of system utils and software bow to it and become co-dependent such that hardly anything works if systemd isn't there.
It shouldn't be necessary to fork it to avoid systemd, but if that's what it comes to, I do support a fork. I don't think that's very hard to understand.
It would be a lot easier to leave Debian as was and just have an add-in repo for those who want a systemd setup than it is to do it the other way.
Better still would be to make systemd a true option and make sure nothing depends on it specifically. Hopefully the GR to that effect will carry the day.
Because PHBs freak out about deviating from the holey hours but don't notice if we all change the clocks out from under them.
No, but it does move the day underneath the PHB who's not happy till you're not happy. That is the actual problem, employers who believe changing business hours will bring a plague of locusts and the end of time.
Actually no. It was a list of ways it knows/guesses that the service being started has actually finished starting. Presumably, it knows a service stopped when it's assigned cgroup is empty but has no idea if the daemon gets wedged without crashing.
There is nothing irrational about rejecting complexity for complexity's sake nor with rejecting kitchen sink style dependencies in software.
But speaking of irrational, every time I try to pin a systemd supporter down on why the architecture is at all acceptable or what benefits it actually offers over less intrusive changes, they never seem to come up with an answer.
They may not automatically restart or reconnect. They don't get notified E has restarted.
If they can't tell the services are down, then they must not depend on them.
That won't work either. Remember F and D are communicating in this scenario. I think if we go enough rounds you will come up with a working solution. But what you would be doing is building the requirement for process management in the init system. Once you accept that process management needs to be in the init then init is out.
If that can't work, then the machine could never have booted in the first place.
Given the large number of people who support one of OpenRC, upstart, or just keep what we have, there are plenty to choose from. The only reason there is any question of choice is that systemd is designed to be a glueball th stick it in place. Note that OpenRC is certainly not dead. Upstart is effectively abandoned at this point, but it's not like it no longer exists.
The thing is, the dependencies don't actually make any sense. They only exist because of coding for political purposes. It's like requiring a degree in zebra training before you can get your drivers license.
Actually, launchd is quite different and nowhere near as objectionable from an architecture standpoint.
You should know that the debate continues in Debian.