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- _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
