Re: Future Direction of GNU Hurd?

[Richard Braun]

On Sat, Sep 12, 2020 at 02:25:57PM +0200, Paul Boddie wrote:
> Let's be honest with ourselves here: no top-level OS architect is likely to 
> roll up and work on the Hurd at this point, partly because they will have 
> their own interests which don't intersect with the visions of the project, or 
> perhaps they have already realised the visions of the project that interest 
> them.

OK let's clear up this idea of "top-level OS architect". I just want people
who are right for the job. For projects like the Hurd, they're usually good
students with the right kind of mind. It happened multiple times in the past
and it could happen again. Google summer of code is a good catalyst for that.

> After all, despite the almost singular emphasis in advocacy around the 
> project 
> of translators being the Hurd's most compelling feature, which seems like a 
> hard sell to most people these days, there are other systems that have 
> implemented configurable namespaces and other related features over the 
> years. 
> Bell Labs managed to do at least two of them in all this time, but such 
> systems tend to get dismissed because they weren't "done right" or whatever 
> excuse tends to be offered to pursue the usual turf wars and factionalism.

Translators aren't just about that and yes, people have a hard time to see
what they're really for, which is really providing arbitrary interfaces at
the file system level without special privileges. I'm still hopeful some kind
of killer app could emerge over time to showcase that feature.

> It certainly is challenging to work with concurrent systems, and I can say 
> from personal experience that it can be very frustrating. Generally, though, 
> people can only get to the point of being a "top-level developer" by learning 
> from others and collaborating with them. And on a particular code base, they 
> need opportunities to become familiar with that code, which will necessarily 
> involve actually writing, testing and debugging that code.
> 
> If you don't provide opportunities for people to get to the right level, and 
> in practice precisely no-one will be - because even an expert will not be 
> familiar with the code, particularly with the documentation available - then 
> it is like you are waiting for some very generous experts to show up and get 
> their hands dirty for no other reward than the hassle involved and the vague 
> possibility of a somewhat better system down the road. Or to use a sports 
> metaphor, the talent development strategy of this particular team would 
> appear 
> to be to neglect the development of players already with the team, instead 
> expecting that the league's big-name players will show up and offer to play 
> for free.
> 
> And that brings me nicely to a point about expecting volunteers to show up 
> and 
> burn out on doing what would really be paid work in other contexts. Quite why 
> people should emphasise their ethics around Free Software, only to advocate 
> the abandonment of ethics around treating people decently and making sure 
> that 
> paid work is actually paid, remains one of the biggest contradictions of the 
> Free Software movement.

Wow you're going way too far with this. First, we're not waiting for fully
trained experts to do the job. Again, it's really about the right kind of
mind, in particular someone who is able to both create an accurate big
picture of how things work and are supposed to work in their mind, and
at the same time pay extreme attention to the tiniest detail to avoid
rare corner cases as much as possible. They also would have to be motivated
enough to just look up things for themselves instead of waiting for others
to put that in their mouth.

I was initially quite opposed to Almudena Garcia in particular because of
his very obvious disdain concerning what I would call "doing things right"
where what he really wanted was "getting things to work", at the same time
dismissing my whole 20 years of system programming experience despite
being a clueless inexperienced student. He seems to have changed since then
but I cannot make sure why. It could be because he's stuck and is trying
to comply with those who could help him to get their help, or because he
starts to really understand the value of good coding rules and paradigms
on a more "philosophical" level. It could be some other reason I'm not
thinking of. I'm using him as an example only, he's just the most recent
person to make that mistake and clearly not the first. And I can't waste
the precious free time I have with someone who's not willing to fully
commit in order to learn when I don't even have time to work on my own
projects. Again, I want someone whith the right kind of mind for the job.
As perfect examples of what I'm referring to, I will mention Justus
Winter, who worked a lot on the project and single-handedly solved some
of the worst problems that plagued the system for the longest time, and
Agustina Arzille, whose work was smaller in scale but nonetheless of
excellent quality. They're clearly not "big-name players", but they're
the perfect kind of contributors the project could use.

Finally, noone is implying to "burn out" on the job. One huge advantage
of FOSS projects is that there is absolutely no obligation to work.
So those questions of getting paid or whatever else you're referring to
here really don't apply. I'm going to completely dismiss that comment
about the free software movement since, despite it being a GNU project,
the people who work(ed) most on it are clearly not zealous free software
advocates. Again that just doesn't apply. If your point is decency, I
don't see where I or anyone else hasn't been decent. We're not expecting
someone to just show up and do perfect work, we're hoping for it. If they
don't, so be it, and if they quit, like almost everyone except Samuel
did in the past, it's perfectly fine. Not great for the project but hey,
thanks for the contributions and good luck with whatever's next. The only
exception would be Svante Signell who's the main reason for me not working
on the project any more [1].

> So why are you so against people improving the Web site and documentation?

I'm not. See [2]. Again, I'd like the right kind of person for the job.
Someone who understands that a mere website isn't going to "save" the
project.

> Some projects might generate reference documentation using automated tools. 
> That would only be a start, however: where projects try and use reference 
> documentation as the primary means of communicating the details of a system, 
> they tend to fail to communicate architectural details, and other kinds of 
> documentation just tend to get lost or obscured. Documentation is chronically 
> undervalued in the software development profession, although I feel that I 
> might be wasting my time making that point in this discussion.

Have you looked at my own projects and how I do documentation ? You either
didn't read my messages, or got a very twisted impression of what I was
trying to convey.

> I can understand that no-one wants to spend time interacting with people who 
> like the idea of contributing to a project but who don't have the skills or 
> patience to perform certain kinds of tasks. But a project like the Hurd - a 
> large-scale software project - has requirements beyond people working on 
> fixing bugs and rewriting large code blocks.

I completely agree. Again, it's all consistent with "the right person for
the job".

> Well, to respond to your last remark, there was a considerably larger amount 
> of interest and list traffic in previous years, meaning that some people must 
> have had time and energy to pursue matters related to the Hurd. Furthermore, 
> the Free Software Foundation was still directing people towards the project 
> and must have offered some kind of assistance. If you are saying that they 
> didn't pay anyone then I can only refer back to my point about volunteer 
> culture in Free Software.

Interest is what contributors put into the project themselves. In all my
years involved with the projects (since roughly 2005), I have never seen
any influence from the FSF at all. The Hurd is really a regular FOSS
project, with additional constraints from the FSF such as copyright
assignment and no clear leadership. It's really all driven by contributors.

> Actually, I am claiming that a more diverse range of contributors would be 
> beneficial for the Hurd, taking into consideration more than just developers 
> fixing up the code as it is today. And even within the realm of development, 
> I 
> cannot really see why there cannot be a range of different levels of 
> developer. After all, much of the software development going on in the wider 
> world encompasses a range of tasks from those which are technically and 
> intellectually challenging through to mundane tooling and maintenance.

I completely agree with that, and don't recall saying the opposite. It
goes back to the criticism in my previous message about mistaking "someone
not fit for the job" with "different types of contributors".

> I actually doubt that all of the development tasks related to the Hurd are 
> the 
> most challenging kind, and if they do happen to be so, then it says quite a 
> bit about the viability of the project and the architecture of the system. 
> One 
> benefit of a microkernel-based system should be that certain components 
> should 
> actually be more approachable because you can write them as "normal" programs 
> and not necessarily be subject to particularly onerous constraints (although 
> there will always be challenges of certain kinds). This particular benefit 
> has 
> never seemed to be worth communicating with regard to the Hurd, suggesting 
> that the project has either undervalued it or the software architecture fails 
> to leverage or deliver such a benefit.

Well I'm not going to replay the Torvalds-Tannenbaum debate here. My
personal opinion is that a multi-server system is actually more complex
than a monolithic system. Thinking that developing servers is easier just
because they can be written as "normal" programs is often a fallacy, since
it doesn't apply to servers involved in bootstrapping the system, or those
involved in debugging, directly like process execution, or indirectly like
file systems. However, I agree that it "ssays quite a bit about the
viability of the project and the architecture of the system". The Hurd
has some implementation and intermediate-design issues (signal handling
comes to mind) that should be entirely revamped and could make life a lot
easier. That's why I said in my previous message that "considering how
badly designed some critical parts of the code are, yes, it would require a
lot of work to get that fixed".

> As for the "survival bias" remark, what you are saying that the bulk of 
> software development isn't challenging and so recommended practices somehow 
> don't apply here. What I was saying is that established practices for the 
> development of systems tend to emphasise the involvement of many different 
> roles. Naturally, small-scale systems can have a few people doing everything 
> and even neglecting various roles if they have everything they need to know 
> in 
> their own heads. This doesn't scale up to large and/or complicated systems, 
> necessitating the involvement of people who take on distinct roles that may 
> have little to do with the most challenging development tasks.

I didn't say that recommended practices don't apply. On the contrary,
it is because the Hurd is noticeably more difficult than most projects
that recommended practices are that more relevant. Again, that answer
refers to your mistake interpreting me saying "someone not fit for the job"
and understanding that I somehow wouldn't want "different types of 
contributors".

> Given that people can do whatever they like with the code and the original 
> non-hopeless code will remain available, what would appear to be missing, 
> then, is a constructively formulated plan that would take the system in what 
> would supposedly be the right direction.

I wouldn't want to see a lot of good work wasted because it got too
tightly coupled with bad work. To an extent, the whole project is already
in that state.

> Yes, certain development tasks and situations are challenging. The other 
> issues are simply project management issues. If someone improving the Web 
> site 
> and documentation is somehow driving down productivity of the "top-level 
> developers" then, well, you are doing it wrong.

I've never said or implied that. That's mere extrapolation from your
previous misunderstandings.

> All I noted were the sentiments expressed about the kind of contributors that 
> would appear to be welcome in the project, and you have pretty much confirmed 
> that this is your position. So, I think that "morally charged misinformation" 
> must be another way of saying that you don't agree with me, which is fine, 
> and 
> that you don't appreciate me pointing things out.
> 
> But since I merely aimed to give the original enquirer some idea of the state 
> of the project and to temper his expectations, I think I have been fairly 
> accurate and hopefully of some assistance.

I disagree. "Morally charged misinformation" referred to the fact that you
didn't get your facts straight and offered moral judgment to newcomers from
those invalid facts, such as how we wouldn't be behaving decently, or that we
somehow wouldn't want diffrent types of contributors.

And no, you're not accurate. You're almost implying that Hurd developers
are too dumb to make a switch to an L4 based kernel because they're
drama queens. The truth is simply that there is too little manpower to
make such a switch, and too little interest *overall* in the project.
It's not about L4 at all.

To better answer Marc, one should say that the Hurd is really in a state
of "survival", with one committed contributor (Samuel Thibault), and
occasional contributors coming and going. And because Samuel considers
himself a maintainer and not a leader, there is no direction for the
project. As I said, it's entirely contributor-driven. So target something
you like and work on that, it's really that simple.

-- 
Richard Braun

[1] https://lists.gnu.org/archive/html/bug-hurd/2017-01/msg00017.html
[2] https://lists.gnu.org/archive/html/bug-hurd/2020-08/msg00119.html