Readit NewsIt's a long-winded article, even for a lawyer, but the payload seems to be a crack at the head of the RIAA, which is suing Midjouney.
"In other words, Glazier doesn't want these lawsuits to get rid of Midjourney and protect creative workers from the threat of AI – he just wants the AI companies to pay the media companies to make the products that his clients will use to destroy creators' livelihoods."
Businesses exist to make money. If you want a commune instead, join one!
Institutional rhetoric at high levels is always meant to manipulate labor markets, financial markets, popular opinion. This is basic worldly-wisdom. The question is how does one (who is not at a high level) survive the recurring institutional changes? There seem to be two approaches to an answer: Do one's professional best regardless of change, or try to anticipate changes and adjust with the wind. For the first, gods may bless you, but it is folly to think your bosses will respect you. For the second -- good luck, you're running with bulls. Either way, the pill to swallow is that most employees including managers are grist to the mill.
An extremely steep one.
The average multi-year TypeScript developer I meet can barely write a basic utility type, let alone has any general (non TypeScript related) notion of cardinality or sub typing. Hell, ask someone to write a signature for array flat, you'd be surprised how many would fail.
Too many really stop at the very basics.
And even though I consider myself okay at TypeScript, the gap with the more skilled of my colleagues is still impressively huge.
I think there's a dual problem, on one side type-level programming isn't taken seriously by the average dev, and is generally not nurtured.
On the other hand, the amount of ideas, theory, and even worse implementation details of the TypeScript compiler are far from negligible.
Oh, and it really doesn't help that TypeScript is insanely verbose, this can easily balloon when your signatures have multiple type dependencies (think composing functions that can have different outputs and different failures).
It's a bad situation.
1. OAuth2 and OIDC are inherently intricate and alarmingly brittle – the specifications, whilst theoretically robust, leave sufficient ambiguity to spawn implementation chaos.
2. The proliferation of standards results in the absence of any true standard – token formats and claim structures vary so wildly that the notion of consistency becomes a farce – a case study in design by committee with no enforcement mechanism.
3. ID tokens and claims lack uniformity across providers – interoperability, far from being an achievable objective, has become an exercise in futility. Every integration must contend with the peculiarities – or outright misbehaviours – of each vendor’s interpretation of the protocol. What ought to be a cohesive interface degenerates into a swamp of bespoke accommodations.
4. There is no consensus on data placement – some providers, either out of ignorance or expedience, attempt to embed excessive user and group metadata within query string parameters – a mechanism limited to roughly 2k characters. The technically rational alternative – the UserInfo endpoint – is inconsistently implemented or left out entirely, rendering the most obvious solution functionally unreliable.
Each of these deficiencies necessitates a separate layer of abstraction – a bespoke «adapter» for every Identity Provider, capable of interpreting token formats, claim nomenclature, pagination models, directory synchronisation behaviour, and the inevitable, undocumented bugs. Such adapters must then be ceaselessly maintained, as vendors alter behaviour, break compatibility, or introduce yet another poorly thought-out feature under the guise of progress.
All of this – the mess, the madness, and the maintenance burden – is exhaustively documented[0]. A resource, I might add, that reads less like a standard and more like a survival manual.
[0] https://www.pomerium.com/blog/5-lessons-learned-connecting-e...
There's no value in naming the employee. Whatever that employee did, if the company needed to figure out who it was, they can from the commit hashes, etc. But there's no value in the public knowing the employee's name.
Remember that if someone Googles this person for a newer job, it might show up. This is the sort of stuff that can disproportionately harm that person's ability to get a job in the future, even if they made a small mistake (they even apologized for it and was open about what caused it).
So no, it's completely unnecessary and irrelevant to the post.
Isn't that beneficial in this case?
Ya gotta be practical.