Re: IPC etc. (was: Future Direction of GNU Hurd?)

--000000000000391d6005be3a3e3b
Content-Type: text/plain; charset="UTF-8"

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

--000000000000391d6005be3a3e3b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Mar 20, 2021 at 11:09 AM Olaf Bud=
denhagen &lt;<a href=3D"mailto:[email protected]">olafbuddenhagen@gmx=
.net</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">&gt; An aside: I absolutely want to have o=
ptional orthogonal persistence<br>
&gt; per-application.=C2=A0 Imagine having emacs up and ready to go the mom=
ent<br>
&gt; you log into your machine.=C2=A0 Yes please.<br>
<br>
How would that work per-application? Don&#39;t we have to restore the<br>
application&#39;s environment (including capabilities) -- meaning it has to=
<br>
be more or less system-wide?...<br></blockquote><div><br></div><div>Observa=
tion: If the persistence is per-application, it isn&#39;t orthogonal. If a =
client application persists and the corresponding server application does n=
ot, capabilities held by the client can cease to be meaningful in very surp=
rising ways. Also: it&#39;s <i>much</i>=C2=A0easier to do this system-wide =
than per-process. The system-wide problem is straightforward. The per-proce=
ss problem is really complex.</div><div><br></div><div>My personal opinion =
is that if you want to go this way you should simply do systemwide orthogon=
al persistence and then let processes that don&#39;t need/want it simply pr=
etend they don&#39;t have it. It&#39;s certainly no <i>worse</i>=C2=A0than =
a non-persistent system, and in some cases it&#39;s much better. You seemed=
 to say something similar later in your note.</div><div><br></div><blockquo=
te class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px =
solid rgb(204,204,204);padding-left:1ex">Either way: yes, I totally want th=
e ability to seamlessly resume any<br>
activities (that do NOT include Emacs in my case :-P ) after logouts,<br>
power cycles etc....<br></blockquote><div><br></div><div>I&#39;ve moved alm=
ost entirely to VSCode these days, but the issues are similar. The idea of =
emacs-the-kitchen-sink becoming persistent is kind of disturbing... :-)</di=
v><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
However, I don&#39;t intend to implement this with orthogonal persistence<b=
r>
based on preserving the entire memory image of processes.<br>
<br>... The problem is at the edges, where it doesn&#39;t help: things like=
<br>
upgrading software; migrating part of the environment to a different<br>
system instance; recovering from crashes involving memory corruption...<br>=
</blockquote><div><br></div><div>Removing systemwide persistence doesn&#39;=
t remove any of these concerns. It might be better to think of it as someth=
ing that is very nice to have in certain places and cheap to ignore when it=
 doesn&#39;t help. Once you leave the machine boundary, it behaves very muc=
h like current systems.</div><div><br></div><div>Migrations aren&#39;t conc=
eptually hard; the trick is to establish the perimeters of what you intend =
to migrate. That&#39;s a design issue in non-persistent systems too.</div><=
div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px=
 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Shap will p=
robably tell me that I got it all wrong or something...</blockquote><div><b=
r></div><div>Well, I certainly don&#39;t want to disappoint you, so: you&#3=
9;ve got it all wrong or something. When I figure out where/how, I&#39;ll l=
et you know. Think of it as &quot;new Promise(Critique)&quot;.</div><div><b=
r></div><div>Seriously, my week has been spent on contracts and patent disp=
utes and donating 40,000 COVID masks and purchasing major equipment and a d=
eath in the family. Except for the last one it has not been an unusual week=
. I&#39;m afraid capability systems aren&#39;t the thing at the top of my a=
ttention these days.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">: but<br>
the truth is that my conclusions on this matter haven&#39;t budged over the=
<br>
past 15 years -- and I can&#39;t imagine them budging over the next 15 :-) =
)<br></blockquote><div><br></div><div>Ah. Then again in the spirit of not d=
isappointing you, I will revise and extend: you&#39;ve got it all wrong or =
something and you&#39;re admirably stubborn about it. :-)</div><div><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">&gt; It&#39;s just a m=
atter of complexity.=C2=A0 The various pieces that implement<br>
&gt; the SLS are less than 5000 lines, wheras libstore is over 7000 on its<=
br>
&gt; own; libdiskfs 12000, and then libext2 on top of that.=C2=A0 But yes, =
it&#39;s<br>
&gt; somewhat like an initrd.<br>
<br>
Why would that matter, though? You aren&#39;t limited in the size of the<br=
>
image loaded by bootloader, are you?...<br></blockquote><div><br></div><div=
>If you plan to rely on those lines for security, the fewer you have the ha=
ppier you&#39;re going to be. For a truly secure system, 10,000 lines is ab=
out the feasible upper limit for the entire system core.</div><div><br></di=
v><div><br></div><div>Jonathan</div></div></div>

--000000000000391d6005be3a3e3b--