4 ms·

This submission won't make any sense without a little bit of background. (The comments here at the moment are all predictably confused.) Start here: http://lwn

This submission won't make any sense without a little bit of background. (The comments here at the moment are all predictably confused.) Start here: http://lwn.net/Articles/520892/ http://lwn.net/Articles/520892/ Core parts of Gnome (and probably lots of other Linux-y software, I haven't been following all of it) are all moving to require systemd. Systemd certainly promises a lot of advantages, like better handling of removable devices (and more: https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530 https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149530), but it is also replacing the tried-and-trusted rc approach. OpenBSD leaders in particular are concerned about systemd from a security standpoint; it has a lot of code that runs as root, it is big and unwieldy and the documentation is a mess. So, not only were the OpenBSD developers faced with either auditing the entire systemd code base -- and then doing it again every time there's a new release -- or attempting to re-implement it in a compatible way, now they're also staring down the very short barrel of a nasty gun in which some really big stuff is going to stop working if they don't deal with it. It's a real ugly situation, and OpenBSD really doesn't have the resources to spare to deal with this kind of nonsense. I wouldn't be surprised if this mess ends up tying up a couple of their core developers at an upcoming hackathon, where they could instead be working on something more useful than having to replace a huge part of the system that was working just fine up until Linux decided to throw it out. (Obviously there are plenty of people that would argue it wasn't "working just fine", either because they have specific knowledge about it or because "otherwise we wouldn't have needed systemd". That's not sufficient justification for forcing other developers to waste tremendous amounts of effort to re-work what was already working for them.) Personally, I'm not a huge fan of the switch to systemd. I liked rc scripts. I've cobbled together my own rc daemon scripts from time to time; I'm not sure how that will work with systemd. I'm also seeing lots of ugly and persistent problems in NetworkMangler and whatever they're using for core audio these days; I'm a little gobsmacked that, rather than fixing those problems, some people decided to replace the init system.

darklajid 14y ago
Thanks for a little bit of context. About systemd itself: I guess so far it's really hard to say if it's worth the hassle. My experience is limited to two installations: One on a (admittedly beta level) Fedora image and running Arch on my Pi. The latter was really pleasant, _including_ the systemd migration. I never used it before and definitely fell in love with a couple of features (The status, unifying log messages and the service status, for one). I'd be the first to agree that there's quite a bit of room to improve. Some design decisions are questionable imho (like the stated opinion that systemd shouldn't write a text-only /var/log/messages file by default). In the end it's always the same though: Some people are having a vision of how things should work and try to promote it. If they are successful, I'd argue that their idea has merit (or everyone else doesn't care).
- stephen_g 14y ago
  "Some design decisions are questionable imho (like the stated opinion that systemd shouldn't write a text-only /var/log/messages file by default)" I think that may have changed in the latest release (or maybe it's in the next release, but I'm pretty sure Lennart said the default was going to be to write logs).
  - npsimons 14y ago
    I think that may have changed in the latest release (or maybe it's in the next release, but I'm pretty sure Lennart said the default was going to be to write logs). See, the problem with the sentence "shouldn't write a text-only /var/log/messages file by default" wasn't the "shouldn't write a [log] by default" part, it was the "shouldn't write a text-only [log]" part. As a CLI jockey/junky/sysadmin, I for one will not accept any solution I can't grep. As a long time Linux user, I can't but agree with the OpenBSD folks: systemd is a "solution" in search of a problem, and the only reason it is gaining any traction appears to be the same shove-it-down-the-user's throat attitude that the GNOME devs have. Granted, there has been a proliferation of parallelized boot schemes cropping up in Linux, but systemd seems to take too much on itself. And while PulseAudio eventually settled down and solved the proliferation of audio multiplexing systems, it was a very bumpy ride getting there. I only bring that up because that was another Poettering project.
gillianseed 14y ago
Thanks for the lwn link, it really helped to put things in a larger perspective. And I can't help but feel that Gnome is being used here to enforce systemd dependancy for reasons other than purely practical.. I think systemd is currently the best init system when it comes to potential, however I don't like how it 'swallows' other core components like udev as I think that might have a negative impact on possible alternatives being developed. I think systemd should compete on it's merits and not by what seems like it becoming a dependency as part of an agenda rather than a practical necessity.
- varjag 14y ago
  Systemd depends on an httpd. It simply can't be the system with the best potential, I refuse to believe it.
  - batgaijin 14y ago
    could you expand on that?
    - rwmj 14y ago
      It's a long and rather sad story, but since systemd started to do its own logging (using a binary format), it can optionally now link to a micro HTTP server so that you can connect to the journal on localhost in order to read these logs (http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n478 http://cgit.freedesktop.org/systemd/systemd/tree/configure.a...). I won't offer any opinions on whether this is good or bad, simply state that's what happened.
  - darklajid 14y ago
    Which version? And are you talking about a hard dependency or a recommendation / something optional? Here: pacman -Si systemd Repository : core Name : systemd Version : 195-2 URL : http://www.freedesktop.org/wiki/Software/systemd Licenses : GPL2 LGPL2.1 MIT Groups : None Provides : libsystemd=195 systemd-tools=195 udev=195 Depends On : acl bash dbus-core glib2 kbd kmod hwids libcap libgcrypt pam util-linux xz Optional Deps : initscripts: legacy support for /etc/rc.conf python: systemd library bindings python2-cairo: systemd-analyze python2-dbus: systemd-analyze systemd-sysvcompat: symlink package to provide sysvinit binaries cryptsetup: required for encrypted block devices quota-tools: kernel-level quota management
ambrop7 14y ago
Concerning NetworkManager, you might like my NCD scripting language designed specifically for programming of network configurations. http://code.google.com/p/badvpn/wiki/NCD http://code.google.com/p/badvpn/wiki/NCD
- thaumaturgy 14y ago
  Wow. You developed a programming language for handling network connections; that is actually really neat. It's way past my bedtime, so I might've missed it, but is there any way in NCD to detect, say, a new wired connection, and then a timeout waiting for dhcp, and then as a fallback, configure the interface with a static ip? I'm not sure what I think about having to edit a file every time I want to connect to a new network, but on the other hand, it would be super nice not to have to reboot every N times I switch network connections.
  - ambrop7 14y ago
    It sure it possible. Seems like the perfect case for the multiprovide() module (CTRL+F on wiki for more info, and also the in-source documentation http://code.google.com/p/badvpn/source/browse/trunk/ncd/modules/multidepend.c http://code.google.com/p/badvpn/source/browse/trunk/ncd/modu... ). process lan { # Set device. var("eth0") dev; # Wait for device, set it up, and wait for network cable. net.backend.waitdevice(dev); net.up(dev); net.backend.waitlink(dev); # Start doing DHCP and waiting for timeout. This spawns two additional # processes to run concurrently (see their code below). process_manager() mgr; mgr->start("dhcp", "conf_dhcp_template", {dev}); mgr->start("static", "conf_static_template", {dev}); # Wait for either multiprovide("LAN-DHCP") or multiprovide("LAN-STATIC"), # but always prefer LAN-DHCP. Even if we've already grabbed LAN-STATIC # and LAN-DHCP comes up, we backtrack and switch to LAN-DHCP. multidepend({"LAN-DHCP", "LAN-STATIC"}) conf_dep; # We can reach objects as seen from multiprovide() by going # through our multidepend() statement. println("got ", conf_dep.result_type); rprintln("lost ", conf_dep.result_type); # Check IP address - make sure it's not local. ip_in_network(conf_dep.addr, "127.0.0.0", "8") test_local; ifnot(test_local); # Assign IP address. net.ipv4.addr(dev, conf_dep.addr, conf_dep.addr_prefix); # Add default route. net.ipv4.route("0.0.0.0", "0", conf_dep.gateway, "20", dev); # Configure DNS servers. net.dns(conf_dep.dns_servers, "20"); } template conf_dhcp_template { # First argument is device name. var(_arg0) dev; # Do DHCP. net.ipv4.dhcp(dev) dhcp; # Expose results. var("dhcp") result_type; var(dhcp.addr) addr; var(dhcp.prefix) addr_prefix; var(dhcp.gateway) gateway; var(dhcp.dns_servers) dns_servers; multiprovide("LAN-DHCP"); } template conf_static_template { # First argument is device name. var(_arg0) dev; # Wait 5 seconds. sleep("5000", "0"); # Expose results. var("static") result_type; var("192.168.111.230") addr; var("24") addr_prefix; var("192.168.111.1") gateway; var({"192.168.111.14"}) dns_servers; multiprovide("LAN-STATIC"); }
pmr_ 14y ago
The maturity of systemd is at the root of the problem here. I switched (even for ArchLinux standards) relatively early and since then I could see how things changed continuously. There are two factors here: I appreciate active development of software and I would like things to stay compatible with previous releases at a minor cost to "progress". It is hard to get both in such a complex design space. Most of the problems are hard to predict and only come up as soon as there is active use of the system and if you never go public, there will never be active use. Overall, jumping on the systemd bandwagon was done prematurely (at least by ArchLinux) and I think the large software packages should just give it another few months before migrating. systemd solves a lot of problems now and developers want problems to go as away before they become a feature or to pervasive to the codebase, but a little restraint might to a lot of good here. There has to come a point where systemd announces feature completeness and stable interfaces so everybody can use it as a standard and then everybody can go for broad use and acceptance. I would hope that this gives the smaller players a chance to catch-up and much needed safety when investing resources into their own implementations.
- AnthonyMouse 14y ago
  >The maturity of systemd is at the root of the problem here. That is pretty much what I came in here to say. It seems like OpenBSD is trying to have it both ways: Include all the latest and greatest toys and still thoroughly audit everything that changes between releases. But it's new toys, secure, cheap. Pick two. Is it really the end of the world if OpenBSD bears a closer resemblance to Debian Stable for the sake of security? Why is 'latest Gnome' a requirement? Just stick with older versions of everything until the new APIs stabilize and mature.
  - sounds 14y ago
    A good compromise, to be sure. But the problems with systemd aren't an isolated case, and they aren't technical, they're political. And political problems generally don't get better when a technical solution is applied; in this case, waiting it out just silences OpenBSD's voice in the potential discussion. So I'm glad they're making an effort to engage the community and look for alternatives to the political problem. I'm deliberately not saying exactly what the political problem is – I'm not "framing" it one way or another.
lostnet 14y ago
Thank you for the background! I worked on Solaris during the Gnome transition and during the largely overlapping SMF transition. I'm not sure which was more painful or was more broken by design, though SMF surely affected more developers. If I were making decisions for OpenBSD I would not accept a requirement to port an init replacement, but I also wouldn't be putting any resources into keeping Gnome running that could go into better integration with an alternative. While it is nice to be able to mix and match everything rather than having choose a silo, having these large market share players like gnome dictate changes on every platform is ultimately rather destructive to having meaningful options. I would rather run the Linux kernel for practical reasons, and often use gnome for practical reasons though I would be thrilled not to. Showing me you can keep up with Linux running gnome isn't compelling at all, particularly if it means you are no longer doing much else. But if you can better integrate with KDE or enlightenment (or fvwm and some duct tape,) and give me an alternative to linux+gnome then I'll deal with a new kernel (and not having PAM?!)
pja 14y ago
I don't understand why systemd is suddenly such a hard requirement: it suggests that the Gnome developers are simply punching through the abstraction layer provided by dbus for reasons of convenience. If some part of Gnome needs a system service, it requests it via dbus and parses the response. How that service is delivered ought to be irrelevant. Since systemd is supposed to offer all its services via dbus, is the problem really "we don't want to implement all these services that a modern desktop needs". OpenBSD et al could offer a dbus layer that implements the same set of services, but they don't want (or have the manpower) to do so. In which case, I'm not really sure they have a leg to stand on: the things systemd offers really are important for a modern well integrated desktop (or any other system for that matter) and they weren't well served by initscripts. OpenBSD is free to implement a service that offers the same dbus interfaces whenever they want, but complaining about Linuxisms is perhaps a little rich: if you want your system to remain stuck in the early 1990s then that's fine, but you can't really expect the rest of the world to hang around waiting for you to catch up.
- pja 14y ago
  NB If the answer to "why can't you write dbus interfaces" is "we'd love to, but the Gnome developers keep changing the interfaces every minor point release" then that's probably a valid retort...
krakensden 14y ago
> it is big and unwieldy and the documentation is a mess. Only if you compare it to RC and then omit the enormous horrible undocumented copypasta mess that was RC scripts

darklajid 14y ago

Thanks for a little bit of context. About systemd itself: I guess so far it's really hard to say if it's worth the hassle. My experience is limited to two installations: One on a (admittedly beta level) Fedora image and running Arch on my Pi. The latter was really pleasant, _including_ the systemd migration. I never used it before and definitely fell in love with a couple of features (The status, unifying log messages and the service status, for one). I'd be the first to agree that there's quite a bit of room to improve. Some design decisions are questionable imho (like the stated opinion that systemd shouldn't write a text-only /var/log/messages file by default). In the end it's always the same though: Some people are having a vision of how things should work and try to promote it. If they are successful, I'd argue that their idea has merit (or everyone else doesn't care).

stephen_g 14y ago
"Some design decisions are questionable imho (like the stated opinion that systemd shouldn't write a text-only /var/log/messages file by default)" I think that may have changed in the latest release (or maybe it's in the next release, but I'm pretty sure Lennart said the default was going to be to write logs).
- npsimons 14y ago
  I think that may have changed in the latest release (or maybe it's in the next release, but I'm pretty sure Lennart said the default was going to be to write logs). See, the problem with the sentence "shouldn't write a text-only /var/log/messages file by default" wasn't the "shouldn't write a [log] by default" part, it was the "shouldn't write a text-only [log]" part. As a CLI jockey/junky/sysadmin, I for one will not accept any solution I can't grep. As a long time Linux user, I can't but agree with the OpenBSD folks: systemd is a "solution" in search of a problem, and the only reason it is gaining any traction appears to be the same shove-it-down-the-user's throat attitude that the GNOME devs have. Granted, there has been a proliferation of parallelized boot schemes cropping up in Linux, but systemd seems to take too much on itself. And while PulseAudio eventually settled down and solved the proliferation of audio multiplexing systems, it was a very bumpy ride getting there. I only bring that up because that was another Poettering project.

gillianseed 14y ago

Thanks for the lwn link, it really helped to put things in a larger perspective. And I can't help but feel that Gnome is being used here to enforce systemd dependancy for reasons other than purely practical.. I think systemd is currently the best init system when it comes to potential, however I don't like how it 'swallows' other core components like udev as I think that might have a negative impact on possible alternatives being developed. I think systemd should compete on it's merits and not by what seems like it becoming a dependency as part of an agenda rather than a practical necessity.

varjag 14y ago
Systemd depends on an httpd. It simply can't be the system with the best potential, I refuse to believe it.
- batgaijin 14y ago
  could you expand on that?
  - rwmj 14y ago
    It's a long and rather sad story, but since systemd started to do its own logging (using a binary format), it can optionally now link to a micro HTTP server so that you can connect to the journal on localhost in order to read these logs (http://cgit.freedesktop.org/systemd/systemd/tree/configure.ac#n478 http://cgit.freedesktop.org/systemd/systemd/tree/configure.a...). I won't offer any opinions on whether this is good or bad, simply state that's what happened.
- darklajid 14y ago
  Which version? And are you talking about a hard dependency or a recommendation / something optional? Here: pacman -Si systemd Repository : core Name : systemd Version : 195-2 URL : http://www.freedesktop.org/wiki/Software/systemd Licenses : GPL2 LGPL2.1 MIT Groups : None Provides : libsystemd=195 systemd-tools=195 udev=195 Depends On : acl bash dbus-core glib2 kbd kmod hwids libcap libgcrypt pam util-linux xz Optional Deps : initscripts: legacy support for /etc/rc.conf python: systemd library bindings python2-cairo: systemd-analyze python2-dbus: systemd-analyze systemd-sysvcompat: symlink package to provide sysvinit binaries cryptsetup: required for encrypted block devices quota-tools: kernel-level quota management

ambrop7 14y ago

Concerning NetworkManager, you might like my NCD scripting language designed specifically for programming of network configurations. http://code.google.com/p/badvpn/wiki/NCD http://code.google.com/p/badvpn/wiki/NCD

thaumaturgy 14y ago
Wow. You developed a programming language for handling network connections; that is actually really neat. It's way past my bedtime, so I might've missed it, but is there any way in NCD to detect, say, a new wired connection, and then a timeout waiting for dhcp, and then as a fallback, configure the interface with a static ip? I'm not sure what I think about having to edit a file every time I want to connect to a new network, but on the other hand, it would be super nice not to have to reboot every N times I switch network connections.
- ambrop7 14y ago
  It sure it possible. Seems like the perfect case for the multiprovide() module (CTRL+F on wiki for more info, and also the in-source documentation http://code.google.com/p/badvpn/source/browse/trunk/ncd/modules/multidepend.c http://code.google.com/p/badvpn/source/browse/trunk/ncd/modu... ). process lan { # Set device. var("eth0") dev; # Wait for device, set it up, and wait for network cable. net.backend.waitdevice(dev); net.up(dev); net.backend.waitlink(dev); # Start doing DHCP and waiting for timeout. This spawns two additional # processes to run concurrently (see their code below). process_manager() mgr; mgr->start("dhcp", "conf_dhcp_template", {dev}); mgr->start("static", "conf_static_template", {dev}); # Wait for either multiprovide("LAN-DHCP") or multiprovide("LAN-STATIC"), # but always prefer LAN-DHCP. Even if we've already grabbed LAN-STATIC # and LAN-DHCP comes up, we backtrack and switch to LAN-DHCP. multidepend({"LAN-DHCP", "LAN-STATIC"}) conf_dep; # We can reach objects as seen from multiprovide() by going # through our multidepend() statement. println("got ", conf_dep.result_type); rprintln("lost ", conf_dep.result_type); # Check IP address - make sure it's not local. ip_in_network(conf_dep.addr, "127.0.0.0", "8") test_local; ifnot(test_local); # Assign IP address. net.ipv4.addr(dev, conf_dep.addr, conf_dep.addr_prefix); # Add default route. net.ipv4.route("0.0.0.0", "0", conf_dep.gateway, "20", dev); # Configure DNS servers. net.dns(conf_dep.dns_servers, "20"); } template conf_dhcp_template { # First argument is device name. var(_arg0) dev; # Do DHCP. net.ipv4.dhcp(dev) dhcp; # Expose results. var("dhcp") result_type; var(dhcp.addr) addr; var(dhcp.prefix) addr_prefix; var(dhcp.gateway) gateway; var(dhcp.dns_servers) dns_servers; multiprovide("LAN-DHCP"); } template conf_static_template { # First argument is device name. var(_arg0) dev; # Wait 5 seconds. sleep("5000", "0"); # Expose results. var("static") result_type; var("192.168.111.230") addr; var("24") addr_prefix; var("192.168.111.1") gateway; var({"192.168.111.14"}) dns_servers; multiprovide("LAN-STATIC"); }

pmr_ 14y ago

The maturity of systemd is at the root of the problem here. I switched (even for ArchLinux standards) relatively early and since then I could see how things changed continuously. There are two factors here: I appreciate active development of software and I would like things to stay compatible with previous releases at a minor cost to "progress". It is hard to get both in such a complex design space. Most of the problems are hard to predict and only come up as soon as there is active use of the system and if you never go public, there will never be active use. Overall, jumping on the systemd bandwagon was done prematurely (at least by ArchLinux) and I think the large software packages should just give it another few months before migrating. systemd solves a lot of problems now and developers want problems to go as away before they become a feature or to pervasive to the codebase, but a little restraint might to a lot of good here. There has to come a point where systemd announces feature completeness and stable interfaces so everybody can use it as a standard and then everybody can go for broad use and acceptance. I would hope that this gives the smaller players a chance to catch-up and much needed safety when investing resources into their own implementations.

AnthonyMouse 14y ago
>The maturity of systemd is at the root of the problem here. That is pretty much what I came in here to say. It seems like OpenBSD is trying to have it both ways: Include all the latest and greatest toys and still thoroughly audit everything that changes between releases. But it's new toys, secure, cheap. Pick two. Is it really the end of the world if OpenBSD bears a closer resemblance to Debian Stable for the sake of security? Why is 'latest Gnome' a requirement? Just stick with older versions of everything until the new APIs stabilize and mature.
- sounds 14y ago
  A good compromise, to be sure. But the problems with systemd aren't an isolated case, and they aren't technical, they're political. And political problems generally don't get better when a technical solution is applied; in this case, waiting it out just silences OpenBSD's voice in the potential discussion. So I'm glad they're making an effort to engage the community and look for alternatives to the political problem. I'm deliberately not saying exactly what the political problem is – I'm not "framing" it one way or another.

lostnet 14y ago

Thank you for the background! I worked on Solaris during the Gnome transition and during the largely overlapping SMF transition. I'm not sure which was more painful or was more broken by design, though SMF surely affected more developers. If I were making decisions for OpenBSD I would not accept a requirement to port an init replacement, but I also wouldn't be putting any resources into keeping Gnome running that could go into better integration with an alternative. While it is nice to be able to mix and match everything rather than having choose a silo, having these large market share players like gnome dictate changes on every platform is ultimately rather destructive to having meaningful options. I would rather run the Linux kernel for practical reasons, and often use gnome for practical reasons though I would be thrilled not to. Showing me you can keep up with Linux running gnome isn't compelling at all, particularly if it means you are no longer doing much else. But if you can better integrate with KDE or enlightenment (or fvwm and some duct tape,) and give me an alternative to linux+gnome then I'll deal with a new kernel (and not having PAM?!)

pja 14y ago

I don't understand why systemd is suddenly such a hard requirement: it suggests that the Gnome developers are simply punching through the abstraction layer provided by dbus for reasons of convenience. If some part of Gnome needs a system service, it requests it via dbus and parses the response. How that service is delivered ought to be irrelevant. Since systemd is supposed to offer all its services via dbus, is the problem really "we don't want to implement all these services that a modern desktop needs". OpenBSD et al could offer a dbus layer that implements the same set of services, but they don't want (or have the manpower) to do so. In which case, I'm not really sure they have a leg to stand on: the things systemd offers really are important for a modern well integrated desktop (or any other system for that matter) and they weren't well served by initscripts. OpenBSD is free to implement a service that offers the same dbus interfaces whenever they want, but complaining about Linuxisms is perhaps a little rich: if you want your system to remain stuck in the early 1990s then that's fine, but you can't really expect the rest of the world to hang around waiting for you to catch up.

pja 14y ago
NB If the answer to "why can't you write dbus interfaces" is "we'd love to, but the Gnome developers keep changing the interfaces every minor point release" then that's probably a valid retort...

krakensden 14y ago

> it is big and unwieldy and the documentation is a mess. Only if you compare it to RC and then omit the enormous horrible undocumented copypasta mess that was RC scripts