If I understand this correctly, the algorithm depends on the underlying platform to ensure correct ordering. Two processes may each get the same bakery ticket number. The conflict is resolved by the process with the lower process id being allowed to go first. This process ID is in effect a ticket number issued by the underlying hardware. If the processes were running in a distributed environment, there would not be a common underlying platform to resolve this conflict.
In that context you could simply pick another thing as the tie breaker, like the IP address expressed as an integer (ie, remove the periods and treat like a number) being lower.
But then there is reliance on an underlying platform to resolve the conflict by providing a globally unique identifier. Instead of process ID, there is the IP address mechanism.
So it's turtles all the way down, if I understand correctly.
Not really. Each process could, at the beginning, generate a random nonce and broadcast it and thereafter use that as its tiebreaker number. The point is to just have a consistent way to break ties that is convenient to implement in whatever domain you’re working in. And in a networked domain, without a valid IP address, the worker isn’t going to be doing much in the process anyway since it wouldn’t be able to communicate at all.
But it's not in a distributed environment, it is a shared memory environment. That is the whole point. If it were a distributed environment the processes would not have to worry about smashing each others memory because they would not share memory in the first place.
Most shared memory environments are distributed, at least to some extent. The process ID is not an issue, you can do the equivalent in a distributed environment just fine. But the algorithm depends on strict memory ordering, and that's much harder to provide than atomic writes. Most shared memory systems don't offer it.
From the link, it appears that it was developed by a single person in 2000, who then brought on board 2 other people as contributors in 2002 and after.
In a few years, as mid-level cognitive tasks get automated by LLMs, resulting in elimination of some percent of well-paying white-collar jobs, there will be economic dislocation and social disruption.
Oligarchic capitalist societies with a hypocritical philosophy of free market economics (such as the USA) will experience social unrest and civil strife.
In the meantime, social-democratic societies that have effective governance and can grow their safety net with universal basic income will be advantaged in this new economic order. Thinking Scandinavian and some Asian economies.
The geopolitical balance of power will shift toward stable societies that are able to make the conceptual leap to UBI. Others who follow the primitive fantasy of free market economics will crumble and get left behind.
Maybe. I don't see any reason to assume the US won't continue to successfully a) escalate police power to keep citizens under control, b) continue giving people just enough crumbs to keep them from getting violent, and c) propagandize the hell out of the idea that societal mismanagement is a matter of personal responsibility. China has done pretty well while clamping down on civil liberties, and the US has always been better at obfuscating and spinning similar tactics to be more palatable to its citizens. And you only need to look at the rust belt to see what happens when US business leadership decides to follow the cheaper option.
Though, regardless of ensuing social unrest, the fact that the people involved are human beings should be enough to not treat them like used condoms when computers figure out how to do their jobs. Should be.
The undocumented workers that I personally know are skilled, motivated, and diligent workers. Perhaps in part because they desperately need to hold on to this source of income. If anything, I think they would boost productivity metrics.
The notion of decentralized identity has been an enchanting vision since Christopher Allen first articulated it in 2016. Since then, DID spec has been around for years in draft form, and there are at least a dozen vendors and/or projects producing DID-compatible or DID-relevant technology.
Of course, these different packages are not (yet) compatible, but that's not the problem. The problem is that, after a good 4 or 5 years, it's hard to find a single project that uses DID protocols at scale in a worthwhile and effective manner.
There are tons of pilot projects and PoCs. A few go into production at limited scale, languish for a while, and then do a slow fade.
I agree with other commenters that DID does not seem to address real-world pain points. I also think that the spec appears murky, abstract, overly complex and hard for developers to work with. I have tried to use DID in projects a couple of times, and found myself sidelining or pushing it into a corner of the system, because it did not seem to serve a useful purpose.
There's a recent alternative to DID, which is narrower in scope and more pragmatic. That is "login with Metamask" or "sign-in with Ethereum" (or something similar in the case of other blockchain platforms).
The SIWE movement probably will win out, imo. Brave already supports it natively, and services like ENS are growing in popularity and use cases. And MetaMask itself is already at 50 million installs. Most other smart contract blockchains are Ethereum compatible, so you can use the same account (via MetaMask or wallet of your choice) across blockchains pretty easily. It's also dead simple to implement as a web developer, and it's a pleasure to use as a user.
