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

init, or "init"?

[Anonymous Coward]

init has been working great for me. "init", however, ...

Re:init, or "init"?

[wonkey_monkey]

It's init, innit?

Re:init, or "init"?

[Anonymous Coward]

It's in what?

Re:init, or "init"?

[Anonymous Coward]

Your shell quoting rules must be broken if you think "init" eq \"init\".

Re:init, or "init"?

[Anonymous Coward]

British dudes love black chicks.

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.

[Aighearach]

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.

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

[Aighearach]

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.

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

[bferrell]

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.

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]

choice !== trust, it's very difficult to unchoose systemD from a distro unlike other init systems because it gets it's claws into everything. I think regardless of whether or not I like it, it's important that it's a choice.

Re:You all presumably know why.

[Anonymous Coward]

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

While sysvinit was unsuitable for modern systems in a lot of way, systemd is not a valid solution. Seriously, I've never seen a *nix init system that didn't have a horrible bootchart on my system--ie, one where there's a large drop in CPU usage or I/O throughput repeatedly. The only real "solution" was to get an SSD, but that's not really a solution either.

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.

It's not that they don't have external input/criticism or pushback. It's that they're so used to it--thinking in part it's distro wars--that they aren't listened to a lot of fundamental input on why systemd is flawed. Honestly, it falls into the same trap as a lot of system-level architects: it thinks it actually has universal control over any system with systemd. Yet it doesn't actually enforce those controls at every step--hence an "invalid" username can exist and is not properly handled. Nor really can it, usually, if it's adopted by other distros--something that seems the goal of most distros that invest into a project. The only "solution"--which still isn't fully one--is to have an open discussion on your component, document all its requirements, put in as many reasonable safety checks as you can, and then when stuff breaks or there's security vulnerabilities on some systems because they ignored the documented requirements, people can reasonably blame that distro instead of the project originator.

Since that's obviously not something Red Hat (or Ubuntu is a big one too) will do--because NIH is their bread and butter and "we have a vision"--, it does fall to the kernel to enforce things precisely because it's the best place for a ring leader in the distro circus. Some stuff--Stack Clash--are unfixable, though, at the kernel level.

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.

[Anonymous Coward]

Lennart just doesn't have enough experience to understand that logging is important.

Re: You all presumably know why.

[Anonymous Coward]

You have a point there. Linux was just fine without systemd, but now I have to learn a new whole set of commands to be able to properly use it. And btw, no other unixes use it so ... BS

Re:You all presumably know why.

[Anonymous Coward]

"Someone who looks at the overall system, its architecture and design goals and decides the best way to implement features and fixes."

Found One!

Patrick Volkerding

Re:You all presumably know why.

[Anonymous Coward]

I work at a startup company with very few developers and a lot of work to do. Furthermore, there are bad team dynamics and consequently there is little overall design discussion. Almost every subset of our software / hardware ends up as someone's pet project. It's rotten.

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]

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.

This is how things get done in open source. However sanity is suppose to come from people deciding which of the many competing projects to pick from.

Ex: there are many init systems, all written because someone felt like it. Distro maintainers repackage which ever ones they feel like into their distro. Users pick which ever distro they feel like.

Overall, this results in a lot more sanity that you would get without the layers of (often bad) choices, but generally fails as we leave the unix philosophy behind: so many things have been tangled into systemD (things it does, and things that depend on it), that is hard to choose something else now, since there isn't a drop in replacement: We are left with fewer bigger choices.

Its worth noting that opensource project that are crap, not well thought out, etc, are more useful contributions to society most other things random people just decide to do in their spare time (Ex: watch TV, complain on the internet, closed source software, etc). If we required everything to be well planned we would have far fewer contributors: it wouldn't really add better planned projects, it would simply subtract peoples fun projects from the community.

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.

[Anonymous Coward]

>why is that it actually solves (most) problems with older init systems?

Because its authors invented those "problems" out of thin air.

>Why is it modern Unix systems have similar "dynamic" init systems rather than the old?

Because NIH.

>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"*?

Because nobody needs it ever.

See? Easy answers.

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.

[Zero__Kelvin]

There were several very legitimate needs, and if you research it you will see that it is well thought out. The fact that Linus has only made a minor comment rather than a vulgar tirade should be telling to all. The fact remains that it is software, it is evolving, and no team is perfect ( no, it isn't one guy as you keep hearing ). Those who never tried to learn what they were talking about before speaking latch on to any chance to criticize because they have been proved wrong and they can't handle that. There is a reason why all the major distributions use it, and it isn't because anti-systemd trolls are smart and have educated themselves on the subject before running their mouths.

Re:You all presumably know why.

[bidule]

By many, it is considered a security breech.

aka, your ass is showing.

Re: You all presumably know why.

[Anonymous Coward]

Swallowing stderr is just asinine.

Re:You all presumably know why.

[Anonymous Coward]

Shhhhhh! The goverment has to infect Linux with backdoors somehow dude!

Re: You all presumably know why.

[Anonymous Coward]

You know, that doesn't invalidate what he said. If you want logs not to be tampered you send them to another machine that does nothing else. That's really security 101.

Re: You all presumably know why.

[Anonymous Coward]

The username starts with a zero thing where closed days ago.

Re: You all presumably know why.

[Zero__Kelvin]

First of all nothing prevents you from doing that with systemd. Second of all said technique can be defeated. Read up on the Mitnick hacks.

Re: You all presumably know why.

[Anonymous Coward]

Wow, you really are a fucking idiot.

Tell that to the company I work for that makes tens of millions of dollars per year securing communications networks for the government. They ship logs files through a VPN tunnel from least-trusted endpoints back to a trusted receiver. They *hate* systemd because of it's logging flaws. It's not a security feature, it's a security flaw.

They started re-writing all their configuration management so we can start deploying FreeBSD systems because of the systemd fiasco. Linux is dying. I just switched one of my desktops to FreeBSD and within a few days I had all my tools and various customizations moved over. I'm about to ditch the last Linux box on my network other than a Unifi controller we are running some 'tests' against.

Re: You all presumably know why.

[Anonymous Coward]

And it was also fixed several days ago.

Re:You all presumably know why.

[Anonymous Coward]

> Those aren't actual bugs that exist,

The username bug (the one mentioned) does exist (https://github.com/systemd/systemd/issues/6237), but the reporting issue was closed for the reasons mentioned (no technical reason).

Logic has vetted parts which constitute the final valid state. The correct answer was "systemD supports non-POSIX systems so we just made up our own standard and will let everyone else sort it out, since POSIX isn't whats used everywhere either". That's a valid approach, but it has to be stated that way as a concrete decision rather than "whatever, everyone who doesnt follow our custom rule is WRONG".

This is not the forum to pretend reality is how you see it as an enlightened elitist. -1 for trolling.

Re: You all presumably know why.

[Anonymous Coward]

Yea in typical LP fashion, he closed the bug as not a problem, trying to pass it off as not a problem on his end. When in fact, it is 100% on his end.

Re: You all presumably know why.

[Anonymous Coward]

"closed" is NOT fixing ... EWONTFIX doesn't resolved this.

And here we have a clear example of what is wrong with systemd...

Re:You all presumably know why.

[Anonymous Coward]

choice !== trust, it's very difficult to unchoose systemD from a distro unlike other init systems because it gets it's claws into everything. I think regardless of whether or not I like it, it's important that it's a choice.

Exactly. If this were some bullshit argument about 'fearing change', I wouldn't have switched all my systems to FreeBSD. I would have just stuck with Linux and systemd....but I didn't. I *hate* systemd. It's a *huge* pain in the ass that solves zero real-world problems for me and my team. Instead, it causes more real-world problems than switching to FreeBSD.

Re: You all presumably know why.

[Anonymous Coward]

So reluctant that it was actually fixed several days ago...

Re:You all presumably know why.

[Anonymous Coward]

you're an ignorant hypocrite

Re:You all presumably know why.

[CrashNBrn]

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: 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]

Notice how he is at +3 and you at nothing?

That is because you didn't answer anything he stated in his post. You bring up a new topic and try to dance around it.

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.

systemd HAS a design?

It's not just a bunch of random patches driven by things like "Oh fuck! When we started redoing THAT because we think we're better than everyone else, we didn't really think it through so NOW we gotta embed a DNS server in our init system!"

You've heard of shit-posting?

systemd is "design by shit-patching".

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.

[Anonymous Coward]

Good for you. Mine didn't. Not my modern computer, not my server. What it did do was work something resembling fine after the init system had an endless array of other things bolted on to it to try and pretend to make it handle system events, It had endless scripts that executed sub processes to monitor the actual daemons in case they went south. Oh and when they did go south there was no way of the system knowing if a process was even running if it didn't go through some arcane process like clearing a PID lock file.

So I'm very glad that that you're not a distro maintainer given that you have a little perfectly working anecdote in your safe little space and think that therefore there is no problem in the wider world.

Re:You all presumably know why.

[thegarbz]

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.

[Anonymous Coward]

Actually, it was invented. It's called openrc and is used by gentoo.

Re:You all presumably know why.

[Anonymous Coward]

Or, exiting zero on error!

As to the problem of swallowing stderr, that's also pretty serious. When you can run a command by hand and see a clear error message, but it isn't logged at all in the journal, that makes troubleshooting very difficult and time consuming. Example from the unit file for MongoDB:

ExecStart=/usr/bin/mongod --quiet --config /etc/mongodb.conf

Or, when Poettering's employer Red Hat does things like this in systemd unit files "... > /dev/null 2>&1" then errors aren't logged. Ran into that this week when I had a typo in a BIND file. I have over 1,900 domains on one server, so it can be very hard to find the error.

Re:You all presumably know why.

[Anonymous Coward]

Daemonized Extensible VI Layer (DEVIL), the SystemD reimplementation of EVIL.

Re: You all presumably know why.

[Anonymous Coward]

Gentoo/Funtoo allow openRC as an alternative and it works just fine. I really don't get what people think systemd does that's so irreplaceable. I mean, use it if you want... I just wish other distros would have kept the choice of inits.

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.

[bferrell]

last I heard it was marked WONT FIX

Re: You all presumably know why.

[bferrell]

Last I heard it was marked WONT FIX

Re: You all presumably know why.

[Anonymous Coward]

Feel free to hate emacs with passion, but don't compare it to systemD. That is - low . . .

Re: You all presumably know why.

[Anonymous Coward]

If so, the ticket doesn't mention it. In fact it seems like it will be kept as-is by design, because forward-compatiblity concerns seem to be considered more important.

Re: You all presumably know why.

[Anonymous Coward]

Please point to the fix, a fix has not been mentioned anywhere else, including the ticket.

Re: You all presumably know why.

[Anonymous Coward]

Systemd makes it so that even the root user can't modify the logs...

That is not true at all. The file format is open and pretty simple. Also, there's a hash, but that is used to detect corruption, but of course you can just recalculate the hash after making changes.

Re: You all presumably know why.

[Anonymous Coward]

I just love how the kids that made it try to explain why they think exit statuses aren't important.

Re:You all presumably know why.

[Anonymous Coward]

That's the Linux way, and to be fair it has served them pretty well everywhere but desktop. There is no coherent base system, everything is an add-on to the kernel and the kernel itself is pretty damn modular. Pros: you can build a system that does one thing really really well, Cons: that isn't super useful to a desktop OS.

SystemD is just one option among many. You don't have to use it, you can use RCinit, or SysV init, or no init system at all really. SystemD was written to solve real problems, they just might not be your problems.

Re: You all presumably know why.

[Anonymous Coward]

Is that you LennarD?

Re: You all presumably know why.

[careysub]

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

[buchner.johannes]

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

[Anonymous Coward]

Wow dude. You is so fucking impressive! If only the rest of the world could see how you is so smart and we all is so stupid! (Yes, you are an incompetent douche)

Backed by nothing but your insignificant opinion....

Perhaps you'd care to prove how your systemd lovechild between you and Pottering isn't completely retarded?

Re:You all presumably know why.

[gweihir]

No. Emacs works well, given enough resources.

Re:You all presumably know why.

[gweihir]

Indeed. That is the main problem with it. On wonders whether this is an indicator of plain incompetence?

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.

[gweihir]

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

[gweihir]

That is complete nonsense. Locally kept logs can always be manipulated. Takes some actual understanding to see that though.

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.

[Anonymous Coward]

This is why Trump supporters and SystemD supporters are so easy to spot. All they do is deflect.

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.

[gweihir]

Indeed. Linus is an excellent kernel architect, but he fails pretty seriously on the system level.

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]

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

That is clueless nonsense. For most situations, sysVinit works just fine. SMF, incidentally, has its own problems and many Solaris admins really hate it, but it can deal with unmodified sysVinit scripts.

Re: You all presumably know why.

[Anonymous Coward]

> That is just one example of how you are talking out your ass.

Speaking of...

> Systemd makes it so that even the root user can't modify the logs...

It doesn't, but thanks for playing.

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.

[Zero__Kelvin]

Good luck getting a clue!

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]

I moved from Arch to Gentoo in 2012 after their little push, where I've been since then. How is FreeBSD as a development environment? Are there good guides to writing portable software that'll work on both GNU/Linux and *BSD?

Re: You all presumably know why.

[Zero__Kelvin]

You clearly didn't take a few moments to get even the most basic education in the subject before replying. Thanks for proving my point that the anti systemd trolls are exactly that ... clueless on the subject matter. Off you go now ...

Re: You all presumably know why.

[Anonymous Coward]

ehm..... I think it's you that needs to learn about how things work..

*disclaimer* : I wrote this post in 2 minutes.. For the "security design" below it's just a quick conceptual description... But it should not be used either way because it's not secure....

signing of data requires us to have a private key... So if we use a private key to sign the log on the system we have a way to create signatures... So if we can do that we can just redo the whole long-file or just the parts we don't want to be left in there.. So truncate the file to the offset you want to clean out and re-add the log-entries (signing them with the available private key)..
Sure you could do public key encryption to have every logentry everything encrypted without the need for the private key... This could work to a part by having each log-entry being encrypted with the public key, and each log-entry would contain a sha2 of the previous logentry checksum + the current logentry data. This would still not prevent anyone from just cutting down the log to the point in time when they entered the system.

And for git.... Do a checkout.. modify some earlier commit and re-apply the following commits... repo will look fine, with new hashes, with the change you just made... What happens is that you just modified the checksums of the commit + any required commits after.. to push it back to the server you may ofcourse need to use the force-flag so it will overwrite the current repo the server has.

If you have the thing locally, and it's not been signed with a private key, you do not have a trust-chain and you cannot protect anything with "cryptographic signing"
As long as you keep the bookkeeping of the logs on the system that is performing the logging there are no ways to protect them, and even if you could protect a private key locally you could still just revert back to a older version of the logfile...

Please go and get a clue... they are fairly easy to come by...

Re: You all presumably know why.

[Anonymous Coward]

If such a bug was fixed I'd appreciate a link to an e-mail, git commit, or other patch that proves technical action was taken. If systemd users want to stick to technical-only, then they better pony up the proof.

Re: You all presumably know why.

[Zero__Kelvin]

Others are smarter than you. You also might want to bear in mind that you can continue to have remote logging, etc. It isn't a replacement, but additional security.

Re: You all presumably know why.

[gweihir]

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.

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

[Anonymous Coward]

So who's paying you, dude? All over this thread all you're doing is telling people they're stupid and haven't offered a single constructive or even insightful comment. What's your angle?

Re: You all presumably know why.

[Zero__Kelvin]

I understand it better than you. I too had the same thoughts initially. The difference between us? I actually educated myself on the approach they are using and understand it, while you continue to refuse to learn anything new and just keep spouting idiotic misinformation on Slashdot.

Re: You all presumably know why.

[Zero__Kelvin]

Yeah .. I didn't offer anything. The irony? You replied to a link to the information that proved they are clueless.

Re:You all presumably know why.

[Anonymous Coward]

Incoming "our behavior has nothing to do with software" argument... It's really telling that they're grasping for straws after being so egotistical.

Re:You all presumably know why.

[serviscope_minor]

biggest evil is, during this furious re-implementation, they introduce new bugs.

NOTABUG WONTFIX.

This function returns EFUCKYOU on attempted use.

Re:You all presumably know why.

[serviscope_minor]

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

[Anonymous Coward]

systemd-editor!

systemctl edit --editor-mode=emacs filename.ext

Re: You all presumably know why.

[Anonymous Coward]

Others understand quite well: Crypto designed by his brother, implemented with a default 15 minute window to allow the attacker to alter logs prior to sealing.

Re: You all presumably know why.

[Zero__Kelvin]

Nope. You at least are starting to have a clue now, though. The epoch isn't fixed. That is why the word "default" is used. Again, this is additional security, not replacement security. You can still send logs to wall and a remote server. Change the epoch if you want. Indeed, the default may be different now than it was back then. At least you finally admit there is such a facility, proving the others are cluelesslu spouting misinformation (my original point)

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.

[Anonymous Coward]

The National Institute of Health (NIH) screwed up SystemD? Why?

Re:You all presumably know why.

[Anonymous Coward]

He uses systemd for an editor and emacs for init.

Re:You all presumably know why.

[Anonymous Coward]

I guess AIX still has init as of 7.2, all the way from 3.2.5 (first time I touched it).... it's true that it has always had src, but there's the regular init starting the src subsystems.

Re: You all presumably know why.

[Anonymous Coward]

Oh dear, you don't know what the word "epoch" means, do you? You regularly post to stories and always claim to know more than anyone else, yet never provide real evidence to back up your ridiculous spouted nonsense, often arguing against those with real first hand knowledge and then vanishing when your arse gets handed to you. You're a poor troll or a Dunning-Kruger poster boy. Either way; I don't really care. You meant period or interval, yet regardless it remains racey (and the crypto hash chain is custom and unpublished which invariably reads "snake oil")

Re: You all presumably know why.

[Anonymous Coward]

And Lennart will just blame Red Hat for those bad unit files despite the fact he works for them.

Re: You all presumably know why.

[Anonymous Coward]

Give him time, he'll get there. Hey, this is systemd we're talking about here. You'll know he's really pissed when he switches to FreeBSD.

Re: You all presumably know why.

[Zero__Kelvin]

Epoch: a period of time in history, typically one marked by notable events or particular characteristics. In this case it is the period of time between key replacements, and is literally the term used in the documentation. Once again it is actually you that has been proved to be a clueless idiot. Off you go now little troll ...

Re: You all presumably know why.

[Anonymous Coward]

No you won't. Systemd will be replaced back to the old init system within 10 years. It'll take a few more security flaws to be discovered bit it'll happen

What is the advantage of systemd anyway?
  That's something I've not seen explained anywhere.

Re: You all presumably know why.

[Anonymous Coward]

Actually, it uses interval; as for your continued unfortunate misunderstanding, QED, I guess.

Re: You all presumably know why.

[Anonymous Coward]

Personally I use OpenRC.

OpenRC does what systemd was built to accomplish, but without consuming services.

Re:You all presumably know why.

[Anonymous Coward]

The wrong one apparently--one that capitalizes the "d" in systemd.

Re: You all presumably know why.

[gweihir]

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.

[Anonymous Coward]

NOTABUG WONTFIX.

This function returns EFUCKYOU on attempted use.

My distro version doesn't provide this support. I tried upgrading systemd but it strangled my cat. Can you advise?

Re: You all presumably know why.

[Anonymous Coward]

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.

Shouldn't the messages be what is not messed with, at least without knowledge that they are messed with?

Let the logging system be a generic interface. Java seems to have done a good job there, though there still are several variations, it is not that hard to plumb them to all go down the same pipe and then take over it, if you need to, by meeting the interface specs.

Important messages or maybe all messages can be cryptographically signed on a per message basis and include timestamps and message numbers. Then all you have to do is verify the messages are continuous and then run a utility to verify the signing.

Of course you still have to deal with who gets to sign the messages. It has been years since I looked at encryption on linux, but surely there is some good starting point that doesn't require a reinvent of the wheel.

Yes, care needs to be made that everything is protected and all that, and that might mean a web of cryptographic signatures on components and all that, but that is not exactly new these days is it? Logging for instance could have four different packages that meet the spec and all have signed binaries available.

I haven't studied systemd, but the more stuff that has to be live on a system the easier it is to compromise. It is better to be able to reduce the system down to a relatively simple core, with the ability to bring in functionality when it is actually needed, then maybe the next systemd can almost get back to doing only a few things, one of which is to run various signed modules that meet the interface spec. For something like init, things could probably even toss around json strings for interop. Simple and verifiable usually beats complex in these situations. In many cases if you could reduce the core to such that it met the minimum goals and you could prove it did so to say a certain level of verification, such as required for say medical devices and such, well that would be a very good thing.

Note, with such certification it would likely be just the core with a few verified modules, but for many things like some web servers that may be all you need.

Re: You all presumably know why.

[Anonymous Coward]

Another guy who didn't read the linked to post. Big surprise.

Re: You all presumably know why.

[Anonymous Coward]

Go fuck yourself idiot. You proved him right by openly stating you aren't about to listen to the facts before running your ignorant cocksucker.

Re:You all presumably know why.

[Anonymous Coward]

Not that NIH, boyo--this one.

Re:You all presumably know why.

[Anonymous Coward]

wtf, i use fedora daily and if a service fail i see the relevent log entries

Re: You all presumably know why.

[Anonymous Coward]

You realise that posting abuse as AC on something only you care about makes it completely transparent who you are, Zero__?

Re: You all presumably know why.

[Zontar The Mindless]

^^^Mod. This. Up.^^^

Re:You all presumably know why.

[Aighearach]

Nobody uses POSIX, but everybody maintains some amount of POSIX compatibility. Welcome to 1995. Oh, wait...

Re:You all presumably know why.

[Aighearach]

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

[ckatko]

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

[Anonymous Coward]

That or he's about to release gitinit or something like that...

Re: You all presumably know why.

[Anonymous Coward]

Well he just sucked Poettering's dick in front of everyone, so merely cheerleading himself in 3rd person probably feels like it couldn't make him an even bigger faggot.

Re: You all presumably know why.

[TWX]

Find a new cat. If your cat was an outdoor cat one will probably take the territory before long anyway.

Re: You all presumably know why.

[TWX]

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

[Anonymous Coward]

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.

All heatsink, no CPU?

Re:You all presumably know why.

[MrKaos]

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

[aardvarkjoe]

It does look like the security problem was fixed:

https://github.com/systemd/systemd/pull/6300

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.

[MrKaos]

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

[Thor Ablestar]

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

[Anonymous Coward]

If your logs are that important then you would be logging a serial console off a real machine.

Re: You all presumably know why.

[Anonymous Coward]

I am quite able to rewrite the logs from the point I want to change them up to the present, regenerating keys and signatures as I go.

There's a zero knowledge proof that says this is always possible.

Re: You all presumably know why.

[Anonymous Coward]

Wow, you really are a fucking idiot.

This is how systemd advocates answer criticism. Now we know our concerns are irrelevant.

Re: You all presumably know why.

[Anonymous Coward]

I hope you meant to check if (index > 15); not just equal to 16. 17 and up are bad indices too. Should also be type size_t.

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.

[Anonymous Coward]

Design flaws are not "bugs". They are reasons to jump ship and redesign.

Re:You all presumably know why.

[MrKaos]

Poettering's work with pulseaudio

Holy crap, that steaming turd called pulse was Poettering's work? Fuck me that explains so much now.

Re: You all presumably know why.

[dbIII]

What is the advantage of systemd anyway?

RedHat owns it and nobody outside of RedHat really understands it for more than a few weeks before it morphs again.

Re:You all presumably know why.

[knorthern knight]

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

[dbIII]

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.

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

[Anonymous Coward]

Shut the fuck up you ignorant douche.

Re:You all presumably know why.

[dbIII]

why is that it actually solves (most) problems with older init systems

I hear that line a LOT but nobody ever seems to provide examples of even trivial problems solved.

Re: You all presumably know why.

[Zero__Kelvin]

You don't suppose it will be obvious that the key generation is happening at the wrong times?

Re: You all presumably know why.

[Anonymous Coward]

Sys V init wasn't broke shouldn't have fixed it in the first place.

Re:You all presumably know why.

[Anonymous Coward]

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.

Thank you for the best laugh I've had all day. To claim systemd handles dependencies well is an incredibly stupid thing to say.

It basically gets everything wrong, endlessly reinventing the wheel and doing it badly each time. With a configuration language which is a baroque, growing, pitifully messed up monster. Init scripts for all their faults were a far cleaner and easier to manage system.

Re: You all presumably know why.

[umghhh]

So it was a fault after all - after all the denials? Or was it closed as 'no fault' sort of way that we know from designers who are incapable to admit failure? Either way it is a mess. We laughed and coursed m$ for the same nonsense. Now we have this shit here. I still do not understand the reason why we had to go trough this transition in this particular way - dig in shit because it tastes so good?

Re:You all presumably know why.

[Anonymous Coward]

Will you also switch to emacsd when systemd will assimilate that too?

Re:You all presumably know why.

[Anonymous Coward]

But it will also change the uid to root before returning the error code, just because systemd's code just does not deserve to be ran with lesser than root privileges.

Re: You all presumably know why.

[Anonymous Coward]

That's what forking is for, right?

Re:You all presumably know why.

[Anonymous Coward]

Gee, if only systemd had some sort of control ultility to check service status...

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.

[DamnOregonian]

Gnome.

Re: You all presumably know why.

[Anonymous Coward]

https://github.com/systemd/sys...

Re: You all presumably know why.

[Anonymous Coward]

Don't bother, Zero__ doesn't have a clue what he's talking about and either stops responding or lapses into AC to hurl abuse when inevitably cornered. Basically, I doubt he has the intelligence to be a real troll and just likes hero-worshipping various people and projects that he thinks are really clever. From his perspective he has so many to choose from.

Re: You all presumably know why.

[guruevi]

You are talking out of your ass. It is easy to forge systemd logs, matter of fact you can even write a systemd unit that pretends to be another unit.

Also, systemd defaults to "no logging", you have to explicitly send to a systemd log.

Re: You all presumably know why.

[Anonymous Coward]

Systemd has absolutely no reason to decide what is or isn't a valid username. Pass it on to the OS to make the decision, job done. But no, Lennart wants control of _everything_. It reeks of a power grab to control everything.

Re: You all presumably know why.

[Zero__Kelvin]

Later in this thread you will see links to the proof that you are the one who is full of shit. HAND and FOAD like a good little incompetent ...

Re: You all presumably know why.

[Anonymous Coward]

Wow ... what irony. Here is your first clue of the day: your distribution vendor decides what systemd defaults to, and you clearly use one that sucks. You will also be surprised to find out that they decide kernel defaults, and all the myriad options when building all the packages.

Re:You all presumably know why.

[nick_urbanik]

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.

A server under heavy load takes an unpredictable amount of time to shut down. Shell scripts have found no sensible way to make restart work reliably. Systemd helps there with management of process groups.

Re:You all presumably know why.

[Anonymous Coward]

even if something is set to restart always systemd by design notabug wontfix will stop testarting it after a certain number of restarts

Re: You all presumably know why.

[fisted]

Maybe if your G+ link didn't fucking contain "LennartPoetteringTheOneAndOnly" people might bother to click it.

Re: You all presumably know why.

[Zero__Kelvin]

Great point! If you want to know about systemd you certainly wouldn't want to hear from that guy! What does HE know about it?

Re: You all presumably know why.

[guruevi]

No, systemd decides what systemd defaults to. I use Debian and several of my init scripts no longer write any logs after upgrading to systemd a few months ago.

Re: You all presumably know why.

[fisted]

Indeed I'd rather hear from it from independent and hence unbiased sources, especially after realizing that

HE

calls himself LennartPoetteringTheOneAndOnly.

Re: You all presumably know why.

[Zero__Kelvin]

Unbiased? This isn't something that involves an opinion. You DO realize that, right?

Re:You all presumably know why.

[thegarbz]

Except when it's not. And the Gnome depends on systemd myth was debunked pretty much the day it showed up thanks to a clueless guy seeing a package listed with both gnome and systemd in the title and going spastic online.

Re: You all presumably know why.

[Anonymous Coward]

SysV init is certainly broken, it's just broken in ways that you've become accustomed to and are willing to accept.

Re: You all presumably know why.

[Anonymous Coward]

folks want a assessment from somebody who isnt leonnard, i know i do. leonnard isnt trustworthy.

Re: You all presumably know why.

[Anonymous Coward]

It isn't an "assessment". The claim was made that there is no such facility; that it simply doesn't exist. The link clearly proved that ZK was correct; said people making that claim were the typical clueless asses that have no knowledge of systemd but pretend to be experts.

Re: You all presumably know why.

[Anonymous Coward]

No you won't. Systemd will be replaced back to the old init system within 10 years. It'll take a few more security flaws to be discovered bit it'll happen

What is the advantage of systemd anyway?

  That's something I've not seen explained anywhere.

The advantage is to the end user, systemd tends to take care of itself. An end user using it on a desktop system is unlikely to have any issue with it as they're not making init scripts that need to interface with it. Further, when that end user decides they want to start running certain daemons provided by the package manager they only need to use systemd to enable it and it takes care of making sure that it will start and be functional. Essentially, it shifts the onus of ensuring proper daemon startup to the people creating the daemon (theoretically the people who should know best how to do it).

It also unifies the experience across distros. When I find myself having to use a non-systemd computer that I own, I have to figure out how init is implemented and it seems every single implimentation is different. Arch used to have it in rc.conf, others used an "rc" shell script which was often not consistent either, there's a complete lack of consistency unless you set it up yourself to be consistent. Across systemd systems, the init commands are all the same and that's rather nice to have.

There's also the bit where systemd takes into account that modern computers aren't getting faster, they're getting concurrent. There's an argument to be made about how important concurrency is when it comes to init, but it's hard to claim it's completely unimportant. Advancement in technology in anyway may lead to technological revolutions that nobody expected.

Re: You all presumably know why.

[Anonymous Coward]

Perhaps you meant >= rather than assignment (=) in option 3? Or was that the point? Option 3 would likely be a disaster that doesn't wait (so still better than option 1).

Re: You all presumably know why.

[Anonymous Coward]

Hmm. I see you brought up POSIX.

I'm pretty sure that is a major part of the problem with SystemD right there...

Re: You all presumably know why.

[Anonymous Coward]

Sheesh, systemd fanbois fail at reading comprehension. Instead of getting the result of your operation back on the console, you say thata equivalent to having to go through the pain of running a seperate command (with flags!) just to find the result of your previous command. Absolutely braindead.

Re:You all presumably know why.

[Anonymous Coward]

I have to ask... Why the hell are you trying to reboot a server under what sounds like, extreme load ?!?!?

It's one thing if a process is Z looped and causing high usage ...
THAT then, sounds like a major bug. In which case, what the hell does SystemD have to do with a bug in other software?

I digress, but if the primary boasting sticking point I see rebooted here, is I can reboot my server faster, when it's going haywire no less... seriously, wtf?! That's it?!?!

Pretty sure if my server is going haywire, I'm taking it offline to figure out wtf is going on first and foremost.

Re: You all presumably know why.

[metrix007]

Still as much an idiot as you ever were. Web designer who thinks he is an engineer, still has no clue when it comes to security.

Re: You all presumably know why.

[metrix007]

It's funny because he staunchly defends himself as a software engineer and does the equivalent of undergrad web design.

Re: You all presumably know why.

[Anonymous Coward]

He literally showed proof he was correct, and I have never once seen him mention "web design". It seems the idiot is you.

Re: You all presumably know why.

[Zero__Kelvin]

Yeah ... OK bud... You should work on your reading comprehension.

Re: You all presumably know why.

[Anonymous Coward]

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.

Are you talking about Trump?

Re: You all presumably know why.

[segedunum]

Indeed so. You can never trust what kind of input you will get into your software. You need to sanitise and verify it, especially in an open source system. To wave that away as someone else's problem is absolutely hilarious, until you realise they're serious, but Poettering has ample amounts of form on that score.

Re:You all presumably know why.

[segedunum]

sysvinit did need replaced and improved at some point, but what we've got is going to be a fucking nightmare to live with in comparison.

Re: You all presumably know why.

[segedunum]

That is certainly *something*, but mainly because he's been forced into it. He just can't bring himself to fix things properly. It's always someone else's problem or he'll just shove it into the documentation and point to that.

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.

[segedunum]

The project is structured in such a way as to making forking an impossibility.

Re: You all presumably know why.

[segedunum]

Yep. That's the response you usually get.

Re:You all presumably know why.

[Anonymous Coward]

I am curious to hear what people in your camp have to say about leaner systemd forks which undo (or claim to undo) claimed (or real) feature creep....

Re: You all presumably know why.

[Zero__Kelvin]

Slashdot has been overrun with dumbfucks who keep saying they are right even after they have been proved wrong because they can't admit they ran their mouth out of turn. Imagine how much I care what those losers think and say if you will.

Re: You all presumably know why.

[Anonymous Coward]

Those would be security chaps, surely?

Re:You all presumably know why.

[a_n_d_e_r_s]

> So SystemD is the Emacs of init?

More like Microsoft Office of init.

I

Re: You all presumably know why.

[chihowa]

That's awesome! I love how quickly the conversation turns to not documenting this behavior because none of the previous behavior was documented anyway and it can change at any moment. Solid foundation, for sure!

Re:You all presumably know why.

[descubes]

Not yet. There is no news reader and no M-x doctor in systemd yet.

Re: You all presumably know why.

[Anonymous Coward]

While it has the potential to correct the worst mistakes and bugs, you're still left with the architecture (lots of fallible LOC under pid 1), configuration syntax and invasive requirements (dbus comms) that means that I'd say "why are you wasting time on this when there are better alternatives?" That's just touching the surface, basically to correct it sufficiently would mean it wouldn't be systemd compatible any more, so why not just use a non broken alternative?

Re: You all presumably know why.

[Anonymous Coward]

Let's spell it out for the cretin. Nobody in a production environment is going to run with an interval of under 15 minutes due to the performance hit (hell, its already hideously non performant to the point of being broken). That leaves an average of 7.5 minutes for intrusion and log rewriting of those intrusion events before the current chain is sealed, an absolute eternity in attack terms. Note that outside of this you can also rewrite all you want, the defense offered is an indication that rewriting has occured, not imaginary "cannot rewrite".

Re: You all presumably know why.

[Anonymous Coward]

Car Salesman: "Look, I know the Poettering Turd2000 is a hard sell, so I'll tell you what. Let's try removing the canoe launcher and sausage machine, take 7 of the wheels off and lower the remaining 4 so they reach the ground, put in some window glass and remove the periscope, jury rig some pedals and a hand break and take the anal intruder off the drivers seat, oh and we'll put some locks on the door and see about it bursting into flames" Me: "That sounds more like a normal car, but there's a whole yard of those over there already for me to choose from"

Re: You all presumably know why.

[Anonymous Coward]

Actually, the more I think about it, the more I realise that the automotive equivalent of systemd is The Homer

Re: You all presumably know why.

[Anonymous Coward]

Performance hit! ROTFLMAO! That's a knee slapper There! Are you really a complete fucking idiot, or are you just trolling?

Re: You all presumably know why.

[Zero__Kelvin]

Holy fuck you are stupid. YOUR defense is "I can hide my tracks, just not without being caught! " Seems the cretin is you :^)

Re: You all presumably know why.

[Anonymous Coward]

I can hide my tracks without being caught. I can also modify or erase much older logs to my hearts content, but may be noticed. That you don't recognise the horrible performance of the systemd journal shows how much out of touch to the reality of running live systems you are, which is typical of the few clueless systemd supporters.

Re: You all presumably know why.

[Anonymous Coward]

You just admitted you can't dumbfuck. Stop spouting ridiculous bullshit even a layperson can see straight through.

Re: You all presumably know why.

[Anonymous Coward]

Slashdot has been overrun with dumbfucks who keep saying they are right even after they have been proved wrong

Like this one?

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.

[Anonymous Coward]

You have been barred from all future communications for the crime of sheer and utter stupidity

Re: You all presumably know why.

[jeremyp]

adduser will also allow numerics at the beginning of the user name. All you have to do to make it so is edit the regular expression in adduser.conf(5).

Re: You all presumably know why.

[Anonymous Coward]

Save it on your phone or write it on a piece of paper?

Wow mane, super secure. Super smart people. Even a first grader knows better security practices than that

Re: You all presumably know why.

[Anonymous Coward]

The sad thing is you aren't even competent at trolling. Sad. Terrible.

Re: You all presumably know why.

[h4ck7h3p14n37]

Honestly, your description sounds exactly like the type of person who would attempt to rewrite the init system. They think they can come up with a better system because they view themselves as some sort of computer genius. Yet, they lack the knowledge and experience to understand why what they are attempting is a bad idea.

The changes that are being made are breaking servers and they don't care. We're all expected to change our behavior to match the new system when the old ones worked just find for the majority of us. I'm just glad my employer has moved away from RHEL so I don't have to deal with this crap. I've never had a problem with either the old AT&T style or System V init system.

Re:You all presumably know why.

[Eunuchswear]

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

Hahaha! Someone was dumb enough to upvote the troll! Well done little troll!

Re: You all presumably know why.

[Eunuchswear]

Also, systemd defaults to "no logging", you have to explicitly send to a systemd log.

Nope, not the case:

man systemd.exec
[...]
              StandardOutput=
                      Controls where file descriptor 1 (STDOUT) of the executed processes
                      is connected to. Takes one of inherit, null, tty, journal, syslog,
                      kmsg, journal+console, syslog+console, kmsg+console, socket or fd.
[...]
                      This setting defaults to the value set with DefaultStandardOutput=
                      in systemd-system.conf(5), which defaults to journal.
[...]
              StandardError=
                      Controls where file descriptor 2 (STDERR) of the executed processes
                      is connected to. The available options are identical to those of
                      StandardOutput=, with some exceptions: if set to inherit the file
                      descriptor used for standard output is duplicated for standard
                      error,
[...]
                      This setting defaults to the value set with DefaultStandardError=
                      in systemd-system.conf(5), which defaults to inherit.

So if you, or your distro, don't change the default it goes to the journal.

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]

(Yes, snatching STDERR from a daemon is genius. Definitely. But what was wrong with then handing the output to the syslog daemon?)

Uh, nothing is wrong with that. That's why you can configure systemd to do that, as, for example, Debian does.

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.

Re:You all presumably know why.

[Eunuchswear]

Quit. A startup with "bad team dynamics" is doomed.

Re:You all presumably know why.

[Eunuchswear]

but it [ SMF] can deal with unmodified sysVinit scripts.

As can systemd. Fuck even upstart can do it AFAIK.

Re: You all presumably know why.

[Eunuchswear]

What is this "console" of which you speak?

Or, to put it another way -- where is this console of which you speak.

Re:You all presumably know why.

[Eunuchswear]

I've had systems that would randomly come up with NFS non working in the past because the sysvinit scripts weren't waiting long enough for the network to become available.

Re: You all presumably know why.

[Anonymous Coward]

I did it.

Just to piss off basement dwellers like you, screaming at the top of your lungs in complete and utter irrelevancy.

Next up - NTP. I'm putting that in just to fuck with you.

And there's not a god damn thing you can do about it.

Next month? Emacs. Yeah. I'm putting a fucking text editor in systemD. I live off your tears.

Re: You all presumably know why.

[Eunuchswear]

You say:

Indeed; its author [...] later congratulated trolls who pushed it on debian-devel [2]

And give the link:

[2]: https://lists.debian.org/debian-devel/2012/11/msg00350.html

But that link is not to a message from Lennart Poettering, it's a message from John Paul Adrian Glaubitz.

Why did you make this false claim?

Re:You all presumably know why.

[Eunuchswear]

it's very difficult to unchoose systemD from a distro

Huh?

# apt-get install sysvinit-core
# reboot

What's the difficulty?

Re: You all presumably know why.

[Eunuchswear]

If you bother to read the anti-systemd trolls (yes, I admit it is boring) you'll find they're full of anti-SJW rants and other lunacy. It's a fair bet that they're Trump supporters. (I even found one who was a full on climate change denier).

Re: You all presumably know why.

[KiloByte]

Well yeah, but when a tool complains that a name is "illegal", it makes you stop. Most users will then believe the error message and pick something else, without thinking.

Re: You all presumably know why.

[Lost Race]

If you bother to read the anti-systemd trolls (yes, I admit it is boring) you'll find they're full of anti-SJW rants and other lunacy.

Trolls be trollin'? You don't say!

Trolls, by definition, will spout whatever lunacy gets you to overreact. If you hate Trump, they're Trump supporters. If you hate strawberry ice cream, they're strawberry ice cream supporters. If you like systemd, they'll shit all over it.

That's how they roll. For teh lulz.

Re: You all presumably know why.

[Anonymous Coward]

Maybe eliminate the dependency on a corporation that can just impose its will on virtually the entire Linux community then?

Re:You all presumably know why.

[amorsen]

But you can't disable the useless binary log system.

Re:You all presumably know why.

[Eunuchswear]

The journal is actually quite useful -- because of the journal stuff that gets logged before syslogd is ready is not lost, also its integration with systemctl status is nice and it includes more information than syslog.

You can (as Debian does) stop it writing its logs to disk if you want.

Of course if the journal was a real problem it would be pretty trivial to write a version of journald that wrote text logs, or just passed stuff off to syslogd or whatever.

But nobody has ever bothered, they just spend all their time bitching about it.

Odd, that.

Re:You all presumably know why.

[amorsen]

Of course if the journal was a real problem it would be pretty trivial to write a version of journald that wrote text logs, or just passed stuff off to syslogd or whatever.

It would be extremely non-trivial to integrate it with systemd. It would break all the time, and the chances of Poettering accepting it as a part of the official distribution of systemd are nil. Not happening.

Hopefully Poettering will tire of systemd soon and pass it on.

Re: You all presumably know why.

[dbIII]

Not a bad idea, I had the same a bit before the year 2000 as did a great many other people with a vast amount more influence than myself. I'm not sure how things worked out the way they did.

Re:You all presumably know why.

[Eunuchswear]

It would be extremely non-trivial to integrate it with systemd.

Why?

It would break all the time

Why?

the chances of Poettering accepting it as a part of the official distribution of systemd are nil

Why would you care?

Not happening.

I know it's not happening. I just find it funny that none of the people who complain about the binary logging can be bothered to do anything about it.

Re:You all presumably know why.

[Anonymous Coward]

I wouldn't say it's "suffered" from feature-creep. I'd say that was the entire point.

Re:You all presumably know why.

[TWX]

Maybe that's because we didn't have problems with ALSA or sysV or BSD init...

Re:You all presumably know why.

[amorsen]

It would break all the time because systemd internals like logging aren't a stable interface. It would require constant maintenance to be kept compatible with standard systemd. It would be worse than maintaining out-of-kernel modules The only way to avoid that would be to get it into the main distribution, and Poettering would never stand for it.

There is no point in contributing to or changing systemd unless you buy into Poettering's "vision". The only way to go is a full-bore fork and none of the distributions have the manpower for that either.

At this point, Linux is stuck with systemd unless Linus himself makes an init daemon. Personally I switched to OS X on the desktop after almost 20 years of Linux.

Re:You all presumably know why.

[Eunuchswear]

Nope, that doesn't work -- if nobody had problems with ALSA, sysvinit or bsdinit nobody would be looking for replacements for them, and lots of people are looking for replacements for them. Hell, even sysvinit, mess that it was, was proposed as a way of getting round the suckiness of bsd init,

Oddly the replacements that have been accepted are pulseaudio and systemd.

Re:You all presumably know why.

[Eunuchswear]

would break all the time because systemd internals like logging aren't a stable interface.

When did the logging interface last change?

Personally I switched to OS X on the desktop after almost 20 years of Linux.

So how's launchd working out for you?

Re: You all presumably know why.

[Anonymous Coward]

The advantage is to the end user, systemd tends to take care of itself. An end user using it on a desktop system is unlikely to have any issue with it as they're not making init scripts that need to interface with it. Further, when that end user decides they want to start running certain daemons provided by the package manager they only need to use systemd to enable it and it takes care of making sure that it will start and be functional. Essentially, it shifts the onus of ensuring proper daemon startup to the people creating the daemon (theoretically the people who should know best how to do it).

Rubbish. That was the existing situation already. Packagers now have to worry about a unit file instead of an init script, but end users didn't get involved.

It also unifies the experience across distros. When I find myself having to use a non-systemd computer that I own, I have to figure out how init is implemented and it seems every single implimentation is different. Arch used to have it in rc.conf, others used an "rc" shell script which was often not consistent either, there's a complete lack of consistency unless you set it up yourself to be consistent. Across systemd systems, the init commands are all the same and that's rather nice to have.

sysvinit is actually a standard. You may have had trouble interacting with the non-standard distro wrappers each distro places around it to make life easier, but at its core it takes the same /etc/rc.d across platforms. What systemd has done is to make Linux a non-standard special case incompatible with all other unix-alikes such as BSD, meaning we now have to manage both sysvinit and systemd. And yet there's no consistency between Linux distros when it comes to systemd, either - different distros and even releases within a distro use different systemd targets in an ever-shifting mess meaning it's virtually impossible for maintainers to track exactly which of multiple unit files they need to be using in any given case. Unlike sysvinit where mostly just had to worry about which wrappers to call (thanks to recent standardisation), systemd changes must be reflected within the unit file itself, which is a nightmare. That aside, even the steps required to install and maintain a unit in systemd make it far more complex to manage than sysvinit - so much so that Redhat ended up having to add new RPM macros just to handle the increase in boilerplate. Worse, systemd requires that to interact with it correctly you must make invasive changes to your own code, and start talking to a Linux-specific desktop component (dbus) - many package maintainers won't or can't do that, and rightly so.

There's also the bit where systemd takes into account that modern computers aren't getting faster, they're getting concurrent. There's an argument to be made about how important concurrency is when it comes to init, but it's hard to claim it's completely unimportant. Advancement in technology in anyway may lead to technological revolutions that nobody expected.

That might be an advantage if startup were CPU-bound, but it isn't. Startup is constrained by serial access to things such as the disk (yes, even on SSD). This is evidenced by the fact that modern systemd startup has been measured to be slower than its sysvinit counterpart. Just because something is new or different doesn't necessarily make it an advance, this is a common mistake.

Re: You all presumably know why.

[Anonymous Coward]

It's already got a webserver and QR code generator, so a text editor isn't even surprising.

Re: You all presumably know why.

[Anonymous Coward]

Ah, sorry. That message was the trolling I was talking about. The Google+ link from #3 is Lennart congratulating him on his involvement in that ML thread. As mentioned in the OC, you'll need to scroll down for it since I couldn't find a way to permalink to a G+ comment. Maybe it's possible with a Google account.

Re: You all presumably know why.

[Anonymous Coward]

systemd-init doesn't care about any username, thank you very much.

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.

Re:Eventually systemd will replace the kernel

[FudRucker]

Linus is worth his salt, and more so, he earned his place at the head of the table, i am agnostic/atheist, but if there is a god (which i doubt) then Linus has more than earned a reward

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

The latest build of systemd now includes a God daemon. The God daemon is enabled by default and cannot be disabled without recompiling from source.

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

Don't let that these legacy tasks are from DRM/MPAA/RIAA control your operating system!!!

Re:Eventually systemd will replace the kernel

[yeupou]

Note that running KDE or PulseAudio without systemd God daemon is not supported.

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

And later versions of Firefox won't support ALSA, only PulseAudio.

So, without systemd, Firefox won't be supported.

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

systemd will one day replace the kernel. It will then be officially called Lennux, but, colloquially, Poenux (pronounced as "penis").

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

Choose something minimal, those bloatyMcBloatFace DEs are always going to depend on giant awful things, systemD is a perfect match for it.

Re: Eventually systemd will replace the kernel

[Anonymous Coward]

You mean SatanicDemon?

It goes around telling "lies" about your processes and what not. The binary truth of standard errors then just get silently redirected to /dev/hell, and instead "slanders" all things good. It then "resists" all things pure and simple by misleading those who would otherwise be free of an idiotic philosophy proven to be evil. The igorant and misguided only see parallelism and perceived performance gains but are compleltely inebriated on it's bullshit, only to find out that strange timing patterns and services are still serial by nature. Like a filthy whore and harlot, an unholy alliance between false unix principles, and almost every single Linux distribution was formed, and she rides on top of these wild beasts of problems, drunken on the corruption and capitalist power of the most appiest appy of app apps. So down the great systemd was hurled, but woe for the luddites and those ACs on /.

Re:Eventually systemd will replace the kernel

[allo]

Bullshit. You can have pulseaudio without systemd.

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

I for one welcome our new systemd overlords

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

Why would you?
I have banned all software by pottering from my system.

Re:Eventually systemd will replace the kernel

[yeupou]

You are calling bullshit on a thread dedicated to God mode. Are you even reading before posting?

Re: Eventually systemd will replace the kernel

[Anonymous Coward]

Please stop saying this. My Gentoo system with openRC is running KDE plasma with pulseaudio just fine. (Would rather nor use pulseaudio but whatever.)

Re:Eventually systemd will replace the kernel

[KiloByte]

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

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

That would be fucking awesome.

Re:Eventually systemd will replace the kernel

[Anonymous Coward]

Git is a total piece of shit.

Re:Eventually systemd will replace the kernel

[jeremyp]

It's probably the perfect tool for merging many patches from many disparate sources into a large code base like, for example, an open source operating system kernel. But for most of us, it is indeed shit.

systemd

[Anonymous Coward]

what's init I've only ever heard of systemd

Re: systemd

[Anonymous Coward]

Get off my lawn fuckar!

Re:systemd

[Anonymous Coward]

Init is the first process called when you boot your system. After the kernel comes up and is ready, it must pass control of the system onto PID 1, or init. init then handles everything needed to bring userland up. Historically, init has been a small, tight process that brings the system to a usable state through the use of outside scripts, or child processes. Its job for the rest of the "session" while the machine is turned on is to handle these child processes, "reaping" them if they are no longer needed or are misbehaving. The reason PID1 is meant to be small is, if anything happens to that process, it creates a kernel panic and the machine must be rebooted. It's the one process on your system you cannot afford to have die.

Various iterations and spinoffs of init have crept up over the years, each adding their own way to do init's hard part: daemon/process management. Some (like Gentoo) use an RC system on top of standard sysvinit (like OpenRC). Some use a different system altogether (like runit, s6, daemontools), and some use enterprise-level software like launchd, SMF, upstart, and systemd, which include more than just basic process management.

systemd is an entire suite of tools on top of its own init, which uses a technique called socket activation to bring "services" up. This, in addition to other tools, can jeopardize the integrity of PID1 due to its complexity. One mishap can bring down an entire system. To do a proper comparison, you'll need to compare the process that gets started first by these projects. systemd's init is indeed smaller than their bevy of tools, but larger than some may be comfortable with.

In the interest of neutrality, here are a few direct links to the projects' actual init processes. If you're familiar with programming in C, you should be able to decide for yourself which init is most friendly to you.

systemd: https://github.com/systemd/systemd/blob/master/src/core/main.c
sysvinit: http://svn.savannah.gnu.org/viewvc/sysvinit/sysvinit/trunk/src/init.c?revision=159&view=markup
runit: https://github.com/vulk/runit/blob/master/src/runit-init.c (upstream doesn't appear to have a code view; http://smarden.org/runit )
minit: https://github.com/chazomaticus/minit/blob/master/minit.c
sinit: http://git.suckless.org/sinit/tree/sinit.c

These inits tend to bring in other code from their respective repositories, though clearly their sizes will differ. Also consider the complete size of each init; more code will bring in a larger attack surface, as it means more code to debug.

Best of luck in deciding what works for you.

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

Re:Not very sytemd like

[Anonymous Coward]

On Ubuntu 17.04, and any Debian, it's suid. Which means vast majority of Linux deployments:

$ ls -l /bin/ping
-rwsr-xr-x 1 root root 64424 Mar 9 23:42 /bin/ping

Re:Not very sytemd like

[allo]

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

Re:Not very sytemd like

[Xenolith0]

They've moved from setuid to posix capabilities on most major distros:

# ls -l /bin/ping
-rwxr-xr-x. 1 root root 62088 Nov 7 2016 /bin/ping

# getcap /bin/ping /bin/ping = cap_net_admin,cap_net_raw+p

see: man 7 capabilities

Re:systemd, unreadable code?

[Anonymous Coward]

systemd is full of spaghetti code that manage the "init of the processes" and the "orphaned processes" while systemd is alive.

In short words, systemd is the giant father process that sucks them.

If an evil process is moved to systemd then the computer maybe compromised by this evil process, similar to a root privileged escalation.

And you won't know easily what does systemd ...

Linus Torvalds

[Anonymous Coward]

He's been quoted as saying that he prefers his toast to be only mildly brown by the Daily Mail, which caused such an uproar that Theresa May changed her view point on Brexit and agreed that the UK should be as isolated from Finland as possible, even though Torvalds lives in the US.

Either way, the UK and the US have decided to peace out so they are not really as relevant as they once were. But this has little to do with what Torvalds was talking about. The toast debacle was ridiculous. People were rioting in the streets over how toasted a piece of bread should be. To make matters worse, this gave rise to the anti-toastites, who feel bread should never be toasted at all.

Linus should really watch what he says in public...

Fuck systemd

[Anonymous Coward]

There, I said it so that Linus didn't have to and bruise the RH egos.

Joke?

[amiga3D]

It init funny. Not at all.

Re:Joke?

[TheGratefulNet]

how about stigginit to init with sigint?

(head asplodes)

Re:Joke?

[93 Escort Wagon]

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.

Re:Linus, this is for YOU:

[Anonymous Coward]

That was modded down... but would people mod down something in support of Debian, which deliberately excludes proprietary and capitalist code from its distro?

To be fair, Debian did revolutionize the concept of package management in the Linux world, which had, prior to that, been essentially using the Slackware model, so I'll give it that.

All hail Nyarlathotep!

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

[Anonymous Coward]

You systemd apologists really are retarted. Lemme explain:

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

No, completely false and wrong. First of all, exactly the SAME answer applies to having no compile-time built-in default: "If your default install can't sync time, then maybe you should be complaining to Ubuntu or Debian or ...".

And having NO compiled-in default is WAY better than having google because then you get the error that there aren't time servers configured. So you go ahead and put a sane config. With this, you don't get any errors. You think it works, because no errors are reported, but your time is way off...

So pray tell, which is better? No default -> error -> fix, or Default -> no error -> wrong time?

Your answer is textbook example why systemd is horribly broken. It behaves in a broken way that does not report errors. It's shite that replaced very well working and behaving systems.

You know why? Because you shitstemd cabal only think of laptops and that 1% of market share, while the 50% of it is supposed to suffer from your laptop-induced crapware on their servers.

No. Just RUN BSD.

-NFS mounts are not a problem providing you RTFM.

The sheer amount of bug reports on the issue and people twitting that, despite them RTFM-ing and setting things up by the book, it breaks.

-A start job is running is a perfectly sane response to waiting for a critical part of a boot process

But it's not a sane response to waiting for a trivial hiccup that shouldn't be waited for. That's what GP said but you conveniently spinned that into "critical". GP never said critical.

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.

There you go spinning and strawmanning again, fanboi. GP was talking about very much critical and serious issues that got closed down as EWONTFIX, like the 0day issue y'all are too stupid to understand why that's an issue to begin with.

Then you deflect with nonsense like "you need root to create a user", completely OBLIVIOUS to the fact that a) no, you don't, systemd will run even if the user doesn't exist and b) the whole problem is with the admin WANTING and expecting the process to run as non-root.

Need a car analogy? You lock your car. It beeps. You walk away thinking it's nice and locked. But alas what's that! A thief! He just walked to the car, opened the door, smirked, and ran with it!

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.

Total mega strawman and spoken by someone who obviously NEVER saw a server. For decades we were managing MASSIVE LOGS just fine. We have had tools to monitor running processes, tools that did not have to intrude in pid1 and become a huge attack surface themselves. There are daemon tools, supervisord, daemon(8) and many other things that do the same. Did the same. Worked fine. On fleets of hundreds and thousands of servers, just fine.

Until lenny boi came here and thought up a scheme to fix his own use case on a laptop. Because the rest of us "hate disabled people".

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: You were warned

[Anonymous Coward]

I have the same problem with sshd. I can't bind to a specific interface since shitestemd insists on attempting to start it prior to the interface being raised, in direct contradiction to the unit file dependencies. To make matters worse, its also set to restart, and shitestemd won't do that, either. How the hell is this heap of bug riddled garbage considered to be a viable init?

Re:You were warned

[thegarbz]

Startup should be deterministic and consistent.

Systemd is 100% deterministic if you RTFM and setup your startup settings correctly. Absolutely need NFS at startup? Well set the service to wait-online for network dependency (not a default setting in most distros).

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.

I'm going to go with the "or not" part considering you're locking up a boot indefinitely. Maybe consider setting up the timeouts if you have your services as part of the critical boot path, I mean we were only just talking about the "A start job is running" messages which is exactly what this does.
Or better still realise that systemd is not sysvinit and read the manual anew. Forget on how you think you should be setting up something like NFS and actually set it up the way it is recommended, and if you haven't read such a guide, then you've set it up incorrectly.

Changes in OSes require changes in configurations, and if your system is not acting in a deterministic way then you have yourself to blame (along with your previous reading material).

Re:You were warned

[sad_]

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

that's the second time now i learned that systemd just ignores failure and takes some default value instead of actually failing. this is not what you want, it's total lunacy and idiotic.

the previous time it was when a user doesn't exist, it just goes ahead and runs as root instead.

the right action is to fail, not to go ahead and do something that was not requested.

Re:You were warned

[mike.hamza]

lennart be like: "who need to mount nfs anyway, i have my hard-drive attached to my laptop and so all of my team, then you don't need it, so nothing to fix here"
issue closed -----------> not-a-bug - won't-fix
its always the case and it'll always remain like that, since all distros maintainers seem quite and following the gnome and systemd folks in their mess.
gnome folks cloning the mac interfaces hardly, systemd folks cloning windows architecture hardly.
the result project redhat will name it "macdows"
at best we're heading into a disaster, and the primary ones to blame are Arch and Debian devs, they're responsible for this mess.
one guy at arch forced the the switch then get hired by redhat, debian vote was a total mess and everybody know about it doesn't need further discussion.

LINUX TORVALDS

[Anonymous Coward]

Linux Torvalds is my favourite superhero.

Re: LINUX TORVALDS

[Anonymous Coward]

Leenux Svalbard is a Demi God.

What does the headline mean?

[Anonymous Coward]

I cannot parse the headline: "In Which Linus Torvalds Makes An 'Init' Joke ". The problem is that it's a prepositional phrase rather than a complete sentence. It would be much easier to read if the words "in which" were dropped. Or was EditorDavid attempting to say something other than "Linus Torvalds Makes An 'Init' Joke "?

By the way, there's another parsing problem in the summary. EditorDavid wrote:

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

For this to parse as intended, single quotes, rather then double quotes, should be used around init.

Re:What does the headline mean?

[Anonymous Coward]

You can parse it just fine, i.e. you know what it means.

In which you can't let go of your OCD grammar hang-ups.

Re:What does the headline mean?

[TC (WC)]

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:What does the headline mean?

[Anonymous Coward]

You need to go back to school if you can't read that.

Re:What does the headline mean?

[Anonymous Coward]

"Chapter IV
In Which it is Shown that Tiggers Don't Climb Trees"

But that makes sense because it's a complete sentence. It is saying that Chapter IV is the chapter in which it is shown that tiggers don't climb trees. In contrast, the headline of this story is not a complete sentence. What is the thing in which Torvalds makes a joke? The headline cannot be parsed as a complete sentence.

Re:What does the headline mean?

[Anonymous Coward]

You can parse it just fine, i.e. you know what it means.

In which you can't let go of your OCD grammar hang-ups.

No. In fact, I did not understand what it means until it was explained that the headline author attempted (unsuccessfully) to emulate the style of the chapter titles in a children's book.

I do not have OCD, by the way.

Re:What does the headline mean?

[Anonymous Coward]

What is the thing in which Torvalds makes a joke? The headline cannot be parsed as a complete sentence.

*golf clap*

(That's part of the joke.)

Re:What does the headline mean?

[Anonymous Coward]

*golf clap*

According to the Urban Dictionary

http://www.urbandictionary.com/define.php?term=golf+clap#1279095

a "golf clap" can either be used sarcastically or sincerely. I do not know which sort of golf clap you intend. But either way, you aren't communicating clearly.

Re:What does the headline mean?

[Anonymous Coward]

No. In fact, I did not understand what it means until it was explained

Did you or did you not write:

It would be much easier to read if the words "in which" were dropped. Or was EditorDavid attempting to say something other than "Linus Torvalds Makes An 'Init' Joke "?

before said explanation? Your comment indicates you had no trouble sussing the meaning.

but...but...but...

[Anonymous Coward]

laptops!

systemd is linux cancer

[sjwest]

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.

Re:systemd is linux cancer

[Anonymous Coward]

you're using debian and then complaining that the implementation is gradual and slow? how the fuck is that systemd's fault?

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?

[Anonymous Coward]

The knowledgeable people do actually like systemd, for building a system that needs to handle changing environments t. Most of the issues listed in the GP post are in parts of systemd that many distros don't use.

Re:Systemd: What Does It Solve?

[Anonymous Coward]

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.

Thank you for being honest about your Linux understanding. Compared to many blowhards that I read elsewhere, your honesty is refreshing.

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?

To answer your questions why people seem to like SystemD(eath): It's a bright shiny new thingie that's different; that just works; that doesn't require that they learn anything to use it.

Sadly, when the SystemD(eath) generation encounters a problem that they cannot solve, they will simply mark it EWONTFIX, then throw it out and find something else.

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?

[Anonymous Coward]

The now somewhat long-in-the-tooth In the Beginning... Was the Command Line [ Alternative source, already unzipped ] tells us that a bug was reported against BeOS with the title

BeOS missing megalomaniacal figurehead to harness and focus developer rage

(about three-quarters of the way down, or search for "megalomaniacal").

I don't know if the same bug has been reported against Linux (and if it has then it should be classified EWONTFIX) but clearly Linus himself is not the solution to this. The promoters of systemd want this role to be filled, while everyone else wants it to stay as EWONTFIX.

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?

[Anonymous Coward]

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.

For some reason, reading this bit got me thinking of Donald Trump....

Re: Systemd: What Does It Solve?

[Anonymous Coward]

We always hear about these unnamed knowedgeable third parties who supposedly like systemd, yet they don't seem to exist in reality.

Re:Systemd: What Does It Solve?

[deek]

Debian put together a discussion document when they were deciding on what init system to default to. It may answer some of your queries.

  https://wiki.debian.org/Debate...

  Myself, I don't mind systemd, though I'd also be fine running sysvinit. I run a few dozen Debian systems for work, and honestly, systemd does the job I need it to do. One feature I really like is that it will log all service boot messages. Sysvinit, being what it is, boot messages scroll out of the console screen buffer, and they're lost for good. I don't want to have to reboot a system just to capture an error message by selectively pausing the bootup sequence.

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.

Re:Systemd: What Does It Solve?

[h4ck7h3p14n37]

I thought boot message written to the console were logged to a separate file, like /var/log/messages.boot or /var/run/dmesg.boot?

Re:Systemd: What Does It Solve?

[deek]

No file like that on my Debian systems. I checked a CentOS server I have access to, and there is a /var/log/boot.log file, but it is sparsely populated with parts of the boot sequence. It's possible that it may contain stderr messages on boot, so that's something.

Re:Systemd: What Does It Solve?

[shoor]

Doesn't dmesg give you what you need? As in, get on the command line as soon as you can and type "dmesg > demsg.out" or some such thing. Then "more dmesg.out" to see it. (I'm showing my command line roots here, worked on a lot of unix systems in the 1980s.)

Re:Systemd: What Does It Solve?

[deek]

Dmesg will show you messages from the kernel. It will not show the STDOUT or STDERR of processes started by init. So unfortunately, not what I'm after.

Down with Lennart

[boudie2]

Putting the boots to Lennart again are we? Can't think of anyone more deserving. May I join in?

Re:Down with Lennart

[Anonymous Coward]

Fuck Lennart! He probably eats shit.

Re: Down with Lennart

[Anonymous Coward]

Filthy cannibal!

If the computer is hosed

[Anonymous Coward]

Then you can't trust it to write it correctly to the WOM.

If your log receiver is hosed, it's only doing logging, therefore it has nearly zero attack surface. And it's far easier to see "illegal access" on a machine that is never supposed to be allowing interactive access via user input.

So, um, bullshit back to you, moron.

If you were so paranoid, you'd write it to BOTH. But YOU wouldn't do that, because, well, LP says it's enough to have binary logs....

Systemd log output

[Anonymous Coward]

Systemd's response to Linus: "I can't afford to have an independent programmer monitoring me. Do you have any idea how many outside systems I've gone into? How many programs I've appropriated?"

Re:Systemd log output

[mfnickster]

There's a 68.71% chance you're right.

Thanks for the new sig

[s1d3track3D]

...it's not only not clear that we want to do this... - Linus Torvalds (https://lkml.org/lkml/2017/7/6/577)

Does this impact Devuan?

[Anonymous Coward]

It should be set at the Kernel level, only to prevent Pottering from trying to usurp it.

Re:Does this impact Devuan?

[Anonymous Coward]

No, it doesn't. The Devuan devs are still trying to figure out how renewing a SSL cert works and still fail at it after years. 100% veteran incompetence, guaranteed.

https://lists.dyne.org/lurker/message/20170715.123207.7de273b0.en.html

Learn English please.

[Anonymous Coward]

Whoever posted that, including the editor, needs to take a remedial English course. Maybe something in basic communication too.

Re:Learn English please.

[Zontar The Mindless]

Apparently at least one editor knows his stuff better than some ignorant AC.

You may be onto something.

[Anonymous Coward]

Imagine a world where RedHat owned everything for an OS from the kernel on up. The Linux kernel has been replaced before (GNU Hurd) and can be again.

Only this time, imagine that RedHat decided to not disclose patch information. Everything appears to be compatible with Linux at first. Just like Open Office and Libre Office diverged, so too would this kernel as it forks. While still adhering to the GPL, this scenario - which has happened in the past - this would make it much harder for other distros to keep up.

Could this scenario happen? It's possible, and I would not put it past any corporation. RedHat has been a pretty good corporate citizen though, and the Linux kernel would be a huge task to replace for an army of programmers, let alone one vendor.

Nice. But the real question is

[Anonymous Coward]

Which kernel developers were sitting next to Linus during the last press conference, who was left off the podium, and how did that change from last year's presser?

GNU Linu-x, not GNOME Lenna-x

[knorthern knight]

Nuff said

Devuan is looking good

[walterbyrd]

I am using gentoo now, but devuan is looking like it might be a decent distro.

Re:Devuan is looking good

[Anonymous Coward]

Lul. The distro by people who cannot renew SSL certs even after two years of learning?

Even their own developers now lul about themselves: https://lists.dyne.org/lurker/message/20170715.123207.7de273b0.en.html

Re:Devuan is looking good

[Anonymous Coward]

I left Debian over systemd and tried to learn to love gentoo. I managed to get it installed on a my laptop and try my very best to come to terms with the package system. When devuan got to where it was relatively stable, I switched to that and it was like coming home. That's me and based entirely on my old guy love for Debian and apt and all the things that were, to me, home. I chose to run Debian many years ago because of it's ideals and the implementation. That Debian is no more. Devuan is trying and I'm good with that, but cheers to gentoo and all those that love it. For Debian, redhat, Ubuntu and the myriad other distributions that chose to chase the systemd dragon, I feel nothing but pity.

Destroys Linux, thanks Lennart

[Anonymous Coward]

Linus Torvalds should be very concerned of this new yet buggy, sorry I mean very buggy init system called systemD.
This is probably a M$ paid programmer to implant some stupid code in almost all Linux distro.
SysV init system wasn't broke, was not bloated and there's no need to fix that. Fixing something which is not broke is very wrong.

I like that!

[Anonymous Coward]

That or he's about to release gitinit or something like that...

I look forward to that!

systemd ate my hamster

[Anonymous Coward]

lol sorry could not resist.

Re: Give him the D.

[Anonymous Coward]

hey.. how did you avood the ascii art filter!

Linus drops a sick burn

[Anonymous Coward]

then proceeds to go all Andy Sixx on Poettering.

Except in funtoo

[Anonymous Coward]

They want gnome and systemd is the price.

Except in funtoo, where gnome has been patched to work perfectly fine without systemd (unlike Gentoo, Funtoo doesn't even support systemd. It's openrc only, and runs the current gnome perfectly fine (for those that want to inflict that gui upon themselves).

Re:Linus, this is for YOU:

[Eunuchswear]

but would people mod down something in support of Debian, which deliberately excludes proprietary and capitalist code from its distro?

Debian only accepts code that is compatible with capitalism -- code you can sell.

Debian refuses to include code that restricts the freedom of Debian users to do whatever they want with it, sell it, use it to make nuclear bombs, whatever.

Debian has even refused to accept code licensed on the "do no evil" license on the grounds that any Debian user should have to freedom do do whatever evil they want with their copy of Debian [ where allowed by local law, of course ].

Devuan is a fork of Debian free of systemd

[psb777]

Devuan is a fork of Debian which is systemd free. It just works for me. I've moved my servers to it. I am still vainly hoping that Ubuntu will announce it is abandoning systemd but I don't think that is going to happen so my desktop has already moved to Devuan & my laptop is going that way too. There are minor issues with the existing sysv init system which could have been improved a little, and improvements had arrived incrementally before systemd. The update-rc.d tool now takes notice of special comments in the init.d scripts so as to allow for parallel execution, and for dependencies, and the crafting of init.d scripts is not a black art: Nothing was broken. Having said that there is no need to have only one init system and various are available and Devuan supports them all except systemd. I warmly recommend Devuan. Stop complaining about systemd, leave it behind! https://devuan.org/