On Sat, Mar 20, 2021 at 11:09 AM Olaf Buddenhagen <[email protected]> wrote:
> > An aside: I absolutely want to have optional orthogonal persistence > > per-application. Imagine having emacs up and ready to go the moment > > you log into your machine. Yes please. > > How would that work per-application? Don't we have to restore the > application's environment (including capabilities) -- meaning it has to > be more or less system-wide?... > Observation: If the persistence is per-application, it isn't orthogonal. If a client application persists and the corresponding server application does not, capabilities held by the client can cease to be meaningful in very surprising ways. Also: it's *much* easier to do this system-wide than per-process. The system-wide problem is straightforward. The per-process problem is really complex. My personal opinion is that if you want to go this way you should simply do systemwide orthogonal persistence and then let processes that don't need/want it simply pretend they don't have it. It's certainly no *worse* than a non-persistent system, and in some cases it's much better. You seemed to say something similar later in your note. Either way: yes, I totally want the ability to seamlessly resume any > activities (that do NOT include Emacs in my case :-P ) after logouts, > power cycles etc.... > I've moved almost entirely to VSCode these days, but the issues are similar. The idea of emacs-the-kitchen-sink becoming persistent is kind of disturbing... :-) > However, I don't intend to implement this with orthogonal persistence > based on preserving the entire memory image of processes. > > ... The problem is at the edges, where it doesn't help: things like > upgrading software; migrating part of the environment to a different > system instance; recovering from crashes involving memory corruption... > Removing systemwide persistence doesn't remove any of these concerns. It might be better to think of it as something that is very nice to have in certain places and cheap to ignore when it doesn't help. Once you leave the machine boundary, it behaves very much like current systems. Migrations aren't conceptually hard; the trick is to establish the perimeters of what you intend to migrate. That's a design issue in non-persistent systems too. Shap will probably tell me that I got it all wrong or something... Well, I certainly don't want to disappoint you, so: you've got it all wrong or something. When I figure out where/how, I'll let you know. Think of it as "new Promise(Critique)". Seriously, my week has been spent on contracts and patent disputes and donating 40,000 COVID masks and purchasing major equipment and a death in the family. Except for the last one it has not been an unusual week. I'm afraid capability systems aren't the thing at the top of my attention these days. > : but > the truth is that my conclusions on this matter haven't budged over the > past 15 years -- and I can't imagine them budging over the next 15 :-) ) > Ah. Then again in the spirit of not disappointing you, I will revise and extend: you've got it all wrong or something and you're admirably stubborn about it. :-) > It's just a matter of complexity. The various pieces that implement > > the SLS are less than 5000 lines, wheras libstore is over 7000 on its > > own; libdiskfs 12000, and then libext2 on top of that. But yes, it's > > somewhat like an initrd. > > Why would that matter, though? You aren't limited in the size of the > image loaded by bootloader, are you?... > If you plan to rely on those lines for security, the fewer you have the happier you're going to be. For a truly secure system, 10,000 lines is about the feasible upper limit for the entire system core. Jonathan
