Live data from Hacker News

There are only 12 binaries in Talos Linux

siderolabs.com

31–40 of 73 posts

Re: There are only 12 binaries in Talos Linux

#31
post #4
post #2

>As opposed to systemd which is over 3000 lines of C code I’ll never comprehend. 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?

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.

So there is a quantum of criticism/observations about systemd that can be made but after that, no more is acceptable?

Re: There are only 12 binaries in Talos Linux

#32
I wonder how a really slimmed down distro like Alpine would compare here, particularly in terms of image size.

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.

Re: There are only 12 binaries in Talos Linux

#33

Super cool. I always enjoy reading about systems that challenge, well, "ossified" assumptions. An OS not providing a shell, for example? Madness! ... or is it genius, if the OS has a specific purpose...? It's thought-provoking, if nothing else. 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 y…

Exactly this. I was thinking of making a similar comment but you made it far better than I could.

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.

Re: There are only 12 binaries in Talos Linux

#34

Earlier quoted context omitted.

Wonder why they would use hard links instead of symlinks. Edit: interesting, seems like there's a mild performance benefit. https://unix.stackexchange.com/a/20716

Reverse question: why use symlinks when you can get away with hard links?

Main thing I've seen with hard links is that deletions delete the source file which about 90% of the time isn't what an end user wants

Re: There are only 12 binaries in Talos Linux

#35

20 years ago, I used to make custom Linux distros for fun. Floppy distros, CDROM distros, RAM-resident distros, network-boot distros. In a few of them, I custom-made my own binary that was both the init system, and a few applications, stripped it down, and shipped just that as the distro (basically just a few files and my static binary). A lot of people downloaded them, and it was great fun - to start. Problem is whe…

In the case of Talos, Kubernetes can provide the flexibility you want from a more traditional Linux distribution.

That sounds like Kool aid. Can you expound more on this?

Re: There are only 12 binaries in Talos Linux

#36

Earlier quoted context omitted.

Reverse question: why use symlinks when you can get away with hard links?

Main thing I've seen with hard links is that deletions delete the source file which about 90% of the time isn't what an end user wants

Only if its the last hard link. If nothing else, its a wee bit of insurance from deletion since no single link removal should remove the file.

Anecdote, eons ago, we had a problem where the vendor needed to log in to the machine with the intent that they were going to upload some utilities, fix a problem, and then delete them.

Before I let them in, I set up a script that constantly scanned the directory tree they were in, and hard linked everything so I could look at what they were using later.

Re: There are only 12 binaries in Talos Linux

#37

Earlier quoted context omitted.

I know there are a lot more lines and I didn’t count any of the imports from systemd either. 300 loc (machined) vs 3000 loc (systemd) was the closest comparison I could think of without crawling all imports and deps. Would be happy to update with a different comparison you think is more fair.

How about we just don't compare lines of code at all, as if it's a useful metric of anything?

"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."

-- attributed to Bill Gates

Re: There are only 12 binaries in Talos Linux

#38

Earlier quoted context omitted.

Reverse question: why use symlinks when you can get away with hard links?

Main thing I've seen with hard links is that deletions delete the source file which about 90% of the time isn't what an end user wants

that isn't generally how hardlinks work: you need to delete all instances of it to delete the file, as opposed to having one 'real' file like with symlinks.

Re: There are only 12 binaries in Talos Linux

#39

Earlier quoted context omitted.

In the case of Talos, Kubernetes can provide the flexibility you want from a more traditional Linux distribution.

That sounds like Kool aid. Can you expound more on this?

With Kubernetes you can schedule workloads in a number of different ways. Let’s say you insisted on having a shell and package manager. Run your favorite distro’s container as a DaemonSet. With the proper mounts and permissions you can do a lot. In other words use Kubernetes to do the things need to do. Then what role does the OS really play? Well in the case of Talos it’s only there to run Kubernetes.

Re: There are only 12 binaries in Talos Linux

#40
post #33

Super cool. I always enjoy reading about systems that challenge, well, "ossified" assumptions. An OS not providing a shell, for example? Madness! ... or is it genius, if the OS has a specific purpose...? It's thought-provoking, if nothing else. 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 y…

Exactly this. I was thinking of making a similar comment but you made it far better than I could. 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…

I agree number of binaries is an arbitrary metric but also an indicator that things work differently with Talos. You have to use the declarative API for management which some people could see as a bad thing.

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

https://github.com/cosi-project/community

Post reply on HN