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.
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.
Interesting. cloc counted even less — 360K of C code, 35K of headers — on the current master.
If 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...
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.
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
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.
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).
Isn't systemd-nspawn useful for this case? It was specifically designed to replace the need for chroot on systemd systems.
What does binary size look like, and has it grown to match?
Kinda rough and probably missing some stuff, but...
You're missing the most significant one, PID 1 itself:
And there's plenty more in /usr/lib/systemd (basically all the binaries that are not supposed to be in $PATH).
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.
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.
I see, thanks for the explanation.
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.
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.
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.
This: https://wizardofbits.tumblr.com/post/96856361060/rethinking-...