Currently only GHA and Gitlab are supported.

It also make it impossible to publish using CI, which is problematic for projects with frequent releases. And trusted publishing doesn't solve that if you use self-hosted CI.

Javascript is a standard with many implementations. Any addition to the "standard library" (such as it is) has to go through a long process to get approved by a committee, then in turn implemented by at least the major implementations (v8, SpiderMonkey, JavascriptKit).

> Or at least first party libraries maintained by the JavaScript team?

There is no "JavaScript team".

It depends on the state, but that is largely kind of already the case. At least in my state you get a significant deduction to your property taxes if it is your primary residence.

> Ah, looks like it was somewhat superseded by RFC 4918, but we’re not going to tell you which parts! How about those extension RFCs? There’s only 7 of them…

This is a major complaint I have with RFCs.

If you want to know the current standard for a protocol or format you often have to look at multiple RFCs. Some of them partially replace parts of a previous RFC, but it isn't entirely clear which parts. And the old RFCs don't link to the new ones.

There are no less than 11 RFCs for HTTP (including versions 2 and 3)

I really wish IETF published living standards that combined all relevant RFCs together in a single source of truth.

Is this true anymore? AFAIK, I've seen "Updated by" (rfc2119), "Obsoleted by" (rfc3501), but that might changed afterwards https://stackoverflow.com/a/39714048

Those notices don't usually point to all RFCs that update the one you are reading. They tend to be more complete on the case of obsolete ones.

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.