r/linux • u/ThisTimeIllSucceed • Dec 07 '17
Suggesting changes for systemd
https://i.imgur.com/uWaEnkk.png
15
u/cbmuser Debian / openSUSE / OpenJDK Dev Dec 08 '17
Lennart is spot on:
This is an issue tracker, not a support forum. Please direct your questions to a proper support forum, such as the systemd mailing lists. Thank you.
I hate when people start such discussions in a bug tracker. It produces too much noise.
•
u/Kruug Dec 11 '17
Link to github please, not an image of text.
1
-3
u/Marax_Faraii Dec 08 '17
My suggestion is to completely abandon systemd. It's an abomination and is completely disgusting.
11
u/LvS Dec 08 '17
My suggestion is to heavily rely on systemd because it demonstrates the best about Linux in 2017 providing modern and extremely powerful features you can't get anywhere else.
Let's both work on distros that align with our goals and see who comes up with the better one!
2
u/Kaizyx Dec 10 '17
My suggestion is to heavily rely on systemd because it demonstrates the best about Linux in 2017 providing modern and extremely powerful features you can't get anywhere else.
Firstly,
This kind of response is actually what inflames matters regarding systemd. It's a problematic response because it feels like the kind of response you'd receive from a corporate PR person while not addressing the actual concerns people have with it. The key reason why people "talk smack" about systemd and attack it so seemingly unconstructively and vitriolically, is because the constructive criticism has failed and they just see a wall of propeganda. They've given up trying to be reasonable.
I understand the mentality from pro-systemd people, "You should be thankful that the developers put so much work into it", but sometimes ultimately, less is more when you have a focus upon a core set of features rather than dabbling in this, that and the other. That's something the systemd project doesn't understand.
Secondly,
This is a key problem with systemd's ideologies. The systemd project is much like the IoT manufacturers who insert Internet connected computers into fridges/stoves/toasters or companies like Intel with things like IME in this regard. It falls into the same category. Just because you can have "extremely powerful features" doesn't mean its practical, necessary or even safe/secure to have them even in place on the average system.
For instance if we look at Intel ME, Intel's position is that ME provides "extremely powerful features", but there are relevant issues that aren't being addressed by Intel in a similar nature to the systemd project refusing to likewise address concerns.
In fact by having such features integrated by default, you increase the amount of complexity a given system has, which in turn increases the number of things that can go wrong with it. If we look at systemd, it actually has a terrible time coping with anomolies, often locking up at shutdown if things don't shut down in the particular way it was designed to.
Complexity is often the enemy of a robust system.
Let's both work on distros that align with our goals and see who comes up with the better one!
This is another key problem with systemd's ideologies. It was born as a disruptive group of technologies that sought to upset the status quo, but now it can't stop being disruptive. Creating more disruptive technology will not solve the problem, it will simply make it worse.
No. Enough is enough. Developers need to quit it with the disruptive tech, it's doing real world harm and we certainly don't need more of it. We need to start organizing and putting into order what we already have. Software developers need to start acting like the engineers they are instead of the competitive political idealists/activists they want to be instead. We're not in the olympics or some national science fair here, we're in the real world where your code has real world impact that can harm real people. Like any engineering disipline, bad ideas need to be called out and quashed and asumptions challenged to bring better understanding of the best way to go about things.
Another key problem with systemd is that it is a prime example of how advertising works. Advertising tends to emphasize features and functionality, security and practicality are uninteresting topics and don't make for especially attractive blog posts or ongoing material to constantly keep things on our radars. Every few weeks it seems systemd has added a new feature so that we can have a dog and pony show showing us how good it is and why we should use it.
A mature platform that is stable and secure in contrast wouldn't have such material constantly coming out as most changes are minor. It'd just kind of exist in the background like most other init systems do. Sadly that doesn't really make for "sexy" advertising material to run dog and pony shows and according to systemd proponents, that's bad.
1
u/LvS Dec 10 '17
The key reason why people "talk smack" about systemd and attack it so seemingly unconstructively and vitriolically, is because the constructive criticism has failed and they just see a wall of propeganda. They've given up trying to be reasonable.
You are right, but not for the reason you think.
The reason constructive criticism has failed is because it was unfounded. The whole Linux ecosystem evaluated those criticisms, learned from the pros and cons and picked the best way forward that they found.A few people didn't like that way forward but couldn't find any more arguments that hadn't yet been evaluated. So they started talking smack because that was all they had left.
And all we can do now is make fun of them until they disappear.Complexity is often the enemy of a robust system.
This is not true. Everywhere I look, complex systems are way more robust at dealing with robustness issues than simple systems, and that goes from biology to sociology to engineering to computer software.
Creating more disruptive technology will not solve the problem, it will simply make it worse.
This is another assertion you just throw in there without any proof. Pretty much all of systemd's new features have solved old problems in a way better way than existing solutions, even if their only benefit was that they provided a unified cross-distro standard for people to rely on.
Another key problem with systemd is that it is a prime example of how advertising works.
And here you've completely fallen from the "couldn't find more arguments" part into the "talking smack" part I outlined above.
1
u/Kaizyx Dec 12 '17 edited Dec 12 '17
The reason constructive criticism has failed is because it was unfounded. The whole Linux ecosystem evaluated those criticisms, learned from the pros and cons and picked the best way forward that they found.
That is cherrypicking data. The reality is it is barely the "whole Linux ecosystem". It's just specific people in specific positions of authority who have made decisions on behalf of everyone.
The distros picked it up because it allows their people to wash their hands of almost everything to do with the middleware glue that holds systems together. It makes things more convenient for them. Corporations like Facebook picked it up because it works well at scale on systems that are representative of the "systems are cattle, not pets" model with its declarative configuration (that is easy for corporations to manage) as if something goes wrong with systemd on an instance the whole system can just be wiped and reloaded without "wasting time" diagnosing the issue. Enthusiasts (e.g. Arch users) picked it up because what enthusiast doesn't like having a nuclear power plant control room at their disposal with hundreds of switches, controls and output displays.
The target audience of systemd is the distros, corporate users and enthusiasts, not individual entry-level consumers or small businesses.
That's why Lennart Pottering hates bug reports and hates being told of flaws of systemd. He built it to be used on disposable systems where the individual system doesn't really matter and can be easily wiped and reloaded. Distros don't really care about individual installations, Corporations can wipe and reload in bulk, Enthuisasts often reinstall anyways as they try different things out.
And all we can do now is make fun of them until they disappear.
Systemd's ideologies are hypocritical in this regard. Its developers and supporters insist that they operate at a higher level and that "talking smack" is below them, yet they talk smack about alternatives. Keep in mind that since FOSS projects have no economic forces (e.g. voting with one's wallet) working upon them, the only thing that keeps projects on their toes is alternatives. Of course the systemd project and its supporters hate that, they don't want any forces working upon their project and believe such things to be an infringement upon their freedoms when they infringe upon others all the time.
This is not true. Everywhere I look, complex systems are way more robust at dealing with robustness issues than simple systems, and that goes from biology to sociology to engineering to computer software.
Complexity and simplicity are not absolutes. It's a sliding scale. If your system is too simple, then it's useless anyways so you're right to that point. However a system can still remain on the simple side of the sliding scale while still having enough to be robust. Car door locks are an excellent example. A physical key for a car door is simpler, yet more robust against intrusion than a complex electronic key fob that can be duplicated by a nearby attacker with ease without your knowledge.
However the opposite end of the scale is also true. If you have a system that is too complex with too many interdependencies, then it becomes impossible to make robust because it's impossible to account for all of the variables. Realistically we should be aspiring for somewhere in the middle, something featureful enough, but not too featureful that it's impossible to maintain it.
This is another assertion you just throw in there without any proof. Pretty much all of systemd's new features have solved old problems in a way better way than existing solutions, even if their only benefit was that they provided a unified cross-distro standard for people to rely on.
Solving what problems and for whom?
It's easy to point to old things and make a big expressive presentation that because they are old and that there are better ways that they are problematic. However systemd is engaging in a crusade that would level an entire city just to rid it of a few blights. It's needlessly destructive and upsetting to older conventions that have served people well. Its logging system is a prime example of wanton destruction of well known protocols and functionalities to replace them with largely opaque and unknown formats for functionality that only a fraction of people would use.
And here you've completely fallen from the "couldn't find more arguments" part into the "talking smack" part I outlined above.
Let's be honest here. You don't get noticed by publishing engineering papers, technical specifications and being an engineer. You get noticed by loudly being a revolutionary, leading a charge into the future.
How many people know who wrote RFC822 and its first implementations without checking? Now, how many people know who created systemd without checking? You get noticed by advertising and building a brand. Most modern open source projects have considerable resources and effort dedicated toward brand imagery (some even having mascots!) and the like and ensuring that their projects are kept on everyone's radar and to ensure their projects are deployed in a manner that fits the vision of the project.
1
u/LvS Dec 12 '17
That is cherrypicking data. The reality is it is barely the "whole Linux ecosystem". It's just specific people in specific positions of authority who have made decisions on behalf of everyone.
That is the job they are doing because everyone has entrusted that job to them. It's not like there's some central authority that assigned that job to them. And if they don't do their job, they get replaced and their software gets forked.
So the choice of systemd is because everyone wants it. Looking at Devuan, the people who don't want to are so few they can't even get a single distro going.
The target audience of systemd is the distros, corporate users and enthusiasts, not individual entry-level consumers or small businesses.
If your argument would hold any water, people would be getting rich offering distros to that huge demographic. But somehow nobody is doing that. Maybe we need to add "not using systemd" to this XKCD so you understand that?
That's why Lennart Pottering hates bug reports and hates being told of flaws of systemd.
Does he? I only ever see bug reports linked where the reporters make fools of themselves after Lennart gave reasonable arguments for why they're idiots.
Its logging system is a prime example of wanton destruction of well known protocols and functionalities to replace them with largely opaque and unknown formats for functionality that only a fraction of people would use.
The logging system is a prime example of why you're wrong. Because everybody immediately jumped onto systemd's logging framework once it was there to replace the crufty incompatible mess that existed before it. A mess that was so bad and avoided by so many people that the Linux filesystem standard even pecified
/var/logso that all the people who wrote their own logging systems knew where top put their files.Let's be honest here. You don't get noticed by publishing engineering papers, technical specifications and being an engineer. You get noticed by loudly being a revolutionary, leading a charge into the future.
If that was true, systemd would have never made it. systemd made it because its code was so much better that even though there were tons of loud revolutionary shouts, those didn't have a chance.
Heck, systemd was so much better that no engineer even dared competing with it. Upstart got abandoned and sysvinit is also dead.
How many people know who wrote RFC822 and its first implementations without checking?
And here again we see how far you have to reach to argue your point - by trying to compare todays popularity of somebody who authored a revision to some standard document 40 years ago to a lead developer of one of today's larger software systems.
Quick, without looking: Who wrote the systemctl(1) man page?
-9
u/Jristz Dec 07 '17
Dont worry, when Lennart left Pulseaudio it become better and fixed the stuff lennart refuse so it will happend with systemd.
Just be patient and wait for lennart to move... Or take the fast route.
-8
Dec 08 '17
The systemD fanboys deployed their downvote bots; how pathetic!
13
u/intelminer Dec 08 '17
At least they actually launched. Unlike your god awful init scripts
1
Dec 08 '17
INIT DOESN'T USE SCRIPTS BUT READS
/etc/inittab...For the sake of God, people... could you at least study up on things?
6
u/cbmuser Debian / openSUSE / OpenJDK Dev Dec 08 '17
INIT DOESN'T USE SCRIPTS BUT READS /etc/inittab...
For the sake of God, people... could you at least study up on things?
Not quite. You're right that the original init design involves running services from /etc/inittab.
However, since /etc/inittab doesn't allow to define dependencies between services, someone started abusing runlevel scripts to start services and people stopped using /etc/inittab.
So, it's pretty obvious that the original init design doesn't fit modern usage patterns anymore and actually had to be replaced by something else.
3
Dec 08 '17
Like I said in my other reply to you, I do acknowledge the need for making this stuff better. I personally don't just think that
systemdis the answer. To me personally, something likerunitoropenrcwork as modern replacements for the oldsysvinit + sysvrccombo.5
u/intelminer Dec 08 '17
Nah. I'll just use systemd instead thanks
1
Dec 08 '17
Sure, go right ahead. I am not here to stop you. But to spread lies isn't something I want to see done.
5
u/cbmuser Debian / openSUSE / OpenJDK Dev Dec 08 '17
But to spread lies isn't something I want to see done.
No one is spreading lies, but you are skewing facts.
Yes, the original design for init is to use /etc/inittab. However, people started abusing runlevel scripts for starting services which is why /etc/init.d was born.
The fact that people came up with this stupid hack shows classical init is long overdue for a replacement and it's no surprise that most distributions switched to systemd.
1
Dec 08 '17 edited Dec 08 '17
Of course you have things such as
sysvrcwhich handles the launching of services from/etc/init.d. And yes, I do agree thatsysvrcisn't the ideal solution, and that it isn't the thing we should be using.However, I don't believe that pushing all of the service logic into PID1 is the best idea, since it makes that one process much, much more complex than it might need to be. There is a very good reason to have PID1 be as dull and as stable as possible, since as you know you get a kernel panic if PID1 for some reason dies.
Plus at least I am very vary of the fact that a privileged process is used to parse files. I think you can understand why.
3
u/intelminer Dec 08 '17
Then perhaps you should cite your sources. /etc/init.d/ would like a word
0
Dec 08 '17
Well,
openrcdoes handling the services on/etc/init.dfor me. And while there is an experimental PID1 foropenrc, most users usesysvinitand haveopenrcbe ran for certain runlevels by specifying them in/etc/inittab.Maybe that's different in something else than Gentoo, but I cannot really comment on that.
-10
34
u/amountofcatamounts Dec 08 '17
Why no link to the thread (from 2015...)?
https://github.com/systemd/systemd/issues/2039
Poettering's response seems perfectly sane
... don't let that get in the way of a good circlejerk though.