Re: Future Direction of GNU Hurd?

--0000000000007c1ba505af13e175
Content-Type: text/plain; charset="UTF-8"

Succinctly:
R.I.P.

On Fri, Sep 11, 2020, 19:53 Richard Braun <[email protected]> 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
>
>

--0000000000007c1ba505af13e175
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">Succinctly:<div dir=3D"auto">R.I.P.</div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Sep 11, =
2020, 19:53 Richard Braun &lt;<a href=3D"mailto:[email protected]">rbraun@sc=
een.net</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Sep =
11, 2020 at 11:52:02PM +0200, Paul Boddie wrote:<br>
&gt; Social factors: you will see plenty of inertia or what people used to =
call <br>
&gt; &quot;stop energy&quot; in the mailing lists. Just review the previous=
 messages on this <br>
&gt; list or look at recent messages on bug-hurd for examples. One gets the=
 <br>
&gt; impression that unless someone is either a top-level operating system =
<br>
&gt; architect and/or willing to burn themselves out fixing up huge amounts=
 of <br>
&gt; existing code or writing new code in precisely the way envisaged by ot=
hers who <br>
&gt; nevertheless aren&#39;t going to be writing any themselves, then new c=
ontributions <br>
&gt; are not really welcome.<br>
<br>
Well it doesn&#39;t need to be &quot;precisely&quot; the way those who aren=
&#39;t active<br>
at the time like me imagine it. Good surprises are welcome too, but those<b=
r>
are rare.<br>
<br>
You seem to imply one doesn&#39;t need to be &quot;a top-level operating sy=
stem<br>
and/or willing to burn themselves out fixing up huge amounts of existing<br=
>
code&quot; to work on something like the Hurd. While I&#39;m not personally=
 requiring<br>
&quot;top-level&quot; anything, I very, very, very strongly believe that a =
project that<br>
combines concurrency, virtual memory, and distribution, requires developers=
<br>
who care deeply about both the big picture and small details, and to me,<br=
>
that&#39;s usually what makes a top-level developer. Besides, considering h=
ow<br>
badly designed some critical parts of the code are, yes, it would require a=
<br>
lot of work to get that fixed. So yes, we need people with both great<br>
technical skills and very hard-working. That too is rare.<br>
<br>
&gt; I recently read an article about Linux kernel development where someon=
e <br>
&gt; actually wrote that if something or other made kernel development easi=
er or <br>
&gt; more accessible then it would be attracting the &quot;wrong kind&quot;=
 of people. Well, <br>
&gt; that would seem to be the view of some people in the Hurd development =
<br>
&gt; community, too, judging from recently expressed sentiments.<br>
<br>
That&#39;s absolutely not correct about the Hurd, however. I guess you&#39;=
re<br>
referring to me saying &quot;I don&#39;t want to work with people who give =
up<br>
because it takes them more than a few seconds to find information&quot;.<br=
>
Note that I&#39;m absolutely not implying to artificially make finding<br>
things hard. They just are, and I&#39;m not aware of any tool that grabs<br=
>
a big, old, fragmented code base like that of the Hurd, and makes it<br>
easy and quick to understand. Serious projects need the right kind of<br>
lazy people, those who try to do things well from the start to avoid<br>
wasting time fixing bugs and rewriting large code blocks, instead of<br>
the wrong kind of lazy people, who just give up quickly and are negligent.<=
br>
<br>
&gt; Of course, many other people in the wider world realise that successfu=
l <br>
&gt; projects require many different types of contributors in order to actu=
ally be <br>
&gt; successful, and judging by the increasing stagnation of what was a fai=
rly <br>
&gt; well-resourced and well-publicised project, I think we can guess whose=
 <br>
&gt; viewpoint is the more realistic of the two.<br>
<br>
Again, not correct. I said I didn&#39;t want &quot;someone not fit for the =
job&quot;<br>
and you&#39;re intepreting I don&#39;t want &quot;different types of contri=
butors&quot;.<br>
I also would like to know when the Hurd was well-resourced these last<br>
twenty years.<br>
<br>
Overall, you seem to claim that the Hurd would be better off with<br>
many mediocre developers than very few excellent ones. In addition,<br>
your argument makes a vague comparison between the Hurd, which is at<br>
its core an amibitious and technically difficult project, and other<br>
&quot;successful projects&quot; which are statistically far from being that=
<br>
difficult, not to mention the survival bias. Well I simply disagree,<br>
I&#39;d rather see the Hurd stagnate in a form that gives it a chance<br>
to take off again than evolve into a hopeless abomination.<br>
Productivity can be very low, even negative, i.e. doing more work<br>
fixing contributions than the work put in the contributions<br>
themselves. Fine-grained multithreading and parallelism/distribution<br>
in general are particularly prone to create such situations.<br>
<br>
In the end, those statements are morally charged misinformation,<br>
which is simply annoying.<br>
<br>
-- <br>
Richard Braun<br>
<br>
</blockquote></div>

--0000000000007c1ba505af13e175--