Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Interview: Lennart Poettering

linuxvoice.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Interview: Lennart Poettering

#71

Post by fsniper »

legulere wrote: post #36
fsniper wrote: post #32

Earlier quoted context omitted.

Distros mostly made the switch because, 1 Redhat pushed systemd into Rhel7 2 Crucial system parts were pr'd into hard dependencies on systemd 3 It's base idea and vision which is currently replaced with broader ones was good evolution. (better init system with woos) 4 technically most of these woos are only implemented with it I am not trying to say systemd does not have it's merits. It has. It is trying hard to brin…

RHEL actually was one of the later distros to adopt systemd, so that line of reasoning doesn't make much sense. > Crucial system parts were pr'd into hard dependencies on systemd Can you tell which crucial system parts you mean? The thing with udev was that it's hard/impossible to build without systemd, however there is no dependency on it. The other thing that is brought up in this context is gnome 3, but that was a…

Gnome and logind is a crucial one. Also it brings it's pam dependency. It is a show stopper for slackware. Kdbus and udev is and will be other parts in this category.

Re: Interview: Lennart Poettering

#72

Post by legulere »

pdkl95 wrote: post #51
mmastrac wrote: post #42

Earlier quoted context omitted.

> That's part of my issue with systemd: replacing safe (-r) shell scripts with C. Because shell scripts are always safe, right? [1][2][3] We used to get root on Android devices by exploiting poorly-written shell scripts. > Also, it probably doesn't help Lennart that he looks like the Rolfe Gruber in the Sound of Music… Personal attacks won't help your case. [1] https://github.com/ValveSoftware/steam-for-linux/issues/…

While bugs happen in any language, shell scripts are far easier to debug than C. You tend to not get nasty interactions spanning multiple source files in shell, where the bugs tend to on a single line (like in that Valve example, where rm should have never been used in such a careless/negligent manner). On the other hand, are you sure you've checked for all of the potential undefined behavior problems in your C progr…

It's also far harder to get shell scripts right compared to C

Re: Interview: Lennart Poettering

#73

Post by ledbettj »

lawl wrote: post #65
chousuke wrote: post #53

Earlier quoted context omitted.

Okay. So, init starts the process supervisor. Then, the process supervisor starts everything else. Then all of a sudden, something goes wrong and the process supervisor crashes. Init then inherits all the children, and has no clue what's going on with them, so your system is hosed. What benefit is there to having the init be separate from the process supervisor? EDIT: let me just expand on this a bit... Monit and oth…

Now you have the process supervisor in your init. What happens if your supervisor crashes now? So obviously that's not a good idea. Additionaly it bears the problem that you can't upgrade your process supervisor without rebooting. So what benefits does it actually provide?

You can restart systemd on the fly with `systemctl daemon-reexec`.

Re: Interview: Lennart Poettering

#74

Post by chousuke »

lawl wrote: post #65
chousuke wrote: post #53

Earlier quoted context omitted.

Okay. So, init starts the process supervisor. Then, the process supervisor starts everything else. Then all of a sudden, something goes wrong and the process supervisor crashes. Init then inherits all the children, and has no clue what's going on with them, so your system is hosed. What benefit is there to having the init be separate from the process supervisor? EDIT: let me just expand on this a bit... Monit and oth…

Now you have the process supervisor in your init. What happens if your supervisor crashes now? So obviously that's not a good idea. Additionaly it bears the problem that you can't upgrade your process supervisor without rebooting. So what benefits does it actually provide?

Your second statement misses the point. Your process supervisor can be ultimately stable and never crash, but if it does crash, it's just as fatal as init crashing.

systemd PID 1 won't be rendered prone to crashing just because it contains more than trivial amounts of code. If that were the case, then surely the Linux kernel would be crashing every fifteen minutes, considering how much code it contains.

As far as I'm aware, the only component that can screw up systemd is dbus, and since the relevant parts are moving into the kernel, you won't just be able to hose your system by killing the dbus daemon accidentally.

I have yet to see an argument for process supervision functionality not existing in PID 1, besides simply stating that it must be so. Meanwhile, an init which is guaranteed to know whether the processes it starts (or stops!) are actually running is able to behave much more intelligently than scripts sending signals to PIDs that hopefully correspond to the correct process.

Re: Interview: Lennart Poettering

#75

Post by jude- »

chousuke wrote: post #53
lawl wrote: post #45

Earlier quoted context omitted.

Process supervising is for process supervisors. Init's jobs is to be able to start a process supervisor.

Okay. So, init starts the process supervisor. Then, the process supervisor starts everything else. Then all of a sudden, something goes wrong and the process supervisor crashes. Init then inherits all the children, and has no clue what's going on with them, so your system is hosed. What benefit is there to having the init be separate from the process supervisor? EDIT: let me just expand on this a bit... Monit and oth…

> When the traditional sysvinit starts and stops processes, it actually has no clue what it's doing and thus init scripts need to rely on PID files and other hacks to provide basic functionality.

Tooting my own horn here, but I wrote a filesystem called runfs that specifically addresses this. A service writes a PID file to runfs, and runfs automatically removes it once the process dies.

Code: https://github.com/jcnelson/runfs

Re: Interview: Lennart Poettering

#76

Post by wtbob »

mmastrac wrote: post #42
wtbob wrote: post #40

> So we slowly started doing stuff that all the other Linux distros did, and implemented that in simple C code that was fast and parallelised. That's part of my issue with systemd: replacing safe (-r) shell scripts with C. Sure, it's fast, but I trust C about as far as I can throw it (and yes, I realise that the Linux kernel is written in C: it constantly has local root exploits, which proves my point). I really wish…

> That's part of my issue with systemd: replacing safe (-r) shell scripts with C. Because shell scripts are always safe, right? [1][2][3] We used to get root on Android devices by exploiting poorly-written shell scripts. > Also, it probably doesn't help Lennart that he looks like the Rolfe Gruber in the Sound of Music… Personal attacks won't help your case. [1] https://github.com/ValveSoftware/steam-for-linux/issues/…

> Because shell scripts are always safe, right?

Hence 'safe (-r),' not 'safe.'

> Personal attacks won't help your case.

It was not an attack, just a statement of fact. He looks just like a movie villain; it's not his fault, and no-one should hold it against him, but I wonder if it hurts him anyway.

Re: Interview: Lennart Poettering

#77

Post by makomk »

chousuke wrote: post #74
lawl wrote: post #65

Earlier quoted context omitted.

Now you have the process supervisor in your init. What happens if your supervisor crashes now? So obviously that's not a good idea. Additionaly it bears the problem that you can't upgrade your process supervisor without rebooting. So what benefits does it actually provide?

Your second statement misses the point. Your process supervisor can be ultimately stable and never crash, but if it does crash, it's just as fatal as init crashing. systemd PID 1 won't be rendered prone to crashing just because it contains more than trivial amounts of code. If that were the case, then surely the Linux kernel would be crashing every fifteen minutes, considering how much code it contains. As far as I'm…

No, your process supervisor crashing won't be as fatal as init crashing, because init crashing is an instant kernel panic under Linux. Also, very few projects are as robust as the Linux kernel or have development practices that are as good, and systemd is unlikely to be one of them.

Re: Interview: Lennart Poettering

#78

Post by makomk »

_delirium wrote: post #48
lawl wrote: post #45

Earlier quoted context omitted.

Process supervising is for process supervisors. Init's jobs is to be able to start a process supervisor.

Are there any examples of a process supervisor that isn't also intended to replace the traditional init system? Even systems less ambitious than SMF/launchd/systemd, like daemontools and runit, aim to replace sysvinit, because otherwise you'd have to specify twice , in different ways, how each service should start and stop (though it's possible to set up configurations where that works).

At the moment I'm using OpenRC which does exactly that on top of sysvinit, as are most Gentoo users. You don't have to specify everything twice because init never actually knew how to start and stop services in the first place - with a traditional sysvinit configuration that was all handled by scripts that it started, and OpenRC replaces those scripts.

Re: Interview: Lennart Poettering

#79

Post by makomk »

jdub wrote: post #16
bhaak wrote: post #9

Earlier quoted context omitted.

The interview wasn't as bad as I expected from the OP's opinion but this one seems mind-bogglingly wrong: "What’s typical for Unix, for example, is that all the tools, the C library, the kernel, are all maintained in the same repository, right? And they’re released in sync, have the same coding style, the same build infrastructure, the same release cycles – everything’s the same. So you get the entire central part of…

He's talking about UNIX , not Linux, and he's 100% right. Look at the BSDs some time, or the Solaris forks. The disconnect between the Linux kernel and basic userland has been a criticism of UNIX traditionalists for years. It's part of the reason why BSD has a few forks and Linux has hundreds of distributions.

Yeah, and from what I've heard most Solaris (and proprietary Unix) installs wound up with a copy of the GNU utilities installed somewhere and added to the sysadmin's PATH because the bundled ones were shit. Before Linux came along, this was the main use of stuff like GNU coreutils. I'm not sure this is really an aspect of traditional Unix we want to be imitating.

Re: Interview: Lennart Poettering

#80

Post by MertsA »

digi_owl wrote: post #58
MertsA wrote: post #46

Earlier quoted context omitted.

That's actually a pretty good summary of the difference between Upstart and systemd, with systemd your services declare what they depend on and your runlevel is now a "target" that declares that it depends on certain services. It does dependency resolution just like a package manager does.

The term "dependency hell" comes to mind...

If that were true you could never start those services in sysvinit either. It works great because there aren't cyclic references and practically no conflicting services. The dependency tree will always be pretty simple.
Post reply on HN