One of my neighbors awhile back had a sportbike, a 'crotch rocket' as they are called. Or rather, he had all the parts for one. They were usually somewhat disassembled, scattered around the house and front yard. He was constantly working on that thing, swapping parts in and out, and whenever I was willing to listen he would fill my ears with all the details, all the tiny little things he would try, to squeeze another 10th of a second out of some racetrack.
Which, presumably, he actually rode. At some point. In a year I think I saw the bike assembled and him on it twice.
Me, I had a pickup loaded with gear, and I put 50k miles on it that year.
The systemd fans seem to me more than a little like that neighbor - spending months to save seconds.
Where is this boot-time Olympics they are so concerned about, and how much is the prize worth?
Or just use a binary distribution produced by sane maintainers. I recommend slackware. No PAM, no systemd, no GNOME, none of this crap shoved down your throat, and no artificial barriers to discourage you from compiling whatever you want.
"There really is very little recourse other than starting your own lobby war to stop the bunch. Because the problem is mostly politican, the technical side is but a symptom, almost a sideshow."
While I will not discourage you from waging a lobbying war (in fact I must encourage you, WAR is indeed appropriate here) let me point out something else you can do. Switch to a distro that says no to this abomination. Vote with your feet.
"As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast."
This is the false postulate on which the entire thing is built. This guy thinks that the most important thing about an init system is how quickly it executes, and that is so fundamentally wrong I find myself wondering how the hell the author got himself a job he is clearly completely unqualified for. Does he imagine that all we linux users do with our systems is sit there with a stopwatch rebooting? Was he dropped on his head as a child? Inquiring minds want to know.
The most important things about an init system are that it accomplishes its task correctly, and that the configuration is human readable and easily edited with the most basic tools. The speed of startup is literally the least important thing about it - just one step up from does not matter at all. If you could speed my boot up to the point it was instantaneous, but the cost is a marginally less reliable system, it would be a very poor trade.
On a server your mean time between reboots should be around a year, but on a personal system you might shut down each night and restart in the morning, so let's assume that case, the best possible case for systemd. You will save, what, 5 seconds? Maybe 7 seconds if you are very very lucky. It takes me longer than that to walk to the fridge, get a drink, and walk back to my desk, which time I will be taking whether the system is ready more quickly or not. So it represents literally 0 possible advantage.
"To ask what benefits the additional almost-9x code brings (especially if the result is deemed inferior)?"
Guess what? A larger program is not necessarily better. The opposite is more likely to be true, in fact. A good designer knows that the job isnt finished when there is nothing left to add, it's finished when there is nothing left to remove.
Unfortunately we live in a world filled with so many poor designers that it's easy to forget that a good design is even possible.:(
Bullshit yourself. The ONLY reason a properly configured production linux box being competently administered is going to reboot is a critical kernel patch or hardware failure. Period, end of story.
Of course, if you have installed a bunch of crap designed with the same philosophy as we see in systemd and let it all run however it want, then yeah, you're misconfigured. Doh.
Quit blaming perfectly good tools for your own incompetence.
I think you should set your sights a little higher than that. RPM and SysV init are both overly complicated - what you are saying is that poison is ok with you in principle, just not quite so fast please.
"You cannot really make a system that consists of a bunch of shell scripts and have it work for a modern laptop where devices and network connections come and go, and you really want different things to run depending on whether you are at home or on the unencrypted airport wifi."
Sure you can. Try slackware ffs.
"SysV init needed replacing. It is just unfortunate that the replacement is systemd."
SysV init was a step in the wrong direction, systemd is a giant leap further down that road. But there are plenty of other good init systems. Slackware and Gentoo work just fine without either of them, and so do the BSDs.
You might should look at Slackware, you could get the best features of the BSDs and Linux combined. And it would be a real shame for an experienced developer to give up at this point - we need you!
Yes, linus shot that down for now although I would have been happier if he had done it earlier and more strongly. And yes, despite all the fanbois that are absolutely convinced they NEED misfeatures like socket activation, Slackware and Gentoo both have much better systems in place that seem to work just fine as far as I can tell.
"But its mixed up with udev, syslog and even gnome to some extent"
You could be accused of minimizing here. If I am not misinformed it actually require PAM!
Which makes sense I guess, one over-engineered pile of steaming refuse requires the other.
The only problem is the growing list of actually useful programs that are beginning to show up with dependencies to this junk.
There is a major effort here, not a hacking effort, a marketing effort, to force free software users to accept insecure garbage in order to keep our programs running.
In my first message I was chatty but I cited some. Anyway: cgroups, reliable mount handling (boot time barrier and during system uptime), socket and filesystem based activation. These features alone remove plenty of race conditions in services life cycle."
I dont see anything there that Slackware has ever given me a problem with. I know it supports cgroups, mount handling? You mean automounting removable drives on insertion? That was working for years before anyone ever heard of systemd.
On the other hand socket activation is not to the best of my knowledge supported, but I think that's a good thing. What a horrible hack! They took something very simple, logical, and robust (serial activation of services) and made it orders of magnitude more complicated, doubtless creating bugs that we will be discovering for many years to come in the process, and for what? To shave 5 seconds off a task that that you might need to do once a year? In what twisted alternate reality would this possibly seem like a good idea to anyone?
These features alone remove plenty of race conditions in services life cycle.
You know what is even more effective at removing race conditions? Serial activation. And all it costs is a few extra seconds in the rare event of a reboot.
"That kill apache, not the crap it started and that forked itself away."
I cant be completely sure here, but there is a funny pattern I have noticed over the years that may explain your experience. Over and over again, I hear about problems that require these over-engineered solutions from people running over-engineered distros that I just cannot reproduce using my (cleaner) system. So I suspect somewhere in your excessively complex system you have managed to break apache in a way that I cannot reproduce using a simpler system.
And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.
"Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me."
Why would I care? I dont use that system and am not affected by their bugs.
"That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best."
It's not anecdotal evidence it's an invention on your part. WTF? You lost the thread man.
"So in other words you do not like it because it looks and feels different than what you are used too with old inet."
No. Let me be very clear here. I dont like it because it is a bad idea. Nothing this complicated should ever be PID1, for starters.
Init could use a redesign, but a good redesign would look to reduce complexity, not increase it. It would give us something simpler and robust at PID1, not something that's larger and more complicated. And it sure as hell would not be something so complicated, over-reaching, and fragile that it brings your system to a halt when you pass 'debug' to the *kernel.*
Linus has been waaaaay too forgiving of this crap.
"Yes unix users are hardcore and do not like changes to things, but this isn't 1982 anymore where you had maybe 35 shell utils and programs total and you could all neatly manage it all in/etc/init.d like clockwork."
Granted init is over-complicated, the point remains that systemd moves in the wrong direction so this is not an argument in its favor.
That said, if you really cannot manage your init.d with just a tiny bit of effort, your system is clearly over-engineered and needs some simplification. A good design isnt done when there is nothing left to add, it's done when there is nothing left to *remove.* And similarly with a linux install - if you do not understand each and every thing that is happening in your startup sequence then it is time to start pruning it until you do.
"The linux ecosystem is extremely wide and there already mission critical environments that can benefit from reliability enhancements that are now possible with systemd. To stress it again: I'm taking about reliability features, not faster boot or fancy services status report."
I notice you stress it but you cannot actually cite such a feature concretely. I will give you the benefit of the doubt and assume there is something you could legitimately refer to as such - it would have certainly have to be really super to justify breaking all the other reliability features that go in the trash to get it.
"At the same time I conceive appliances where systemd is just not the right choice and something simpler and minimal should be used instead."
Great, you realize it's not always the right solution. Yet by supporting them you are advancing their goal of making themselves indispensable, of getting package after package rewritten to use them specifically so that more and more software becomes unavailable on sane systems. Even if you are ok with that on the desktop, dont you see how that will be biting your ass when you try to do something different?
"If you think sysv init is not broken, then you must not have been using unix systems in earnest."
SysV is broken, yes, and systemd is worse. I do not use or want either of them.
"BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?"
"the journal instead of a set of randomly formatted text-dumps all over/var/log,"
A huge regression. Replacing a simple, robust, well supported system with something overly complicated is NOT a gain for me.
"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
"a more secure system by being able to isolate daemons from one another and the rest of the system."
A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.
"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"
You REALLY seem confused now. You have the players backwards.
"First, I have to ask, what is wrong with systemd?"
It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.
If it were just a bad program, that's no big deal in and of itself, there are plenty, you just avoid them. But these people are not hackers, they have a marketing engine and are aggressively attempting to push themselves into a position where it WILL become impossible to avoid them and still use many new programs. That's beyond offensive. That's an attack on the Free Software ecosystem itself.
"The author is basically saying: we shouldn't take the risk of writing complex software."
No, he's saying you shouldnt write software that is more complex than it needs to be *for a critical system component* - and he's right. Get as complex as you want to be in your application, but things like init systems need to be taken more seriously.
"Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point."
You are wrong, and fundamentally wrongheaded.
"If there are things you don't like about it, trying to use an alternate init mechanism is only going to cause you personal grief that will likely only increase in severity over time as it gets harder and harder to retrofit software packages to use other init systems as systemd further embeds itself into the Linux software world."
And if we accept your advice we ensure that catastrophe. No thanks.
"If there are things you don't like about systemd, you should write up coherent bug reports or feature requests, and get them in front of the right people (once gain, someone jump in here and say who these people are and how to get these types of requests out there, I actually don't know). Or better yet, make the improvements to systemd yourself if you are capable of doing so."
This advice does not fit the situation at all. Bug reports and feature requests? You do not fix a fundamentally mis-specified and mis-designed program with bug patches and requests for even more misfeatures!
"Your goal should be to improve both systemd itself"
This makes no sense whatsoever. I dont want to 'improve' it I dont want it period. Init works great. It's not broken, dont fix it.
"By hook and by crook, systemd has become the standard way"
Negative. Init is the standard way. What's happened is that the number and visibility of the deviationists has increased. Popularity along is not sufficient to change a standard.
"If systemd is so onerous to you that you can't use Linux anymore"
Huh? Cant use linux? WTF are you talking about?
I am pretty sure that Linus has no plans to integrate this trash into the kernel. And if he did that would just mean it's finally time for a fork.
How about if it isnt broken, dont fix it? Isnt that still valid?
BSD init works great. First you want me to replace it with an overengineered monstrosity that offers me no benefit, and then when I refuse, you think *I* should fix it? Why? Why would I bother fixing it when I dont want or need it?
OK, fine, for the sake of argument let's say I should fix it. Easily done. Delete the whole damn tree, and replace it with init. Job done, let's get a beer.
Seconded. Slackware is the best. It's actually a fork from BSD init with a little code added to accommodate stupid applications that expect SysV IIRC. But whatever it is, it works wonderfully, it's simple, robust, and easy to work with. I dont understood why anyone would deliberately use anything else.
Slashdot Mirror
One of my neighbors awhile back had a sportbike, a 'crotch rocket' as they are called. Or rather, he had all the parts for one. They were usually somewhat disassembled, scattered around the house and front yard. He was constantly working on that thing, swapping parts in and out, and whenever I was willing to listen he would fill my ears with all the details, all the tiny little things he would try, to squeeze another 10th of a second out of some racetrack.
Which, presumably, he actually rode. At some point. In a year I think I saw the bike assembled and him on it twice.
Me, I had a pickup loaded with gear, and I put 50k miles on it that year.
The systemd fans seem to me more than a little like that neighbor - spending months to save seconds.
Where is this boot-time Olympics they are so concerned about, and how much is the prize worth?
Or just use a binary distribution produced by sane maintainers. I recommend slackware. No PAM, no systemd, no GNOME, none of this crap shoved down your throat, and no artificial barriers to discourage you from compiling whatever you want.
I do see the difference and I wouldnt have jumped on you like that, but since we are going here, cant you see how offensive your post was?
"There really is very little recourse other than starting your own lobby war to stop the bunch. Because the problem is mostly politican, the technical side is but a symptom, almost a sideshow."
While I will not discourage you from waging a lobbying war (in fact I must encourage you, WAR is indeed appropriate here) let me point out something else you can do. Switch to a distro that says no to this abomination. Vote with your feet.
From your link:
"As mentioned, the central responsibility of an init system is to bring up userspace. And a good init system does that fast. Unfortunately, the traditional SysV init system was not particularly fast."
This is the false postulate on which the entire thing is built. This guy thinks that the most important thing about an init system is how quickly it executes, and that is so fundamentally wrong I find myself wondering how the hell the author got himself a job he is clearly completely unqualified for. Does he imagine that all we linux users do with our systems is sit there with a stopwatch rebooting? Was he dropped on his head as a child? Inquiring minds want to know.
The most important things about an init system are that it accomplishes its task correctly, and that the configuration is human readable and easily edited with the most basic tools. The speed of startup is literally the least important thing about it - just one step up from does not matter at all. If you could speed my boot up to the point it was instantaneous, but the cost is a marginally less reliable system, it would be a very poor trade.
On a server your mean time between reboots should be around a year, but on a personal system you might shut down each night and restart in the morning, so let's assume that case, the best possible case for systemd. You will save, what, 5 seconds? Maybe 7 seconds if you are very very lucky. It takes me longer than that to walk to the fridge, get a drink, and walk back to my desk, which time I will be taking whether the system is ready more quickly or not. So it represents literally 0 possible advantage.
"To ask what benefits the additional almost-9x code brings (especially if the result is deemed inferior)?"
:(
Guess what? A larger program is not necessarily better. The opposite is more likely to be true, in fact. A good designer knows that the job isnt finished when there is nothing left to add, it's finished when there is nothing left to remove.
Unfortunately we live in a world filled with so many poor designers that it's easy to forget that a good design is even possible.
Bullshit yourself. The ONLY reason a properly configured production linux box being competently administered is going to reboot is a critical kernel patch or hardware failure. Period, end of story.
Of course, if you have installed a bunch of crap designed with the same philosophy as we see in systemd and let it all run however it want, then yeah, you're misconfigured. Doh.
Quit blaming perfectly good tools for your own incompetence.
"Any other thoughts?"
I think you should set your sights a little higher than that. RPM and SysV init are both overly complicated - what you are saying is that poison is ok with you in principle, just not quite so fast please.
"You cannot really make a system that consists of a bunch of shell scripts and have it work for a modern laptop where devices and network connections come and go, and you really want different things to run depending on whether you are at home or on the unencrypted airport wifi."
Sure you can. Try slackware ffs.
"SysV init needed replacing. It is just unfortunate that the replacement is systemd."
SysV init was a step in the wrong direction, systemd is a giant leap further down that road. But there are plenty of other good init systems. Slackware and Gentoo work just fine without either of them, and so do the BSDs.
Linux is just fine actually, it's only certain distros are continuing to break themselves.
You might should look at Slackware, you could get the best features of the BSDs and Linux combined. And it would be a real shame for an experienced developer to give up at this point - we need you!
Yes, linus shot that down for now although I would have been happier if he had done it earlier and more strongly. And yes, despite all the fanbois that are absolutely convinced they NEED misfeatures like socket activation, Slackware and Gentoo both have much better systems in place that seem to work just fine as far as I can tell.
"But its mixed up with udev, syslog and even gnome to some extent"
You could be accused of minimizing here. If I am not misinformed it actually require PAM!
Which makes sense I guess, one over-engineered pile of steaming refuse requires the other.
The only problem is the growing list of actually useful programs that are beginning to show up with dependencies to this junk.
There is a major effort here, not a hacking effort, a marketing effort, to force free software users to accept insecure garbage in order to keep our programs running.
I dont see anything there that Slackware has ever given me a problem with. I know it supports cgroups, mount handling? You mean automounting removable drives on insertion? That was working for years before anyone ever heard of systemd.
On the other hand socket activation is not to the best of my knowledge supported, but I think that's a good thing. What a horrible hack! They took something very simple, logical, and robust (serial activation of services) and made it orders of magnitude more complicated, doubtless creating bugs that we will be discovering for many years to come in the process, and for what? To shave 5 seconds off a task that that you might need to do once a year? In what twisted alternate reality would this possibly seem like a good idea to anyone?
You know what is even more effective at removing race conditions? Serial activation. And all it costs is a few extra seconds in the rare event of a reboot.
"That kill apache, not the crap it started and that forked itself away."
I cant be completely sure here, but there is a funny pattern I have noticed over the years that may explain your experience. Over and over again, I hear about problems that require these over-engineered solutions from people running over-engineered distros that I just cannot reproduce using my (cleaner) system. So I suspect somewhere in your excessively complex system you have managed to break apache in a way that I cannot reproduce using a simpler system.
And yet this is an argument for introducing yet more excessive complexity to remedy? Doesnt make sense to me.
"Systemd can set up filesystems without racing, something that is not possible with sysv init. No more races makes for a more robust boot. In fact systemd does address most of the race issues found in the debian init system. Go and check their bug tracker if you do not believe me."
Why would I care? I dont use that system and am not affected by their bugs.
"That you were unable to configure your system to make it boot with systemd is anecdotal evidence at best."
It's not anecdotal evidence it's an invention on your part. WTF? You lost the thread man.
"So in other words you do not like it because it looks and feels different than what you are used too with old inet."
/etc/init.d like clockwork."
No. Let me be very clear here. I dont like it because it is a bad idea. Nothing this complicated should ever be PID1, for starters.
Init could use a redesign, but a good redesign would look to reduce complexity, not increase it. It would give us something simpler and robust at PID1, not something that's larger and more complicated. And it sure as hell would not be something so complicated, over-reaching, and fragile that it brings your system to a halt when you pass 'debug' to the *kernel.*
Linus has been waaaaay too forgiving of this crap.
"Yes unix users are hardcore and do not like changes to things, but this isn't 1982 anymore where you had maybe 35 shell utils and programs total and you could all neatly manage it all in
Granted init is over-complicated, the point remains that systemd moves in the wrong direction so this is not an argument in its favor.
That said, if you really cannot manage your init.d with just a tiny bit of effort, your system is clearly over-engineered and needs some simplification. A good design isnt done when there is nothing left to add, it's done when there is nothing left to *remove.* And similarly with a linux install - if you do not understand each and every thing that is happening in your startup sequence then it is time to start pruning it until you do.
A sign of a broken browser.
If your browser is based on mozilla code then this may be all you need to fix it:
https://addons.mozilla.org/en-US/firefox/addon/refreshblocker/
"The linux ecosystem is extremely wide and there already mission critical environments that can benefit from reliability enhancements that are now possible with systemd. To stress it again: I'm taking about reliability features, not faster boot or fancy services status report."
I notice you stress it but you cannot actually cite such a feature concretely. I will give you the benefit of the doubt and assume there is something you could legitimately refer to as such - it would have certainly have to be really super to justify breaking all the other reliability features that go in the trash to get it.
"At the same time I conceive appliances where systemd is just not the right choice and something simpler and minimal should be used instead."
Great, you realize it's not always the right solution. Yet by supporting them you are advancing their goal of making themselves indispensable, of getting package after package rewritten to use them specifically so that more and more software becomes unavailable on sane systems. Even if you are ok with that on the desktop, dont you see how that will be biting your ass when you try to do something different?
"If you think sysv init is not broken, then you must not have been using unix systems in earnest."
SysV is broken, yes, and systemd is worse. I do not use or want either of them.
"BSD init is way simpler, true, but then that was deemed to be too inflexible already in the golden times of Unix. You really want to go back to that? Seriously?"
What go back? Never left.
"the journal instead of a set of randomly formatted text-dumps all over /var/log,"
A huge regression. Replacing a simple, robust, well supported system with something overly complicated is NOT a gain for me.
"a convenient way to kill apache with all the crap that it started,"
Something wrong with apachectl stop?
"a more robust boot process that is not sprinkled with sleep 5 statements to give daemons enough time to be fully up before bringing up services that depend on them being there."
You're confused, you actually getting a less robust boot process here. But it will be faster!
Well, ok. My computer boots fast enough without it, thanks.
"a more secure system by being able to isolate daemons from one another and the rest of the system."
A far less secure system actually. Without it, the only real attack front is sshd. With it, we suddenly have another front to worry about - and an attack here is likely to be much more damaging.
"a lot of convenient system config tools that work on (almost) all modern Linux distributions and do so even better that the "do one thing and do it well" tools that got replaced by them"
You REALLY seem confused now. You have the players backwards.
"Sheesh:-)"
Exactly.
"First, I have to ask, what is wrong with systemd?"
It's a massive, complicated, and very poorly behaved substitute for a simple, robust, and well behaved program. And it's not just a regular program, it is (if used as intended) a critical system component that will take your entire system down when it goes wrong.
If it were just a bad program, that's no big deal in and of itself, there are plenty, you just avoid them. But these people are not hackers, they have a marketing engine and are aggressively attempting to push themselves into a position where it WILL become impossible to avoid them and still use many new programs. That's beyond offensive. That's an attack on the Free Software ecosystem itself.
Indeed, Slackware is the standard by which others are to be judged - and usually found wanting.
"The author is basically saying: we shouldn't take the risk of writing complex software."
No, he's saying you shouldnt write software that is more complex than it needs to be *for a critical system component* - and he's right. Get as complex as you want to be in your application, but things like init systems need to be taken more seriously.
"Whether you love, hate, or are ambivalent about systemd, I think you have to accept it at this point."
You are wrong, and fundamentally wrongheaded.
"If there are things you don't like about it, trying to use an alternate init mechanism is only going to cause you personal grief that will likely only increase in severity over time as it gets harder and harder to retrofit software packages to use other init systems as systemd further embeds itself into the Linux software world."
And if we accept your advice we ensure that catastrophe. No thanks.
"If there are things you don't like about systemd, you should write up coherent bug reports or feature requests, and get them in front of the right people (once gain, someone jump in here and say who these people are and how to get these types of requests out there, I actually don't know). Or better yet, make the improvements to systemd yourself if you are capable of doing so."
This advice does not fit the situation at all. Bug reports and feature requests? You do not fix a fundamentally mis-specified and mis-designed program with bug patches and requests for even more misfeatures!
"Your goal should be to improve both systemd itself"
This makes no sense whatsoever. I dont want to 'improve' it I dont want it period. Init works great. It's not broken, dont fix it.
"By hook and by crook, systemd has become the standard way"
Negative. Init is the standard way. What's happened is that the number and visibility of the deviationists has increased. Popularity along is not sufficient to change a standard.
"If systemd is so onerous to you that you can't use Linux anymore"
Huh? Cant use linux? WTF are you talking about?
I am pretty sure that Linus has no plans to integrate this trash into the kernel. And if he did that would just mean it's finally time for a fork.
""If you do not like it, fix it" is still valid."
How about if it isnt broken, dont fix it? Isnt that still valid?
BSD init works great. First you want me to replace it with an overengineered monstrosity that offers me no benefit, and then when I refuse, you think *I* should fix it? Why? Why would I bother fixing it when I dont want or need it?
OK, fine, for the sake of argument let's say I should fix it. Easily done. Delete the whole damn tree, and replace it with init. Job done, let's get a beer.
Sheesh.
Seconded. Slackware is the best. It's actually a fork from BSD init with a little code added to accommodate stupid applications that expect SysV IIRC. But whatever it is, it works wonderfully, it's simple, robust, and easy to work with. I dont understood why anyone would deliberately use anything else.