1. It's not an authentication protocol, but it was abused as one for until OpenID Connect came along
2. OpenID Connect is the compatible authN protocol, and it actually has a spec unlike OAuth2
Both of those are annoying because they are over-complicated for simple use cases and for a long time there were very few simple open-source providers that weren't hiding all the important stuff behind their enterprise/cloud versions.
Open source options like Zitadel are improving this space somewhat, though they are still sort of painfully complicated if you want to deploy something small and simple that you can understand. In order to be big business they have to support tons of 3rd-party provider plugins with all their out-of-spec wrinkles.
It would be nice to have something like Zitadel that is signficantly less concerned about all those third parties - like let me very easily just host username/password and passkey auth in a small package.
Even if everyone had enough financial security (or realized they did), you need coordination, people are never going to independently and spontaneously turn down these jobs at evilcorp en masse - you need coordination, a.k.a strong unions which can actually effect the policies of the employer.
X11 and everything around it is unfixable security hazard slop, just slop that was painstakingly created by humans.
Also Wayland is it being forced on us? I have plenty of coworkers that run X daily because they are still afraid of the Wayland boogeyman despite the fact that their supposed clipboard and screen sharing problems in Wayland (the only two supposed problems they can name) have been solved for years.
People don't use Xorg daily because they are afraid of wayland. People use Xorg daily because they have tried wayland and there was something that stopped working.
Xorg allows running sub-instances.
Wayland is now older than Xorg was when "it was really old, we need something new".
The way it works is that Restate supports suspending workflows that sleep for months and later (once the sleep finishes) resumes them at exactly this point. Technically, this is the same process as resuming a crashed workflow.
While the workflow is actively doing work (like calling other services, accessing state or interacting with external services, for example) the server is connected to the workflow deployment via a low-latency bidirectional streaming connection to receive and acknowledge progress that the workflow makes. That way the workflow can finish as fast as possible.
A nice side effect of this model is that you can co-locate your workflow with expensive resources, such as a sandbox, which should be used by all durable actions that the workflow executes. The reason this works is because Restate can inline durable steps (what would be modeled in Temporal as activities, I believe).
If a handler starts a sleep/human approval/RPC call, or so, then this timer/promise is persisted in Restate's journal. Restate does the waiting. The handler process itself can suspend (e.g. on a serverless function), and the bidirectional connection is closed. Once the timer fires/approval comes in, Restate re-invokes the service with the journal of previously completed steps, and the service can replay to the exact point in the code where it suspended and continue from there. Restate is like a DB for journals, so you can sleep for as long as needed, also months.
So you have fast persistence of events while a handler can make progress, and suspensions while waiting.
I guess the confusion is that it doesn't have to be one single persistent stream.
While the durable function does fast work and adds steps, it pushes it through a stream. When a wait point comes, it closes and replays on resumption (typical durable execution style).
That gives you the best of both worlds: same long-running workflows with long sleets and suspensions, but also ability to add steps with few ms overhead only.
I does. The OP says "Linux" but means "Linux distros", which are made of thousands of "commingled" pieces (i.e. the licence of one piece does not affect the other).
Each piece that becomes MIT means less pressure on corporate users to give back any changes they make, and we'll end back up in the 1980s again where "Amazon Linux" is full of secret-sauce they refuse to publish and makes the base system incompatible with "Google Linux" (or whatever happens to be kicking about), creating deliberate lock-in out of a system that started open. In much the same way that macOS and FreeBSD are divergent today.
In theory there could be a the MIT version relicensed to GPL and this version could be carried as a standard if having MIT software as core utilities was considered enough of a threat - right? You just have to retain original license/attribution.
That would be an awfully awkward move in the realm of Linux-related politics but if having an MIT-licensed coreutils was such an existential thread, at least you can fix it with aggressive license moves and not code.
We've balkanized Linux but you're free to use the original (which we are deliberately incompatible with, as is rival #2, rival #3, rival #4, etc. and we're all mutually incompatible with each other)
Amazon and other clouds already patch the hell out of Linux, but they don't distribute physical devices with that Linux on it to anyone, so they don't have to deliver source code either.
I am not totally sure I see the actual concern here, that a company is going to sell devices with a really great `find` implementation but not contribute it upstream?
In the 1980s and 1990s, there were a number of commercial Unices (SunOS, HP-UX, AIX, IRIX, etc.) Every one of them was incompatible with each other, sometimes subtly, sometimes blatantly. They were all competing against each other and all seemed to encourage you to use their proprietary extensions in your software and deliberately fuck over anyone using any other variants.
What it meant was a headache for writing platform-agnostic software. It was not a productive way to create software.
Replacing GPL software with MIT software just encourages this behaviour to come back. We already see it with how macOS userland took FreeBSD and sprinkled incompatibilities everywhere.
reply