In Which Linus Torvalds Makes An 'Init' Joke (lkml.org) 359
Long-time Slashdot reader jawtheshark writes:
In a recent Linux Kernel Mailing List post, Linux Torvalds finishes his mail with a little poke towards a certain init system. It is a very faint criticism, compared to his usual style. While Linus has no direct influence on the "choices" of distro maintainers, his opinion is usually valued.
In a discussion about how to set rlimit default values for setuid execs, Linus concluded his email by writing, "And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."
In a discussion about how to set rlimit default values for setuid execs, Linus concluded his email by writing, "And yes, a large part of this may be that I no longer feel like I can trust "init" to do the sane thing. You all presumably know why."
You all presumably know why. (Score:4)
Re:You all presumably know why. (Score:5, Insightful)
Re:You all presumably know why. (Score:4, Funny)
So SystemD is the Emacs of init?
Re: (Score:2)
systemd is absolutely the emacs of init. I've been using emacs since the 90s and I would never switch to something else. All that time I was wish for a better init system. Now I have the init system that I want to keep using for the next 30 years.
Re:You all presumably know why. (Score:5, Funny)
So what editor do you use?
Re: (Score:3)
It is probably worse. Systemd gobbles up external features because it is inherently incompatible with the packages implementing them. And feature creep is just the smallest evil, the biggest evil is, during this furious re-implementation, they introduce new bugs.
Re: (Score:2)
biggest evil is, during this furious re-implementation, they introduce new bugs.
NOTABUG WONTFIX.
This function returns EFUCKYOU on attempted use.
Re: (Score:2)
Find a new cat. If your cat was an outdoor cat one will probably take the territory before long anyway.
Re: (Score:2)
Find a new cat. If your cat was an outdoor cat one will probably take the territory before long anyway.
If it was Schrödinger's cat that would be one possibility.
Re: (Score:2)
The only sad part is, if everyone here used all the energy they have to hate on SystemD, to actually fix those bugs, we wouldn't be having these discussions about how buggy it is.
Re: (Score:3)
How? Lennart isn't listening and isn't going to accept fixes to something he doesn't see as a problem.
It appears a lot of the energy is going into FreeBSD etc.
Re: You all presumably know why. (Score:4, Insightful)
Re: (Score:2)
> The only sad part is, if everyone here used all the energy they
> have to hate on SystemD, to actually fix those bugs, we wouldn't
> be having these discussions about how buggy it is.
You've hear of how the best "Widnows solution" is linux? Well, the best "systemd fix" is openrc.
Re:You all presumably know why. (Score:4, Informative)
The only sad part is, if everyone here used all the energy they have to hate on SystemD, to actually fix those bugs, we wouldn't be having these discussions about how buggy it is.
Anyone who has tried has had issues waved away as someone else's problem. This also does not resolve the maintainer or responsibility, a notion which is just downright hilarious.
Re: (Score:2)
*grin*
Just playin' on the vi/emacs rivalry. Most non-emacs people I knew that had experience with it commented that it was a great operating environment and shell but a fairly crappy editor. Of course, the biggest difference is that having one on one's system doesn't break the other, and neither worms its way into every part of the OS.
Re: (Score:2)
RedHat owns it and nobody outside of RedHat really understands it for more than a few weeks before it morphs again.
Re: (Score:2)
No. Emacs works well, given enough resources.
Re: (Score:2)
So SystemD is the Emacs of init?
As a vi user, I would not insult Emacs that way.
systemd is the svchost of linux, except that svchost is for windows and they don't want systemd either.
Re: (Score:2, Interesting)
Re: (Score:2, Informative)
> doing it half-assed.
Like logging. Logging is critical for both troubleshooting and security. With sys V init scripts, even if the error wasn't logged to syslog, you'd at least see it on the console instead of so often seeing nothing with systemd.
Re: You all presumably know why. (Score:4, Insightful)
No, logs are preserved by shipping them off to another system over the network. Binary logs are harder to forge, but not impossible. Faking wtmp entries is a thing, for example.
Re: (Score:3)
Re: (Score:3)
Funny. The level of your cluelessness is staggering. This is about enterprise computing, and of course logs get transferred out to protect them. There may be some revision-proof storage at the end somewhere, but there always is a network connection first. You can deride and ridicule all you want, people with an actual clue will see you for the cretin you are.
Re: (Score:2)
That is complete nonsense. Locally kept logs can always be manipulated. Takes some actual understanding to see that though.
Re: (Score:3)
And more cluelessness. Crypto-signing done locally with everything only stored locally afterwards is worthless. Again, some actual understanding of what crypto can and cannot do is required. You are completely clueless and incompetent. It is painful to watch you disgracing yourself again and again.
Re: (Score:3)
Well, the evidence points to you being a moron, as you apparently do not even know about a standard-attack against cryptographic signatures, yet claim they solve the issue. You are similar to your idol Poettering in that, I guess.
Re: You all presumably know why. (Score:2)
Re: (Score:2)
That is because I got a pretty good education on crypto 25 years ago and I have kept current in the meantime. I do not need to look this stuff up, it is covered by the basics. You apparently have not bothered finding out even said basics or you are too mentally limited to understand them.
Quite in line with my assessment of you being a moron. Or more exactly a Dunning-Kruger far left-side sample, i.e. big, big ego and really small skills.
Re: You all presumably know why. (Score:2, Flamebait)
Re: (Score:2)
I have stopped listening when people claim things can be done that are actually impossible. In all cases, they are just full of it, usually by misstating the border conditions or not actually understanding what they claim to understand or, surprise!, buy suddenly claiming something else than they did initially. Waste of my time. And you are too, so I will now stop answering.
Re: You all presumably know why. (Score:2)
Re: You all presumably know why. (Score:2)
Re: You all presumably know why. (Score:2)
Re: (Score:2)
That seems to be accurate. He and his team also are lacking quite a bit of other insights, for example into what this pesky "Unix philosophy" is.
Re: (Score:2)
Indeed. That is the main problem with it. On wonders whether this is an indicator of plain incompetence?
Re: You all presumably know why. (Score:5, Informative)
Don't forget the recent severity 9.8 CVE regarding invalid username handling [nist.gov] that Poettering closed as NOTABUG [github.com]. It's a trainwreck of bad design driven by an egotistic idiot.
Re: (Score:3)
And that is the core problem. This moron cannot recognize what is important and what is not. Add the fanatic followers he has and that whole thing becomes extremely dangerous.
Re: You all presumably know why. (Score:5, Informative)
you are one of those special idiots my mother warned me about... EWONTFIX/Closed is NOT fixing...
Updating manuals to (now) state that systemd only accepts usernames adhering to: [a-z_][a-z0-9_-]*$? is not a fix.
Systemd hasn't fixed teh issue, they man paged what it doesn't like. someone creating a username starting with a 0 will still get executed as root. Even worse!!! a username with a "." in it will also do it... Periods have been permitted for ages (just not starting...) and this means if a linux machine is part of an AD it could cause issues...
https://lists.freedesktop.org/archives/systemd-devel/2017-July/039237.html
> 1. We do not permit empty usernames
> 2. We don't permit the first character to be numeric
> (This also filters out fully numeric user names)
> 3. We do not permit dots in usernames, neither at the beginning nor in
> the middle.
> 4. We do not permit "-" at the beginning of usernames (something which
> POSIX explicitly suggests, btw)
> 5. We require that the user name fits in the utmp user name field, so
> that we can always log properly about it.
Re: You all presumably know why. (Score:5, Insightful)
There are so many ways to add an username Poettering won't like. The majority of programs for creating new accounts (except for adduser). Samba+AD, as you said. LDAP. Any random "pull authentication from a database" script. Using an editor on /etc/passwd. Etc.
POSIX defines a minimal set that must be supported, and systemd fails to handle even that.
But this is not the damning part -- every piece of software can have bugs, any non-trivial piece of software has bugs. This is natural. What's totally, utterly unacceptable, is responding to an obvious, critical bug, that also contradict the standard without providing a rationale, with a WONTFIX.
On a shit package that applies rainbow colors to a line of text, this would be grounds for immediate purging.
On something that wants to replace init+rc+mount+pm-utils+DNS+lxc+about everything else, it's grounds for nuking an entire distribution from the orbit.
Re: (Score:3)
One of the reasons my employer will stay away from systemd and, if that becomes unworkable on Linux, will move to one of the xBSDs. Replacing things that work well with complex crap is just not acceptable at all. It does not speak well for the current state of the Linux community that an incompetent cretin can engineer a hostile takeover of this size.
Re: (Score:2)
From Raster's comments about his brief time working for RedHat some time back we should have seen this coming when we left most of the heavy lifting in linux to RedHat. As far as they can tell Lennart is the genius and Linus is as bad as Lennart's insults say he is.
Re: (Score:2)
It does look like the security problem was fixed:
https://github.com/systemd/systemd/pull/6300 [github.com]
So they're at least no longer doing the "fallback to root" behavior. Although they still didn't fix the problem of systemd incorrectly deciding that certain usernames are invalid.
Re:You all presumably know why. (Score:4, Interesting)
And yet that part isn't 100% separate... it cannot operate on its own, it requires libsystemd -> it isn't separate. While it is true it is mostly unused it is a gross misrepresentation to say it is 100% separate.
Systemd is a poorly thought out concept.. Half of the feature-creep is because of a lack of understanding and the other half due to NIH. ... sure starting with a number is bad BUT blocking a "." in the name... that SMB and AD issues right there...
The recent "username starting with a number" bullshit is clear proof of that... username start with a number & wanting a unitfile executed as said user ? TOBAD... executing as ROOT... Systemd still hasn't resolved this & their preferred solution right now is redefine what a valid user is
Or what about the rapid polling of getpid() ?
its a flawed concept
Re: You all presumably know why. (Score:5, Insightful)
The username starts with a zero thing where closed days ago.
Why the fuck should an init system even CARE what the user name is?
Why the fuck did that init system reinvent user handling that the OS was ALREADY doing?
Why the FUCK does systemd have it's own fucking DNS implementation?!?!
Calling systemd SHIT is an insult to every piece of excrement, feces, turd, and dung that will ever be egested in the entire past and future history of this and every other fucking universe.
Re: (Score:2)
Look, there are at least 3 styles of programming:
1) int a[16]; index=something(); SOMECODE; b=a[index];
2) int a[16]; SOMECODE; index=something(); b=a[index&0x0f];
3) int a[16]; SOMECODE; index=something(); if((index=16)) process_error(); b=a[index];
The first one is a disaster waiting to happen because you rely on something() to return proper values and on SOMECODE to not change index and not to allow jumps inside it. And as I understand the problem it was closed by 1st way.
Re: (Score:3)
It was closed for transparently bullshit reasons.
Firstly Lennart Poettering displayed an alarming ignorance of the way in which user names are managed in Linux based systems. "I wonder which tool he used..." LP clearly doesn't realise it is possible to add a user to a Linux system with the cat command, if you so choose.
Secondly, his insistence that Linux has a standard format for user names is bullshit. Linux (the kernel) has no concept of user names (how does the lead of an init system project not know tha
Re:You all presumably know why. (Score:4, Insightful)
No. The problems in systemd were closed because the maintainer didn't like people pointing out that his design is shit.
Re:You all presumably know why. (Score:5, Informative)
Make no mistake, this is a turf war.
Who's in charge? The user? The kernel? Ring-0?
The answer to this is different depending on the topic. The topic here is init and who gets to say what the rlimits are and how. There are lots of other topics - random numbers, filesystems, network attach-detatch, routing etc. For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this".
This is generally fine, but for each there will be a slashdot thread with many jerks represented.
Re:You all presumably know why. (Score:5, Insightful)
...For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this"....
At that point, the need for an overall system-level architect comes into play. Someone who looks at the overall system, its architecture and design goals and decides the best way to implement features and fixes.
.
To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.
Re: (Score:2, Interesting)
To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.
No, it's both. There was a valid problem: sysvinit was decrepit and unsuitable for modern systems, as seen by the fact that every other Unix system out there has abandoned it and has something that resembles systemd in some way (Solaris has SMF, MacOSX has something else).
But because there's no overall system-level architect, some g
Re:You all presumably know why. (Score:5, Insightful)
sysvinit was decrepit and unsuitable for modern systems,
This is complete bullshit. My (modern) computer worked perfectly fine before systemd. There was zero improvement after my preferred distro replaced init with systemd. Maybe it booted up 2 seconds faster? I don't know, it's linux, I don't ever fucking reboot it. The only change in my life was how much time I had to spend learning systemd bullshit that added ZERO VALUE to my use of linux on my pc.
So you better get a LOT more specific as to which system was "unsuited" for sysvinit before you start making blanket statements like that or people are going to continue to call you out on your bullshit.
Re:You all presumably know why. (Score:4, Informative)
Mod parent up...
Classical init was made to handle monitoring of services, making sure they get restarted if they fail but not over and over if they keep failing. This was done with inittab.
Unfortunately inittab because too limiting, especially when it came to starting order and dependencies, and so everyone abandoned it, replacing it with a bunch of shell scripts, different depending on distribution and Unix variant. Alas, the process monitoring was lost in that change, so everyone had to run stuff like monit and write a bunch more scripts.
SystemD brings proper daemon monitoring back, on steroids. It does away with stupid PID files and it handles dependencies very very well. It is an enormous leap forwards.
Alas, it also decided to solve a bunch of non-problems like logs and DNS resolution and file system mounting. Problems that already had really well tested solutions that could be relied on to never break.
(Yes, snatching STDERR from a daemon is genius. Definitely. But what was wrong with then handing the output to the syslog daemon?)
Re: (Score:2)
https://en.wikipedia.org/wiki/... [wikipedia.org]
https://en.wikipedia.org/wiki/... [wikipedia.org]
Or just have a look at this list:
https://en.wikipedia.org/wiki/... [wikipedia.org]
There are many alternatives to systemd that handles the issue you mentioned above with deamon monitoring.. This is with systemd there are loads of cases that are more or less impossible to handle in a sane way without having to redo/recheck the configuration after every single upgrade done of packages..
There are also a lot bigger issues with systemd where it's causing pure secu
Re:You all presumably know why. (Score:5, Insightful)
That's because in-part design-by-committee ends up with the noisiest, stupidest person on the committee calling the shots, that project ends up catering to the lowest common denominator.
A large part of why Linux itself is successful is that while there's a lot of input, there's a single point of decision making in the form of Torvalds himself, and he's both smart enough to generally make good choices, and to listen to the debate and weigh the arguments to make a decision.
Lennart Poettering is no Linus Torvalds. Perhaps something to replace System V and BSD inits is necessary, but Poettering's work with pulseaudio is itself incomplete; the init system is far too important to trust to him when his sound daemon, a relatively small but important piece of the desktop system, isn't really finished to a polished state.
Besides, with the advent of the VM model for hosting and "cloud" where VMs are created and destroyed on an as-needed basis and automatically, stripping down the init process to the bare-minimum needed for a VM and using some kind of staging system to spawn the right conditions in the VM init process is probably more important than some all-knowing, all-seeing system that seems more tailored toward long-running, general-purpose computing anyway. The problem that SystemD solves isn't the new problem, it's the old one.
Re: (Score:2)
... The problem that SystemD solves isn't the new problem, it's the old one.
systemd actually solves a problem?
Like hell.
It's a solution in search of a problem from a close-minded CODER who never saw anything he couldn't solve by writing MORE crap code.
Poettering has a hammer - MUST WRITE MOAH CODEZ!!! - and to him, every damn thing is a nail. His solution is ALWAYS to write more of his own code to do ANYTHING. That's why systemd reinvents all kinds of crap it doesn't need to.
Poettering is a close-minded, unthinking amateur.
Re: (Score:2)
What do you call design by committee but adopt by technical evaluation?
I mean the systemd project itself may be shit, but for some reason all the technical maintainers of distros who have nothing to do with systemd think the opposite.
Re:You all presumably know why. (Score:4, Informative)
They want gnome and systemd is the price.
Re: (Score:2)
Poettering's work with pulseaudio
Holy crap, that steaming turd called pulse was Poettering's work? Fuck me that explains so much now.
Re: (Score:2, Interesting)
incorrect so stop spreading FUD...
sysvinit is perfectly fine. The issue was sysvrc & more specifically the really bad sh coders that redhat had.
SysVinit as init, ie pid1 is good enough... its boots from the kernel, its launches RC, it reaps zombines and it shuts down the system. THAT IS ALL INIT NEEDS TODO.
Sure pid2 might need to be more complex BUT PID1 does not! especially if you need todo an update w.r.t. RC, which with systemd needs a reboot DERP!
SysVInit is very simple and does its job well; runit
Re:You all presumably know why. (Score:4, Interesting)
...For all these things and many more there has been a turf war along the lines of "We will fix this in the kernel!", "Oh no you won't, we will fix this with our daemon", "Oh no you won't, my userland administration tool will fix this"....
At that point, the need for an overall system-level architect comes into play. Someone who looks at the overall system, its architecture and design goals and decides the best way to implement features and fixes.
.
To this Linux outsider, it seems that systemd was implemented more because someone decided to do it, rather than being done because it was the appropriate solution to a problem.
Unlike most complainers (some that simply doesn't understand systemd at all) systemd solves a number of real world problems created by the disconnect of how computers used to be used (let's call it "static" configuration) and how a system is used today (... "dynamic" configuration).
If systemd is so bloated, reinvents the whole of Linux, is a Microsoft conspiracy etc. why is that it actually solves (most) problems with older init systems? Why is it modern Unix systems have similar "dynamic" init systems rather than the old? Why is it nobody else actually created a modern init system that can be used for the same things as systemd but "follows the Unix philosophy"*?
In a was systemd is kind of a hack - but that is because it tries to integrate into the Unix design and allow it to do things it wasn't designed to do. In some cases maybe systemd have to much of hack in it but again: where is the alternative?
Note: I don't really like systemd.
(* I strongly maintain that people taking about 1) doing one thing well being a Unix thing rather than a design thing 2) thinking that philosophy is actually applied to modern Unix systems are seriously confused)
Re: (Score:2)
Before SystemD, when I restarted a service|daemon, I would see a console message when the service stopped/restarted or failed. With SystemD I see absolutely nothing for success or failure. Improvement? Certainly fucking not. Needing to do a PS|GREP on the service is hardly an improvement over anything.
Re: (Score:2)
I hear that line a LOT but nobody ever seems to provide examples of even trivial problems solved.
Re: (Score:2)
Indeed. Linus is an excellent kernel architect, but he fails pretty seriously on the system level.
Re: (Score:2)
The fact that Linus has only made a minor comment rather than a vulgar tirade should be telling to all.
So... Linus is praising it with faint damns. Okay.
Given Linus's legendary abusive style that could be a valid argument, but I'd be happier with a stronger endorsement.
Re: (Score:3, Informative)
Indeed; its author campaigned to get it into every major DE and distribution, starting with a proposal to have GNOME depend on logind. [1] He later congratulated trolls who pushed it on debian-devel [2], publicly, on Google+. [3] Later, he moved to force udev to depend on kdbus (and thus systemd; though that was thwarted by LKML), adding "Gentoo, this is your wake-up call." [4] Now, what type of developer treats his fellow FOSS members like that
Re: (Score:2)
^^^Mod. This. Up.^^^
Re: (Score:2)
The joke is, it isn't doing anything wrong, people just don't "trust" it because change is scary.
It was a brilliant version of the joke because both sides can laugh at each other.
And everybody gets to keep the init system they wanted, except for the people that don't know how, who will probably whine a lot even though it doesn't affect people not fiddling with it.
Re:You all presumably know why. (Score:5, Interesting)
I quote myself...
More pointedly, systemD has recently been found declareing usernames that are considered valid by the system at large and by POSIX standards, to be invalid and selecting a new userid at random (on some very common systems, root) and silently running processes under that user id.
This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large. By many, it is considered a security breech. Based on the comment from Linus, I suspect he does not consider this to be sane behavior.
The systemD developer community has demonstrated reluctance to correct this observed behavior.
This isn't "change is scary". This is, the damned thing is broken and the developers went into Pewee Herman mode (I meant to do that! I won't fix it).
THAT is scary. The rude and dismissive attitude around the cult of SystemD is even more scary.
Re: (Score:2)
This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large.
The counter-argument was that it is not supported by distros already, for many years, for other reason, so there is no good reason for systemd to support it.
Re: (Score:3)
Point in fact, distros DID support it, which is how the issue was discovered.
Some wrapped the command that did it, but most didn't.
The core issue isn't the bug. The core issue is the pattern of rude and dismissive responses to the bugs.
Re: (Score:2)
What do you mean "not supported". There were some scraps of documentation in some places saying it wasn't supported, and documentation in other places (e.g. POSIX) saying it was. There is no real Linux userland standard, so this was really just systemd people unilaterally declaring it to be so and blaming users for the massive hole.
Re: (Score:2)
Last I heard it was marked WONT FIX
Re: (Score:3)
The issue (which has a CVE with a critical score [nist.gov]) was closed as "not a bug". [github.com]
Think about that for a little while before responding again that it was "fixed".
Re: (Score:2)
Nobody uses POSIX, but everybody maintains some amount of POSIX compatibility. Welcome to 1995. Oh, wait...
Re: (Score:2)
My advice, look up the word "hypocrite." Dictionaries don't hurt, man. But words have meaning. Your insults will sound a lot better if you select one that is relevant, instead of just using a medium-sized word that sounded impressive.
Re: (Score:2, Insightful)
More pointedly, systemD has recently been found declareing usernames that are considered valid by the system at large and by POSIX standards, to be invalid and selecting a new userid at random (on some very common systems, root) and silently running processes under that user id.
This is an EXTREMELY non-standard behavior and as such, unexpected by the user community at large. By many, it is considered a security breech. Based on the comment from Linus, I suspect he does not consider this to be sane behavio
Re: (Score:2)
last I heard it was marked WONT FIX
Eventually systemd will replace the kernel (Score:5, Funny)
Linus knows his time is short
Repent, Linus, and maybe systemd will allow your kernel to run as a background process for housekeeping and legacy tasks.
Re: (Score:2)
When Linus did not like previous solutions (CVS, SVN) yet his chosen program (BitKeeper) went apeshit, see what he did. Let's see how this goes...
Not very sytemd like (Score:5, Funny)
Surely in the systemd era, we should be deprecating setuid on executables, and replacing it with some kind of systemd api. This provides a much more modern "unified" approach then all that minimalist, modular rubbish that infected the system for so long.
Re: (Score:2)
I know you're trying to be funny, but for those who don't know it, setuid executables have been deprecated since a while.
/bin/ping /bin/ping
$ ls -l
-rwxr-xr-x 1 root root 44104 Nov 8 2014
See? No setuid bit, and still able to mess with raw packets.
The old setuid thing has been replaced with granular capabilities(7) bits, which are stored in a "security.capability" extended attribute.
/bin/ping /bin/ping = cap_net_raw+ep
$ getcap
Re: (Score:2)
nope. /bin/ping /bin/ping
$ ls -l
-rwxr-xr-x 1 root root 44104 Nov 8 2014
Debian jessie.
Joke? (Score:2, Funny)
It init funny. Not at all.
Re: (Score:3)
how about stigginit to init with sigint?
(head asplodes)
Re: (Score:2)
It init funny. Not at all.
Well, your comment is funny at least. But I'm not seeing the attempted humor in Linus' line... it just seems like a plain old comment. ... unless they were talking about GNU scanner software.
You were warned (Score:5, Insightful)
SystemD is a trainwreck from day one and just keeps on piling more of it. If it were only init, things would've been more than fine. But no. It's a whole project of reinvented crapware that is reinvented BADLY. And distros blindly install more and more from the "project". Like Ubuntu and their idiotic decision to switch to systemd-resolved which was wrought with nothing but trouble, rendered Ubuntu 17.04 dead in the DNS water for a month since its release! I wonder which maintainer got paid to subvert Ubuntu with that.
* networkd assuming dhcp client role, but then not renewing lease (freedesktop bug #82731 -- open for 3 years now!!), among many other issues ...
* resolved assuming DNS resolver role, but then not being nearly compliant with RFC, among many other issues, some even serious security vulnerabilities
* consoled taking over console, but then someone realized it's a REALLY dumb idea so they scraped it (for now)
* timesyncd assuming ntpd role, but then doing stupid things like defaulting to Google NTP which is NOT a normal NTP service! Asked by google to not do that, responded EWONTFIX (systemd github issues #437), among many other issues
In fact, it's even bad at being "just an init". Good luck with those NFS mounts and systemd. Good luck with "A start job is running" when it encounters a trivial situation that every. other. init. can. work. around.
It's a shitshow fueled by arrogance of "we know better than all of you combined", just a quick look in the github issues is sufficient to see this. It's so out of control, that issues found to be 10 on vulnerability scales are closed as not a bug (CVE-2017-1000082).
Every software has bugs, but systemd bugs are closed EWONTFIX because the principal developer has zero clue about modern operating systems. The principal developer of an init for a traditionally server oriented operating system* who, by his own words, never administered servers. And who, by his own words, disables read ahead prefetch because "systemd developers all run laptops with SSDs and don't need it"....... !!
It's a sinking ship, rats are fleeing, and more and more professionals are getting SICK of it. You were warned, you laughed, you called us luddites, now enjoy the turd.
*) With a server market share of more than 50% (look up Netcraft monthly stats), and a desktop market share of 1% -- so guess where the priorities are
Systemd: What Does It Solve? (Score:5, Interesting)
I am not questioning you opinions on systemd, particularly since my father, a retired CE and lifelong *nix user dislikes it with a passion. But I'm way to ignorant of the dirty mechanics and politics of Linux to understand how, with so many presumably knowledgeable folks who dislike systemd, it became a standard in the more popular distros. Does it solve some vexing issue for the maintainers of these distros? What do these people find so compelling as to make such a fundamental change?
Re:Systemd: What Does It Solve? (Score:5, Interesting)
It's a trojan horse story.
Maintaining unit files seemed easier than maintaining sysvinit scripts, so the distro maintainers liked it (along with a couple of other init replacement contenders). It's also shiny and new and backed by RedHat.
There was feature creep and capricious architectural design before most distros picked it up, but perhaps people didn't think that it would keep getting worse and worse. Now the project encroaches on more and more system roles and doesn't play well with the existing tools.
Re: (Score:3)
because other projects started integrating systemd parts. other distro's could either drop those projects (but they were popular), or use systemd and continue to offer said projects.
and all in all, systemd does offer some benefits, or rather said promises, but it just does too much and keeps evolving as 'the blob' growing bigger and bigger. when other distro's stepped in, it was still something small'ish.
Re: (Score:3, Interesting)
Re: (Score:2, Informative)
If you're going to bitch about bugs, there are so many to bitch from. But the ones you linked seem perfectly reasonable won'tfixs.
- One single person reporting that DHCP leases don't renew even though his logs show that the client attempted renewal. If this were worth looking at there'd be thousands of confirmations. Why should the bug be fixed if it can't be confirmed?
- Defaulting to google's NTP service is perfectly reasonable given the complete lack of alternatives. As shown in the bug tracker you are sp
Re: (Score:3)
systemd is linux cancer (Score:2)
some things use systemd, others use the init.d scripts and the /etc/default/ (even in debian 9 the latest) systemd appears to not use /etc/default or you need to generate the systemd file from it.
Then you have to daemon-reload systemd to try out
Finding these systemd startup scripts is a nightmare if you need to adjust them.
Maybe we upgrade linux to bsd nextime.
Thanks for the new sig (Score:2)
...it's not only not clear that we want to do this... - Linus Torvalds (https://lkml.org/lkml/2017/7/6/577)
GNU Linu-x, not GNOME Lenna-x (Score:2)
Nuff said
Devuan is looking good (Score:2)
I am using gentoo now, but devuan is looking like it might be a decent distro.
Re: (Score:3)
It's init, innit?
Re: (Score:2)
The title is in reference to chapter titles in some older humorous books. The house at Pooh Corner is the one that I can think of, but it's in others from the same era.
For instance,
"Chapter IV
In Which it is Shown that Tiggers Don't Climb Trees"
The author is implying that it's another piece of an ongoing saga that's got some silliness in it.
Re: (Score:2)
There's a 68.71% chance you're right.
Re: (Score:2)
Apparently at least one editor knows his stuff better than some ignorant AC.