Well, technically true, but systemd is a whole lot more than 3000 lines...
I can see another binary in the demo video called apid, does that one not count?
Any comparison with Bottlerocket OS?
I don’t think the complexity it brings is required for Kubernetes.
I have systemd on the laptop I am typing on right now. Do I want it on some tiny embedded linux device? probably not.
Notably the kubelet is also missing from the list because it's not built into the OS but pulled as needed from the correct version of Kubernetes requested.
Bottlerocket runs systemd and also runs 2 versions of containerd. One for the system and one for workloads. This (in theory) hardens the OS more, but in practice makes things extremely annoying to manage because you have to get a shell on the host to access the API.
disclaimer, I used to work at AWS on EKS and closely with the Bottlerocket team.
A lot of people downloaded them, and it was great fun - to start. Problem is when you want to do more things. You have to start finding workarounds to bolt-on additional tools, or maybe you just throw one or two extra tools in there by default. Over time you find more and more missing things or incompatibilities with other systems, which make it harder to cover more use cases. And finally you realize that "the tiniest system" is a lot more effort than it's worth, and what you really want is "a slim yet compatible system". The system you end up with is a lot fatter, but a lot less headache.
(The security benefits of fewer files are overblown, too. If you audit and harden the system, it doesn't matter how many binaries you have, because the attack vectors they use will be mitigated)
Want GPU drivers? Add the extension. Need Tailscale? Extension.
https://www.talos.dev/v1.6/talos-guides/configuration/system...
In the context of that assertion, adding or subtracting "extensions" and adding or subtracting binaries are equivalent. Both are adding or subtracting "piece of code that provides fuction".
Err, that's definitely 1 file with 5 directory entries, not 5 files.
Edit: interesting, seems like there's a mild performance benefit.
https://www.talos.dev/latest/reference/configuration/v1alpha...
It offers most of the standard Linux utilities we know and love, but most of them are actually just symlinks to Busybox, which is ~900K on my (ARM64) system. That's less than a hello world in Go, for a program that can replace most common Linux utilities in daily usage.
(They and we all know that. They said as much theirself right in the comment.)
$ find . -name *.go | xargs wc -l | tail -1
354085 total
$ find internal/app -name *.go | xargs wc -l | tail -1
96885 total
At least here it makes more sense, since it's not like "our init system is just 200 lines" when those lines are wrapping a third party init system library.
It's more like "our init system logic is just 200 lines, not including third party dependencies". That's legit, provided that those deps are stuff like parsers, some library for dealing with strings or running processes, and things like that.
Would be happy to update with a different comparison you think is more fair.
I'm a bit skeptical of parts. For instance, the "init" binary being less than 400 lines of golang - wow! And sure, main.go [1] is less than 400 lines and very readable. Then you squint at the list of imported packages, or look to the left at the directory list and realize main.go isn't nearly the entire init binary.
That `talosctl list` invocation [2] didn't escape my notice either. Sure, the base OS may have only a handful of binaries - how many of those traditional utilities have been stuffed into the API server? Not that I disagree with the approach! I think every company eventually replaces direct shell access with a daemon like this. It's just that "binary footprint" can get a bit funny if you have a really sophisticated API server sitting somewhere.
[1]: https://github.com/siderolabs/talos/blob/main/internal/app/m...
[2]: https://www.talos.dev/v1.6/reference/cli/#talosctl-list
Number of binaries is kind of a meaningless metric, especially for a system that historically follows the UNIX philosphy of each program doing one thing.
Sure, a shell is complicated and a potential risk, and perhaps it's a good idea to exclude from the base system in this context.
But I'd rather have ls, tr and wc on my system than some bespoke, all-encompassing API service that has been far less battle tested providing similar functionality.
And like you rightly pointed out, these new binaries all contain their own list of dependencies which are pulled in at build time and need to be taken into scope as well.
That's not to say Talos or its approach doesn't hold merit, but I think it's a little disengenious to simply point at the number of binaries.
I’d also like to point out that the system API is designed to be extendable and adaptable to different operating systems. We’d love for more vendors to create adapters/shims to get the benefits of API managed Linux
I've always struggled to compare filesystems fairly. My justification for ext4 is just that everybody else uses it :)
Granted just used in a home setting running smaller workloads for backups, private projects, git etc.