Re: A proposed Roadmap

[Sprink]

This sounds like a wxcellent idea to me. Using linux to make the
transision sounds like a very logical solution to most of the problems
the hurd currently has.

I hope others see your idea working as well as I do.


On 9/5/07, R. Steven Rainwater <address@hidden> wrote:
> 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/
>
>
>
>
>
>
>