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

[Marcus Brinkmann]

At Mon, 7 Nov 2005 02:20:30 +0100,
<address@hidden> wrote:
> 
> 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.)

I definitely agree that there is a range of options between
persistence and non-persistence.  Well, in fact there is exactly one
third option, and that is orthogonal persistence, but of course you
can vary the extent on which the persistence attribute applies.

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

Note that this works both ways.  Let's assume we start with global,
transparent persistence.  Then it is easy to completely ignore that
the system is persistent, and just shoot down the whole subsystem at
recover time (ie, when the persistent checkpoint is rebooted).

So, I don't think that your argument is really an argument against
global transparent persistence as a mechanism in the underlying
operating system.  You _are_ making an argument about how much and
when the persistence should be leveraged in the (sub) system design.
That's something that certainly should be discussed in depth.

Thanks,
Marcus