Oh man, the only big struggle I have with docker, is the abandonment of Docker Swarm.

I've struggled for years wanting something that wasn't K3S or K8S. Something good for small cluster management that had a lower level of entry, that I'd feel better handing off to other teams.

Docker Swarm seemed to fight the puzzle, but falls short based on things that needed to be fixed or finalized, that just never happened.

Any reason that whole pathway got abandoned? Other than just "Google uses Kubes so just everyone can use it"?

The annoyance I have is that it isn't one of the other. I spend a lot of time thinking and fighting with whatever frontier model we're on today. I've seen people let LLMs make absolutely atrocious decisions and just click next and collect checks.

I just posted this morning about this type of engineering has secured us numerous customers and put some projects in our backlog that either need significant rework or at least a very close eye to see if their issues crop up.

IDK, the idea that we shouldn't be thinking is a worrying one. I still have to think a lot.

What I'm _mostly_ worried about is that the path to get to high performing senior is basically a burned bridge with our current training techniques, and I'm not sure we'll adapt before a brain-drain situation in the industry.

As someone who owns a company:

Some holdouts excel at what they do to the point of retaining significant value, earnestly worried about being out of touch with what we do, some holdouts just suck and are bitter.

Also: let's be honest. "I wrote a little app in a few weekends" -- "I built this in a few weeks", "this took me a month instead of a year"

These are productivity increases, sure, but still are $2000, $8000, $14000 of labor.

And doesn't count continued increase build time, more features, maintenance. The $20/mo SaaS isn't going away, and work can't pay you to endlessly tinker on fun internal projects and save $1200 of subscriptions for your $120k/yr salary.

It's fun, but SaaS is going to shift to more feature rich and we're going to see a ton of smaller projects that were pains to get started that can now work in a short amount of time.

Companies are going to get a huge surge of random internal projects and have to debate whether all the upkeep is valid for the pet projects, or if it's people fucking around at an untold scale.

That and talking to a lot of users, Duolingo reduced the quality of their service moving to LLM generated content -- a lot of people moved to other apps.

The only hangup with the myth "debunking" is that the point is that the corruption doesn't happen to a per-disk buffer, but to the in-flight data before it's persisted to your stripe.

Which means all copies of the data will be corrupted. This can be anything from an irrecoverable file to complete filesystem corruption.

But generally, yeah, not any more dangerous than any other filesystem, and ECC used to be cheap so it was a no-brainer, you should have backups anyway TBH if we're being honest about storage resiliency.

What has been debunked is the "scrub of death" issue, on a scrub a bad bit flip would cause an error, which would be copied over with good data -- well it was technically good before. It would be statistically difficult to have a fault on a read, then a clean read, then a second bit flip destroying the data.

Apple makes this a huge PITA, along with having to do a significant amount of it from another apple device.

I'm glad we ditched iPads, it sucked.

> The input latency might not be as good as you'd like.

Yeah input latency is annoyingly rough, not super bad but _just_ laggy enough to make it annoying to use.

Debating how much I want to change things, I can directly punch into my Linux machine but all my dev IDEs are on a VM for a long list of reasons, and I doubt Zed is going to run on my old ThinkPad if it struggles on software rendering, but we'll see.

I've literally programmed with VSCode for basically a decade this way without issues. Zed lags, it's disappointing and if I really like Zed I'll have to sort out another setup.

MSTSC is one of the rock-solid tools from Microsoft, and does better than almost everything else available on the market other than some PC over IP technologies specifically highly optimized for this use case. I've been programming with an ancient ThinkPad forever because I'm just remoting into a much more powerful machine.

We build a Shopify-leading platform on C# at a startup -- they got so much flak from colleagues about it being built on C# instead of Node or Python.

Absolutely no reason other than "C# icky" -- they ended up with a platform that is crazy fast (and fast scales way easier, it handles a dumb amount of traffic without a lot of crazy design)

Startup culture is toxic AF at times, bad engineering decisions for cargo cult stuff.

I experience the same. When I try to have a rational dialog about trade offs, there’s nothing there. Or the “only runs in Windows” classic 10+ years outdated stuff I’ve been writing C# on a Mac deploying on Linux for a decade.