879 karma · joined March 5, 2011
justin@linux.com
1. https://raw.githubusercontent.com/kubernetes/kubernetes/mast...
Might save you some arrow presses
The benefit is declarative API driven management. You spend less time automating a system to a desired state in a similar vein Kubernetes provides a declarative API.
Talos is purpose built to run Kubernetes workloads and not general purpose Linux. Hopefully, you don't have to add _everything_ back to the OS, but we know some things cannot run as a container or Kubernetes workload.
Extensions are required for specialized hardware (eg network, GPUs) and is the closest thing to a "package manager" available in Talos. Extensions can be binaries but don't have to be. We have a lot of common extensions provided and maintained by us but anyone can create extensions as needed.
One nice thing about extensions is they get layered and you don't have to pre-build an artifact like you do with other Linux distros with something like packer. factory.talos.dev will let you pick you extensions and get an artifact no packer/bash/config management required.
That is what I was trying to convey and couldn't find a reasonable metric.
Want GPU drivers? Add the extension. Need Tailscale? Extension.
https://www.talos.dev/v1.6/talos-guides/configuration/system...
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'm using projectbluefin.io for all my laptops/desktops and love it. Wouldn't want the same on single-purpose, production servers.
https://www.talos.dev/latest/reference/configuration/v1alpha...
Would be happy to update with a different comparison you think is more fair.
I don’t think the complexity it brings is required for Kubernetes.
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.
I’m not affiliated with the service but did interview the creator a couple years ago about how the infrastructure worked https://youtu.be/O1p2crPpFIc
Installation is pretty quick too! Here’s a video I made showing the process https://youtu.be/doQW1FyAISQ
Different desktop environments are available, but gnome is the default.
It’s been around longer than Bottlerocket