Interview: Lennart Poettering

Post by digi_owl » Fri, Jan 16, 2015, 5:53 PM UTC

vezzy-fnord wrote: post #12

pachydermic wrote: post #7

Earlier quoted context omitted.

I dunno. If it's able to do what you want automatically that's amazing. If I can just plug the printer in and have it work that's amazing. If I can turn the wireless on my laptop on and it works that's amazing. And so on. The problems arise when it doesn't automatically do what you want it to do and you don't have a good way of fixing it yourself. I'm not in a position to understand init systems so I will be in this…

Hotplug isn't the job of systemd to begin with, though. It's the job of the device manager, which on Linux is usually udev (but alternatives like eudev, mdev, smdev and vdev exist) - udev being a part of the systemd repository and to an extent coupled with it (which will become complete when kdbus is merged into mainline Linux), however it's still a rather distinct piece of software that maintains the hardware databa…

Post by _delirium » Fri, Jan 16, 2015, 6:10 PM UTC

nurb wrote: post #23

"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 no…

Post by lawl » Fri, Jan 16, 2015, 6:14 PM UTC

_delirium wrote: post #43

nurb wrote: post #23

"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 no…

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

Post by digi_owl » Fri, Jan 16, 2015, 6:16 PM UTC

forgottenpass wrote: post #31

random28345 wrote: post #10

Earlier quoted context omitted.

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

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

Post by Wilya » Fri, Jan 16, 2015, 6:38 PM UTC

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