Re: Aw: Re: Reviewing Hurd-on-L4 (and considering its future?)

[Paul Boddie]

[Reply addresses trimmed]

On Thursday 24. May 2018 11.45.41 Nala Ginrut wrote:
> Hi all!
> I'm glad to see there's still people interested in keeping improving
> Hurd with L4 family.
> 
> Personally, I don't think "free OS kernel" is still the key reason why Hurd
> exists today. Because it is one of the free OS kernel of GNU OS now
> (with less users), it's the true fact. In this context, RMS is right and
> reasonable, if we just want to do more contribution to respect people's
> freedom, it's better to contribute to other urgent project.

If the question is "I know how to program, don't have any particular 
interests, fancy the idea of contributing to something, should I contribute to 
Hurd development or something else?" then a reply that suggests that such a 
person contribute to more "urgent" projects is not unreasonable. I must say 
that a better answer is to suggest that such a person cultivate their own 
interests and then work on something that motivates them.

Indeed, parachuting into PDF reader development might well be frustrating and 
demotivating, particularly since (from my observations of the PDF tool domain) 
there are plenty of users who will constantly demand improvements at no cost 
from Free Software projects whilst running their businesses on such programs. 
(Proper funding for Free Software is just another interest of mine.) And it 
is, of course, possible that a newcomer just doesn't find document formats and 
layout to be engaging topics.

> The key reason to me is "a better free OS kernel". Linux is very
> successful, and I use it everyday. I'm interested in Hurd not because
> Linux is not free enough, but because I want to see a better free OS
> kernel. Is Linux perfect? Of course no. Is it possible to provide better
> features in the current Linux architecture? I don't think so. For such
> reason, why not give microkernel another chance?

Here I agree with you. I've been using GNU/Linux for over twenty years in 
various situations, and I'm sure others have been using it for even longer. It 
works very well as a practical solution. But there are technical and social 
reasons for exploring other options.

The social reasons have become more obvious in recent years, with observations 
about the way contributions are handled by various parts of the Linux effort, 
the behaviour of people having authority in that effort towards others, and so 
on. Having seen some of this from just reading mailing lists, it is clear that 
the organisational architecture of Linux development contributes to such 
problems.

The sustainability of solutions is also a concern of mine. I got into looking 
at L4 because I have old hardware lying around that cannot run recent Linux 
kernels. While many people might denigrate such systems as being obsolete, 
having miniscule amounts of memory, poor display resolutions, and so on, this 
doesn't mean that they might not be usable for some purpose.

And why shouldn't systems retain a level of software support over decent 
amounts of time, anyway? Why should people have to throw things away because 
some kernel developers decided to "rearrange the furniture"?

> Personally, I'm interested in seL4. Because it's formal verified, which
> is proved to be safe in math.

Certainly, seL4 is interesting. However, I have been using Fiasco.OC because 
it has been ported to the MIPS architecture. I guess it shouldn't matter too 
much in the end, but I don't have the necessary overview with regard to L4 
kernel interoperability, and it might be the case that seL4 lacks features 
that Fiasco.OC provides (and the other way round, of course).

> I think if we start yet Hurd-on-L4, it should be rewritten from
> scratch. And the aim is not to replace Linux or Hurd, but yet another
> alternative to free kernel.

My personal objectives have been to just gain experience with existing L4 
userspaces, with L4Re being the most convenient to try because it is 
distributed with Fiasco.OC. By exploring how various features might be 
implemented, I think it would be interesting enough to see if there are 
parallels between Hurd-on-Mach and what might be developed along this other 
path. Naturally, looking at existing work would help to inform development 
decisions.

I don't envisage trying to cover the broad spectrum of existing functionality 
in one big effort. That kind of thing would be costly and have a substantial 
risk of failure. Instead, an organic approach would be taken. Indeed, it seems 
to me that a benefit of microkernel-based systems should be to allow people to 
participate in activities that might be less accessible with other systems...

> Arne Babenhauserheide writes:
> > 
> > While I see the Hurd as great progress towards improving the Free
> > Software solutions by making it much easier to hack low-level
> > components, this does not replace existing proprietary lock-in. So in
> > this, judging from existing information without taking unproven
> > assumptions, RMS is right, because we did not demonstrate yet that it is
> > easier to develop drivers on the Hurd than on Linux.

...so that instead of having to learn today's framework for device drivers in 
Linux (and then aim to get work upstreamed in the hope that someone might port 
it to tomorrow's framework), one might be able to achieve something by writing 
programs in one of the L4 userspace environments, which admittedly also 
involves frameworks but under fewer constraints, and then build on top of such 
things later.

None of this would prevent obsolescence, but clearer boundaries between 
components and more stable APIs might at least provide the means to deal with 
change in a better way. I'm sure microkernel and component-based systems 
advocates have been saying such things all along.

Another reason for exploring things like L4 in this way is that it could lead 
to other kinds of systems being developed, just because the general 
availability of usable components might then make other efforts more 
approachable. Over the years, there have been people wanting to do OpenVMS and 
OS/2 clones on top of L4 microkernels, for instance.

Paul