[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Future Direction of GNU Hurd?

From: Olaf Buddenhagen
Subject: Re: Future Direction of GNU Hurd?
Date: Sun, 14 Mar 2021 18:56:17 +0100
User-agent: NeoMutt/20170609 (1.8.3)


On Thu, Feb 25, 2021 at 06:00:13PM +1100, William ML Leslie wrote:

> The hurd-ng project, to the extent that there remains a project, is
> really very open ended.  Any sufficiently motivated person who came
> along could make whatever they wanted to with it.  As long as they
> follow the license of any code they use, they can make it into
> anything they like.  They don't have to agree with the opinions of
> Shap or myself, they are free to make decisions that would make Thomas
> Bushnell look down his nose at them, and are free to ignore the
> opinions of Samuel or Richard.
> But the one thing that stands out to me from the open source community
> is that every time someone tells you what you should or shouldn't be
> building, you can feel free to loudly ignore them.

Woah, calm down. Of course you are free -- and generally encouraged --
to work on any kind of system you like. (As long as you don't call it

Indeed I'm myself contemplating a design that is inspired by the Hurd in
some ways, but diverges significantly in others...

Having said that, keep in mind that this list is owned by the Hurd
project. You are entitled to disagree: but saying that the opinions of
Hurd developers don't matter, is frankly just rude.

> nor am I going to justify decisions I've made in a new project I
> started in September.

Of course you don't have to justify the decisions you make in your own
project. However, if you are bringing them up on this list, I'd hope you
would be willing to explain what makes you like one approach over
another: considering that this is basically the whole point of the
discussions here...

> You can probably tell from my previous email that I'm still kind of
> mired in low-level nonsense at this point and don't have anything
> useful to share about it.

Well, I wouldn't call it nonsense... Though for my project, I decided to
go a different route: mostly focusing on high-level aspects for now --
only considering lower-level implementation details when they come up
while thinking about other aspects. And when I'll start the
implementation, I'll go with low-effort approximations based on existing
systems first, leaving a native implementation for later.

Of course this way I'm taking a risk that some of the things I'm
envisioning for the low-level mechanisms turn out not to be viable, and
I'll have to revamp major aspects of the system... But at least I'm
avoiding the risk of getting bogged down in low-level details, and never
getting to the interesting parts -- like so many other projects...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]