7 ms·

Systemd for Developers I (2011)

48 points by luckysahaf 12y ago

vezzy-fnord 12y ago
I think it's unfortunate that Lennart didn't continue this series. The last installment was III in October 2012. These articles actually provided some valuable insight into the internals of systemd, rather than the highly abstract and inconsistent descriptions that have generally been given for systemd throughout the years. I actually remember seeing an infographic comparison that was taken from Ohloh, showing systemd, Upstart and OpenRC. systemd trumped the other two in SLOC, contributor counts, repository activity, but it was absolutely devastated in one area... source code comments. The systemd codebase is quite opaque to follow. I guess you could say most codebases are, as we have yet to develop any sufficiently advanced tools to assist in reading and instrumenting source code beyond scoping and IDE-style symbol relation trees. But it's still excessively inaccessible, I find. That said, systemd has changed radically since 2012, now using its own homegrown kdbus layer called sd-bus which currently communicates through a shim that translates kdbus calls into dbus1. There's been new generators, networkd, resolved, prerequisites for kmscon, additions to journald like compression, and so much more. It really is a beast. Instead, they seem to have thrown their hands in the air and said it "Fuck it, we're doing a second kernel." (as this year's GNOME Asia talk elucidated). For those who say systemd is well documented because "look at all the damn manpages", those manpages are often inconsistent, incomplete, vague or otherwise unhelpful to understanding systemd on a level beyond that of a cursory end user. Which is probably why both systemd proponents and opponents are all totally confused in the entire mess, both thinking they've grokked it and all of them looking like fools. I guess when you have PR like Red Hat alternately calling systemd a "service manager", "system manager", "init daemon", "basic userspace building block to make a Linux-based OS from", "a general system framework to unify Linux work" and whatnot, you get a whole bunch of chaos.
- mateuszf 12y ago
  > it was absolutely devastated in one area... source code comments. It is arguable whether this is a downside. I think that comments mean that source code itself is not readable enough. Comments should be used sparingly - only in exceptional conditions.
  - vezzy-fnord 12y ago
    In systemd's case, it is. Everything is buried through layers of obscure abstraction, and understanding the code can be a difficult task, indeed. On the other hand, Upstart makes heavy use of libnih (it's like glib, but nowhere near as heavy) and is actually very easy to follow. Compared to systemd, it certainly is, at least. Many of the comments are actually annotations for the automated documentation generator, from what I recall. OpenRC makes use of source code comments in a more conventional way, but they actually do tend to help with adding insight into what was going on in the author's head, and the code is still understandable (though not as clean as Upstart's), regardless. Its small size obviously also helps.
  - valarauca1 12y ago
    >It is arguable whether this is a downside or not. No it isn't. Software developers have been saying for 30-40 years "the code is readable as is", yet we keep coming up with easier to read languages, and comments are still in the spec of all these languages. Comments are important, it's not worth arguing if the code is readable or not. It's a waste of time that could be spent better documenting what ever you consider readable. Because your co-workers, or co-contributors may have a different definition of what readable is.
    - mateuszf 12y ago
      > Because your co-workers, or co-contributors may have a different definition of what readable is. The same could be said about comments. You can always say they are not enough. As I said - comments have their use - in my opinion for the cases where language is not flexible enough to express intent in a readable way.
      - Sanddancer 12y ago
        Or you're implementing an odd algorithm where a pointer to the paper, etc, describing it is located so that co-workers, etc, know what's going on. Or you're working around architectural limitations, such as doing work on microcontrollers, where you don't always have your preferred integer size to work with. Or working around bugs and/or poor naming conventions in other peoples' software. Yes, your code may be beautiful and cause angels to sing, but it's going to be working with code belched from the deep bowels of hell, and giving others clues as to why you're doing things in non-intuitive manners is not just useful, but needed.
- makomk 12y ago
  That doesn't surprise me; PulseAudio had the same complete lack of source code comments last time I looked. (Was trying to track down a crash in the resampling code. In the end I think I concluded that what the code was doing made no sense, it was unlikely it had ever worked properly, several important variable names were misleading in a way that had probably tricked a developer, and it wasn't worth trying to figure out a fix.)
- bitwize 12y ago
  I can't speak for other systemd opponents, but I don't care much for it because it's so mind-bogglingly complex. I used to be of the opinion that it was particularly dangerous for pid 1 to accrete complexity, as more complexity created more spaces for bugs to hide, and a process-gunning bug in pid 1 can take down your whole system. With sysvinit, you could understand pid 1 with a few hours' study. With systemd, it's bloody near impossible no matter how much time you set aside. So accordingly, the attitude of Lennart & co. parallels Nancy Pelosi: "All distros should adopt systemd in order to find out what it does." Systemd has a pretty compelling feature set, but I don't care if it fucking turns water into wine at this point; I've an allergic reaction to software complexity and abstruseness, and systemd gives me every reason to not trust it.
- deleted 12y ago
  [deleted]
- CoffeeDregs 12y ago
  This comparison?: https://www.openhub.net/p/compare?project_0=Upstart&project_1=OpenRC&project_2=systemd https://www.openhub.net/p/compare?project_0=Upstart&project_... The systemd LoC count is much higher than for the other two...
ushf 12y ago
Quick question re using systemctl to check status on machine running SSH on a non-standard port. Is it possible? So, for example, I have no problems with "systemctl --host me@somehost.com status httpd.service". But I would _like_ to be able to do "systemctl --host me@localhost.localdomain --port 2255". The manpages seems to only show "--host" as an option with no ability to specify "--port". Grepping through the code left me no wiser, so was hoping someone in the know could confirm/deny. (The specific case is that I have a bunch of VMs controlled by VirtualBox and am redirecting localhost ports e.g. 2255 to guest port 22. I can of course run "ssh -l me -p 2255 localhost "systemctl status httpd.service".)

48 points by luckysahaf 12y ago

I think it's unfortunate that Lennart didn't continue this series. The last installment was III in October 2012. These articles actually provided some valuable insight into the internals of systemd, rather than the highly abstract and inconsistent descriptions that have generally been given for systemd throughout the years. I actually remember seeing an infographic comparison that was taken from Ohloh, showing systemd, Upstart and OpenRC. systemd trumped the other two in SLOC, contributor counts, repository activity, but it was absolutely devastated in one area... source code comments. The systemd codebase is quite opaque to follow. I guess you could say most codebases are, as we have yet to develop any sufficiently advanced tools to assist in reading and instrumenting source code beyond scoping and IDE-style symbol relation trees. But it's still excessively inaccessible, I find. That said, systemd has changed radically since 2012, now using its own homegrown kdbus layer called sd-bus which currently communicates through a shim that translates kdbus calls into dbus1. There's been new generators, networkd, resolved, prerequisites for kmscon, additions to journald like compression, and so much more. It really is a beast. Instead, they seem to have thrown their hands in the air and said it "Fuck it, we're doing a second kernel." (as this year's GNOME Asia talk elucidated). For those who say systemd is well documented because "look at all the damn manpages", those manpages are often inconsistent, incomplete, vague or otherwise unhelpful to understanding systemd on a level beyond that of a cursory end user. Which is probably why both systemd proponents and opponents are all totally confused in the entire mess, both thinking they've grokked it and all of them looking like fools. I guess when you have PR like Red Hat alternately calling systemd a "service manager", "system manager", "init daemon", "basic userspace building block to make a Linux-based OS from", "a general system framework to unify Linux work" and whatnot, you get a whole bunch of chaos.

mateuszf 12y ago
> it was absolutely devastated in one area... source code comments. It is arguable whether this is a downside. I think that comments mean that source code itself is not readable enough. Comments should be used sparingly - only in exceptional conditions.
- vezzy-fnord 12y ago
  In systemd's case, it is. Everything is buried through layers of obscure abstraction, and understanding the code can be a difficult task, indeed. On the other hand, Upstart makes heavy use of libnih (it's like glib, but nowhere near as heavy) and is actually very easy to follow. Compared to systemd, it certainly is, at least. Many of the comments are actually annotations for the automated documentation generator, from what I recall. OpenRC makes use of source code comments in a more conventional way, but they actually do tend to help with adding insight into what was going on in the author's head, and the code is still understandable (though not as clean as Upstart's), regardless. Its small size obviously also helps.
- valarauca1 12y ago
  >It is arguable whether this is a downside or not. No it isn't. Software developers have been saying for 30-40 years "the code is readable as is", yet we keep coming up with easier to read languages, and comments are still in the spec of all these languages. Comments are important, it's not worth arguing if the code is readable or not. It's a waste of time that could be spent better documenting what ever you consider readable. Because your co-workers, or co-contributors may have a different definition of what readable is.
  - mateuszf 12y ago
    > Because your co-workers, or co-contributors may have a different definition of what readable is. The same could be said about comments. You can always say they are not enough. As I said - comments have their use - in my opinion for the cases where language is not flexible enough to express intent in a readable way.
    - Sanddancer 12y ago
      Or you're implementing an odd algorithm where a pointer to the paper, etc, describing it is located so that co-workers, etc, know what's going on. Or you're working around architectural limitations, such as doing work on microcontrollers, where you don't always have your preferred integer size to work with. Or working around bugs and/or poor naming conventions in other peoples' software. Yes, your code may be beautiful and cause angels to sing, but it's going to be working with code belched from the deep bowels of hell, and giving others clues as to why you're doing things in non-intuitive manners is not just useful, but needed.
makomk 12y ago
That doesn't surprise me; PulseAudio had the same complete lack of source code comments last time I looked. (Was trying to track down a crash in the resampling code. In the end I think I concluded that what the code was doing made no sense, it was unlikely it had ever worked properly, several important variable names were misleading in a way that had probably tricked a developer, and it wasn't worth trying to figure out a fix.)
bitwize 12y ago
I can't speak for other systemd opponents, but I don't care much for it because it's so mind-bogglingly complex. I used to be of the opinion that it was particularly dangerous for pid 1 to accrete complexity, as more complexity created more spaces for bugs to hide, and a process-gunning bug in pid 1 can take down your whole system. With sysvinit, you could understand pid 1 with a few hours' study. With systemd, it's bloody near impossible no matter how much time you set aside. So accordingly, the attitude of Lennart & co. parallels Nancy Pelosi: "All distros should adopt systemd in order to find out what it does." Systemd has a pretty compelling feature set, but I don't care if it fucking turns water into wine at this point; I've an allergic reaction to software complexity and abstruseness, and systemd gives me every reason to not trust it.
deleted 12y ago
[deleted]
CoffeeDregs 12y ago
This comparison?: https://www.openhub.net/p/compare?project_0=Upstart&project_1=OpenRC&project_2=systemd https://www.openhub.net/p/compare?project_0=Upstart&project_... The systemd LoC count is much higher than for the other two...

ushf 12y ago

Quick question re using systemctl to check status on machine running SSH on a non-standard port. Is it possible? So, for example, I have no problems with "systemctl --host me@somehost.com status httpd.service". But I would _like_ to be able to do "systemctl --host me@localhost.localdomain --port 2255". The manpages seems to only show "--host" as an option with no ability to specify "--port". Grepping through the code left me no wiser, so was hoping someone in the know could confirm/deny. (The specific case is that I have a bunch of VMs controlled by VirtualBox and am redirecting localhost ports e.g. 2255 to guest port 22. I can of course run "ssh -l me -p 2255 localhost "systemctl status httpd.service".)