Lennart: The State & Future Of Systemd

[xeekei]

Does anyone know if there's a video of this talk up online?

[Krejzi]

Thanks to the monolithic systemd, causing pid 1 to be linked with Dbus, I've had to reboot my Linux box more than Windows in last month The re-exec option, just didn't work and the insecure deleted Dbus lib was still mapped into systemd's memory space. This may be a choice of my distro, rather than a consequence of systemd, I have read Lennart somewhere saying systemd doesn't have to run as pid 1, I would like it not to, so sending a SIGHUP or something to pid 1, or killing systemd would have it auto restarted, solving the security update problem.

What? When was it that you last checked it? There is nothing linked to libdbus-1 in systemd-215.

$ ldd /sbin/init
        linux-vdso.so.1 (0x00007fff567ff000)
        libpam.so.0 => /lib/libpam.so.0 (0x00007fc2dac20000)
        libcap.so.2 => /lib/libcap.so.2 (0x00007fc2daa1c000)
        libkmod.so.2 => /lib/libkmod.so.2 (0x00007fc2da806000)
        librt.so.1 => /lib/librt.so.1 (0x00007fc2da5fe000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc2da3e0000)
        libc.so.6 => /lib/libc.so.6 (0x00007fc2da033000)
        /lib/ld-linux-x86-64.so.2 (0x00007fc2dae2d000)
        libdl.so.2 => /lib/libdl.so.2 (0x00007fc2d9e2f000)
        libattr.so.1 => /lib/libattr.so.1 (0x00007fc2d9c2a000)
        liblzma.so.5 => /lib/liblzma.so.5 (0x00007fc2d99fb000)
        libz.so.1 => /lib/libz.so.1 (0x00007fc2d97e2000)

$ readelf -d /sbin/init | grep NEEDED
 0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libkmod.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

I fail to understand why it links to PAM and kmod libraries but I guess not without a good reason. Do note that you can disable PAM and kmod support, leaving you only with libcap besides the glibc supplied libs.

[faildozer]

SVCHost for Linux

Originally I wasn't really fond of the idea of svchost on Windows, all those processes gunking up my lightweight system with craziness. Once I found out what svchost was actually doing I was a bit more okay with it. Coming into Linux, I'm actually starting to like Systemd a lot more. For a rather simple user like myself, it's never crashed on me, never given me any kind of trouble, even in its current state it just works. Systemd is becoming large in features, but that's not really that big of a problem. It's becoming the SvcHost for Linux, which I feel is actually rather helpful and a somewhat necessary push for Linux's operating design to make it competitive with Windows. Stripping the features out of the kernel and into Systemd, or getting rid of 10 alternatives 3rd-party programs that all do the same thing is nice. I know plenty of linux/pro-choice purists are upset at that, but for someone like me that really helps with getting things set up a lot faster with every fresh install/reformat. At the same time, just like the svchost/service system in Windows, most of the time you can disable parts of systemd, so if you ever want to have a different component you can just install it afterwards. It even solves my biggest design gripe about svchost processes in that Systemd actually has names for its components instead of just command-line arguments onto svchost.exe

[curaga]

It's becoming the SvcHost for Linux

That's an excellent comparison.

[johnc]

Originally I wasn't really fond of the idea of svchost on Windows, all those processes gunking up my lightweight system with craziness. Once I found out what svchost was actually doing I was a bit more okay with it. Coming into Linux, I'm actually starting to like Systemd a lot more. For a rather simple user like myself, it's never crashed on me, never given me any kind of trouble, even in its current state it just works. Systemd is becoming large in features, but that's not really that big of a problem. It's becoming the SvcHost for Linux, which I feel is actually rather helpful and a somewhat necessary push for Linux's operating design to make it competitive with Windows. Stripping the features out of the kernel and into Systemd, or getting rid of 10 alternatives 3rd-party programs that all do the same thing is nice. I know plenty of linux/pro-choice purists are upset at that, but for someone like me that really helps with getting things set up a lot faster with every fresh install/reformat. At the same time, just like the svchost/service system in Windows, most of the time you can disable parts of systemd, so if you ever want to have a different component you can just install it afterwards. It even solves my biggest design gripe about svchost processes in that Systemd actually has names for its components instead of just command-line arguments onto svchost.exe

This is an intriguing view to me. Systemd makes Linux more competitive with Windows "for a rather simple user" like yourself... how?

If a rather simple user went and installed Ubuntu 12.04, how would his experience be deficient because of not having systemd?

[Chousuke]

This is an intriguing view to me. Systemd makes Linux more competitive with Windows "for a rather simple user" like yourself... how?

If a rather simple user went and installed Ubuntu 12.04, how would his experience be deficient because of not having systemd?

The "rather simple user" benefits indirectly. With systemd providing shared components with well thought out interfaces, there's significantly less integration and testing work that the distro maintainers need to do to ensure that their core system components work correctly. This translates to having more time to work on actual user-visible features.

[faildozer]

This is an intriguing view to me. Systemd makes Linux more competitive with Windows "for a rather simple user" like yourself... how?

If a rather simple user went and installed Ubuntu 12.04, how would his experience be deficient because of not having systemd?

It really isn't that deficient without Systemd, which is why I wonder why people really care that much about whether or not their system is using it if they're a simple user such as myself. Personally I use Manjaro because of it's rolling distro design and because I get tons of nice software updates to everything without having to add 15+ PPAs to my sources list. Manjaro has been using Systemd the entire time I've had it installed, and while I don't know everything it does, it works. It really wouldn't affect me that much whether I use upstart or systemd. Having a project that's supported by so many developers and so much of the community is what makes Systemd so appealing over something like Upstart, for other developers and people like myself. When you see something with so much support and care put into it, you can trust your system again and feel safe having it installed as the backbone of your system because you're going to have something stable in the long run.

What I feel is that something having like Systemd, becoming a rather monolithic set of modules and processes, becoming like svchost, helps someone like myself actually marginally understand what my computer is starting up with and what it all does. When I have 20 different system applications installed to do their own little bits, if I look in my process list to see what might be causing my system to be messing up, I have to go looking up what everything is doing to make sure I don't accidentally kill something that's gonna wreck my current session. If there's just systemd and its modules, I know the name and I know that I probably shouldn't really kill any of those. Really if you just look at anything forked from the init process you can think the same thing, but telling a friend that you just got to try out linux to "not kill Systemd" or "don't kill upstart" is so much easier to explain than "don't kill X-random process because it does Y-random feature".

The "rather simple user" benefits indirectly. With systemd providing shared components with well thought out interfaces, there's significantly less integration and testing work that the distro maintainers need to do to ensure that their core system components work correctly. This translates to having more time to work on actual user-visible features.

This as well is an extremely good point. With a solid backend, distros can now focus on software and front-ends again. I'll be able to give my artist friends a distro that specifically caters to art software, or video editing, with all the software included in them at their bleeding edge releases, while I can give someone like my mother, who just wants a computer for web browsing and working on geneology in documents and spreadsheets, something like Ubuntu which focuses on a balanced, stable experience.

[rockinrobstar]

Has anyone got a mirror for that pdf file? It seems Lennart's site is struggling a bit.

[johnc]

The "rather simple user" benefits indirectly. With systemd providing shared components with well thought out interfaces, there's significantly less integration and testing work that the distro maintainers need to do to ensure that their core system components work correctly. This translates to having more time to work on actual user-visible features.

So we could infer that systemd-based distros provide a better user experience than non-systemd distros?

Is there any evidence that systemd distros were at the top of the popularity charts?

[faildozer]

So we could infer that systemd-based distros provide a better user experience than non-systemd distros?

Is there any evidence that systemd distros were at the top of the popularity charts?

I wouldn't say there's any evidence now, but at the same time the growth of Systemd and then amount of features it's getting is only really just starting to accelerate quickly, as is the number of distros picking it up. It's barely 4 years old, which for the kind of thing it is marks it as a baby project. The fact that there are distros that have adopted it that aren't exploding every other minute I feel is a rather impressive statement of its quality of development so far.