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

51–60 of 91 posts

Re: Interview: Lennart Poettering

#51

Post by pdkl95 »

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/…

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 programs? These are far more numerous[1] than many people realize.

[1] https://www.securecoding.cert.org/confluence/display/seccode...

Re: Interview: Lennart Poettering

#52

Post by digi_owl »

The part about Gnome and logind vs consolekit could have been more detailed.

Poettering was sitting as co-maintainer of consolekit for some time. Then as logind got underway, the maintenance was to pass to Ubuntu under a new project name. But i can't find any trace of this actually happening.

After that the state of consolekit as a project seems to have been in limbo, until recently when a XFCE dev forked the existing code to github as consolekit2.

Apparently said dev would have loved to continue consolekit in place rather than fork, but the final email list traffic between Poettering and Ubuntu gave him the impression that Poettering wanted to see consolekit dead.

So it may well be that people didn't maintain the consolekit code in Gnome because they had the impression that consolekit was dead and buried.

but then Gnome and systemd devs seems to share a "one true way" attitude.

Re: Interview: Lennart Poettering

#53

Post by chousuke »

lawl wrote: post #45
_delirium wrote: post #43

Earlier quoted context omitted.

> In fact the only purpose of an init system is to start executables in a defined order, not more. A good init system should also do process supervision and integrate with the OS's resource-management subsystem (on Linux, cgroups). You could do that with an even bigger pile of shell scripts, of course, and some Linux distros towards the end of the sysvinit era have been trying to. But at some point a giant tangle of…

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 other process supervisors do more than just manage the lifecycle of a process; they can run various checks to ensure that a service actually works. Systemd's process supervision is limited to knowing the current state of the process (running, stopped by admin, failed to start, constantly crashing, or optionally: not responding to watchdog), so systemd in no way makes monitoring daemons redundant.

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.

I would like to know why you think that the process that starts and stops processes should not be interested in whether the processes are actually running or not.

Re: Interview: Lennart Poettering

#54

Post by acdha »

digi_owl wrote: post #44
mercurial wrote: post #39

Earlier quoted context omitted.

I believe it's not about between magical in the general case, but about how you specify dependencies between services, an area where systemd and upstart work differently. See the 'On Upstart' section here [1]. 1: http://0pointer.de/blog/projects/systemd.html

Reminds me why slackware packages do not have dependency resolution, because it invariably breaks. This most often in the sense of X wants Y while Z wants Y+-1. And so you are at an impasse because the dependency resolver can't handle having two versions of Y installed at the same time. A recent failure of systemd i have seen was related to NFS. For some reason systemd would yank the network down before dismounting N…

> A recent failure of systemd i have seen was related to NFS. For some reason systemd would yank the network down before dismounting NFS.

This isn't specific to systemd – I had to deploy workarounds to the same bug in RHEL, Debian, Ubuntu, FreeBSD, etc.

Re: Interview: Lennart Poettering

#55

Post by digi_owl »

Wilya wrote: post #49
_delirium wrote: post #48

Earlier quoted context omitted.

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

Supervisor, god, monit, circus, etc. And even though it can handle both init and process supervision, runit has a clear separation between the two tasks. The "runit" program handles init tasks. The "runsvdir" program handle process supervision. And each one is completely functional without the other.

I wonder how much reduced the grief would be if systemd could run on top of another init process as just a supervisor (similar to how daemontools work, and runit can work).

but then the argument is that systemd needs to be init to properly manage the cgroups etc.

Re: Interview: Lennart Poettering

#56

Post by digi_owl »

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…

That is, imo, the beauty of shell script.

At its core, they are the very same commands you would give manually. but wrapped in basic programming logic (if clauses etc).

thus you can walk the shell script and get a good feel for why the script is doing what it is doing.

If you want to do that with a binary, you pretty much have to either hit it with a debugger (i think a previous thread here on Hacker News actually recommended using strace to inspect systemd boot behavior) or have the source code sit beside it for reference.

Re: Interview: Lennart Poettering

#57

Post by digi_owl »

jvreeland wrote: post #33
gergles wrote: post #24

Earlier quoted context omitted.

The distro developers likely all 'chose' systemd because they were forced to to continue using GNOME, which is the experience people expect as end-users on Linux.

Arch was one of the first to switch and while a decent number use gnome I sincerely doubt they made the choice because of gnome. Arch has a long history of alternative WM/DE It's not likely any individual one could force their hand on an architecture change like systemd.

The Arch switch was a decree from on high as best i can tell, with a very "deal with it" style forum posting.

And i think at least one Arch offshot is not adopting systemd at this time.

Re: Interview: Lennart Poettering

#58

Post by digi_owl »

MertsA wrote: post #46
forgottenpass wrote: post #25

Earlier quoted context omitted.

I find myself wondering why the init is supposed to figure out what the computer is to be doing. I've never messed with systemd configuration too much, but is it much more complicated than a make-style "how do I get there from here? OK lets do that"?

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

Re: Interview: Lennart Poettering

#59

Post by the_why_of_y »

vezzy-fnord wrote: post #22
vinkelhake wrote: post #17

Earlier quoted context omitted.

> Lennart seems to harbor this very strange belief that developing your software in one repository makes you Unix-like, and that this alone is sufficient entirely. He is saying that a trait of the Unix systems was the development in a single repository. In that particular aspect, a fully integrated DOS clone might be more Unix-like than, say, Linux. This is a response to the people who mistake the "Linux way" for the…

The thing is, the aforementioned trait is far too generic - it's a characteristic of how development is structured, and has little or nothing to do with the more technical aspects of the Unix design, which is what is being contested. It's not just Unix. Development in a single repository has been how almost all operating systems were done. In fact, standalone kernels have usually been research projects throughout the…

Of course you can get more specific - for example, the Solaris kernel/libc combination is so tightly coupled that it is described as a "welded unit"

https://www.youtube.com/watch?v=TrfD3pC0VSs#t=29m10

OpenBSD solved the Year 2038 problem by incompatibly changing the kernel and libc ABI in lockstep, which broke every single existing binary application using time_t - how's that for tight coupling...

http://www.openbsd.org/papers/eurobsdcon_2013_time_t/

Re: Interview: Lennart Poettering

#60

Post by bnolsen »

digi_owl wrote: post #57
jvreeland wrote: post #33

Earlier quoted context omitted.

Arch was one of the first to switch and while a decent number use gnome I sincerely doubt they made the choice because of gnome. Arch has a long history of alternative WM/DE It's not likely any individual one could force their hand on an architecture change like systemd.

The Arch switch was a decree from on high as best i can tell, with a very "deal with it" style forum posting. And i think at least one Arch offshot is not adopting systemd at this time.

that's the arch style "deal with it". i run it on several machines but that's always the feeling i got from the arch devs.
Post reply on HN