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 > >
