Re: Future Direction of GNU Hurd?

--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable


Jonathan S. Shapiro <[email protected]> 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 bee=
n:
>> 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.=20

Well, you didn=E2=80=99t 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 ask=
ed
> what problem Hurd attempts to solve that *users* should care about. Most =
of
> your examples are technical rather than user objectives. The exception th=
at
> 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=E2=80=99m still open to a different approach
(it=E2=80=99s not implemented yet, and if there=E2=80=99s a better way I=E2=
=80=99d 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=E2=80=99s a larger problem, but further removed from users: You need k=
ernel
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=E2=80=99t 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=E2=80=99s why I started the Month of the Hurd: regularly showing concr=
ete
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 sy=
stems, 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 oper=
ating system, which is viable for everyday use, and gives users and program=
s as much control over their computing environment as possible.
=E2=86=92 https://www.gnu.org/software/hurd/community/weblogs/antrik/hurd-m=
ission-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
=2D-=20
Unpolitisch sein
hei=C3=9Ft politisch sein
ohne es zu merken

--=-=-=
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJEBAEBCAAuFiEE801qEjXQSQPNItXAE++NRSQDw+sFAl9hIXkQHGFybmVfYmFi
QHdlYi5kZQAKCRAT741FJAPD67h2D/wKt5yW78XzYQjRDxG9OxH4O0QdGwwvbjbE
yv6lcr0Xx4J0s6RBUpZWWH7Peh+PVj0GHNgVRX4uVcgpn0khNk+koPpwHGACT95L
ISqMjzu0jv2cDbGwM10qjf/7LqMBO27If0sDPPPFUT9BoY5VQqaYeBLXdagrsaC3
CwpRfX2NAKgkUZrS5eGvnU01IkBdYIJzBauCHhSmgleISo7lB5KoyMvw3Bdc7d7W
i6ooI+AVlmFU4JeerMz8/2FeHXFa+dAnxoQqfasWYOiY1ySAkySHtEsS5VaRG8Da
CXBID4GGXslO3RMGj7HAIIcXRLr6ysdapeSbsB1rwx4eGc7x9DqlDTwwhjCkPBA+
LLzfMahx+/n1fRxVm1wYqyABT+WQfP8eVRjC3zUr1midbTTXicLn/wLHoDmC/EiV
QZXJ7gWUaEm4j9E50j58zLB5jpAMQ8p1xECwxqztL51N0NGtD24mOe36LaDe69gl
kumvzsnzm3kkgvEK0OHl3RjeA/la+wZJ+i3y/hNTKErElMPKOLPanX2xJxWH6ZX+
4V8y+TQabsSHU9rcDkhEXAoYKuuvMHa4F22y9DSxRqCUdYevCalcCgTRkE4hrkRA
uM1DtxlDQs1JRs9KQcgMJOZdjA4MS8zYguNJLnvpEQmnIWddpoxjhG65aOgli99z
gGSLEIKyV4jEBAEBCAAuFiEE3Si95tmHXKvOSosd3M8NswvBBUgFAl9hIXkQHGFy
bmVfYmFiQHdlYi5kZQAKCRDczw2zC8EFSA0uBACX9aZgbwnr+2Nu0GkN1QyU5D9y
FA14uKyZp93jFhm2chR9ZISAblmVmAOTfwIvEJ8IkWZzav61u38zT8fWOZ166d5D
KNj6OSOgvynTJdHUujPzxGUwEbxSDRLgMEmPB66KtVhMHI61XDQmsUcBy5pIPvZ8
dqARpJTywCdiK8Mj5w==
=3yd0
-----END PGP SIGNATURE-----
--=-=-=--