> Once eros goes network distributed, won't a signal telling the object that
> it has been "moved" to another system be neccessary anyways, why not use
> this same signal?
I'm not sure that distributing in this way is a goal, but if it is the answer to your question is "no". If the system is truly transparently distributed it is non of the object's business where it happens to be running at the moment, and it shouldn't be told
> Besides, what security knowledge could you gather from knowing that the
> system has been cycled, and is functional again, that you couldn't
otherwise
> gather from watching connections drop.
It isn't really a security issue. It's more a programming style issue. Since the system recovers consistently, the majority of objects have no need to know that a crash has occurred. The principle of least privilege says that if they don't need to know, you shouldn't give them an authority by which to find out.
> Also a program that stores a
> timestamp every minute could easily figure out the system it is running on
> has crashed...
Yes it could, but access to a clock is *also* one of those things that not all programs should have. This, however, is a weaker statement, as multithreading is equivalent to having a clock. Norm and I have debated some scheduling strategies that limit the clock accuracy under multithreading, but I don't think we have anything conclusive yet.
Jonathan