This systemd thing is really out of hand.

FrostCat

@blakeyrat said:

I give a shit about boring.

This should keep ya going for a while, then:

flabdablet

@NBeezy said:

I read somewhere that systemd includes a minimal http server, + libqrencode

I read somewhere that systemd gave Chuck Norris Ebola.

Maciejasjmj

@Yamikuronue said:

Pop quiz: How do you restart Apache?

Kick the power button?

@bugmenot said:

No joke, it was included so that you could get your kernel crash dumps as a huge QR code rather than console spew.

Ick. Wouldn't they, like, take far more pixels than any printer can possibly print reliably, and any monitor render? Or are we supposed to send the techs poster-sized sheets of paper now?

PJH

@flabdablet said:

<a href="http://0pointer.net/blog/projects/the-biggest-myths.html">The monolith myth</a>

If you build systemd with all configuration options enabled you
will build 69 individual binaries.

All interdependent on each other. As I said, monolithic. You can't take one binary out of that lot and run it in isolation.

Debunked here: http://judecnelson.blogspot.co.uk/2014/09/systemd-biggest-fallacies.html

In his blog, Lennart Poettering claims that systemd is not monolithic by pointing out that it is made of upwards of 69 separate binaries. This is a non sequitur, because "modular" and "monolithic" are not mutually exclusive terms.

A program is modular if it is decomposable into distinct functional units such that each unit addresses a specific concern. Systemd, the Linux kernel, and X.org are all examples of modular software. Systemd addresses its concerns with its binaries, the Linux kernel with loadable kernel modules, and X.org with its drivers and extensions.

PJH

@blakeyrat said:

Not to mention, the answer to, "is it too monolithic" is, "who gives a shit?"

I do if "it" is PID 1. The more complicated it is the more likely is is to crash.

PleegWat

If those different systemd binaries also run in separate processes, is it such a huge complexity concern? If the crond replacement is still a separate process, and it dies, then that doesn't take the whole system down (just as it is currently).

Of course, if that's all inside pid 1, then you do have a huge vulnerable spot.

dkf

@PleegWat said:

Of course, if that's all inside pid 1, then you do have a huge vulnerable spot.

You would not want to run lots of binaries within the same process too much, as each would replace the preceding one in memory ('cos that's how execve() works) and threading the state of everything would be awful. Having processes fail and get restarted by the main monitor (pid 1?) is fine provided the rest of userland isn't hanging off that subprocess.

PleegWat

Not having done my research, I was hedging against the case where those binaries are all shared objects.

dkf

You mean as in the old style loading and unloading of overlays from the bad old DOS days? That's what they probably won't be doing because it sucked back then because it was horribly error-prone. Running a cluster of worker processes under a main monitor process is far simpler to get right and to program in the first place, and it lets you do things like reducing the permissions of workers that don't need full system access (OS permissions are always enforced at the process level; that's one of the primary defining features of a process).

I believe that OSX's launchd does similar things, with a main monitor that is responsible for killing zombies, (re)launching workers and basically doing not much more than that. Virtually everything else goes into the workers. Yes, they're designed as a group and are meant to work together, but they're not that tightly coupled in a runtime sense.

PleegWat

Oh, I agree that's probably the best way to go about it. Probably the way I'd do it too. I guess I'm looking for how it could be the huge WTF @pjh is making it out to be.

VinDuv

@PJH said:

All interdependent on each other. As I said, monolithic. You can't take one binary out of that lot and run it in isolation.

Yeah, but people who say “systemd is monolithic” usually imply “it’s all bundled into one process, so if it goes down, the system crashes”. Of course these processes are somewhat interdependent, but the point is that except for PID1, if one crashes, the system stays up and systemd can restart them.

Things like udev, syslog, dbus existed way before systemd. The fact that they are now bundled in systemd (but still independant processes) do not mean that the system will be more unstable (I’d say it’s the contrary).

As a matter of fact, I booted a Debian install and killed systemd-udevd, systemd-journald, systemd-logind, dbus-daemon. Not only the system stayed up, but everything restarted automatically.

Also, what about making Linux not panic when PID 1 crashes?

PJH

@PleegWat said:

I guess I'm looking for how it could be the huge WTF @pjh is making it out to be.

I'm only going off a few sites I read yesterday - I have no personal experience of it, but from what I did read I'd be very reluctant to choose to use it.

And the attitude of the developers seems a magnitude worse than of a certain DiscoDev.

PJH

@VinDuv said:

Also, what about making Linux not panic when PID 1 crashes?

How about making init not crash?

#define _XOPEN_SOURCE 700
#include <signal.h>
#include <unistd.h>

int main()
{
    sigset_t set;
    int status;

    if (getpid() != 1) return 1;

    sigfillset(&set);
    sigprocmask(SIG_BLOCK, &set, 0);

    if (fork()) for (;;) wait(&status);

    sigprocmask(SIG_UNBLOCK, &set, 0);

    setsid();
    setpgid(0, 0);
    return execve("/etc/rc", (char *[]){ "rc", 0 }, (char *[]){ 0 });
}

That's all init needs to do.

VinDuv

@PJH said:

[That's all][1] init needs to do.
[1]: http://ewontfix.com/14/

If you’re going that way, what about letting the kernel start /etc/rc directly, and not care if it stops?

PJH

Because /etc/rc need not be the thing that needs to start. It's quite possible (though probably not reasonable) to have emacs be 'init'.

razerwolf

This is probably why so many people are against it

powerlord

It's funny that you should say that, as the Windows NT kernel design uses the Unix philosophy.

...and the Linux kernel doesn't (it's monolithic).

blakeyrat

@PJH said:

I do if "it" is PID 1. The more complicated it is the more likely is is to crash.

Well maybe you just need better developers. Windows doesn't crash.

PJH

@blakeyrat said:

Windows doesn't crash.

I see what you did there...

blakeyrat

Stated a fact?

Yes. Yes that is what I did.

asdf

@VaelynPhi said:

I think the major opposition to systemd comes from that second row: "Hard-to-debug monolithic startup in undocumented C".

I don't think so. At least, that's the weakest argument against systemd.

The actual problem is that systemd intends to replace a lot of daemons/tools and couples them tightly whereas they were loosely-coupled components before. Even worse, the systemd developers refuse to define stable interfaces between the single components (so you cannot replace parts of systemd with own implementations) and have even built some of the components in a way that they're absolutely impossible to reimplement without systemd.

Sources:

I like most of the things systemd does, but God help us if we ever need to get rid of it in the future (like we need to get rid of the X server now). Also, it's making the whole Linux world dependent on Lennart Poettering.

accalia

:frystare.swf:

blakeyrat

@asdf said:

Even worse, the systemd developers refuse to define stable interfaces between the single components

Oh so they're taking development advice from Linus and the kernel team.

I bet the same people who bitch about that in systemd are perfectly ok with it in the kernel.

@asdf said:

Also, it's making the whole Linux world dependent on Lennart Poettering.

This has to be hyperbole.

blakeyrat

All OSes crash when paired with unreliable broken hardware. That's the only reason Windows NT crashes, and has been for... a solid decade now.

PJH

@blakeyrat said:

Stated a fact?

Funny guy. No you didn't.

asdf

@blakeyrat said:

I bet the same people who bitch about that in systemd are perfectly ok with it in the kernel.

Funny that you'd mention that, because that's precisely Lennart's faulty argument against the critics.

blakeyrat

@asdf said:

Funny that you'd mention that, because that's Lennarts faulty argument against the critics.

Well it's appeal to authority, but it's also super-hypocritical for people to demand he change it and not Linus. Pick a single development methodology and stick fucking with it, Linux people.

PJH

@blakeyrat said:

All OSes crash when paired with unreliable broken hardware. That's the only reason Windows NT crashes,

Anyone else hear those goalposts move?

I've had windows 8 bluescreen because of problems with the swap file. Of its own making.

asdf

@blakeyrat said:

Well it's appeal to authority, but it's also super-hypocritical for people to demand he change it and not Linus. Pick a single development methodology and stick fucking with it, Linux people.

What does that even have to do with development methodologies?

Just because there's a huge flaw in the design of the Linux kernel, systemd doesn't have to replicate it. And "the kernel is shitty in the same way" is not an excuse for Doing It Wrong™.

blakeyrat

@asdf said:

Just because there's a huge flaw in the design of the Linux kernel, systemd doesn't have to replicate it.

I concur.

@asdf said:

And "the kernel is shitty in the same way" is not an excuse for Doing It Wrong™.

I also concur.

I guess you didn't understand what I typed? Or...? I have no idea why you posted that.

blakeyrat

@PJH said:

Anyone else hear those goalposts move?

Because there's an OS that can magically run on faulty hardware? How the holy fuck is that goalpost-moving? Maybe "goalpost defining".

@PJH said:

I've had windows 8 bluescreen because of problems with the swap file. Of its own making.

I don't believe you.

asdf

@blakeyrat said:

I guess you didn't understand what I typed? Or...? I have no idea why you posted that.

I know you agree with me, because you hate Linux and you specifically hate the kernel's lack of stable interfaces. I still disagree with what you wrote in your last post, because everything you wrote would support Lennart's shitty excuse.

accalia

@blakeyrat said:

I don't believe you.

then we're going to have a hard time, because i've seen my Surface 3 do exactly that at least 3 times since i got it.

it's also done the whole "I'm just going to stop responding to everything, including keyboard and hardware buttons so the only option you have is to unplug it and wait for the battery to run down to reset me. and i'll boot inot safe mode the next time you turn me on."

blakeyrat

@asdf said:

I still disagree with what you wrote in your last post, because everything you wrote would support Lennart's shitty excuse.

I said in the very first phrase of the very first sentence that it's appeal to authority, a fallacy-- you know what screw this thread, apparently nobody capable of defending Linux can read plain english.

asdf

@blakeyrat said:

I said in the very first phrase of the very first sentence that it's appeal to authority, a fallacy

And then continued to claim it'd be hypocritical to point out the flaws in one piece of software while not pointing out the same flaw in another piece of software. Why can't I rant about the software I care about while not giving a shit about another piece of software? There are way more sysadmins than driver developers, after all, so most Linux users don't have to care about kernel internals.

Also, you told "Linux people" to "pick a single development methodology and stick fucking with it". Whatever the fuck that meant (if it meant anything), it sounded like something that would support Lennart's argument.

blakeyrat

Look, I support anything that makes Linux suck less ass. It sounds to me like the systemd is that. It sounds like the Linux community agrees, since they have mostly already adopted it.

It's a couple dozen noisy whiners on Slashdot (some of whom apparently have usernames here, who'd have thunk it!?) who are making this into a whole big-ass issue. And, even worse, doing it long after it's already been settled by the people who do the actual work of writing code. It's just pundits being noisy at this point.

So whether or not I "support Lennart's argument", the fact is: the people who actually get shit done in the Linux community do, and have already finished switching to systemd, and everybody else should either shut the fuck up, or (instead of bitching and moaning) ACTUALLY BUILD SOMETHING BETTER.

flabdablet

@accalia said:

and i'll boot inot safe mode the next time you turn me on.

...and I'll then complain that something stopped me from booting right, and offer to fix whatever that was, and then tell you I couldn't, and offer to boot again just in case whatever it was has magically gone away on its own, which it won't have, and I'll give you a maze of options you have to Google the mysterious keyboard shortcuts to expose, none of which will work except the one that takes you to the place where I offer to boot again just in case whatever it was has magically gone away on its own now.

No Windows automated troubleshooter has ever done anything useful ever in the whole history of ever, not even once, and now they've embedded one of the dumb little fuckers in the boot sequence? Fuck Windows 8 sideways with a white hot wrought iron dildo.

asdf

I like systemd's features and support the migration. And yes, a lot of people criticize systemd for stupid reasons. I still think it's important to point out the important design flaw in systemd until its developers finally understand how important stable interfaces and loose coupling between the single components are. Especially because systemd is trying to replace pretty much everything, we need to make sure its components can be easily replaced again in the future.

bugmenot

I hear that the largest standard QR code is 177x177. Given that the QR code generators I've used emit three pixels for each QR code element, you'd only need an area of 531^2 pixels display such a QR code.

IMO, the big problem is to assume that we have a camera that can resolve such a code (ha!).

PJH

@blakeyrat said:

I don't believe you.

Your prerogative. But it happened. Too many times for me to, like you do, to fail to link or cite.

VaelynPhi

@asdf said:

Also, it's making the whole Linux world dependent on Lennart Poettering.

@asdf said:

At least, that's the weakest argument against systemd.

Quoted you against you only because I wanted to point out that the whole Linux world is pretty much dependant on Linus Torvalds already. On a serious note, though, how is

@asdf said:

the systemd developers refuse to define stable interfaces between the single components

Different from "Hard-to-debug monolithic startup in undocumented C"? In fact, I thought what you brought up was exactly what they meant (the lack of specs for interfaces). That tight-coupling, BTW, is what is meant by monolithic. It is modular, like the Linux kernel, as well as monolithic, like the Linux kernel.

Point being, I think we're talking past each other but saying much the same thing.

@asdf said:

Just because there's a huge flaw in the design of the Linux kernel, systemd doesn't have to replicate it. And "the kernel is shitty in the same way" is not an excuse for Doing It Wrong™.

THIS. This->yesThis();

@PJH said:

Because /etc/rc need not be the thing that needs to start. It's quite possible (though probably not reasonable) to have emacs be 'init'.

What fresh hell have you proposed!?

@PJH said:

Debunked here: http://judecnelson.blogspot.co.uk/2014/09/systemd-biggest-fallacies.html

This seems to be the best "fallacious fallacies fellating fail" I have seen so far. Poettering's development style seems to to be the #1 argument against systemd. Then again, maybe that means he'll fit in beside Linus just fine...

asdf

@VaelynPhi said:

On a serious note, though, how is

asdf:
the systemd developers refuse to define stable interfaces between the single components

Different from "Hard-to-debug monolithic startup in undocumented C"? In fact, I thought what you brought up was exactly what they meant (the lack of specs for interfaces).

That "argument" is mostly brought up by people who claim that Bash scripts are to be preferred over C code because they're supposedly easier to debug. I'm glad to hear that's not what you meant when you quoted it, though.

ender

Systemd

FrostCat

@Yamikuronue said:

Pop quiz: How do you restart Apache?

It's a trick question, the answer is "why would you? Use IIS!"

</troll>

razerwolf

Why use Apache when systemd has a built in webserver!

cartman82

OK, I've read a ton of stuff on this sysvinit vs systemd thing. My notes:

The initial idea of systemd was to emulate a similar MacOS system, that allows Macs to have their super-fast boot times.
The trick is twofold:

Parallelize everything by mocking dependent sockets/files upfront, instead of waiting for dependent processes to finish loading
Move functionality away from shell scripts, so that less forks are needed during boot time

It was deemed that a lot of beloved linux tools were better off as modules of systemd than as separate apps. Goodbye crond, syslog etc... Instead, you get crummy stand-in shivs that advertise systemd replacements every time you run them.
This is seen by some as going against Linux philosophy of "each tool should be simple and do one thing, but do it well". Is running the entire system a one thing? According to some, who cares.
Ah yes, the guys behind the systemd. Especially this Poettering dude. They are apparently big time corporate people in Red Hat and such. So they were already pretty despised by the anti-corporate Linux purists. Words such as NSA-sponsored anti-freedom cabal had been thrown around.
The thing is, these hard-core Linux people may appreciate a speed gain, but what they REALLY love is the freedom to pick & chose components and twiddle with shell scripts and know everything that's happening in their system. If they wanted shiny prepackaged performance, they'd have been Mac freaks instead. So systemd is already off to a bad start with them.
Then it turns out that systemd has hardcoded dependencies to Linux kernel and you can't easily (or at all) port it to whatever hacked BSD / Solaris / *Nix kernels they like to run.
Then it turns out syslog replacement is writing logs using a binary format. And you need a native utility to properly read them. And these logs sometimes get corrupted.
Then it turns out systemd usurps kernel --debug switch for itself. Which means these graybeards end up bombarded with reams of useless logs while they are just trying to play with their kernels. Causing some of them to suggest kernel hacks targeted specifically against systemd. And Linus to blow a gasket in his characteristic style.
Then, when all these issues are brought up with Pottering & Co, they turn out to be huge douches. They basically just brush them aside dismissively, as they continue dismantling the Linux the systemd opponents know and love.
And then finally, after all that, huge important distros, such as RedHat and Debian, start adopting systemd as their default init. At this point, there seems to be little chance of going back.

So you might see why there's such a huge drama over all this.

As for the technical dimension... is systemd a good idea overall, in the long run?

I have no idea. I'm not really knowledgeable enough to judge. Obviously it has its upsides and downsides. The history will show which will prevail in the end.

cartman82

This post is deleted!

dkf

@cartman82 said:

As for the technical dimension... is systemd a good idea overall, in the long run?

The cost of doing everything with shell-scripts was actually pretty high; the usual things that accelerate such stuff — particularly caching of plenty of relevant code by the kernel — don't really apply during boot, as that's when the caches are still being populated.

Delaying loads of things while slow services start up was another big boot cost, so the proxy stuff was generally a good idea. A lot of the dependencies rely on having something there, but don't really need to communicate with it immediately.

OTOH, changing the logging format isn't a great idea. Adding log corruption into the mix… abysmal.

rad131304

@accalia said:

it's also done the whole "I'm just going to stop responding to everything, including keyboard and hardware buttons so the only option you have is to unplug it and wait for the battery to run down to reset me. and i'll boot inot safe mode the next time you turn me on."

IIRC you can force a surface to reboot by holding the power button and the window button below the screen. You shouldn't have to wait for the battery to drain.

hhaamu

I hesitate to take part in this juicy Barbie/BSOD/Blakeyrant/systemd/Windows thread, but I'd like an answer to a question.

What problem(s) is systemd trying to solve? (And how come none of the other solutions so far written aren't suitable?)

From my point of view, it seems that Poettering convinced Gnome to have systemd as a hard dependency, and since Gnome is a 'flagship' open sauce project, none of the distros dare to ship a release with an outdated version of gnome. So it pressures them to adopt systemd.

This will affect me even though I haven't touched Gnome in ten years. (I fail to see what's so good about that DE. Or, hell, any DE. Just a plain window manager is plenty for me.) And since I tend to be rather conservative with my software, yes, I'm rather miffed by this sort of upcoming change.

So, um, what problem is systemd trying to solve?