[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
