Satan Comes to Dinner (1997) | Hacker News Reader

Satan Comes to Dinner (1997)

erights.org

64 pointsEtDybNuvCu14 comments

Doesn't this radically change the constraints of the dining philosophers problem?

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.

Yeah I felt similar when reading, actually it is simply removing forks from the system, and rate limiting ‘eat’. It is not much different than an rate limited API design on ‘eat’ function.

Also pretty similar to view architecture requiring paint (ex: setNeedsDisplay)

The comment on code signing is always a good one to remember: "You could verify that the signature is truly Satan's, but proof that it came from Satan is not proof that it is safe."

I got a good laugh from the next part:

> 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 joke being that Microsoft is in the habit of signing deals with Satan... probably a popular theory in the late 90s.

What I found really sad to see is the amount of dead links at the end of the document. Of all the links 2 are still in existence.

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.

Let dead things go in peace.

Pity Nature doesn't have a Wayback Machine: http://archive.org/web/

> Not sure what to do about it, though.

Donate to the Internet Archive!

https://archive.org/donate/

To the Monte team, erights.org is an archeological dig site. We rely heavily on it for historical context and to learn the lessons of our predecessors, but it hasn't aged at all; it's a snapshot into those who came before.

I, at least, treat my web/ directory as an append-only FS.

That does make it more and more cluttered over time, but at least I'm not contributing to linkrot.

Not just sad but ironic: some of the E people came to it from Xanadu, the pre-web hypertext system which included a solution to linkrot. (Notably Mark S. Miller.)

Mildly worth noting that the Original-E dialect of this article's code is different from later E. If you don't like the syntax, maybe you'll find it gets better! Also there's Monte which looks rather like Python.

Basically diner problem is simplied version of real world, which this approach is trying to oversimply it by introducing something, information about how to eat shrimp.

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’)

> A philosopher is not necessarily made by a fork dispenser, but it is initialized by a fork dispenser.

That made me laugh. When a fork dispenser dispenses philosophers, your data modeling took a wrong turn somewhere.

Reply on news.ycombinator.com