Re: Future Direction of GNU Hurd?

[Dr. Arne Babenhauserheide]

Paul Boddie <paul@boddie.org.uk> writes:
>> 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 
> genuine question.

That’s simply a function of people and time.

The compelling features don’t need deep core work. Take the common lisp
bindings. Or write other bindings and build something cool with them.

That’s not trivial, but it also doesn’t need core hacking.

The documentation for that is spread around — you need quite some time
to get into it. But that said: I expect that if three determined people
took up creating cool features for the Hurd, it would move quickly.

Why don’t such people just show up? Because most Free Software
developers are already occupied by their own projects. Devs who invest
half their free time into a project are even rarer. If they are somewhat
skilled and the tasks are already viable (not blocked by hard problems)
then any project they take up starts to move fast.

>> Also did you catch subhurds becoming usable without root?
>> 
>> 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?
>> 
>> 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 
> observations about how people will dismiss such efforts, not necessarily with 
> the more valid arguments for doing so).

Plan 9 was proprietary until 2000.
Inferno was proprietary until 2004.

In 2004 many of the features in the Hurd already worked pretty well.

In addition, the Hurd aims to be a drop-in replacement. About 80% of
debian packages are available — it’s goal is to be a real alternative
for day-to-day work.

One big thing that changed in the past 16 years since I first got
involved with the Hurd is that nowadays the Hurd is mostly stable. It
can compile itself and doesn’t crash when load rises. This was very
different in 2004. And getting there took a lot of unglamorous work.

"The Hurd no longer crashes when you try to compile GCC" doesn’t sound
big, but in fact it is. And that’s where the time from the core devs is
very important.

This was one of the hard problems whoose solution takes work and time.

> (and probably sells more hardware and services). But how is the Hurd and its 
> features going to get into the hands of people who might benefit?

By having people use it and talk about what already works. That’s a
pretty important part of the work which does not put more load on
current core developers.

If you feel that the docs aren’t good enough, you can do a great
contribution by doing the small tweaks that can make them much better.
Often all it takes to improve them a lot are a few well-placed fixes.
While you search for your way through the docs, it can help a lot to
build a tutorial while you learn that others can follow.

Now you can ask why not more people use the Hurd. My main answer to that
is "missing USB and sound support". For the latter I’m pressed for time,
because there’s something I’d like to still get done this year, but I
need to finish another project beforehand.

I won’t write much more in this thread, because an email like this takes
about an hour that I’d prefer to spend hacking.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

signature.asc
Description: PGP signature