Systemd Is Approaching 1.3M Lines(phoronix.com)
phoronix.com
Systemd Is Approaching 1.3M Lines
https://www.phoronix.com/scan.php?page=news_item&px=systemd-2019-stats
35 comments
Interesting. cloc counted even less — 360K of C code, 35K of headers — on the current master.
--------------------------------------------------------------------------------
Language files blank comment code
--------------------------------------------------------------------------------
C 937 106426 22822 362913
XML 308 12090 455 63485
C/C++ Header 636 10009 13197 35346
Python 26 1409 6695 16629
PO File 29 3842 4158 11713If you add blank+comment+code, you get remarkably close to the results of the parent comment.
I've noticed a trend on Phoronix -- most articles and especially articles on controversial topics (systemd, BSDs, pulseaudio, etc.) are very low effort. Like literally pasting a few images from GitStats (like this case), quoting a mailing list entry with no context, or running your standard desktop test suite and issuing a performance verdict based on it...
Seems to me like the main purpose for such articles is not to inform, but to generate clicks by having a controversial project in its title...
Seems to me like the main purpose for such articles is not to inform, but to generate clicks by having a controversial project in its title...
It's bad journalism. /r/linux for example has a blanket ban on Phoronix articles and classifies them as blog spam.
Most of the "announcement" type articles are mailing list quotes without context that don't link to the original source, but link to even more Phoronix articles.
Most of the "announcement" type articles are mailing list quotes without context that don't link to the original source, but link to even more Phoronix articles.
With the amount of systemd-related articles on Phoronix lately, I'd wager systemd clickbait/trollbait is responsible for a large part of their ad revenue...
They published 14 articles tagged with systemd in the last half of 2019. You are overstating this, and the fact that your "phoronixrly" username was created a few minutes before your comment suggests that you know it.
https://www.phoronix.com/scan.php?page=news_topic&q=systemd
https://www.phoronix.com/scan.php?page=news_topic&q=systemd
This is >2 articles per month with one a week in December alone. Here's a better overview: https://www.phoronix.com/scan.php?page=search&q=systemd
Michael typically publishes around eight or nine articles a day, every day. So something like two articles a month would be a long way from being a major part of the content on that site.
https://www.phoronix.com/scan.php?page=recent
https://www.phoronix.com/scan.php?page=recent
It replaces a lot of lines too. Like every service that has to demonize itself, buggy init scripts, etc
runit also takes care of all that and it is much simpler.
Putting this into perspective with other init systems, e.g. SysVinit, OpenRC or Dinit would probably be much more meaningful...
I hate that systemd refuses to work in a chroot. With all those extra services in systemd like dns, it's impossible to run in a container or chroot... And the developers blatantly refuse to fix that.
Isn't systemd-nspawn useful for this case? It was specifically designed to replace the need for chroot on systemd systems.
dns, network and ntp services are run in separate processes. These processes are sandboxed in a more effective manner than chroot (namespaces, capabilities, etc.).
Moreover, systemd itself relies heavily on Linux sandboxing tools (like cgroups).
What does binary size look like, and has it grown to match?
Kinda rough and probably missing some stuff, but...
[megadekay@ryzen ~]$ du -h /usr/bin/systemd*
1.5M /usr/bin/systemd-analyze
16K /usr/bin/systemd-ask-password
20K /usr/bin/systemd-cat
20K /usr/bin/systemd-cgls
36K /usr/bin/systemd-cgtop
24K /usr/bin/systemd-delta
20K /usr/bin/systemd-detect-virt
20K /usr/bin/systemd-escape
40K /usr/bin/systemd-firstboot
16K /usr/bin/systemd-hwdb
20K /usr/bin/systemd-id128
20K /usr/bin/systemd-inhibit
24K /usr/bin/systemd-machine-id-setup
48K /usr/bin/systemd-mount
20K /usr/bin/systemd-notify
312K /usr/bin/systemd-nspawn
20K /usr/bin/systemd-path
0 /usr/bin/systemd-resolve
56K /usr/bin/systemd-run
28K /usr/bin/systemd-socket-activate
20K /usr/bin/systemd-stdio-bridge
52K /usr/bin/systemd-sysusers
84K /usr/bin/systemd-tmpfiles
28K /usr/bin/systemd-tty-ask-password-agent
0 /usr/bin/systemd-umountYou're missing the most significant one, PID 1 itself:
$ du -hs /usr/lib/systemd/systemd
1,5M /usr/lib/systemd/systemd
To add to the list: What shared libraries (.so) do these executables require? When trying to minimize the footprint of something, I often find that this is where the bulk is hiding.
Forgive my ignorance, but I was under the impression that Systemd was a relatively simple service that just manages services on a cpu. I had the mental model of systemd as a cronjob on boot with status management.
What else does it do besides that, that warrants such an enormous complexity? I'm sure i'm missing out on a ton of features with this simple model but I haven't seen anyone else use it otherwise in the wild than a service manager.
What else does it do besides that, that warrants such an enormous complexity? I'm sure i'm missing out on a ton of features with this simple model but I haven't seen anyone else use it otherwise in the wild than a service manager.
The systemd project develops a lot more than that. One component is udev, which manages (among other things) /dev and firmware loading. For this purpose it includes a database of all supported hardware, which alone counts in at 271K lines of "code" (it's really just structured plain text).
I wouldn't be surprised if the core service manager comes in at only ~20K lines of code.
I wouldn't be surprised if the core service manager comes in at only ~20K lines of code.
Systemd doesn't just troll through a directory of symlinks to shell scripts and fire them off.
It's parsing a DSL for the .service scripts, building dependency graphs, making lists, checking them twice, and so forth.
It's parsing a DSL for the .service scripts, building dependency graphs, making lists, checking them twice, and so forth.
I see, thanks for the explanation.
That's been the ongoing issue/debate re: systemd. If it were just a simple service manager, there probably wouldn't be nearly so much debate around it. Instead, it's both a service manager and a collection of bundled services. It often isn't trivial (both due to dependencies and packaging) to substitute a single service systemd provides with an alternative implementation.
Blech. Somebody get docker working on *BSD so I can drop Linux.
Bsd has jails that are arguably better in most ways.
Yea, and Beta was technically superior to VHS.
I'm very well aware that this isn't really what you were asking for, but it's interesting to note that it appears to be possible to throw a debian VM into bhyve and use docker CLI tools from the FreeBSD host system to launch docker images inside the VM.
Having seen the vast amount of pain Joyent went through with their LX flavour zones trying to get the syscall emulation right, and Windows having gone "sod this" and switched to an embedded linux kernel for WSL2, I do rather wonder if this isn't as good as it's going to get without an engineering effort by FreeBSD that could likely get better ROI focused elsewhere.
Having seen the vast amount of pain Joyent went through with their LX flavour zones trying to get the syscall emulation right, and Windows having gone "sod this" and switched to an embedded linux kernel for WSL2, I do rather wonder if this isn't as good as it's going to get without an engineering effort by FreeBSD that could likely get better ROI focused elsewhere.
That's about 1.3 million too many.
Gravitational collapse in 3, 2, 1 . . .
Well, hopefully soon.
It's already happened. Systemd is a black hole that absorbs everything.
Can't wait to see what happens when systemd-homed becomes entrenched across all distros. What's left after that? Systemd-gccd?
I used to joke with my colleagues that eventually everything will converge and become systemd running jupyterhub (now jupyterlab) running "apps" that are actually notebooks on some kind of Node.js kernel.
$ tokei C: 492003, C Header: 58547
Total line count at 889658, "code" count at 716316, but 202314 of that is plain text which could signify documentation. It's still a lot, but not even nearly close the headline.