10 ms·

Interview: Lennart Poettering

84 points by talles 12y ago

fsniper 12y ago
I'm not sure if he is really clueless or just trying to flame wars.
- dinergy 12y ago
  i honestly think he believes his stance is the only correct one. you can see it in the way he answered the questions. the bit where he picks apart upstart, gentoo, etc., are nothing more than callous, myopic opinions yet he answers them with cheerful conviction. technical arguments can be made for or against any piece of code. but, he dismisses other projects with a wave of his hand firmly stating that systemd is the "only" correct evolution. i'm am neutral on systemd. do i think the old init system(s) are the right way? not really. do i think systemd is the right way? not really. would i be fine with systemd in the future? perhaps. would i be fine with another bit of code? perhaps. but to dismiss the concerns of a large number of community members, to neglect or downright deny bugs and issues, to shoehorn a project into _everything_ while closing your ears to everyone else, these are my issues with the project. if it works, great. but at least open your eyes and ears and work with everyone. i migrated my home kit to freebsd from debian because i was having errors. failed boots. crashes. config problems. and i didn't have a decade of old crusty init scripts to begin with. what used to be rock solid on my hardware became annoying to deal with. i'm all for change and evolution in software/systems and i don't personally have a problem with poettering or what he is trying to do, but he's doing it in a piss poor way.
  - XorNot 12y ago
    I don't get how an opinion like this: "...to make it clear, I think Upstart actually has its benefits. The source code is very, very nice, and it’s very simple, but I think it’s too simple. It doesn’t have this engine that can figure out what the computer is supposed to be doing." is callous and myopic?
    - random28345 12y ago
      > how an opinion [...] is callous and myopic? There have been hundreds of thousands of words written on how simple utilities can form the basis of supportable, complex systems and still retain the ability to be comprehensible. He has dismissed all that as beneath consideration, and he has the One True Vision™ on how Unix should be architected. Don't get me wrong, hubris and self-righteousness have given us great things: GNU, OpenBSD, qmail, etc. But I don't think anyone would accuse rms or theo or djb of not being callous and myopic.
      - forgottenpass 12y ago
        He has dismissed all that as beneath consideration, and he has the One True Vision™ on how Unix should be architected. I don't see him passing a value judgement on how it should be done, just dismissing a particular criticism as poorly founded. If you look at the difference between the Unix and Linux development models, there is a point. There are a lot of properties to Unix so it's a bad argument to say "not Unixy enough" when you really mean something more along the lines of "components take on too many responsibilities at once and are too tightly coupled."
        digi_owl 12y ago
        Focusing on the repository is a distraction. the whole of systemd sits in a single source tree in freedesktop.org. You don't find system-networkd in one tree, udev in another, systemd-init in a third. In contrast, each part of XFCE, the window manager, the panel, etc, sit as their own source trees within the XFCE repository.
    - digi_owl 12y ago
      I find myself wondering why the init is supposed to figure out what the computer is to be doing. That kind of "automagical" behavior is what drove me bonkers when trying to use Windows for more than a games console...
      - pachydermic 12y ago
- antientropic 12y ago
  Care to point out which remarks were clueless or trollish?
  - bhaak 12y ago
    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 the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was!" I don't even know how you could get this misconception. This really does sound clueless or trollish. The rest of the interview is of a better quality and you follow his reasoning much better even if in the end you would still disagree with him.
    - erglkjahlkh 12y ago
      He mentioned kernel, c libraries, and "all the tools". Well, kernel is in one repository. The (gnu) c library is in one repository. The tools, well the category of stuff like "ls" and "cat" is afaik in one repository. In similar manner, he seems to think that systemd should manage the set of most crucial processes of the base system. I am not saying that he is correct, I am just interpreting!
    - fsniper 12y ago
      Thank you. That's well said. I wish I could read all the piece with the pay per view part. But with this part he is absolutely sure , he is the righteous on every aspect of computing and it's history that he just tries to "create un realistic lines" to make his point.
    - jdub 12y ago
      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.
vezzy-fnord 12y ago
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. So by this logic, a standalone Unix kernel is not Unix-like, but a fully integrated DOS clone, is. In addition: Then we convinced the Fedora Technical Committee to adopt it, and then Red Hat internal management accepted it for RHEL, and we managed to convince every committee that mattered, bit by bit. So there was, in fact, a PR campaign. So Journald is a requirement, and Udev is a requirement. But pretty much all other components are completely optional. Though for some reason the build system doesn't let you disable a ton of these components by default. The committers group is quite diverse, and for us it’s quite an exercise in making the diversity of the community be reflected in the diversity of the people who work on it. This is not as idealistic as Lennart portrays it. See Fallacy #13 here: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...
- mksaunders 12y ago
  "So there was, in fact, a PR campaign." Er, how do you think the Systemd developers convinced these technical teams to use Systemd? With bribes? Sexual favours? Or perhaps, you know, using the software itself? It's funny. The lead developers of Arch Linux, OpenSUSE, Fedora, Mageia, Debian etc. etc. etc. have all chosen to use Systemd. Yet for some reason, many commentators assume these people -- distro technical leads -- simply don't have a clue, and have switched their projects to Systemd because Lennart is somehow forcing it on them. All these distro developers, people a LOT smarter than me, and putting in more work than me, have chosen Systemd. That says a lot to me, and I'm not going to judge them. I'm still on the fence about a lot of Systemd, but to say that major distros have switched because of "PR campaigns" is ridiculous.
  - vezzy-fnord 12y ago
    Hold up. Please don't invoke the argument from popularity, it simply doesn't work. The lead developers of major distros, as smart as they may be, do make mistakes (Debian with cdrkit, sticking with libav for too long, the PRNG bug, etc.) and they may not be fully in line with the intricacies and conceptual differences between process management, init, supervision, hotplug and so on. There's lots of misinformation from both sides and a lot of knowledgeable people (like those maintaining powerful daemontools derivatives) have never been ones to proselytize, but stick to their inner circles. Furthermore, how are you sure the decision to adopt was entirely technical in nature? Perhaps they realized that the incoming systemd-integrated Linux desktop userland wasn't worth the maintenance hassle of trying to avoid it? The way Lennart worded those sentences sounded funny. He is known to distort and exaggerate when promoting, for which I don't blame him, since his goal is to get his software adopted, but nonetheless. systemd proponents have been all too eager to completely dismiss any political meddling on part of systemd's adoption as totally unsubstantiated, insisting it was purely "technical merits". Lennart's words paint a subtly different picture, at the least. Most people don't fully grasp the state of Unix process management, so it's no surprise they're susceptible. For example, the only alternatives that have been debated primarily were Upstart and OpenRC. That's a red flag.
sudioStudio64 12y ago
There's so much emotion wrapped up in this issue that there really isn't anything that this guy could say that would change the perceptions of a lot of people.
geographomics 12y ago
There's a lot of complaint about logical fallacies in the comments of this article. Does anyone know what they're referring to? Seemed like quite a clear interview to me, and interesting to hear a bit of the history behind such a fundamentally useful piece of software.
- bhaak 12y ago
  It's probably from readers of this blog post where "logical" and "fallacy" is quite often used (careful, needs js for viewing): http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...
nurb 12y ago
"if you do an init system but still invoke all the shell scripts and all the other things needed to bring up the system, you’ve only solved part of the problem." That's exactly what I think is wrong with systemd. If a script bring a speed issue on start up, it should fixed by optimizing the script, use/create another script language with parallelism and higher pref, or even turn it into a compiled program. This is not supposed to be the problem of the init system developper. In fact the only purpose of an init system is to start executables in a defined order, not more. This is going to be like X, a huge pile of unmaintainable code, and that's definitely not the UNIX philosophy.
- elwin 12y ago
  > In fact the only purpose of an init system is to start executables in a defined order, not more. That's where the disagreement lies. I see the purpose of an init system as being to transition the machine from one state to another. Sometimes this means starting executables. Sometimes it means stopping them. Sometimes it involves more complicated tasks. > This is going to be like X, a huge pile of unmaintainable code That is exactly my opinion of the shell scripts that previously handled networking.
  - sethrin 12y ago
    Yes, "init" is a bit of a misnomer, given that it also handles shutdown/runlevel transitions. I see the big difference here as being between the people who think that the job of the OS is to provide a simple base for executing user-defined scripts, and well, everyone else. I think that an appropriate analogy would be handcrafted goods versus mass production. Linux has been transformed into a wide variety of products at various times, and while I don't think the init scripts played a very large role in any of that, the idea that the OS is what you choose to turn it into does have strong credence in this community. The other side of the debate, I think, are the people who feel like a collection of init scripts should be refactored somehow, and mostly this seems to involve rewriting things in C, adding dependency annotations to init files, and implementing support for cgroups. At least that's what OpenRC has been doing. Systemd unit files go a step further, but it's a good step in my opinion. Anything that any two scripts do should be refactored into a common method or library, and hopefully that process leaves very little for the init script or unit file to do. It doesn't matter to me personally whether this stuff gets done in Bash or C; I can't really maintain either. I could probably write a unit file if I had to. I understand there are lots of people who have put lots of time into writing Bash scripts. Some sysadmins may even think that their job is to write scripts. These people should continue to write all the scripts that they want, because Linux is all about that, but maybe they should also let other people write a decent plumbing layer for Linux, because modern OSes are all about that.
wtbob 12y ago
> 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 projects like systemd were written in something of like Ocaml, Go, Rust, Common Lisp—anything fast enough but safer. Also, it probably doesn't help Lennart that he looks like the Rolfe Gruber in the Sound of Music…
- mmastrac 12y ago
  > 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/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 [2] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi... [3] http://www.exploit-db.com/papers/13199/ http://www.exploit-db.com/papers/13199/
  - wtbob 12y ago
    > 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.
  - pdkl95 12y ago
    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/CC.+Undefined+Behavior https://www.securecoding.cert.org/confluence/display/seccode...
digi_owl 12y ago
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.
- vezzy-fnord 12y ago
  Oracle actually picked up ConsoleKit and beefed it up significantly for Solaris, giving it true multi-seat support. [1] However, they did this in complete silence, so very few people actually know about this. [1] https://hg.java.net/hg/solaris-desktop~spec-files/file/79574a01c676/patches/ https://hg.java.net/hg/solaris-desktop~spec-files/file/79574... (15 patches)
  - digi_owl 12y ago
    Things like this makes me wonder if RH changed once Oracle bought Sun and then forked RHEL into Oracle Linux. Thus Oracle went from being something of a partner to being a competitor, and RH rolled back on various behaviors (package patch sets etc).
bkeroack 12y ago
"But we believed that an init system should work the other way around, where you say: this is where I want to go to, and you figure out the rest. Because of that design, Upstart was very simple, but it put a lot of complexity on admins and developers, because you actually had to write down all these rules" ...and this is the problem. Pushing this kind of complexity into PID 1 (or however systemd achieves this) is exactly the wrong solution. The init system should not be clever, or contain an "engine that can figure out what the computer is supposed to be doing" as he says later. This really smells of second system syndrome. In reality even with a simple init that pushes complexity to the admins, end users rarely incur the cost. The distribution authors set up init as needed and end users don't need to worry unless they makes changes. Then you get the best of both worlds: easy maintainability and a simple, reliable init system.

84 points by talles 12y ago

fsniper 12y ago

I'm not sure if he is really clueless or just trying to flame wars.

dinergy 12y ago
i honestly think he believes his stance is the only correct one. you can see it in the way he answered the questions. the bit where he picks apart upstart, gentoo, etc., are nothing more than callous, myopic opinions yet he answers them with cheerful conviction. technical arguments can be made for or against any piece of code. but, he dismisses other projects with a wave of his hand firmly stating that systemd is the "only" correct evolution. i'm am neutral on systemd. do i think the old init system(s) are the right way? not really. do i think systemd is the right way? not really. would i be fine with systemd in the future? perhaps. would i be fine with another bit of code? perhaps. but to dismiss the concerns of a large number of community members, to neglect or downright deny bugs and issues, to shoehorn a project into _everything_ while closing your ears to everyone else, these are my issues with the project. if it works, great. but at least open your eyes and ears and work with everyone. i migrated my home kit to freebsd from debian because i was having errors. failed boots. crashes. config problems. and i didn't have a decade of old crusty init scripts to begin with. what used to be rock solid on my hardware became annoying to deal with. i'm all for change and evolution in software/systems and i don't personally have a problem with poettering or what he is trying to do, but he's doing it in a piss poor way.
- XorNot 12y ago
  I don't get how an opinion like this: "...to make it clear, I think Upstart actually has its benefits. The source code is very, very nice, and it’s very simple, but I think it’s too simple. It doesn’t have this engine that can figure out what the computer is supposed to be doing." is callous and myopic?
  - random28345 12y ago
    > how an opinion [...] is callous and myopic? There have been hundreds of thousands of words written on how simple utilities can form the basis of supportable, complex systems and still retain the ability to be comprehensible. He has dismissed all that as beneath consideration, and he has the One True Vision™ on how Unix should be architected. Don't get me wrong, hubris and self-righteousness have given us great things: GNU, OpenBSD, qmail, etc. But I don't think anyone would accuse rms or theo or djb of not being callous and myopic.
    - forgottenpass 12y ago
      He has dismissed all that as beneath consideration, and he has the One True Vision™ on how Unix should be architected. I don't see him passing a value judgement on how it should be done, just dismissing a particular criticism as poorly founded. If you look at the difference between the Unix and Linux development models, there is a point. There are a lot of properties to Unix so it's a bad argument to say "not Unixy enough" when you really mean something more along the lines of "components take on too many responsibilities at once and are too tightly coupled."
      - digi_owl 12y ago
        Focusing on the repository is a distraction. the whole of systemd sits in a single source tree in freedesktop.org. You don't find system-networkd in one tree, udev in another, systemd-init in a third. In contrast, each part of XFCE, the window manager, the panel, etc, sit as their own source trees within the XFCE repository.
  - digi_owl 12y ago
    I find myself wondering why the init is supposed to figure out what the computer is to be doing. That kind of "automagical" behavior is what drove me bonkers when trying to use Windows for more than a games console...
    - pachydermic 12y ago
antientropic 12y ago
Care to point out which remarks were clueless or trollish?
- bhaak 12y ago
  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 the operating system like that. If people claim that, because we stick a lot of things into the Systemd repository, then it’s un-Unixish, then it’s absolutely the opposite. It’s more Unix-ish than Linux ever was!" I don't even know how you could get this misconception. This really does sound clueless or trollish. The rest of the interview is of a better quality and you follow his reasoning much better even if in the end you would still disagree with him.
  - erglkjahlkh 12y ago
    He mentioned kernel, c libraries, and "all the tools". Well, kernel is in one repository. The (gnu) c library is in one repository. The tools, well the category of stuff like "ls" and "cat" is afaik in one repository. In similar manner, he seems to think that systemd should manage the set of most crucial processes of the base system. I am not saying that he is correct, I am just interpreting!
  - fsniper 12y ago
    Thank you. That's well said. I wish I could read all the piece with the pay per view part. But with this part he is absolutely sure , he is the righteous on every aspect of computing and it's history that he just tries to "create un realistic lines" to make his point.
  - jdub 12y ago
    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.

vezzy-fnord 12y ago

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. So by this logic, a standalone Unix kernel is not Unix-like, but a fully integrated DOS clone, is. In addition: Then we convinced the Fedora Technical Committee to adopt it, and then Red Hat internal management accepted it for RHEL, and we managed to convince every committee that mattered, bit by bit. So there was, in fact, a PR campaign. So Journald is a requirement, and Udev is a requirement. But pretty much all other components are completely optional. Though for some reason the build system doesn't let you disable a ton of these components by default. The committers group is quite diverse, and for us it’s quite an exercise in making the diversity of the community be reflected in the diversity of the people who work on it. This is not as idealistic as Lennart portrays it. See Fallacy #13 here: http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...

mksaunders 12y ago
"So there was, in fact, a PR campaign." Er, how do you think the Systemd developers convinced these technical teams to use Systemd? With bribes? Sexual favours? Or perhaps, you know, using the software itself? It's funny. The lead developers of Arch Linux, OpenSUSE, Fedora, Mageia, Debian etc. etc. etc. have all chosen to use Systemd. Yet for some reason, many commentators assume these people -- distro technical leads -- simply don't have a clue, and have switched their projects to Systemd because Lennart is somehow forcing it on them. All these distro developers, people a LOT smarter than me, and putting in more work than me, have chosen Systemd. That says a lot to me, and I'm not going to judge them. I'm still on the fence about a lot of Systemd, but to say that major distros have switched because of "PR campaigns" is ridiculous.
- vezzy-fnord 12y ago
  Hold up. Please don't invoke the argument from popularity, it simply doesn't work. The lead developers of major distros, as smart as they may be, do make mistakes (Debian with cdrkit, sticking with libav for too long, the PRNG bug, etc.) and they may not be fully in line with the intricacies and conceptual differences between process management, init, supervision, hotplug and so on. There's lots of misinformation from both sides and a lot of knowledgeable people (like those maintaining powerful daemontools derivatives) have never been ones to proselytize, but stick to their inner circles. Furthermore, how are you sure the decision to adopt was entirely technical in nature? Perhaps they realized that the incoming systemd-integrated Linux desktop userland wasn't worth the maintenance hassle of trying to avoid it? The way Lennart worded those sentences sounded funny. He is known to distort and exaggerate when promoting, for which I don't blame him, since his goal is to get his software adopted, but nonetheless. systemd proponents have been all too eager to completely dismiss any political meddling on part of systemd's adoption as totally unsubstantiated, insisting it was purely "technical merits". Lennart's words paint a subtly different picture, at the least. Most people don't fully grasp the state of Unix process management, so it's no surprise they're susceptible. For example, the only alternatives that have been debated primarily were Upstart and OpenRC. That's a red flag.

sudioStudio64 12y ago

There's so much emotion wrapped up in this issue that there really isn't anything that this guy could say that would change the perceptions of a lot of people.

geographomics 12y ago

There's a lot of complaint about logical fallacies in the comments of this article. Does anyone know what they're referring to? Seemed like quite a clear interview to me, and interesting to hear a bit of the history behind such a fundamentally useful piece of software.

bhaak 12y ago
It's probably from readers of this blog post where "logical" and "fallacy" is quite often used (careful, needs js for viewing): http://judecnelson.blogspot.com/2014/09/systemd-biggest-fallacies.html http://judecnelson.blogspot.com/2014/09/systemd-biggest-fall...

nurb 12y ago

"if you do an init system but still invoke all the shell scripts and all the other things needed to bring up the system, you’ve only solved part of the problem." That's exactly what I think is wrong with systemd. If a script bring a speed issue on start up, it should fixed by optimizing the script, use/create another script language with parallelism and higher pref, or even turn it into a compiled program. This is not supposed to be the problem of the init system developper. In fact the only purpose of an init system is to start executables in a defined order, not more. This is going to be like X, a huge pile of unmaintainable code, and that's definitely not the UNIX philosophy.

elwin 12y ago
> In fact the only purpose of an init system is to start executables in a defined order, not more. That's where the disagreement lies. I see the purpose of an init system as being to transition the machine from one state to another. Sometimes this means starting executables. Sometimes it means stopping them. Sometimes it involves more complicated tasks. > This is going to be like X, a huge pile of unmaintainable code That is exactly my opinion of the shell scripts that previously handled networking.
- sethrin 12y ago
  Yes, "init" is a bit of a misnomer, given that it also handles shutdown/runlevel transitions. I see the big difference here as being between the people who think that the job of the OS is to provide a simple base for executing user-defined scripts, and well, everyone else. I think that an appropriate analogy would be handcrafted goods versus mass production. Linux has been transformed into a wide variety of products at various times, and while I don't think the init scripts played a very large role in any of that, the idea that the OS is what you choose to turn it into does have strong credence in this community. The other side of the debate, I think, are the people who feel like a collection of init scripts should be refactored somehow, and mostly this seems to involve rewriting things in C, adding dependency annotations to init files, and implementing support for cgroups. At least that's what OpenRC has been doing. Systemd unit files go a step further, but it's a good step in my opinion. Anything that any two scripts do should be refactored into a common method or library, and hopefully that process leaves very little for the init script or unit file to do. It doesn't matter to me personally whether this stuff gets done in Bash or C; I can't really maintain either. I could probably write a unit file if I had to. I understand there are lots of people who have put lots of time into writing Bash scripts. Some sysadmins may even think that their job is to write scripts. These people should continue to write all the scripts that they want, because Linux is all about that, but maybe they should also let other people write a decent plumbing layer for Linux, because modern OSes are all about that.

wtbob 12y ago

> 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 projects like systemd were written in something of like Ocaml, Go, Rust, Common Lisp—anything fast enough but safer. Also, it probably doesn't help Lennart that he looks like the Rolfe Gruber in the Sound of Music…

mmastrac 12y ago
> 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/3671 https://github.com/ValveSoftware/steam-for-linux/issues/3671 [2] https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commit/a047be85247755cdbe0acce6f1dafc8beb84f2ac https://github.com/MrMEEE/bumblebee-Old-and-abbandoned/commi... [3] http://www.exploit-db.com/papers/13199/ http://www.exploit-db.com/papers/13199/
- wtbob 12y ago
  > 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.
- pdkl95 12y ago
  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/CC.+Undefined+Behavior https://www.securecoding.cert.org/confluence/display/seccode...

digi_owl 12y ago

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.

vezzy-fnord 12y ago
Oracle actually picked up ConsoleKit and beefed it up significantly for Solaris, giving it true multi-seat support. [1] However, they did this in complete silence, so very few people actually know about this. [1] https://hg.java.net/hg/solaris-desktop~spec-files/file/79574a01c676/patches/ https://hg.java.net/hg/solaris-desktop~spec-files/file/79574... (15 patches)
- digi_owl 12y ago
  Things like this makes me wonder if RH changed once Oracle bought Sun and then forked RHEL into Oracle Linux. Thus Oracle went from being something of a partner to being a competitor, and RH rolled back on various behaviors (package patch sets etc).

bkeroack 12y ago

"But we believed that an init system should work the other way around, where you say: this is where I want to go to, and you figure out the rest. Because of that design, Upstart was very simple, but it put a lot of complexity on admins and developers, because you actually had to write down all these rules" ...and this is the problem. Pushing this kind of complexity into PID 1 (or however systemd achieves this) is exactly the wrong solution. The init system should not be clever, or contain an "engine that can figure out what the computer is supposed to be doing" as he says later. This really smells of second system syndrome. In reality even with a simple init that pushes complexity to the admins, end users rarely incur the cost. The distribution authors set up init as needed and end users don't need to worry unless they makes changes. Then you get the best of both worlds: easy maintainability and a simple, reliable init system.