A proposed Roadmap

[R. Steven Rainwater]

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/