The broken links include links on the same domain.
What a sad state of affairs - and I am guilty of it myself, having killed content on the web oftentimes in the past. Not sure what to do about it, though.
Donate to the Internet Archive!
Pity Nature doesn't have a Wayback Machine: http://archive.org/web/
That does make it more and more cluttered over time, but at least I'm not contributing to linkrot.
> Satan, pretending to be offended by your skepticism, asks "Whose signature do you trust? Just say the name, and I will have them sign my class. Would you like Microsoft to sign it? There's a guy over there who owes me a favor." You come to the conclusion that a signature cannot by itself transform a suspect class into a fully trusted class, so you decide that you need a more credible security mechanism.
The existence "fork <- revoke" calls mean that you're no longer designing a solution for coordination/resource management (the usual aim of dining philosophers); you're designing a system in which a higher-permissioned administration system manages resources for lower-permissioned users.
The untrusted-peer problem is interesting on its own, but my gut says it's different from the usual aim of this puzzle: to figure out the simplest/best strategies, or simplest/best means of central administration, required to manage resources effectively.
Also pretty similar to view architecture requiring paint (ex: setNeedsDisplay)
Normal setup should be more in line with, each have forks, knives and spoons, and there is a new food in table, which can require (x amount of forks, y amount of knives and z amount of spoons) and where you dont have information about this requirement upfront.
In here system knows about the requirements to eat shrimp, which is removing the forks from equation (where central system can manage forks, and the only function here is to ‘eat’)
That made me laugh. When a fork dispenser dispenses philosophers, your data modeling took a wrong turn somewhere.
