GUI systems
Jonathan S. Shapiro
shap@eros-os.org
Wed, 28 Jun 2000 06:44:46 -0400
> 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