dmwilcox

Long live the philosopher king??

I mean only somewhat in jest this is precisely the debate going on since Plato's not so subtle critiques of Pericles' Athens circa 400 BC

Love Tails, but I haven't used it in ten years. I have had Tails and Qubes disposable VMs on my mind though.

I switched off of Qubes last year to my own Alpine chroot with a hand crafted kernel and initrd that lives only in memory. I find turning off the computer when I'm finished and having it forget everything to be a very peaceful way to compute. I owe the internet a write up.

I feel like ramfs for root filesystems is an underused pattern more broadly. "Want to upgrade? Just reboot. Fallback? Pick a different root squashfs in the grub menu"

Agree with the sentiment but, one CSS preprocessor (!!) Lol I must be getting old, CSS3 is amazing why do you even need one?

That's a totally optional component that now needs to be updated, used in your build pipeline and Lord help you if you install it with npm and it isn't updated for a couple of years.

I'd add boring really means boring, yes that kind of boring (zzz) ;)

Enterprise version has all of those things ;)

For my personal use I don't need them and for a business Enterprise won't break the bank. You'd be surprised how much your management might be interested in having an escalation path if everything goes south and you need a hot fix. I can vouch that Enterprise support is worth it if you're on a small team that can't spend all day on this stuff

Interesting, I went the other direction recently, from systemd to Nomad.

I was motivated by a move away from config management in favor of commands wrapping Nomad API calls. For a "devs on-call" model this was preferable to being gatekeepers of PRs against config management.

To glue the whole thing together I got Consul Connect going in the Nomad jobs, so service config complexity was comparable to docker-compose.

Saying this out loud makes me realize it was the organizational model I was pursuing that led me here (so called "production ownership"). And I'm not a big config management fan ;). I take it you have dedicated Ops teams or Devs willing to learn Ansible well?

Not associated with CloudFlare but I've built similar stuff with Nomad.

The cost/maintenance trade-off works when you have more SPOF management hosts than Nomad servers (5). You decrease host images down to 2, Nomad server and client, versus N management images.

Though it does sound a bit like they're using config management rather than pre-build images.

Bonus, Nomad servers are more failure resistant using Raft consensus versus any N management hosts. And for discovery I found the optimal pattern is to put all of the Nomad servers in a "cluster" A record for clients to easily join (pattern works well for Consul too)

Having worked in several declarative config systems at a big tech company that tried to provide these guard rails. They errode!!

And it makes sense. As we demand more flexibility to not repeat ourselves (DRY) we get clever and add little features.

Suddenly you can stick an entire cluster config (or several!!) inside a lambda that returns the declared resources... And you've gone straight to hell. You're more than Turing complete by then and engineers are reinventing conditionals and loops with lambdas all over your config codebase.

Might as well have just started and left it at Python/etc.

The Internet offers free fuzzing to open ports j/k that actually looks useful ;)