I also suspect those responses were all generated by an AI.

I don't know much about stenography, but that seems like something that would be trivial for a computer to do.

And certainly something that would only have to be done once...

The human should be left in the loop, full stop. Language is hard and court rooms can be chaotic places and you want the transcript to be clean.

(disability accomodations is a different conversation altogether)

> Abstractions don’t remove complexity. They move it to the day you’re on call.

As someone who has been on call a lot, this is only true for bad or incomplete abstractions.

When you are on call (or developing) you can't possibly know everything about the system. You need abstractions to make sense of what is going on, how the system as a whole works, and know which parts to hone in on when things go wrong.

And it is extremely useful to have standard ways of changing configuration for things like timeouts, buffer sizes, etc. in a central place.

I don't think it's meant to be a point against abstraction or a point against complexity. I think it's widely understood that abstraction is part of how advancement is made in our practice, as well as in other disciplines. I have taken this saying to be an observation that there is almost always possible failure beneath the façade provided by the abstraction. Therefore, yes, you avoid having to let that complexity enter your brain, but only when the abstraction is holding. Beyond that point, often after pages are sent, you will still have to engage with the underlying complexity. A proactive measure following from this idea would be to provide support in or alongside your abstractions for situations where one must look under the bonnet.

> Outside of the domain of Firefox/Chromium, screencasting is much seamless

Not always. In my experience Zoom screencasting is much, much worse than on browsers in Wayland. But that isn't terribly surprising given how generally bad Zoom UX is on Linux.

Technically, X is also just a protocol. But there was just one main implementation of the server (X.org), and just a couple implementations of the client library (xlib and xcb).

There isn't any technical reason we couldn't have a single standardized library, at the abstraction level of wlroots.

> a heat shield named Pridwen after the legendary shield of King Arthur will be deployed to protect the spacecraft from the intense temperatures it will experience as it re-enters the Earth's atmosphere.

Why bring back the entire spacecraft and not just the finished product?

I'm also curious how they handle cooling the silicon, since dissipating heat in space is kind of difficult.

Harder engineering to separate the components? Making the oven + crystal formation work is probably maxing out their novelty budget without trying to make the craft partially disassemble.

Plus, they can study the oven after the process which is likely to be helpful if the entire experiment poops the bed.

Brown sauce and malt vinegar.

Same in the US

I actually think it would have had a better chance of success if ipv6 had embraced the breaking changes to add some killer feature that would have made it worthwhile to upgrade even for entities who didn't need to worry about running out of ipv4 addresses.

I'm not sure what that feature would be though.

This is actually unwanted in a dual-stack world. Once you have divergent behaviors on your networks, you have a complex/weakened security model.

Networking should be boring.

> IPv6 was not backward-compatible with IPv4

I don't think there is any way it could have been.