In Which Linus Torvalds Makes An 'Init' Joke (lkml.org)

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."

Comments

You all presumably know why.

[QuietLagoon]

I don't know why. Can someone explain? thanks.

Re:You all presumably know why.

[darkHanzz]

Presumably, this is a poke towards systemD. It has suffered from feature-creep, which directly opposes the unix-philosophy of doing only one thing, but doing it well. Recently, there was a problem with, I believe the DNS server which is part of systemD.

Re:You all presumably know why.

[TechyImmigrant]

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.

[QuietLagoon]

...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:You all presumably know why.

[Grishnakh]

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 guy just decided to make his own solution, which very likely is suboptimal because he's not a system-level architect and there seems to have been little to no other input on the solution. People complain about "design by committee", but this is what happens when you don't have some amount of design-by-committee: you get one person's pet project which might have some great ideas but then has too many rough edges or even severe design flaws because that one person's judgment isn't tempered by other peoples' experiences and criticisms (esp. if that one person is actually hostile to outside criticism...). Even the Linux kernel has a good amount of design-by-committee if you look at its history: different subsystems have different maintainers, and there's been a very active mail discussion list ever since the start where people discussed major changes before just merging them in willy-nilly.

You make a great point about having a system-level architect. Red Hat has been trying to fulfill that role for a long time now, but has done a very questionable job really. Just the fact that they've been pushing GNOME so hard shows their judgment isn't very good; Gnome has horrible architecture (esp. its terrible and unstable and undocumented Gtk+ library) and just isn't very functional. It's another great example of a small team with some wacky vision pushing it on everyone else without any external input/criticism or pushback. Red Hat projects seem to be like this a lot.

Re:You all presumably know why.

[TWX]

So SystemD is the Emacs of init?

Re:You all presumably know why.

[Anonymous Coward]

Yeah. systemD supports the Windows-philosophy of doing almost everything, but doing it half-assed. Besides, what's wrong with having the DNS server be part of the init system?

Re:You all presumably know why.

[Anonymous Coward]

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.

[Anonymous Coward]

Don't forget the recent severity 9.8 CVE regarding invalid username handling that Poettering closed as NOTABUG. It's a trainwreck of bad design driven by an egotistic idiot.

Re:You all presumably know why.

[Anonymous Coward]

> 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.

[TWX]

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:You all presumably know why.

[Anonymous Coward]

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.
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 ... sure starting with a number is bad BUT blocking a "." in the name... that SMB and AD issues right there...

Or what about the rapid polling of getpid() ?

its a flawed concept

Re:You all presumably know why.

[TWX]

So what editor do you use?

Re:You all presumably know why.

[Anonymous Coward]

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 is very very good as well, likewise openrc-init is good. The commonality is simple PID1

So because Redhat cannot write good sh they push a concept with people that can't write C/C++ not can design an RC system and when they run into issues they absorb concepts rather than fixing their issues.

Re:You all presumably know why.

[bferrell]

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:You all presumably know why.

[someone1234]

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:You all presumably know why.

[Anonymous Coward]

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.

[Megol]

...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: You all presumably know why.

[DeHackEd]

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: You all presumably know why.

[Anonymous Coward]

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: You all presumably know why.

[Anonymous Coward]

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.

[Anonymous Coward]

... 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: You all presumably know why.

[spire3661]

This is so fucking backwards its not even funny. If you truly dont want logs to be tampered with you store them on write-once media. Shipping logs across the network introduces a whole host of vulnerabilities.The network is NOT the computer.

Re: You all presumably know why.

[KiloByte]

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:You all presumably know why.

[bferrell]

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:You all presumably know why.

[amorsen]

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: You all presumably know why.

[gweihir]

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: You all presumably know why.

[gweihir]

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.

[gweihir]

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: You all presumably know why.

[Anonymous Coward]

There is a reason why all the major distributions use [systemd]

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? I'll tell you: someone looking for a fight.

No legitimate libre software project needs to be pushed to gain adoption. Perhaps you should read more about Lennart's original goals, such as "gently pushing everyone to use the same standard base". [ https://lists.fedoraproject.org/pipermail/devel/2011-June/152672.html ] This attempt to "standardize" was little more than building a solution and *then* finding problems to fix with it. In short, it was politically-motivated. It's a big part of why, predictably, it has become a Gordian knot of "modular" components. Moving away from systemd 10, 15, 20 years from now will be a nightmare; I bet they haven't thought about that, though! By keeping components 100% divorced from each other, a proper *nix system can swap components out in just about any order or combination. Those who've invested too much into systemd will need to find a replacement for each systemd "module" they actively use if they're going to get away from it. It's the classic all-in-one software architecture that looks easy to adopt, but proves extremely painful to move away from. Do you think that was by accident? If so, I've got swamp land in Arizona for sale.

If it was as you say, there wouldn't have been a big upset over its adoption. If what you said was true, literally every distro would use it and it would have little to no flaws. A big part of what people dislike about systemd is its culture, both users and developers. Before you fire out that "only technical discussion plz" bullshit, take a look at other projects. Would you want to be part of any of them if they had a shit culture? If they arbitrarily closed bugs, assuming their software is perfect? Social merit is just as relevant as technical merit; without both, you won't get users and your community will die, which will lead to bitrot and eventually, software death. Consider that the reason most people use systemd is a) distros were "gently pushed" to use it and b) most users don't pay much attention to init. With those two facts in mind, how can anyone say systemd earned that position? It was marketed and pushed, plain as day. Your willful ignorance does not contradict it.

Now that systemd architectural flaws are showing their faces (as others have predicted), the rabble are scrambling to defend the poor technical choices made by the systemd team. The biggest supporters of systemd (Arch Linux devs in particular) lied -- yes, lied -- to their users about their plans for systemd. [5] One such developer was rewarded for their duplicity with a spot on the systemd dev team: Mr. Tom Gunderson, who I've had the displeasure of communicating with personally. Even one of his fellow devs was pissed he was spreading false information: [6]

At what point will you and others realize that the systemd team is socially manipulative and does not appreciate others finding holes in their software? How many other teams would dismiss as NOTABUG or WONTFIX, like the recent '0day' username bug? They are not good libre software citizens and are hardly worth the bits their code is stored on. The Bazaar has little use for an Ivory Tower.

Perhaps you should read up on the history yourself before proclaiming others are full of shit.

[1]: https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00427.html
[2]: https://lists.debian.org/debian-devel/2012/11/msg00350.html
[3]: https://plus.google.com/+LennartPoetteringTheOneAndOnly/posts/jcCjMct3SJ3 (See Lennart's Dec 19th commen

Re: You all presumably know why.

[gweihir]

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: You all presumably know why.

[gweihir]

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.

[Anonymous Coward]

https://en.wikipedia.org/wiki/...
https://en.wikipedia.org/wiki/...

Or just have a look at this list:
https://en.wikipedia.org/wiki/...

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 security issues just because they refuse to stop gobbling up things we already have stable things for...

If systemd was a *PURE* init-system that just maintained ISC's dhclient, ntp-client (of your choice) and so on i would have no big problem with it, except that it has removed easy modifications of startup scripts.. But the way it works right now is just horrific.

Re: You all presumably know why.

[chihowa]

The issue (which has a CVE with a critical score) was closed as "not a bug".

Think about that for a little while before responding again that it was "fixed".

Re:You all presumably know why.

[dbIII]

if everyone here used all the energy they have to hate on SystemD, to actually fix those bugs

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.

[dbIII]

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.

They want gnome and systemd is the price.

Re: You all presumably know why.

[dbIII]

The project is a massive "cathedral" instead of modular pieces - planned for that reason or not a fork would be more difficult than devising a total replacement structured differently.

Re:You all presumably know why.

[segedunum]

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: You all presumably know why.

[jeremyp]

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 that?) His reasoning seems to be based on the fact that the adduser utility default configuration does not allow user names to start with a number. This constraint is defined in the adduser configuration file, a file that a system administrator can edit to relax the rules, if they so choose.

Finally, his understanding of portability is backwards. He claims that portability means only accepting the most restrictive of user names, but it doesn't it means accepting the most liberal of user names so that an administrator on any Linux system can use any user name. He claims he wants unit files to be portable, but where a user name is concerned, that is impossible unless the user is one that is defined on any Linux system,

LP displays ignorance about a significant part of Unix-like operating systems and also stupidity in terms of reasoning about portability. Do you really want such a man in charge ofd developing the code that runs as process number 1?

Re:You all presumably know why.

[Eunuchswear]

And the whole thing came up because someone (and not a systemd developer) decided that rlimits for setuid processes should be copied from pid 1, because that seemed a good default. Linus didn't like the patch, making his joking reference to systemd, but he was right whatever pid 1 was, shell, init(1), upstart or whatever -- copying rlimits from pid1 to all setuid processes makes no fucking sense whatever.

https://lkml.org/lkml/2017/7/6...

Re:You all presumably know why.

[Eunuchswear]

You know, the thing that always intrigues me is that people spend an inordinate amount of time criticising Poettering's code (pulseaudio, systemd), but nobody ever succeeds in doing better enough to get their solution adopted by as many people.

Odd that.

Eventually systemd will replace the kernel

[Anonymous Coward]

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.

Not very sytemd like

[Mostly a lurker]

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:Not very sytemd like

[tender-matser]

I know you're trying to be funny, but for those who don't know it, setuid executables have been deprecated since a while.

$ ls -l /bin/ping
-rwxr-xr-x 1 root root 44104 Nov 8 2014 /bin/ping

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.

$ getcap /bin/ping /bin/ping = cap_net_raw+ep

You were warned

[Anonymous Coward]

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

Re:You were warned

[thegarbz]

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 specifically requested NOT to default to pool.ntp.org unless you're the vendor, and then the configuration becomes vendor specific. i.e. if your default install is hitting Google.com then maybe you should be complaining to Ubuntu or Debian or Arch or whoever decided to blindly include systemd-timesyncd without creating a proper config default for their distribution.
-NFS mounts are not a problem providing you RTFM.
-A start job is running is a perfectly sane response to waiting for a critical part of a boot process, and it has the perfectly sane action of eventually timing out. If this occurred without change then chances are it's a hardware failure. If it occured due to an upgrade then you distribution maintainer did a shit job at adding the new package. e.g. the "bug" introduced in systemd 230 which curiously only affected Arch linux.

Every software has bugs, but systemd bugs are closed EWONTFIX because the principal developer has zero clue about modern operating systems.

Actually I find the problem more with the peanut gallery who think that ever turd smeared on a bug tracker is critical or even real. Like the guys who keep quoting the "open bugs" graph of systemd without realising that some 2/3rds of the bugs being posted are RFEs.

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

With the servers, where management of massive logs and monitoring of running processes was a key design goal and one of the primary reasons why the likes of Debian and RHEL adopted systemd.

Re:You were warned

[rl117]

Look, NFS mounting is broken. BROKEN. It works a small percentage of the time, but most of the time it fails to mount anything successfully at boot. The mount exists, but any attempt to use the mount results in an IO error. systemd fundamentally failed to bring up the NFS services properly, leading to a non-functional system. I can log in on the console, unmount everything, then remount it and it works perfectly after that manual fix. But on a day to day basis, I can't rely on using NFS mounts with systemd.

This is unbelievable. Correct order of service startup was one of the big arguments for systemd. Despite the fact that this was never a problem with insserv dependency ordering with sysv-rc. My FreeBSD systems can mount NFS correctly. Every. Single. Time. Because their startup isn't buggy or defective. systemd has had this issue with NFS for bloody years. Still unfixed today. Don't make excuses for it; fix it.

Startup should be deterministic and consistent. With systemd, it's a lottery whether the system will come up correctly configured or not. That's plain stupid, and a massive regression. I've also had other instances where the boot hangs indefinitely; this is also beyond ridicule.

Re:init, or "init"?

[wonkey_monkey]

It's init, innit?

Re:Joke?

[TheGratefulNet]

how about stigginit to init with sigint?

(head asplodes)

Systemd: What Does It Solve?

[Frosty Piss]

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?

[shoor]

I'm a long time user of Linux, and I've been scratching my head over the question of why are so many distros using systemd if it's so bad also. This has been discussed on slashdot many times. I can remember in the early days of systemd when it came up here on slashdot, a suspiciously methodical bunch of replies to any criticism would crop up, as though someone had been hired to defend it. It was these apparently crafted replies, supposedly designed to win people over, that made me more wary and suspicious than anything else. OK, that doesn't answer the question, it's just some background. All we groundlings know are what people who presumably do know tell us, and we have to decide which explanations have a ring of truth and which smell fishy for some reason. Right now I'm thinking particularly about a slashdot topic from July 3:

'Severe' Systemd Bug Allowed Remote Code Execution For Two Years

and an anonymous coward earned a score of 5 with a posting that to me had the ring of truth: https://it.slashdot.org/comments.pl?sid=10813029&cid=54733511

Re:Systemd: What Does It Solve?

[chihowa]

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:Systemd: What Does It Solve?

[sad_]

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.