SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I don't want to reply to all your statements again, but here's the most wrong:
Quote:
For us, Init systems like SysVInit, OpenRC, and BSDInit have been extremely reliable, because for the most part, they all use the same scripts in plaintext.
Did you ever diff for example the apache startup script from Debian with the one from Slackware ?
Besides being written in shell, they have NOTHING in common.
Service file from systemd are (or should be) completely IDENTICAL in all distro since all the logic behind the service file is handled by systemd itself.
Then the chore of making a "startup script" can be relayed upstream.
This is ineeded removing some weight of the package shoulders.
Yes, shell script are plain text file like all the services file from systemd.
As a professional datacenter-scale software engineer and sometimes system administrator, I have to say that Erik and ReaperX7 have nailed my concerns precisely, much more eloquently than I could.
The nature of reliability changes as a system scales up.
Consider: When The Internet Archive switched from using debian-stable to debian-unstable, it encountered a problem with the forcedeth ethernet driver. About one time in twenty, a system would hang on boot.
Not a big deal, right? Right, until 2000 servers lost power and had to come back up.
They would all come up .. except for a hundred servers, give or take. These would have to be located and cold-booted again.
So those would come up .. except perhaps for four or six, which would have to be located and cold-booted again.
The Archive's datacenter isn't even that large. There are plenty of companies out there sporting tens of thousands of servers.
They don't need unreliable code in the init system, and new code is unreliable code.
As a professional datacenter-scale software engineer and sometimes system administrator, I have to say that Erik and ReaperX7 have nailed my concerns precisely, much more eloquently than I could.
The nature of reliability changes as a system scales up.
Consider: When The Internet Archive switched from using debian-stable to debian-unstable, it encountered a problem with the forcedeth ethernet driver. About one time in a fifty, a system would hang on boot.
Not a big deal, right? Right, until 2000 servers lost power and had to come back up.
They would all come up .. except for forty servers, give or take. These would have to be located and cold-booted again.
So those would come up .. except perhaps for one or two, which would have to be located and cold-booted again.
The Archive's datacenter isn't even that large. There are plenty of companies out there sporting tens of thousands of servers.
They don't need unreliable code in the init system, and new code is unreliable code.
Okay you say systemd code is unreliable.
Well I say sysvinit isn't more reliable.
This discussion is so constructive.
Okay you say systemd code is unreliable.
Well I say sysvinit isn't more reliable.
This is wrong. The more a codebase is used, the more of its bugs become revealed. If developers focus more on bugfixing than new feature development, they will eventually fix more bugs than they create, resulting in more-reliable code.
This implies that sysvinit should be extremely reliable, and that is precisely what is observed in the real world.
Quote:
This discussion is so constructive.
It's not bad, but I'm starting to see the point of those who consider you a troll. I should stop feeding you.
This is wrong. The more a codebase is used, the more of its bugs become revealed. If developers focus more on bugfixing than new feature development, they will eventually fix more bugs than they create, resulting in more-reliable code.
Of course you are totally right.
This means that Windows is a lot more reliable then GNU/Linux since Windows is used by so much more people therefore more of its bug got fixed by microsoft engineers with reports from users.
I like when people bring troll as an argument.
Someone isn't a troll because his opinion differ from yours.
It doesn't work like that sorry.
Everything in life isn't black or white.
Oh and ReaperX7, you said to me that you weren't a programmer at all.
Then, how can you say that systemd is "bloated" if you don't know shit about C, besides repeating what you heard everywhere on the web like a sheep ?
I'm curious really.
This means that Windows is a lot more reliable then GNU/Linux since Windows is used by so much more people therefore more of its bug got fixed by microsoft engineers with reports from users.
Nice try, but you missed the point.
Your aggressive defence of systemd is really off-putting. Anyhow, I think I read somewhere in the mess above that you don't even use Slackware... so why do you insist on hanging around here and antagonising people?
There has been entirely too much vitriol from both sides in this "debate." Enough already.
I don't want to reply to all your statements again, but here's the most wrong:
Did you ever diff for example the apache startup script from Debian with the one from Slackware ?
Besides being written in shell, they have NOTHING in common.
Service file from systemd are (or should be) completely IDENTICAL in all distro since all the logic behind the service file is handled by systemd itself.
Then the chore of making a "startup script" can be relayed upstream.
This is ineeded removing some weight of the package shoulders.
Yes, shell script are plain text file like all the services file from systemd.
Who cares about Debian? Much less who cares about any specific distribution of Linux for that matter? I could give a rat's fat arse about Debian's Apache shell scripts versus Slackware's? There's two fundamentally different systems using two variants of an Init system. Slackware uses BSD Stylized SysVInit scripts while Debian uses classic SysVInit.
Quote:
Originally Posted by elvis4526
I like when people bring troll as an argument.
Someone isn't a troll because his opinion differ from yours.
It doesn't work like that sorry.
Everything in life isn't black or white.
Oh and ReaperX7, you said to me that you weren't a programmer at all.
Then, how can you say that systemd is "bloated" if you don't know shit about C, besides repeating what you heard everywhere on the web like a sheep ?
I'm curious really.
System Administrators ARE NOT PROGRAMMERS!!! We don't give a rat's fat arse about learning C code. yes, if I knew it's I'd help, but WHO CARES!?!
Your aggressive defence of systemd is really off-putting. Anyhow, I think I read somewhere in the mess above that you don't even use Slackware... so why do you insist on hanging around here and antagonising people?
There has been entirely too much vitriol from both sides in this "debate." Enough already.
I'm open to make a kind and calm discussion but it is not possible when people comes claiming something totally false like: "Sysvinit use plaintext configuration file unlike systemd"; right into my face.
I didn't made a lot of claim about sysvinit.
Why?
Because I didn't tinker with it like I did with systemd therefore I don't speak about what I don't know.
All I do is rectifying all the stuff that you claim about systemd when i'm sure half of you didn't even tinker with it.
You may not care about Debian, but it is still the distribution with the biggest number of contributor.
So yeah, a lot of person care about debian.
Quote:
There's two fundamentally different systems using two variants of an Init system.
Here I will quote you:
Quote:
For us, Init systems like SysVInit, OpenRC, and BSDInit have been extremely reliable, because for the most part, they all use the same scripts in plaintext.
You clearly said that all init system that use shell for startup script USE THE SAME SCRIPTS.
Quote:
System Administrators ARE NOT PROGRAMMERS!!! We don't give a rat's fat arse about learning C code. yes, if I knew it's I'd help, but WHO CARES!?!
How can you say systemd is bloated when you don't even know a damn thing C ?
How can you say systemd is bloated without even reading his source code ?
If you don't use Slackware then WHY THE HELL ARE YOU HERE!?!
One doesn't need to be a Slackware user to post in the Slackware sub-forum.
Also, you really seem to be emotionally invested in this. Seriously, you've got a nasty attitude going on. Wait and see how systemd performs in an enterprise environment before condemning it and its supporters.
One doesn't need to be a Slackware user to post in the Slackware sub-forum.
Also, you really seem to be emotionally invested in this. Seriously, you've got a nasty attitude going on. Wait and see how systemd performs in an enterprise environment before condemning it and its supporters.
I'm open to make a kind and calm discussion but it is not possible when people comes claiming something totally false like: "Sysvinit use plaintext configuration file unlike systemd"; right into my face.
I think you are missing one point; sysvinit is not only configured through plain text files, it is also implemented through shell scripts (text files too). Which means that you can study and modify the configuration AND the scripts, for example to add a new feature customized for your environment. And this can be easy: just add a few lines of code to a shell script. You are not limited to setting some predefined configuration options decided by the developer.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
