- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
The Story Behind ‘init’ and ‘systemd’: Why ‘init’ Needed to be Replaced with ‘systemd’ in Linux
|
|
|
Comments (92)
72 earlier comments in the full thread.
@penguinist
> Are we sure that the only processes launched are those described in the declaration files?
I think that's quite an unjustified criticism. By that token all code of system utilities should be shell scripts and nothing else. Reviewing medium and large shell script is itself not an simple task. Not to mention that you have to assume that shell script itself does not launch more than it says and the host of other utilities it launches.
> How can we know and verify that?
That holds for all code not just systemd. You have the source and so peer review is the guarantee which is the same as it is for all open source projects. How do you know bash does not execute more than what its script says -- have you verified bash code (its a large beast itself)? How do you know the same about the multitude of utilities in coreutils? How can you say that sysvinit is just launching the shell scripts mentioned in /etc/rc*/* and nothing else? In fact have you actually compared the number of lines of code of all the utilities, scripts that systemd replaces with that in systemd? Given the design, it looks very likely that the number of lines of code in systemd would actually be smaller or equivalent to all those it replaces while still providing many additional features that are required.
Yes, one can say that the code is still very young and so less tested, but then that will be true of all new software and nothing unique to systemd. As I mentioned on first glance it looks like systemd is trying to do too much which could be left to other existing utilities which is a valid criticism. However, I would need to look deeper to form an opinion on that.
> As I said earlier, systemd is not as transparent as the system it is intended to replace.
It seems that the only thing that would make it "transparent" to you is reverting back to using shell scripts because it would somehow give more "power" than simple configuration files. Quite obviously systemd devs do not agree. And you could always move away such systemd utilities where you think would be able to do better than systemd and write own shell scripts instead. Its still a simple job to plug-in your own shell scripts in systemd. I am pretty sure that the amount of code you will need to review to ensure "ExecStart=" does what it purports is very small -- smaller that sysvinit code I suppose.
> Are we sure that the only processes launched are those described in the declaration files?
I think that's quite an unjustified criticism. By that token all code of system utilities should be shell scripts and nothing else. Reviewing medium and large shell script is itself not an simple task. Not to mention that you have to assume that shell script itself does not launch more than it says and the host of other utilities it launches.
> How can we know and verify that?
That holds for all code not just systemd. You have the source and so peer review is the guarantee which is the same as it is for all open source projects. How do you know bash does not execute more than what its script says -- have you verified bash code (its a large beast itself)? How do you know the same about the multitude of utilities in coreutils? How can you say that sysvinit is just launching the shell scripts mentioned in /etc/rc*/* and nothing else? In fact have you actually compared the number of lines of code of all the utilities, scripts that systemd replaces with that in systemd? Given the design, it looks very likely that the number of lines of code in systemd would actually be smaller or equivalent to all those it replaces while still providing many additional features that are required.
Yes, one can say that the code is still very young and so less tested, but then that will be true of all new software and nothing unique to systemd. As I mentioned on first glance it looks like systemd is trying to do too much which could be left to other existing utilities which is a valid criticism. However, I would need to look deeper to form an opinion on that.
> As I said earlier, systemd is not as transparent as the system it is intended to replace.
It seems that the only thing that would make it "transparent" to you is reverting back to using shell scripts because it would somehow give more "power" than simple configuration files. Quite obviously systemd devs do not agree. And you could always move away such systemd utilities where you think would be able to do better than systemd and write own shell scripts instead. Its still a simple job to plug-in your own shell scripts in systemd. I am pretty sure that the amount of code you will need to review to ensure "ExecStart=" does what it purports is very small -- smaller that sysvinit code I suppose.
> Quite obviously systemd devs do not agree.
Quite. In fact, I doubt the systemd devs and the boycott systemd folks agree on much of anything.
> Its still a simple job to plug-in your own shell scripts in systemd. I am pretty sure that the amount of code you will need to review to ensure "ExecStart=" does what it purports is very small -- smaller that sysvinit code I suppose.
Again, if I'm going to opt out of all of it's "features", exactly why am I running systemd?
Quite. In fact, I doubt the systemd devs and the boycott systemd folks agree on much of anything.
> Its still a simple job to plug-in your own shell scripts in systemd. I am pretty sure that the amount of code you will need to review to ensure "ExecStart=" does what it purports is very small -- smaller that sysvinit code I suppose.
Again, if I'm going to opt out of all of it's "features", exactly why am I running systemd?
Jase,
> They are trying to replace something simple (whether broken or not), with something complex. And, there's little to no benefit from doing that.
Thank you for that table. While I had the impression which the table articulates, seeing it in cold hard numbers only makes me even more uncomfortable with the change.
Sadly, it seems that the change in going to be occurring regardless. My hope is that by spreading it wide the problems are ironed out quickly so people can get back to work.
I now look forward to whatever it is that is going to replace systemd. Maybe after the singularity when such things are written by the AI herself.
> They are trying to replace something simple (whether broken or not), with something complex. And, there's little to no benefit from doing that.
Thank you for that table. While I had the impression which the table articulates, seeing it in cold hard numbers only makes me even more uncomfortable with the change.
Sadly, it seems that the change in going to be occurring regardless. My hope is that by spreading it wide the problems are ironed out quickly so people can get back to work.
I now look forward to whatever it is that is going to replace systemd. Maybe after the singularity when such things are written by the AI herself.
@krisum
"So distributions have simply replaced sysv with upstart or systemd etc. What is new about systemd here? It was never possible to have a distribution work against multiple init systems (except for very select few like Gentoo)."
True, but we have a different situation now. Given the controversy, I think it would be a great idea. I don't think it would be that hard to make different packages. On the contrary, I think the resistance against systemd would subside if people were given a chance to simply ignore it if they wanted. Let the bazaar decide.
Quoting:``This makes parallelizing services difficult, and even if someone were to write init scripts that run in parallel, they would be very brittle and a nightmare to maintain in the face of upgrades etc (unless one embeds own dependency logic that is).''Parallel startup scripts was never a really important need until some people got obsessed with this faster startup kick. Which, to me, is about as important as `which OS can format a floppy disk faster' that was the craze in the early days of the PC. Faster startup is only important to a few. (I care about it only when I'm using a laptop, for example, which isn't all the time.) I suspect most people don't really care. Rather than abandoning the traditional sysvinit for something that's not well documented and has insinuated itself into major subsystems of Linux just because someone thinks that parallel startup is absolutely necessary -- and for laptop use that's certainly a nice thing to have -- I'm of the opinion that faster startup would have been better achieved by making the hibernate function more reliable so that a complete reboot wouldn't be necessary. But a developer doesn't make as big a splash by working on something as mundane as that.
> ...just because someone thinks that parallel startup is absolutely necessary -- and for laptop use that's certainly a nice thing to have...
My Dell Mini-9 had a 30 second or so boot time back when it shipped with Ubuntu 8.04. It's never been that significant an issue.
My Dell Mini-9 had a 30 second or so boot time back when it shipped with Ubuntu 8.04. It's never been that significant an issue.
@jdixon
You're so right. I'm running a six-year old, very tired system and it does 90 secs. That doesn't bother me too much. Booting Windows7 (at least from a network) take MUCH longer. I've seen 20 MINS boot time from a WinXP system (iron, no VM, corporate use). Why? Because I boot once a day, in the morning. It's not an issue, so I don't see why people are focused on it that much - apart from beating MS. Yeah, it's great fun when slapping MS-fanbois, but else.. No, what I'm worried about is how happy SuSE users were when systemd was introduced (https://news.opensuse.org/2011/12/22/systemd- %E2%80%93-boot-faster-and-cleaner-with-opensuse-12-1/) and how much speedier their system got (http://www.phoronix.com/scan.php?page=news_item&px=MTAxNzA). Adding all that: what exactly is systemd trying solve? I only see LOTS of problems I'm not waiting for. It's like getting an electronic transmission that in the end isn't doing any faster - for what? I can't speed out the garage anyway - that requires me to learn all kinds of different shift positions and additional buttons I'll probably never care to use and on top of it doesn't get out of the first gear.
> Besides, I think the number of lines is quite misleading. It includes replacements for many utilities like mount etc
Replacement for "mount"? Seriously? <splutters on keyboard>
Why on earth would systemd need a replacement for mount? Are you sure?
Replacement for "mount"? Seriously? <splutters on keyboard>
Why on earth would systemd need a replacement for mount? Are you sure?
> On a related note, last month Martin Gräßlin made a post about kwin-wayland requring logind and states that logind can be run independent of systemd. I just felt his post (this one, not his previous self-trolling post) was an insightful look into why they had the dependency and the benefit provided by logind to KWin on Wayland.
It has always been that Unix and Linux base philosophy is that subsystems co-operate based on standards not on code dependencies. So they use pipes, shared memory, kernel facilities etc. rather than requiring the direct dependency of a specific implementation.
The alternative which is called "coupling" in the computing realm is generally felt to be the sign of poor design.
It is sad that the youngsters these days seem to be intent on ignoring the sage wisdom of some very clever people from the last 30 years.
It has always been that Unix and Linux base philosophy is that subsystems co-operate based on standards not on code dependencies. So they use pipes, shared memory, kernel facilities etc. rather than requiring the direct dependency of a specific implementation.
The alternative which is called "coupling" in the computing realm is generally felt to be the sign of poor design.
It is sad that the youngsters these days seem to be intent on ignoring the sage wisdom of some very clever people from the last 30 years.
Skel,
>Replacement for "mount"? Seriously? <splutters on keyboard>
Yep. Now you're seeing the violence inherent in the systemd.
For example, from http://www.tecmint.com/systemd-replaces-init-in-linux/
o Job Scheduling using systemd Calendar Timers.
No more cron. So much for supreme executive powers deriving from a mandate from the masses.
o Logs are stored in binary file.
No more browsing easily with standard tools on the console through a log to see what went wrong. I said, Be Quiet!
o Users login managed by systemd-logind.
The Lady of the Lake, her arm clad in shimmering samite, brought forth Excalibur from the bosom of the water. That is why I am your King.
o Better integration with Gnome for interoperability.
Integration with ONE DESKTOP ENVIRONMENT (which I don't use) is being called "interoperability", which is exactly opposite of reality. This is Cathedral thinking at its WORST.
Or, "You don't vote for a King!"
>Replacement for "mount"? Seriously? <splutters on keyboard>
Yep. Now you're seeing the violence inherent in the systemd.
For example, from http://www.tecmint.com/systemd-replaces-init-in-linux/
o Job Scheduling using systemd Calendar Timers.
No more cron. So much for supreme executive powers deriving from a mandate from the masses.
o Logs are stored in binary file.
No more browsing easily with standard tools on the console through a log to see what went wrong. I said, Be Quiet!
o Users login managed by systemd-logind.
The Lady of the Lake, her arm clad in shimmering samite, brought forth Excalibur from the bosom of the water. That is why I am your King.
o Better integration with Gnome for interoperability.
Integration with ONE DESKTOP ENVIRONMENT (which I don't use) is being called "interoperability", which is exactly opposite of reality. This is Cathedral thinking at its WORST.
Or, "You don't vote for a King!"
Quoting:``...what I'm worried about is how happy SuSE users were when systemd was introduced [snip] and how much speedier their system got...''Not this OpenSUSE user. It might seem faster because the GUI may be up and visible more quickly but there's still seems to be parallel startup tasks running that make the system pokey and difficult to use until they finish. So someone needs to remind me why this was such a great move.
> the GUI may be up and visible more quickly but there's still seems to be parallel startup tasks running that make the system pokey and difficult to use until they finish.
That was always an argument against Windows. The Windows boosters would say, "See how quickly the GUI is up?" and the Linux user would point out, "Yes, but you can't DO anything until the rest of the system is finished thrashing."
The GUI used to be the _last_ thing started, which meant that when you got it everything else was finished and it was ready to go.
Et tu Brute?
That was always an argument against Windows. The Windows boosters would say, "See how quickly the GUI is up?" and the Linux user would point out, "Yes, but you can't DO anything until the rest of the system is finished thrashing."
The GUI used to be the _last_ thing started, which meant that when you got it everything else was finished and it was ready to go.
Et tu Brute?
@ rnturn
If you had followed the links the sarcasm had been quite evident ;-)
@ rnturn If you had followed the links and read the comments the sarcasm had been quite evident ;-) (FTFY)
Dear Everybody, I have just received an unpleasant message via the LXer email site. I will not reveal the author however parts of it were, I consider, a direct attack on me personally simply because I had the temerity to question Rahul's intentions and also that I defended the need to either waste bin systemd or at least improve it dramatically. Normally, I would never take this action, however I am now a trifle annoyed. For the information of people on LXer, I enclose my response to the person below:
Dear .............whether he is a troll or not (and that is debatable), Rahul had no right to insult the intelligence of virtually every contributor to that thread. Which he did in black and white. Whether he has been a contributor to Fedora for many years or not has nothing to do with his insulting post. It does however, explain why he is such a devoted supporter of systemd, since my understanding is that systemd is coming directly out of the "RedHat stable".
As regards my understanding of systemd, I have already stated bluntly in that thread that I am not a programmer, but I can read discussions and debates on the topic (and there are many of them) regarding what is wrong with systemd. Penguinist gave the best summation I have seen anywhere so far on that thread. Assuming he is correct, then there definitely are aspects of systemd which should be corrected to make them far more open and conform with traditional Unix standards. I find nothing in that activity that says I should not have an opinion on the matter, and if I wish to do so, make that opinion known to others. It has nothing to do with whether or not I am an "aging LXer".
Quote: "You and the rest of the aging LXers are simply devastated that much (of) the knowledge you struggled to acquire about the init system has to be revised. And like the classic mob, you follow the loudest voice and turn your back on civility." End of quote.
................., the above quote from your message to me is nothing more nor less than a personal attack on myself and I strongly resent that you have taken my time to read such diatribe. I am always scrupulous in trying to give as little offence as possible to anyone on a thread and in fact have often tried to "remove fuel from the fire" when thread debates became a trifle overheated. Please cease this type of correspondence and any future emails of this type will be ignored.
Sincerely
Ridcully
Dear .............whether he is a troll or not (and that is debatable), Rahul had no right to insult the intelligence of virtually every contributor to that thread. Which he did in black and white. Whether he has been a contributor to Fedora for many years or not has nothing to do with his insulting post. It does however, explain why he is such a devoted supporter of systemd, since my understanding is that systemd is coming directly out of the "RedHat stable".
As regards my understanding of systemd, I have already stated bluntly in that thread that I am not a programmer, but I can read discussions and debates on the topic (and there are many of them) regarding what is wrong with systemd. Penguinist gave the best summation I have seen anywhere so far on that thread. Assuming he is correct, then there definitely are aspects of systemd which should be corrected to make them far more open and conform with traditional Unix standards. I find nothing in that activity that says I should not have an opinion on the matter, and if I wish to do so, make that opinion known to others. It has nothing to do with whether or not I am an "aging LXer".
Quote: "You and the rest of the aging LXers are simply devastated that much (of) the knowledge you struggled to acquire about the init system has to be revised. And like the classic mob, you follow the loudest voice and turn your back on civility." End of quote.
................., the above quote from your message to me is nothing more nor less than a personal attack on myself and I strongly resent that you have taken my time to read such diatribe. I am always scrupulous in trying to give as little offence as possible to anyone on a thread and in fact have often tried to "remove fuel from the fire" when thread debates became a trifle overheated. Please cease this type of correspondence and any future emails of this type will be ignored.
Sincerely
Ridcully
Quoting:Quote: "You and the rest of the aging LXers are simply devastated that much (of) the knowledge you struggled to acquire about the init system has to be revised. And like the classic mob, you follow the loudest voice and turn your back on civility." End of quote.
Repulsive. Simply, repulsive.
Said quote says much about the author, and none of it positive.
skelband wrote:
It has always been that Unix and Linux base philosophy is that subsystems co-operate based on standards not on code dependencies. So they use pipes, shared memory, kernel facilities etc. rather than requiring the direct dependency of a specific implementation.
The alternative which is called "coupling" in the computing realm is generally felt to be the sign of poor design.
It is sad that the youngsters these days seem to be intent on ignoring the sage wisdom of some very clever people from the last 30 years.
I think Skelband is getting at the essential core of the problem quite well, here. It seems to me that this "coupling" is arguably the intractable point that most of the contention reduces to, and which outwardly manifests in different ways.
> You and the rest of the aging LXers are simply devastated that much (of) the knowledge you struggled to acquire about the init system has to be revised. And like the classic mob, you follow the loudest voice and turn your back on civility.
It seems to me that I have not seen a reasoned answer to the issue of coupled dependencies inherent in the systemd design. This is just the kind of childish response one expects from someone who just won't listen to the experience of decades of good design practice.
The innards of Linux really could do with a lot of rework for more consistent and architected design. From what I can see of systemd, however, what is proposed is well organised lunacy. Even upstart has the advantage of trying to develop a replace for init, and *only* init. You do not improve the design with large monolithic components sprawling their way across the system. To the inexperienced, it gives the cosy glow of consistency while creating an unmodular monster.
I'm all in favour of experimenting with different designs for init... or any other component for that matter, but systemd has all the hallmarks of a coup of the Linux infrastructure.
It seems to me that I have not seen a reasoned answer to the issue of coupled dependencies inherent in the systemd design. This is just the kind of childish response one expects from someone who just won't listen to the experience of decades of good design practice.
The innards of Linux really could do with a lot of rework for more consistent and architected design. From what I can see of systemd, however, what is proposed is well organised lunacy. Even upstart has the advantage of trying to develop a replace for init, and *only* init. You do not improve the design with large monolithic components sprawling their way across the system. To the inexperienced, it gives the cosy glow of consistency while creating an unmodular monster.
I'm all in favour of experimenting with different designs for init... or any other component for that matter, but systemd has all the hallmarks of a coup of the Linux infrastructure.
Unfortunately this thread has gotten far to negative in its interactions. I am sorry but I am closing this thread from further posts. Closing threads does not make me proud and it reflects on me badly in that I have let this happen in the LXer discussion boards when it could have been avoided. I am sorry.
Comments on this story are closed.
I realize I am being petty, but the Cathedral and Bazaar referred to the development model of the software, not the availability of choices.
Pettiness aside, is systemd taking away choice or are the distributions taking away choice? I am not trying to deflect criticisms away from systemd. I am neither an opponent or proponent of it (I've run both Slackware and Fedora on my laptop and really haven't cared about the init system). The systemd developers wrote something. The distributions didn't have to adopt it. Other software doesn't have to tie in. But it is happening. Why? I trouble believing the systemd developers themselves could force that.
<conspiracytheory>Now RedHat forcing this because it suits their enterprise needs is something I could believe.</conspiracytheory>
On a related note, last month Martin Gräßlin made a post about kwin-wayland requring logind and states that logind can be run independent of systemd. I just felt his post (this one, not his previous self-trolling post) was an insightful look into why they had the dependency and the benefit provided by logind to KWin on Wayland.