Jonathan S. Shapiro <[email protected]> writes: > On Mon, Sep 14, 2020 at 11:46 PM Dr. Arne Babenhauserheide <[email protected]> > 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
