Can't reproduce the findings. I think this is counting all lines ever added across all commits. The current source tree is at 500k lines of C:
$ 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.
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...
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.