Err, that's definitely 1 file with 5 directory entries, not 5 files.
There are only 12 binaries in Talos Linux
11–20 of 73 posts
Re: There are only 12 binaries in Talos Linux
#12It's disingenuous to say that /sbin/init (machined/main.go) is less than 400 lines of code. Sure, that file is. What about all of the in-tree modules that are being imported? A super lazy summing of Go lines in the master branch of the repo: $ find . -name *.go | xargs wc -l | tail -1 354085 total Heck, there are almost 100k lines under internal/app! $ find internal/app -name *.go | xargs wc -l | tail -1 96885 total…
Would be happy to update with a different comparison you think is more fair.
Re: There are only 12 binaries in Talos Linux
#13It's disingenuous to say that /sbin/init (machined/main.go) is less than 400 lines of code. Sure, that file is. What about all of the in-tree modules that are being imported? A super lazy summing of Go lines in the master branch of the repo: $ find . -name *.go | xargs wc -l | tail -1 354085 total Heck, there are almost 100k lines under internal/app! $ 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.
Re: There are only 12 binaries in Talos Linux
#14Where is networking configured? I assume the system has to have an IP address before containerd can fetch images.
https://www.talos.dev/latest/reference/configuration/v1alpha...
Re: There are only 12 binaries in Talos Linux
#15Earlier quoted context omitted.
The systemd hate is getting long in the tooth now. It's not like it doesn't do anything with its line count, or that the code is obfuscated.
I’m actually a big fan of systemd. It’s an awesome, general purpose, and flexible init system. I don’t think the complexity it brings is required for Kubernetes.
Something along the lines of "...not needing a general purpose init system that integrates with logging, network and mounting, when all we are running is Kubernetes."
Re: There are only 12 binaries in Talos Linux
#16I'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
Re: There are only 12 binaries in Talos Linux
#17Where is networking configured? I assume the system has to have an IP address before containerd can fetch images.
Re: There are only 12 binaries in Talos Linux
#18The /sbin/init binary is hard linked to /sbin/dashboard, /sbin/poweroff, /sbin/shutdown, and /sbin/wrapperd. While this technically is 5 files, it’s a single file hard linked 4 times to provide convenience commands. Err, that's definitely 1 file with 5 directory entries, not 5 files.
Edit: interesting, seems like there's a mild performance benefit.
Re: There are only 12 binaries in Talos Linux
#19Re: There are only 12 binaries in Talos Linux
#20A 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)