Re: Future Direction of GNU Hurd?

On Saturday, 12 September 2020 15:34:12 CEST Dr. Arne Babenhauserheide wrot=
e:
> Paul Boddie <[email protected]> writes:
> > After all, despite the almost singular emphasis in advocacy around the
> > project of translators being the Hurd's most compelling feature which
> > seems like a hard sell to most people these days
>=20
> Where did you get that from?

The various talks that seem to get given every year.

> And more importantly: Where did you see advocacy? I have not seen much
> advocacy for the past 10 years. There=E2=80=99s the odd article or talk n=
ow and
> then, but that=E2=80=99s it.

See above. If there is no new advocacy, one can only speculate as to why th=
at=20
might be.

> Translators are a building block to make other features easier.

They probably are, yes. The problem for the purposes of advocacy and=20
communication might be the examples that are used. Accessing a CD image or =
a=20
=46TP or Web site, which seemed to be most prominent ones, are not particul=
arly=20
compelling to many people these days.

> The past years have seen the pains people go through to club together
> features in Linux that are much easier to realize in the Hurd.

I don't disagree that Linux has been bolting features on in an incoherent w=
ay=20
and that things might be easier for a lot of people if they didn't need to=
=20
follow all the "hot" "new" technologies from a bunch of people (many of who=
m=20
seem to have something to do with a fairly well-known IBM subsidiary) who a=
re=20
entirely wedded to Linux.

> If anything, the past decade has shown that the features the Hurd
> provides make it much easier to implement very compelling features.

So why are more such compelling features not being implemented? This is a=20
genuine question.

> Also did you catch subhurds becoming usable without root?
>=20
> And adding permissions at runtime, which is the clean way of doing what
> flatpak gets into GNU Linux in a way that makes many programs much less
> convenient to work with?
>=20
> Or Guix adding a hurd-vm as system-service?
> https://guix.gnu.org/blog/2020/a-hello-world-virtual-machine-running-the-=
hur
> d/

My impression was that things like Plan 9 and Inferno already allow subhurd-
like namespace configuration, hence my remarks about Bell Labs (and my=20
observations about how people will dismiss such efforts, not necessarily wi=
th=20
the more valid arguments for doing so). Other systems have also done this=20
previously: I suspect that Spring does so, too.

So, even though those systems are also somewhat neglected (or abandoned in =
the=20
case of Spring), people do have the option of trying them out (where still=
=20
available) or improving them to see if they like the ideas as much as they=
=20
think they do. Certainly, Inferno is fairly easy to get running in its=20
"virtualised" form on a number of architectures, even though it has its own=
=20
compilers.

Of course, the features mentioned are beneficial and very much preferable t=
o=20
the container culture that pervades Linux-based deployment where whole syst=
ems=20
are deployed on top of whole other systems because that ends up being "easi=
er"=20
(and probably sells more hardware and services). But how is the Hurd and it=
s=20
features going to get into the hands of people who might benefit?

And that takes me back to my observations about broadening the appeal of th=
e=20
project and actively embracing the broad range of contributions that might=
=20
result.

Paul