
Systemd for Developers I (2011) - luckysahaf
http://0pointer.net/blog/projects/socket-activation.html
======
vezzy-fnord
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
> 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.

~~~
valarauca1
>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
> 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
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.

~~~
mateuszf
I agree, though in my experience all the cases you enumerated are not norm but
exceptions to it.

~~~
Xenmen
I think the point is that in writing something like systemd it's more likely
to be the norm than if you were, say, writing a Ruby server.

~~~
mateuszf
Point taken.

------
ushf
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".)

