I'm not the one making up bullshit about sysvinit being finished, that was a direct quote from the poster here that claimed that he had commit rights to the sysvinit upstream.
initng was great as a faster systemvinit, what it brought to the table was better parallelization of the init scripts which made for a faster boot. It was great in that regard but it really didn't bring anything new to the table other than that. So it was sysv but slightly faster, which of course was nice in itself.
upstart had some great promises, it had some of the things that make systemd great (well defines config files instead of init scripts, possibility to restart crashed daemons) but it never got anywhere, it's somewhat buggy and Ubuntu put it into maintenance mode since long before they switched to systemd. And if we are to believe Lennart Poettering there where architectural problems with upstart that made it not a good choice to start from. I have not examined both projects enough to make a trustworthy reply if this is true or not so I have just to take Lennart on his word here, and he claims to have been first looking at building from upstart so he should know and I have no reason to distrust him on this.
If we should wait two decades before deciding on which init to use we would still be using what we used before sysv because that is how software development works, if no one uses it it will not get enough progress to ever reach a state where it's deemed stable enough.
And systemd will never be feature complete, just like apache, nginx and so one also will never be feature complete.
But what does the First Amendment have to do with anything? ICANN was never part of the US government so how could the constitution dictate how and what ICANN did? They only had a contract with the US government that stated that the Department of Commerce would veto any changes to the root file. And since that veto lead to the dismissal of the.xxx top domain one does wonder how that decision was in line with the First Amendment.
I can actually not find a single CVE for systemd since it was put into production. Yes there where 5 in total during 2013 as reported by Ubuntu but that is before it was put into either RHEL, Debian or Ubuntu. Doesn't really matter though because the claim that TFA is trying to push is that this single bug in systemd should mark the entire project as a failure and we should throw it out, by showing that there have been at least one (and quote more serious at that) vulnerability in sysvinit demonstrates that following this logic sysvinit should have been thrown out back in 1998 a position that I think we can all agree is complete ludicrous.
Ok, I personally stopped coding in asm and switched to C because the processors got so complicated that a compiler would have a higher chance of creating faster code and so that porting the code between architectures would no longer require a complete rewrite of the whole program line by line. How would your C++ compiler be any better than a C compiler for any of that?
And sometimes when talking directly to hardware, array[-1] is exactly what is needed. Of course for the majority of software that will never be the use case so it would be nice to have warnings for such things and thankfully there are static source code checkers that does exactly this. http://cppcheck.sourceforge.ne... for example would warn about "out of bounds" for this very code.
How is more available tools similar to lock-in? You might not like systemd and it's tools, and that is ok and you are free to use whatever else that you like but that does not mean that you have to throw fud like this around. Could we be a little bit more civilized than the emacs vs vi idiots?
And you never wonder why it was thrown out from the majority of distributions (not to mention that Solaris, Apple and the BSDs threw it out even before that)? It's feature completion was insufficient even back in the day, which is why people like Bernstein created the deamon tools, why Solaris made SMF, why Apple made launchd, why I myself sponsored initng in Gentoo back in 2005, why Ubuntu switched to upstart and afaik the BSDs are working on their own modern init system.
The hard part for that project was not the "to split the applications" but that systemd uses lots of Linux only systemcalls and functionality that is not available on other systems like BSD for which uselessd was a target. They also tried to move away from D-BUS to another IPC entirely so they tried to do a hell of a lot more than just "split the applications".
It's not only mature, it's also unmaintained. There is no white hackers looking at the code so there might be crawling with bugs that we do not know of. And with SysV there is also the problem with the init scripts themselves, recently there where a vulnerability with the MySQL wrapper script. The incentive to switch would be among other things, much simpler unit files, far better logging, no difference between distributions, possibility to automatically restart crashed deamons, cgroup control for the daemons and so on.
What is absorption to some is unification to others. No one is forcing you to use these tools and most of them are and will be disabled by the popular distributions anyway, the main focus of them as I understand it is the container/vm/cloud people and that crowd apparently sees that as a big win (I have no clue regarding that area what so ever since I don't use containers or virtual instances).
I take it that you have not looked at the actual code, afaik there is no nasty web of dependencies. Where there are dependencies they are on a documented DBUS service and not on a specific pid 1 and afaik there are no inter-project dependency either. Yes it's a bit different from how we did things back in the day but then it is no longer back in the day, for good and worse the computing environment have changed and so the systems have to adapt or die. Solaris and Apple went this route years ago and the BSDs are following, it's just here on Slashdot that this is a RedHat/Poettering conspiracy.
The impact is that you can DOS the systemd init daemon by a local exploit, some systemd aware applications/daemons will then timeout for aprox 30 seconds before they downgrade to non-systemd mode. A vulnerability that where patched three days ago on distributions.
But let us all hail SysV init that have had several buffer overflow vulnerabilities over the years, because exploitable security vulnerabilities are of course better...
How else should he call it when the original article throws all kinds of shit at systemd and claims that it should be abolished for a very small bug? If that where so then your beloved SysV init would have been killed decades ago.
There is a major difference between the systemd project (which is the one you counted the lines of code from) and the systemd init daemon that you talk about. The inid system does not need any of that stuff, the systemd project aims to present a unified set of administration tools, aka the low level plumbing, just like how the GNU project provided a unified set of the Unix command tools.
So yes it is guilt by git association because you look at tons of source files that have nothing to do with what is running as pid 1
No, it's you who fails to see that what somenickname showed was not the number of lines of code in the systemd init but the number of lines of all the applications, deamons etc that is stored in the systemd source repository. Just like BSD stores all the code for their kernel and user space applications in a single repository.
That is far from a detailed description and more of a list of uninformed rants. Much better to read the informed reply to TFA here: https://medium.com/@davidtstra...
What does feel surreal is that people now all of a sudden pretend that SysV init where without exploits while going completely berserk when systemd have a non remote exploitable denial of service bug that cannot be used to take over the machine that also where patched three days ago...
And the reason they cannot is because apparently this bug exists in debug code (it's a ASSERT that is triggered) so only distributions that compiled with -DDEBUG are affected. Also the affected distributions was patched three days ago.
If we play with the numbers and say that it happens once per year than that is still only 25 loads from the disk, even the 1541 wasn't _that_ bad at reading disks.
Slashdot Mirror
I'm not the one making up bullshit about sysvinit being finished, that was a direct quote from the poster here that claimed that he had commit rights to the sysvinit upstream.
initng was great as a faster systemvinit, what it brought to the table was better parallelization of the init scripts which made for a faster boot. It was great in that regard but it really didn't bring anything new to the table other than that. So it was sysv but slightly faster, which of course was nice in itself.
upstart had some great promises, it had some of the things that make systemd great (well defines config files instead of init scripts, possibility to restart crashed daemons) but it never got anywhere, it's somewhat buggy and Ubuntu put it into maintenance mode since long before they switched to systemd. And if we are to believe Lennart Poettering there where architectural problems with upstart that made it not a good choice to start from. I have not examined both projects enough to make a trustworthy reply if this is true or not so I have just to take Lennart on his word here, and he claims to have been first looking at building from upstart so he should know and I have no reason to distrust him on this.
If we should wait two decades before deciding on which init to use we would still be using what we used before sysv because that is how software development works, if no one uses it it will not get enough progress to ever reach a state where it's deemed stable enough.
And systemd will never be feature complete, just like apache, nginx and so one also will never be feature complete.
But what does the First Amendment have to do with anything? ICANN was never part of the US government so how could the constitution dictate how and what ICANN did? They only had a contract with the US government that stated that the Department of Commerce would veto any changes to the root file. And since that veto lead to the dismissal of the .xxx top domain one does wonder how that decision was in line with the First Amendment.
I can actually not find a single CVE for systemd since it was put into production. Yes there where 5 in total during 2013 as reported by Ubuntu but that is before it was put into either RHEL, Debian or Ubuntu. Doesn't really matter though because the claim that TFA is trying to push is that this single bug in systemd should mark the entire project as a failure and we should throw it out, by showing that there have been at least one (and quote more serious at that) vulnerability in sysvinit demonstrates that following this logic sysvinit should have been thrown out back in 1998 a position that I think we can all agree is complete ludicrous.
This again? You actually pretend that the switch to systemd in (most) distributions wasn't preluded with years of technical debates and arguments?
Ok, I personally stopped coding in asm and switched to C because the processors got so complicated that a compiler would have a higher chance of creating faster code and so that porting the code between architectures would no longer require a complete rewrite of the whole program line by line. How would your C++ compiler be any better than a C compiler for any of that?
That is because your a[-1] is not equivalent to a a[-1] in C but to a vector_set_at_pos (a, -1, 0x666);
I don't think that straight arrays such a "int a[10]; a[-1] = 0x666;" throws any exceptions in C++ either.
And sometimes when talking directly to hardware, array[-1] is exactly what is needed. Of course for the majority of software that will never be the use case so it would be nice to have warnings for such things and thankfully there are static source code checkers that does exactly this. http://cppcheck.sourceforge.ne... for example would warn about "out of bounds" for this very code.
How is more available tools similar to lock-in? You might not like systemd and it's tools, and that is ok and you are free to use whatever else that you like but that does not mean that you have to throw fud like this around. Could we be a little bit more civilized than the emacs vs vi idiots?
And you would not be able to choose exactly why? Since when have more choice meant less choice, that does not even compute.
And you never wonder why it was thrown out from the majority of distributions (not to mention that Solaris, Apple and the BSDs threw it out even before that)? It's feature completion was insufficient even back in the day, which is why people like Bernstein created the deamon tools, why Solaris made SMF, why Apple made launchd, why I myself sponsored initng in Gentoo back in 2005, why Ubuntu switched to upstart and afaik the BSDs are working on their own modern init system.
Here is one: https://www.cvedetails.com/cve...
How is that a problem? Is it better to have a non unified set of administration tools between distributions?
The hard part for that project was not the "to split the applications" but that systemd uses lots of Linux only systemcalls and functionality that is not available on other systems like BSD for which uselessd was a target. They also tried to move away from D-BUS to another IPC entirely so they tried to do a hell of a lot more than just "split the applications".
It's not only mature, it's also unmaintained. There is no white hackers looking at the code so there might be crawling with bugs that we do not know of. And with SysV there is also the problem with the init scripts themselves, recently there where a vulnerability with the MySQL wrapper script. The incentive to switch would be among other things, much simpler unit files, far better logging, no difference between distributions, possibility to automatically restart crashed deamons, cgroup control for the daemons and so on.
What is absorption to some is unification to others. No one is forcing you to use these tools and most of them are and will be disabled by the popular distributions anyway, the main focus of them as I understand it is the container/vm/cloud people and that crowd apparently sees that as a big win (I have no clue regarding that area what so ever since I don't use containers or virtual instances).
I take it that you have not looked at the actual code, afaik there is no nasty web of dependencies. Where there are dependencies they are on a documented DBUS service and not on a specific pid 1 and afaik there are no inter-project dependency either. Yes it's a bit different from how we did things back in the day but then it is no longer back in the day, for good and worse the computing environment have changed and so the systems have to adapt or die. Solaris and Apple went this route years ago and the BSDs are following, it's just here on Slashdot that this is a RedHat/Poettering conspiracy.
So what is buffer overflow exploits in SysV init then? Full on thermal nuclear warfare?
The impact is that you can DOS the systemd init daemon by a local exploit, some systemd aware applications/daemons will then timeout for aprox 30 seconds before they downgrade to non-systemd mode. A vulnerability that where patched three days ago on distributions.
But let us all hail SysV init that have had several buffer overflow vulnerabilities over the years, because exploitable security vulnerabilities are of course better...
How else should he call it when the original article throws all kinds of shit at systemd and claims that it should be abolished for a very small bug? If that where so then your beloved SysV init would have been killed decades ago.
There is a major difference between the systemd project (which is the one you counted the lines of code from) and the systemd init daemon that you talk about. The inid system does not need any of that stuff, the systemd project aims to present a unified set of administration tools, aka the low level plumbing, just like how the GNU project provided a unified set of the Unix command tools.
So yes it is guilt by git association because you look at tons of source files that have nothing to do with what is running as pid 1
No, it's you who fails to see that what somenickname showed was not the number of lines of code in the systemd init but the number of lines of all the applications, deamons etc that is stored in the systemd source repository. Just like BSD stores all the code for their kernel and user space applications in a single repository.
It's just a guilt by git association.
That is far from a detailed description and more of a list of uninformed rants. Much better to read the informed reply to TFA here: https://medium.com/@davidtstra...
What does feel surreal is that people now all of a sudden pretend that SysV init where without exploits while going completely berserk when systemd have a non remote exploitable denial of service bug that cannot be used to take over the machine that also where patched three days ago...
Wait till you discover the BSD ports archive, boy will you be amazed at the number of lines of code they have in their repository!
And the reason they cannot is because apparently this bug exists in debug code (it's a ASSERT that is triggered) so only distributions that compiled with -DDEBUG are affected. Also the affected distributions was patched three days ago.
If we play with the numbers and say that it happens once per year than that is still only 25 loads from the disk, even the 1541 wasn't _that_ bad at reading disks.
Yep, Kim Justice have a lot of good videos about the old companies in computing and gaming history. Worth checking out.