help-hurd
[Top][All Lists]
Advanced

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

Re: Future Direction of GNU Hurd?


From: Theodore M Rolle, Jr.
Subject: Re: Future Direction of GNU Hurd?
Date: Fri, 11 Sep 2020 21:39:51 -0400

Succinctly:
R.I.P.

On Fri, Sep 11, 2020, 19:53 Richard Braun <rbraun@sceen.net> wrote:
On Fri, Sep 11, 2020 at 11:52:02PM +0200, Paul Boddie wrote:
> Social factors: you will see plenty of inertia or what people used to call
> "stop energy" in the mailing lists. Just review the previous messages on this
> list or look at recent messages on bug-hurd for examples. One gets the
> impression that unless someone is either a top-level operating system
> architect and/or willing to burn themselves out fixing up huge amounts of
> existing code or writing new code in precisely the way envisaged by others who
> nevertheless aren't going to be writing any themselves, then new contributions
> are not really welcome.

Well it doesn't need to be "precisely" the way those who aren't active
at the time like me imagine it. Good surprises are welcome too, but those
are rare.

You seem to imply one doesn't need to be "a top-level operating system
and/or willing to burn themselves out fixing up huge amounts of existing
code" to work on something like the Hurd. While I'm not personally requiring
"top-level" anything, I very, very, very strongly believe that a project that
combines concurrency, virtual memory, and distribution, requires developers
who care deeply about both the big picture and small details, and to me,
that's usually what makes a top-level developer. Besides, considering how
badly designed some critical parts of the code are, yes, it would require a
lot of work to get that fixed. So yes, we need people with both great
technical skills and very hard-working. That too is rare.

> I recently read an article about Linux kernel development where someone
> actually wrote that if something or other made kernel development easier or
> more accessible then it would be attracting the "wrong kind" of people. Well,
> that would seem to be the view of some people in the Hurd development
> community, too, judging from recently expressed sentiments.

That's absolutely not correct about the Hurd, however. I guess you're
referring to me saying "I don't want to work with people who give up
because it takes them more than a few seconds to find information".
Note that I'm absolutely not implying to artificially make finding
things hard. They just are, and I'm not aware of any tool that grabs
a big, old, fragmented code base like that of the Hurd, and makes it
easy and quick to understand. Serious projects need the right kind of
lazy people, those who try to do things well from the start to avoid
wasting time fixing bugs and rewriting large code blocks, instead of
the wrong kind of lazy people, who just give up quickly and are negligent.

> Of course, many other people in the wider world realise that successful
> projects require many different types of contributors in order to actually be
> successful, and judging by the increasing stagnation of what was a fairly
> well-resourced and well-publicised project, I think we can guess whose
> viewpoint is the more realistic of the two.

Again, not correct. I said I didn't want "someone not fit for the job"
and you're intepreting I don't want "different types of contributors".
I also would like to know when the Hurd was well-resourced these last
twenty years.

Overall, you seem to claim that the Hurd would be better off with
many mediocre developers than very few excellent ones. In addition,
your argument makes a vague comparison between the Hurd, which is at
its core an amibitious and technically difficult project, and other
"successful projects" which are statistically far from being that
difficult, not to mention the survival bias. Well I simply disagree,
I'd rather see the Hurd stagnate in a form that gives it a chance
to take off again than evolve into a hopeless abomination.
Productivity can be very low, even negative, i.e. doing more work
fixing contributions than the work put in the contributions
themselves. Fine-grained multithreading and parallelism/distribution
in general are particularly prone to create such situations.

In the end, those statements are morally charged misinformation,
which is simply annoying.

--
Richard Braun


reply via email to

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