emanlin

Caching proxies and traffic controlling NAT.

I find it much easier to use direnv and set GIT_AUTHOR_EMAIL in each of ~/work/.envrc and ~/personal/.envrc No need to reconfigure every repo this way.

Attach an Apple USB keyboard to your ESXi host and you’re good to go.

Plain old systemd unit files work great. If you really need containers for some reason and love UID and GID mapping then podman in systemd is great.

The only reason I’ve found to run k8s at home is if your full time job is operating k8s at work.

Keybase jumped the shark with their crypto coin offering.

It’s only a big deal if someone sues you and wins. If you comingle assets there’s an increased risk you could lose them in a judgement. If you don’t comingle there’s lower risk of losing personal assets.

But for larger organizations with operations folks we expect to be able to scale individual pieces of the stack or use our own managed infrastructure (e.g. MySQL, Redis, RabbitMQ).

Puppet professional services consultant here. I work with lots of "enterprise" teams on "ops stuff" on-premise.

Between 2010 and 2016, I observed a change in teams interested in trying to scale individual components. Back in 2010/2011 teams did expect to scale out and manage individual components of the stack. Today, nearly every team I work with is like, "Oh you ship your own postgresql server in the product? Awesome, I'd much rather use that (and make it your problem)." Same is true for pretty much every component in the stack.

I don't know exactly why this is the case, but I have two suspicions. First, every Ops team I work with is has too much on their plate. Way too much. They're having trouble finding people to hire. They're happy to offload a potential maintenance issue, particularly if they're paying for the software. Second, this might be a reflection of crossing the chasm to the mainstream market sometime between 2011 and now, so the teams themselves might be inherently different.

What surprises me is that it doesn't really matter what industry the customer is in today. Government, technology, retail, insurance, finance, whatever... No team is interested in taking these maintenance issues on unless they _have_ to. Making a product they don't need to tune and scale component-by-component is a highly valued feature. Both for SaaS and On-prem products.

I think this "feature" is the common root of all the things cited as issues in the article. Making this stuff easy to operate is _hard_, hard enough for SaaS and _much harder_ when on-premise.