I’ve been reading this for years, and the hypothesis always seems to be that zipper merging is good because it maximizes road usage. You know what else maximizes road usage? Bumper to bumper gridlock.

This is so dumb. I absolutely love it.

I see them as ways to find content that otherwise wouldn’t be on my radar. I generally don’t let them “talk me out” of seeing something that interests me.

Yeah, the whole exhibit on Goya is a trip. You walk through this guy’s decades of professional work leading up to the war, his fall into depression, and the black paintings. I really can’t recommend it enough.

Yes, but the situation is getting strange.

Our model has always been that the reviewer is responsible for protecting the repository. This led to one IC getting fired for “letting in” a catastrophic bug his teammate generated with Claude.

As for “toe,” it’s probably an old-school usage of a verb which is preserved in that phrase, but not carried on otherwise. Making it sound weird, today.

That would make it a fossil word (one of my favorite language quirks)!

This is incredibly funny to me because I remember coming home for a holiday and seeing a new Blu-ray player under my brother’s PS3. My dad was so excited about it.

I’m just guessing here, but it’s probably for battery management and wireless charging, which are tricky problems you’re not gonna solve with a 555. I generally trust EEs to not put MCUs where they aren’t needed, so this must have been the cheapest/easiest option.

The incredibly silly true answer is that the software industry’s love for “deploy early, deploy often” has led to all embedded devices shipping with over-the-air (OTA) update support even when it barely makes sense. The earliest units of a given product run will ship with a minimally viable product build that has lots of bugs, but solid OTA.

Fun anecdote: I had a TV backlight die after about 3 years, and the root cause was a shitty embedded app that incorrectly regulated the voltage for the LED strips.

Real answers: gitlab has awesome integrated CI, and you can always go for a remote integration if you prefer (e.g. self-hosted Jenkins, or a managed solution like circleci).

Causing annoyance is one of the more polite ways of expressing your dissatisfaction with the status quo.

No true leftist would post this

Those of us who lived through the Microsoft vs Linux debacle know that you don’t need a large, popular distribution to manufacture a legal challenge. All you need is something that effectively undermines the opposition’s legal basis.

Space exploration is weight lifting for science.

For top left I’d like to humbly nominate SCO Unix.

This might seem like a very indirect response, and that’s because it is largely a notion I have after a couple years of observing the fediverse. My background is in infrastructure for micro services, which is a powerful source of bias, so take this with a grain of salt.

The fediverse is suffering from major problems caused by homogeneity, data duplication, and lack of meaningful coordination. It is completely unsurprising that it struggles to provide the level of service that most users expect. I’m not saying this to be mean, but because I’ve experienced these same growing pains in commercial settings.

The solution has always been to restructure product services in a way that separates concerns. Most of the big guys will, at a very high level, use an API gateway which handles security + authn, then forward requests to high level product services which in turn reach down to the data layer services (which are often ORMs with huge caches sitting on top of databases). Works great, usually.

The fediverse, from what I’ve seen, does not do this. Everyone sets up largely identical monolithic applications which share messages through the Pubsub protocol. Information is duplicated everywhere, and inter-instance communications are a liability not only in content but even in compute and persistence (you can absolutely get DDOS’d by a noisy neighbor). Individual instances are responsible for their own edge security, compute, and data. It’s just a lot to ask of a single person that wants to host a federated instance.

I think that a healthy federated internet will eventually require highly specialized instances at several layers, and for certain maintainers to thanklessly support the public facing services. One of the most obvious classes of these specialized instances, to me, would be the data layer and catching instances, which exist to ensure that content posted on one instance is backed up and served for other instances. It reduces the strain on public facing instances because they no longer have to host all the content they’ve ever seen, and it also ensures that if a public instance goes down, the content does not disappear with it.

This same principle could be used on “gateway” or “bastion” instances which enforce strict security on behalf of public instances. Public instances would block direct connections while treating requests from the gateway nodes as highly privileged. Each public instance would either find a gateway instance to protect it or handle its own security and inter-instance communications.

This obviously isn’t a complete solution, and it’s a hell of a long way from a technical specification, but my hope is that others who are looking at the weird and wonderful landscape of our new internet are having similar concerns and reaching similar conclusions.