Re: A proposed Roadmap

[R. Steven Rainwater]

On Thu, 2007-09-06 at 11:47, Michael Heath wrote: 
>         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. 
> 
> The more I think about this idea, the more I like it. I suggested it
> in another thread, infact, before reading your comments here. I think
> its important to get a complete, releasable operating system, and
> thats not possible with the current kernel, and may not be possible
> for a very long time. 

Thanks for reading and commenting on my suggestions. I realized when I
posted it that there may be problems with my plan. I have been reading
the list archives, trying to educate myself on where things are with the
GNU OS and the Hurd but there is little recent information on the GNU OS
and the history of the Hurd is confusing for someone coming to the
project for the first time.

I discussed my plan on #hurd briefly today and one person said when they
read it, it looked like I was saying "Phase 1. Magic happens, Phase 2.
More magic happens, Phase 3. Profit". :-) I think this is a common
complaint with high-level plans though, since they usually leave out
many technical details.

One concrete problem with my idea pointed out on #hurd is that Linux and
the Hurd are not binary compatible, so the transitions between my
suggested phases would not be simple upgrades. After thinking about
this, however, I'm not sure it's a very big problem. I run CentOS on our
servers and they have a simple policy regarding binary compatibility
between upgrades: minor version changes such as 4.1 to 4.2 are
guaranteed to be binary compatible; major version changes such as 4.5 to
5.0 are not guaranteed to be binary compatible.

The 4 phases I proposed are the major changes. There would likely be
years and many minor versions of the GNU OS between each. So those
interim versions of the GNU OS could be kept binary compatible. The 4
phases would be the major version changes without binary compatibilty.

As I talked with the developers on #hurd I also got the impression that
there may be another problem with the idea of using the Linux kernel for
the GNU OS. I'm not sure exactly what the problem is but it does not
appear to be technical or legal in nature so much as political.


>         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 
> 
> Here is really where I start to disagree with you. Phase  1 is fine,
> and is just what we've discussed - using the Linux kernel. 
> 
> However, while projects like L4Linux do have some advantages over
> conventional linux systems, it really isn't a 'stepping stone' along
> the way for moving from Linux to Hurd+microkernel. It wouldn't do much
> good. I'm not sure what the point of Phase 2 would be. 

You may be right. My thinking was that there are two pieces to the Hurd
which need to be made to work well. One is the microkernel. Using the
microkernel in single server mode as a base for linux puts the
microkernel into real-world use without the need to have the entire Hurd
working. I thought this would help give us a very stable, production
ready microkernel while the upper parts of the Hurd are being developed.
If it doesn't produce any benefit for the development process, this
phase could be dropped, of course.

> Phase 3 and 4 are logical, but I'm confused about your distinction
> between Linux Drivers and GNU drivers. 

I probably used incorrect terminology to describe my idea. The current
version of Hurd relies on drivers borrowed from Linux (or on driver code
borrowed from Linux drivers). I'm assuming the version of Hurd referred
to in phase 3 of my roadmap would similarly rely on Linux drivers (or
their code).

I had the impression from what I've read on this list, that one of the
long term goals is to make Hurd work without the need to borrow parts of
Linux. So while my phase 3 provides a working Hurd for the GNU OS, work
would continue on native drivers that were not borrowed from Linux but
designed specifically for the Hurd. In my Phase 4, the GNU OS would be
shipped with these native Hurd drivers instead of the borrowed Linux
drivers.

> Yes, drivers need to be created, but the goal should be to make
> drivers that work WELL, whether they do that by using Linux code or
> not, and not to make an exclusively GNU driver. 

Then phase 4 could be dropped. I probably misunderstood some of the
discussion about using Linux driver code in the Hurd.

> However, I think the main complaints about a missing roadmap in the
> other threads have been referring to one specific to the particulars
> of continued development on the Hurd+microkernel. 

I agree a detailed roadmap for the Hurd is also needed but I don't know
enough about the Hurd and microkernels to create such a roadmap. My main
interest lies in seeing the GNU OS as a whole moving forward again. My
thought was that if we could develop a broad plan for getting
development of the GNU OS going again, we could then work on a detailed
plan. I think if we had such a plan and a person or persons to work on
implementing the plan, we might hope to see a GNU OS release someday
soon.

-Steve