l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Persistance and boot scripts (was: Re: L4-HURD , POSIX, UNIX)


From: olafBuddenhagen
Subject: Persistance and boot scripts (was: Re: L4-HURD , POSIX, UNIX)
Date: Mon, 7 Nov 2005 02:20:30 +0100
User-agent: Mutt/1.5.9i

Hi,

> > Persistence could be an option. There are issues with persistence
> > (such as reloading the corrupt code on every boot), and therefore it
> > should not be enforced. Personaly, I would like to see persistence
> > in GNU/Hurd.
> 
> As far as I understood Shapiro, applications don't have to do this.
> They have to accept remote resources (network connections for example)
> to disappear, but they have to accept that without persistence as well
> anyway.  The low level system code to handle it may be a little
> complex, but that's a one-time job to write.  And it means we don't
> have to write the complex boot-script stuff. :-)

I agree that getting rid of boot scripts solves many problems, and is
desirable from both security and usability viewpoints.

Note however that this absolutely doesn't require transparent
system-wide persistence. Between boot-scripts and transparent
persistence, I can see a whole palette of possible session management
mechanisms, which are less radical but have a similar effect. That's
what I tried to point out in my original article at
http://tri-ceps.blogspot.com/2005/09/persistance-vs-insistance.html
(Which has some confusion and definitely needs a major revision for all
the stuff I learned in the meanwhile; but still holds in the core
statement.)

There is another considerable implication from such a middle ground:
While I'm advocating for session management to be integrated into the
system much tighter than existing (flawed) approaches like e.g. X
session management, it can be still considerably less invasive than
transparent persistence, meaning it can be integrated later on.

That would give us two great advantages: For one, it means we wouldn't
need to bother with it from the beginning, which seems very important
considering the situation with the Hurd.

Moreover, it would allow for a smooth transition path for both users and
existing software. This is crucial for the usefulness and success of the
Hurd IMHO.

-antrik-




reply via email to

[Prev in Thread] Current Thread [Next in Thread]