
Satan Comes to Dinner (1997) - EtDybNuvCu
http://www.erights.org/history/original-e/satan/index.html
======
zbentley
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.

~~~
bluesign
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)

------
classichasclass
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."

~~~
default-kramer
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.

~~~
titanomachy
The joke being that Microsoft is in the habit of signing deals with Satan...
probably a popular theory in the late 90s.

------
sdoering
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.

~~~
bringtheaction
> Not sure what to do about it, though.

Donate to the Internet Archive!

[https://archive.org/donate/](https://archive.org/donate/)

------
abecedarius
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.

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

------
bcbrown
> 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.

