Nice! I use the Helm Component Chart [1] from the creators of DevSpace [2] for exact same reasons on personal projects. At a previous company, all of our dev, staging, production services used the Component Chart and it really helped with maintainability and significantly reduced the amount of YAML we had to write.
What you've listed for k3s is mostly included in k0s. I wouldnt go far to say k0s isnt convenient.
* A helm controller is included in k0s
* Etcd is bundled and bootstrapped automatically which I perfer because I dont want the overhead of the translation that Kine does. Although Kine is available for a non-etcd datastore if that is preferred.
* Upgrade controller is included (autopilot).
* They have a local storage provider based on OpenEBS.
* Ingress is missing, but due to the built in helm controller that can be boot strapped upon cluster initialisation.
Overall, together with k0sctl and its declarative configuration it is easier to deploy k0s than it was k3s.
Kine (https://github.com/k3s-io/kine) is a shim or an external process (when not k3s) that translates the etcd api to enable compatibility with a database or alternative data store.
Kubernetes natively talks etcd, so this translation is what enables its usage with sqlite or another database, but it incurs an overhead.
I don't have specific numbers unfortunately since it was years ago I benchmarked Kine against etcd. But I had a better results with etcd both in cluster and single node.
Could someone please rundown the pros and cons of using third party cost management software (ex. Ternary)? Are the tools in this space specifically designed for enterprise level cloud cost management?
There seem to be a lot of options out there. Would love a critical overview and recommendations for SaaS in this space.
This is something that boggles my mind. Why would not lead with compensation range so we don't waste each others time? Moreover, it some state it is law to reveal the comp range in the job post.
Would like to recommend reading the book `Range by David Epstein`. It has some interesting thoughts about being a generalist vs specialist in our complex world.
Linux containers are containers, not VMs. They are more like docker (although, lxd/lxc typically are used more like jails/VMs - a "full" user land, rather than just an application binary, like with a docker container wrapping a service implemented in go).
Technically, docker/lxc uses kernel namespaces to isolate a process tree - firecracker starts up a virtual machine.
When a VM context switch happens, the CPU uses extensions like Intel VMX to isolate the virtual machine code from the host code. Usually the hypervisor also forces a cache flush to
mitigate CPU vulnerabilities as well.
And you need to configure i3br/polybar, amongst lots of other things.
I ended up on Regolith mostly to see how someone else who’s used i3 for a while sets things up. I’ve found I like it pretty well. It’s a nice middle ground. I may sometime go back to building my desktop from the bottom up, but Regolith has been a good way to get a working i3 setup to build from.
It’s also a very fast way to have i3 setup and use for a week to see if you like it. If you do, then you can build what you like. But if you start from building first, your initial time investment will be much greater.
in my experience, if cruft is a major concern in your day-to-day use of linux, you probably already have a desktop/window management environment and theme you've settled on :P
i consider myself a sort of power-casual linux user, i don't develop professionally but love to tinker and play around with it, almost exclusively for aesthetic reasons. regolith being built on ubuntu means that the second i find myself out of my element, there's always the familiar and ever-present terminal i can pull up, that responds to all the commands i already know, has the binaries and services i am already familiar with, etc.
that being said, i've taken some light dips into the wild, mainly using manjaro architect to play around with manjaro/i3 - regolith was a very awesome(lol) way to learn i3wm because i wasn't simultaneously having to also learn the ins-and-outs of a non-debian-based operating system
[1] https://www.devspace.sh/component-chart/docs/introduction
[2] https://www.devspace.sh/