Re: Future Direction of GNU Hurd?

[Dr. Arne Babenhauserheide]

Jonathan S. Shapiro <jonathan.s.shapiro@gmail.com> writes:

> On Mon, Sep 14, 2020 at 11:46 PM Dr. Arne Babenhauserheide <arne_bab@web.de>
> wrote:
>
>> > The fundamental problem with the Hurd is the same as it has always been:
>> it
>> > is a solution looking for a problem. Hurd advocates have not been able to
>> > clearly articulate what problem is being solved and why it is a problem
>> > that users should care about or be concerned about. This has been the
>> state
>> > of the Hurd *for 30 years*.
>>
>> This is false.

> Oddly enough, I have learned to appreciate the (usually) German habit of
> combatively absolutist assertions on subjects that are fundamentally
> matters of opinion. 

Well, you didn’t state it as a matter of opinion :-)

> I also appreciate the irony in this, since one of my failings is
> that I am prone to the same pattern of interaction.

At least that way there is a statement that can be discussed. I do not
consider this a statement of opinion, though the "should care" naturally
is subjective.

> Your response, unfortunately, does not provide any counter-example. I asked
> what problem Hurd attempts to solve that *users* should care about. Most of
> your examples are technical rather than user objectives. The exception that
> I see (the audio confirmation pop-up) is a security anti-pattern; it is in
> direct opposition to what we know about human factors design in security
> systems. The browsers are also getting this wrong, so perhaps they should
> not be our design guide.

What would be the better way? I’m still open to a different approach
(it’s not implemented yet, and if there’s a better way I’d rather
implement that).

The fundamental goal is to only allow programs access to the
audio-hardware if they should be allowed access. And to not follow the
path of Windows were we regularly lost time at work because the
microphone was muted and we had to hunt down for the right setting.

The main advantage of this idea is that it can be implemented without
changing programs (though the pervasiveness of pulseaudio nowadays is a
stumbling block for it). On the Hurd it would be easier to ensure that
every audio-program only gets access to the hardware when it is
permitted access.

> The justification for this type of effort demands a *large* human
> problem. Sometimes, humans do not recognize such problems until they
> are presented with a solution, which is why I framed my question as
> users "should" care about it.

Here’s a larger problem, but further removed from users: You need kernel
hackers to build a performant filesystem. This was solved by the Hurd
and much later got bolted onto Linux with FUSE.

Another one: To isolate the rocket chat App from my system, I need
flatpak. But with that, I cannot open folders for which I did not give
the application permission beforehand.

Another one (though this is the first time I write about it): You could
mark files as automatically backuped on writing by setting a
create-backups translator on top of them.

And you don’t need a dozen services running in the background (as is
common nowadays). SystemD wrote a lot about socket-activation while the
Hurd long provided passive translators started on-demand.

And there is one more thing: Users should care about gatekeepers.
Forking parts of the Linux-kernel is only possible for groups with lots
of funding, while with the Hurd, a skilled student can build and
distribute a replacement for a core service that users can wire in.

> The Hurd may have one now, but it did *not* have one the last time I had
> contact with the project. The claimed goal at that time was *provably* (in
> the formal mathematical sense) unachievable. It would be wonderful if that
> has changed.

Which goal was provably unachievable?

And when was this?

When I joined the project I looked for the worst problem I saw for the
Hurd. And I found pretty lively development which was hampered by the
public perception that the Hurd were vaporware.

That’s why I started the Month of the Hurd: regularly showing concrete
steps the project moved forward. Also I worked on the startpage and
antrik and a few others joined me and found a description and a mission
statement for the Hurd:

# What is the GNU Hurd?

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a 
collection of servers that run on the Mach microkernel to implement file 
systems, network protocols, file access control, and other features that are 
implemented by the Unix kernel or similar kernels (such as Linux).

# What is the mission of the GNU Hurd project?

Our mission is to create a general-purpose kernel suitable for the GNU 
operating system, which is viable for everyday use, and gives users and 
programs as much control over their computing environment as possible.
→ 
https://www.gnu.org/software/hurd/community/weblogs/antrik/hurd-mission-statement.html

(note the "suitable for the GNU operating system". That implies that
 the needs of users always win over the needs of programs)

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

signature.asc
Description: PGP signature