I'm new here but I have some thoughts on the Hurd and the GNU project. I have read the past emails on gnu-system-discuss as well as other related lists. My impression is that the GNU Project (the project to produce a GNU OS) has been stalled because of problems developing the Hurd. Many of the emails lately have suggested other problems plaguing the Hurd and the GNU OS. I began making a mental list of the problems and started thinking about a solution. My idea may not be original or may not be the best plan but I thought it might be good to post it. Perhaps it will lead to a better idea or further discussion of how to get the GNU Project moving again.
Here are the Problems I See: 0. There is no roadmap or plan of how the GNU OS will proceed 1. There is no clear chain of command for GNU OS or GNU Hurd 2. GNU OS is stalled waiting for a kernel 3. Without GNU OS releases, the entire project loses visibility and interest 4. GNU Microkernel needs improvement/completion/replacement 5. GNU Hurd Servers need improvement/completion/replacement 6. GNU Hurd needs modern Linux driver compatibility 7. GNU Hurd needs native own drivers (I'm not entirely clear on the correct terminology, so by microkernel, I refer to the underlying part of the Hurd such as gnumach or L4 and, by Hurd Servers, I mean the part of the Hurd that runs on top of the microkernel. By Hurd I mean the combination of both parts.) Solving problems zero and one should be the first priority. I'm going to propose my idea of a roadmap for the GNU OS and Hurd. It may be a bad plan, so feel free to poke holes in it and explain why it's wrong. On the other hand, perhaps it's a good idea but with flaws that need to be corrected. In that case consider this a rough draft of the plan and help me improve it. But for things to move forward, we need to find a plan we can agree on. I believe someone (I assume RMS?) needs to bless a plan and assign one person who will be in charge of things and make decisions. We have plenty of smart people working on the Hurd already and there appear to be many others who would work on it if they understood the plan and knew their effort would be useful. So it should not be hard to solve problem one by finding someone here who can coordinate a project like this. Problems 2 through 7 are solved in my proposed road map by releasing an initial version of the GNU OS that uses a 100% Linux kernel. Over time, we would transition to a 100% GNU Hurd kernel. This allows us to immediately resume work on the GNU OS and we can release a working version of the entire GNU OS very soon, perhaps within a year. My idea for the kernel transition is to go through several phases that would allow work to focus on specific tasks, each of which would move us closer to a 100% GNU Hurd kernel, while maintaining a completely usable GNU OS at each point in the transition. The phases of the kernel shipped in the GNU OS would look like this: Phase 1: Linux kernel + Linux drivers Phase 2: GNU microkernel (single server) + Linux + Linux drivers Phase 3: GNU microkernel (multiple server) + GNU Hurd Servers + Linux drivers Phase 4: GNU microkernel + GNU Hurd + GNU drivers Phase 1 solves the immediate problem of the GNU OS not having a kernel. So we can start working on actually putting together and releasing a complete GNU OS. My impression is that there is still a huge amount of work to do, even with a working kernel. But I think it might be possible to ship a full GNU OS within a year. During this time, whoever is in charge should make a formal, official decision as to which microkernel will be used for Hurd (gnumach, L4, coyotos, the rumored new microkernel, or whatever). This decision will need to be made on a technical basis and to do that, it seems there needs to be more discussion of what the technical requirements and problems are. This leads us to Phase 2, where we do something similar to the L4Linux project; we create a single server Linux running on top of the selected GNU microkernel. Once stable enough, this goes into the GNU OS distro where it can be used heavily by real users. This sort of real world use should help improve the microkernel and identify any bugs. This exercise may also help identify ways in which the Hurd can improve on Linux. Meanwhile, kernel programmers can now focuses on Phase 3: getting the Hurd servers running on top of the selected GNU microkernel. A Linux driver layer would be added here also. Once this becomes stable enough, the Hurd goes into the GNU OS distro for real world use. At this point the GNU OS would no longer need the Linux kernel itself, but would still rely on Linux drivers. This would be the point at which we can begin to demonstrate the Hurd's potential to be better than Linux. The kernel programmers can now move on to creating GNU-specific drivers to replace the borrowed Linux drivers. This brings us to Phase 4, a GNU OS that's 100% Linux-free. This will likely be at least several years after the phase 1 GNU OS has shipped, which means we will already have a sizable installed user base waiting to upgrade and enjoy the 100% GNU Hurd version of the GNU OS. The beauty of this is plan, as I see it, is that it would allow work to resume on the GNU OS right away and should lead to a working distro that can be installed, used, and improved. GNU OS improvements can continue as the kernel evolves from 100% Linux to 100% Hurd. And the fact that the FSF is making regular releases of a complete working OS should result in greatly increased visibility, increased interest, and more programmers volunteering. -Steve http://advogato.org/person/StevenRainwater/
