On GUIs and such things

[Jonathan S. Shapiro]

> > Neither of these statements is relevant to persistence in EROS. The
problem
> > is that this statement is mixing a couple of levels of abstraction.
> >
> > For purposes of understanding persistence, the only code we care about
in
> > EROS is the kernel. If a domain is bad, EROS will guarantee that it is
still
> > bad on reboot.
>
> The point of Shawn's statement, I think, is that memory leaks can
> continue across reboots, which they can't in OSes that don't support
> transparent persistence.

Indeed.

The point of *my* statement, is that only one program in EROS has this
problem: the kernel. It is true that you can build applications that run
forever, and that these applications might leak. It is not *necessary* that
you build them that way.

> I think very little software should run forever, which solves the
> problem.

There are a surprisingly large number of very simple programs in the world.

> > > Those languages have their own problems ;)
> >
> > Performance?  the usual complaint.  What other problems?  (BTW when
> > I said "exclusively" I meant for user-level applications...not the OS)
>
> High-level languages have some disadvantages, but I don't think
> poor performance is legitimately among them.

Actually, I was thinking of lack of specification.  There still isn't a
proper spec for Java, for example.

HLL performance divides into compilation problems and runtime problems. The
compilers are still evolving, but we are definitely seeing a trend toward
language features that require code explosion to support -- consider Self.

Runtime performance is unpredictable in the sense that you don't know when
GC will kick in. The GC generally doesn't cost more, but it occurs at times
you cannot control. Real-time collectors really do have serious performance
problems so far.