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/

[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 <srainwater@...> 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/
>
>
>
>
>
>
>

[R. Steven Rainwater]

Thanks Sprink, but I don't think many people here found my idea
interesting. I got several off list emails saying it was a good idea but
otherwise it was pretty much ignored. I wonder if there is a GNU mailing
list that is specifically about the GNU OS as whole as opposed to just
the Hurd where my post would be more appropriate? Anyone know? I've
looked on the GNU website but didn't find any indication that anyone is
even working on an official release of a GNU OS anymore.

-Steve

On Wed, 2007-09-05 at 13:42, Sprink wrote:
> 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 <srainwater@...> wrote:
> > I'm new here but I have some thoughts on the Hurd and the GNU project.

[Michael Heath]

There is such a list; you are posting on it.

But, yeah, as far as I know no one is working towards an official release of the GNU OS. Closest thing is some snapshots/images people occasionally put together. I somehow missed your earlier e-mail; I'm going to read it and reply in a bit.

By the way: Why do people so often insist on responding off-list? Silly.

Mike Heath.

On 9/6/07, R. Steven Rainwater <srainwater@...> wrote:

Thanks Sprink, but I don't think many people here found my idea
interesting. I got several off list emails saying it was a good idea but
otherwise it was pretty much ignored. I wonder if there is a GNU mailing
list that is specifically about the GNU OS as whole as opposed to just
the Hurd where my post would be more appropriate? Anyone know? I've
looked on the GNU website but didn't find any indication that anyone is
even working on an official release of a GNU OS anymore.

-Steve

[Michael Heath]

Thanks, Steven. I've included my replies/responses inline with quotations from your plan:

On 9/5/07, R. Steven Rainwater <srainwater@...> wrote:

[...] 

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 agree entirely with your list of problems. 

[...]

Solving problems zero and one should be the first priority.

Solving the roadmap and the organizational problems are the critical thing we need for success; creating a roadmap is probably going to be easier than creating a good organizational development structure, as we lack enough skilled people that would be good at the task.

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.

There has been wide disagreement against that kind of statement. While yes, there are a lot of intelligent people potentially able to help, the consensus seems to be that it needs to  be someone already involved and intimately familiar with the Hurd+Mach to work on that.

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.

Over time,
we would transition to a 100% GNU Hurd kernel.

Once again, I agree. While Linux would fill a temporary void, I feel that the Hurd and a micorkernel are/could be better in a variety of ways. It just needs lots of work and improvement between now and then.

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.

Phase 3 and 4 are logical, but I'm confused about your distinction between Linux Drivers and GNU drivers. GNU Mach already uses a lot of (old) Linux kernel driver code; this doesn't mean that its 'compatible with linux drivers', and it would be impossible to make it completely compatible with all Linux drivers.

If we do spend the time to port driver code from Linux to Hurd+microkernel, why do we need to replace that, assuming it works well?

I don't think theres a big distinction between Linux Drivers and GNU drivers in this sense. 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.

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.

I agree entirely. Your roadmap is a general, broad one I  can mostly agree with for the GNU  Operating system releases. 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.

That being said, I like your ideas, plan, and I interested on seeing what other people think about using Linux as the official GNU kernel while the Hurd is improved.

Michael Heath

[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

[olafBuddenhagen]

Hi,

On Wed, Sep 05, 2007 at 01:07:26AM -0500, R. Steven Rainwater 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. 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.

As I already said on IRC, this suggestion is totally out of the question
IMHO.

There is just no point in releasing the GNU system based on Linux, to
compete against the hundreds of existing GNU/Linux distributions. And
once it would be release with Linux, it would be virtually impossible to
switch -- nobody would dare to go from a limited but perfectly working
kernel to something rough and incomplete. There would be absolutely no
chance of moving over to Hurd unless it's almost perfect -- but that
won't ever happen, as with the GNU system already released with Linux,
there would be even less inclination for people to work on the Hurd.

The GNU system would be totally irrelevant as just yet another GNU/Linux
distribution, and the Hurd would be marginalised even more -- a perfect
loss-loss situation.

Really, there is absolutely no point in releasing the GNU system with
Linux as the kernel. It would bring no good at all.

> 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.

That doesn't work. Mach also was tested for a long time with
single-server systems. The real problems showed only when people
actually tried building proper (multiserver) microkernel systems on top
of it.

-antrik-

[olafBuddenhagen]

Hi,

On Thu, Sep 06, 2007 at 10:47:54AM -0600, Michael Heath wrote:

> Phase 3 and 4 are logical, but I'm confused about your distinction
> between Linux Drivers and GNU drivers. GNU Mach already uses a lot of
> (old) Linux kernel driver code; this doesn't mean that its 'compatible
> with linux drivers', and it would be impossible to make it completely
> compatible with all Linux drivers.
>
> If we do spend the time to port driver code from Linux to
> Hurd+microkernel, why do we need to replace that, assuming it works
> well?
>
> I don't think theres a big distinction between Linux Drivers and GNU
> drivers in this sense. 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.

Well, I'm not so sure about it. Of course, reusing existing drivers
would save the Hurd an *enormous* amount of maintenance. Yet we might
want native drivers in the long run.

Of course, as long as drivers run in a boring old-fashioned framework
like they do in gnumach, there is no point in rewriting them. But when
we have full control over the drivers, we can do much more interesting
things with them: We can create a framework that integrates the drivers
better with the rest of the system, running them as more or less
ordinary translators.

In fact, I believe half of the potential power of the Hurd architecture
is wasted without such a well-integrated approach to drivers...

-antrik-

[R. Steven Rainwater]

On Thu, 2007-09-06 at 18:10, olafBuddenhagen@... wrote:

> On Wed, Sep 05, 2007 at 01:07:26AM -0500, R. Steven Rainwater 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. 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
>
> There is just no point in releasing the GNU system based on Linux, to
> compete against the hundreds of existing GNU/Linux distributions. And
> once it would be release with Linux, it would be virtually impossible to
> switch -- nobody would dare to go from a limited but perfectly working
> kernel to something rough and incomplete. There would be absolutely no
> chance of moving over to Hurd unless it's almost perfect -- but that
> won't ever happen, as with the GNU system already released with Linux,
> there would be even less inclination for people to work on the Hurd.

I've thought about this more today and I still disagree with that view.
IMHO of course and, if I'm wrong, it wouldn't be the first time. :)  I
think the reason there are not more programmers inclined to work on the
Hurd or, more importantly to me, the GNU OS, is because there are no
releases. The general perception in the outside world is that it's dead.
I think a release of the GNU OS, with any kernel: Hurd, Linux, even a
BSD kernel, would generate increased interest in the GNU OS and Hurd and
cause more programmers to be inclined to work on it.

No one expects early releases of an OS or a kernel to be production
ready. What if Linux distros were not released until they were
prefected? Fedora Core 1 sucked badly. Fedora Core 2 sucked less. The
Fedora 7 running on my laptop today is mostly very nice but still sucks
in a few areas. By making regular releases, though, there is a
pereception that Fedora is always improving and a perception that it's
an active project I might want to participate in.

Imagine if RedHat had said, "There's no point in releasing Fedora Core
1. Let's keep working on it until it's better than Ubuntu and then
release it." That would be silly. The problem is all those Linux distros
are going to keep making releases and keep getting better. I think the
longer we wait to release a GNU OS, the further behind we fall. Let's
just jump out there and start competing!

A GNU OS version 1 (or 0.1 or 0.01) is going to suck no matter what
kernel we put in it, but at least we'll have made a start. And once
people see that, I think it will bring lots of new people to help and
the rate of improvement will increase.

Reading about the history of the The GNU OS reminds me of a Doctor Who
episode. It's been years since I saw it so I may have the story a little
out of whack but it went something like this...

A spaceliner became lost and crashed on an unpopulated planet. The
surivors decided they must repair their spacecraft, launch it, and
achieve their freedom. So they started working on the ship. When the
doctor arrived on the planet, he discovered that generation upon
generation of the descendents of the original crash survivors had worked
on the spacecraft for thousands of years, trying to get it to the point
it was ready to launch.

As he watched them work, the doctor realized the engineers had replaced
the idea of repairing the ship with the idea of perfecting the ship. It
had been able to launch and leave the planet for a long time. But as
long as the engineers saw any imperfection in its design, they kept
everyone in dark and forced them to keep working on it, until the great
day in distant future when they would launch the perfect spaceship. The
doctor, of course, revealed the truth to the people. They overthrew the
engineers and launched the ship.

I think we need a Doctor Who of OS design to sort out the GNU project.
Maybe a little work with the sonic screw driver is all the Hurd needs.
:-)

> That doesn't work. Mach also was tested for a long time with
> single-server systems. The real problems showed only when people
> actually tried building proper (multiserver) microkernel systems on top
> of it.

Understood. It seems that phase of my idea is simply not helpful or
necessary, so it should be eliminated.

-Steve

[Michael Heath]

On 9/6/07, olafBuddenhagen@... <olafBuddenhagen@... > wrote:

Hi,

On Wed, Sep 05, 2007 at 01:07:26AM -0500, R. Steven Rainwater 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. 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.

As I already said on IRC, this suggestion is totally out of the question
IMHO.

First, please remember that a good number of people subscribed to this list and replying to discussion on it are not in whatever IRC channel you're talking about. If there is a relevant discussion or opinion, write it/re-write it here, don't just talk about it like the matter is settled and done without ever talking about the matter.

There is just no point in releasing the GNU system based on Linux, to
compete against the hundreds of existing GNU/Linux distributions. And
once it would be release with Linux, it would be virtually impossible to
switch -- nobody would dare to go from a limited but perfectly working
kernel to something rough and incomplete. There would be absolutely no
chance of moving over to Hurd unless it's almost perfect -- but that
won't ever happen, as with the GNU system already released with Linux,
there would be even less inclination for people to work on the Hurd.

If you notice, you call these operating systems GNU/Linux. Why? Because they are theoretically _based on the GNU operating system_. GNU would not be competing with these things, it is what all of these things have in COMMON. Providing a consistent base operating system would allow for greater compatibility and continued innovation in the GNU operating system.

I don't understand your argument about how "there would be absolutely no chance of moving over to the Hurd unless it's almost perfect". You're basically saying people shouldn't use software that works well because it discourages interest in software that doesn't. How about GNU vs Windows? Using your same logic, one could argue that no one should switch to GNU, because then there will be less interest in Windows and the problems in that system will take longer to fix.

And, even if we do switch, why would it discourage interest in the Hurd? The vast majority of GNU based systems already run Linux as the kernel, and yet we're still here, working on the Hurd, discussing it. If anything, a stable, complete GNU system would provoke more interest in the Hurd+a mirokernel, as it would be seen as a 'next generation' kernel, rather than the poorly written, poorly maintained weird project that so many people see it as now.

The GNU system would be totally irrelevant as just yet another GNU/Linux
distribution, and the Hurd would be marginalised even more -- a perfect
loss-loss situation.

No; see above. A stable GNU system could be a powerful, standardized base for GNU software distributions.

Really, there is absolutely no point in releasing the GNU system with
Linux as the kernel. It would bring no good at all.

> 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.

That doesn't work. Mach also was tested for a long time with
single-server systems. The real problems showed only when people
actually tried building proper (multiserver) microkernel systems on top
of it.

-antrik-

[Sprink]

There is just no point in releasing the GNU system based on Linux, to
compete against the hundreds of existing GNU/Linux distributions.

 

Coming from someone who is not yet a real developer, but a long time GNU/Linux user, and free software supporter, I strongly disagree.  I think having a GNU/Linux distro who's goal is specifically for developing the hurd would have way more advantages than any other option. One of those advantages being the distributions goal, to work towards developing the real GNU OS. Me and I assume many others would be more encouraged to use this distro on a daily basis knowing it's goal is to develop the hurd and a real GNU OS than using any other Linux distro out there, regardless of its current shape, strictly because of its goal.  I've tried installing and running the the hurd at home, which seemed almost impossible, I know if I could have at least got it up and running, I would be helpful to the project, as I am technical enough to submit good bug reports, fix minor (easy) bugs, and be a additional user (supporter) of the GNU OS and the Hurd.
 

And
once it would be release with Linux, it would be virtually impossible to
switch -- nobody would dare to go from a limited but perfectly working
kernel to something rough and incomplete. There would be absolutely no
chance of moving over to Hurd unless it's almost perfect -- but that
won't ever happen, as with the GNU system already released with Linux,
there would be even less inclination for people to work on the Hurd.

I don't agree with this either. When I first made the switch from Windows to Linux,Linux was not perfect, in fact, Windows worked a lot better for me. I had way more problems with Linux than windows, but that didn't stop me, because I was looking at the long run, and it felt good to know I was supporting free software, and I knew what the underlying goals and philosophy were that I was supporting just by using the software. I knew what the GNU License was, I knew what proprietary software was, I knew enough to know I would prefer to support GNU/Linux over windows, regardless if windows worked better for me. I knew if enough people used it, and supported it, it would improve, and we would have the best of both worlds (Software and Freedom). People would not use a GNU/Linux distro designed to be a road for the hurd to develop on unless they planned to use the hurd when it was released for testing in the distribution. There for, I see no reason for people to hesitate to use the Hurd over Linux, since it was their intentions for using the distribution in the first place.

The GNU system would be totally irrelevant as just yet another GNU/Linux
distribution, and the Hurd would be marginalised even more -- a perfect
loss-loss situation.

It wouldn't be just another GNU/Linux distro, it would be a distribution aimed at developing the hurd and the GNU OS. That would be its main goal. People like me, and many others, who want to support the hurd, would choose to run this distribution, test it, talk about it, submit bugs, keep it active, and people who don't plan to use the hurd in the future, would not. There would be no users of this distribution who don't want to use linux instead of the hurd. I think just getting people involved in wanting to support the hurd, is a advantage in itself. Get people excited about the hurd and the GNU OS.
 

On 9/7/07, Michael Heath <mike.thomas.heath@...> wrote:

On 9/6/07, olafBuddenhagen@... <olafBuddenhagen@... > wrote:

Hi,

On Wed, Sep 05, 2007 at 01:07:26AM -0500, R. Steven Rainwater 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. 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.

As I already said on IRC, this suggestion is totally out of the question
IMHO.

First, please remember that a good number of people subscribed to this list and replying to discussion on it are not in whatever IRC channel you're talking about. If there is a relevant discussion or opinion, write it/re-write it here, don't just talk about it like the matter is settled and done without ever talking about the matter.

There is just no point in releasing the GNU system based on Linux, to
compete against the hundreds of existing GNU/Linux distributions. And
once it would be release with Linux, it would be virtually impossible to
switch -- nobody would dare to go from a limited but perfectly working
kernel to something rough and incomplete. There would be absolutely no
chance of moving over to Hurd unless it's almost perfect -- but that
won't ever happen, as with the GNU system already released with Linux,
there would be even less inclination for people to work on the Hurd.

If you notice, you call these operating systems GNU/Linux. Why? Because they are theoretically _based on the GNU operating system_. GNU would not be competing with these things, it is what all of these things have in COMMON. Providing a consistent base operating system would allow for greater compatibility and continued innovation in the GNU operating system.

I don't understand your argument about how "there would be absolutely no chance of moving over to the Hurd unless it's almost perfect". You're basically saying people shouldn't use software that works well because it discourages interest in software that doesn't. How about GNU vs Windows? Using your same logic, one could argue that no one should switch to GNU, because then there will be less interest in Windows and the problems in that system will take longer to fix.

And, even if we do switch, why would it discourage interest in the Hurd? The vast majority of GNU based systems already run Linux as the kernel, and yet we're still here, working on the Hurd, discussing it. If anything, a stable, complete GNU system would provoke more interest in the Hurd+a mirokernel, as it would be seen as a 'next generation' kernel, rather than the poorly written, poorly maintained weird project that so many people see it as now.

The GNU system would be totally irrelevant as just yet another GNU/Linux
distribution, and the Hurd would be marginalised even more -- a perfect
loss-loss situation.

No; see above. A stable GNU system could be a powerful, standardized base for GNU software distributions.

Really, there is absolutely no point in releasing the GNU system with
Linux as the kernel. It would bring no good at all.

> 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.

That doesn't work. Mach also was tested for a long time with
single-server systems. The real problems showed only when people
actually tried building proper (multiserver) microkernel systems on top
of it.

-antrik-

[Sprink]

. There would be no users of this distribution who don't want to use linux instead of the hurd.

Sorry. I meant:

. There would be no users of this distribution who want to use linux instead of the hurd.

[Richard Stallman]

    Thanks Sprink, but I don't think many people here found my idea
    interesting.

I have not had time to study it yet.  I am very backlogged this week
so I am only dealing with mail that is easy or urgent.

I will try to make time to think about this during the weekend.

Meanwhile, I suggest that people send fewer messages that just
criticize.  Those make the thread so big I can hardly read it.

[Srikrishna Das]

I missed out on these for a whole week :P

 

Just read it.

Nice plan Steven.

 

But, somehow hurd developers may not like to ship-in the Linux kernel.

 

Not sure how many would like this

" UNICS -> UNIX ->....-> minix->Linux-> Hurd "

 

I am sure enough to hear a "No way" at #hurd

 

Nevertheless, hurd development needs a pace up.

People are already waiting to get their hands on the complete GNU system.

 

On 9/7/07, Richard Stallman <rms@...> wrote:

   Thanks Sprink, but I don't think many people here found my idea
   interesting.

I have not had time to study it yet.  I am very backlogged this week
so I am only dealing with mail that is easy or urgent.

I will try to make time to think about this during the weekend.

Meanwhile, I suggest that people send fewer messages that just
criticize.  Those make the thread so big I can hardly read it.

--
krish

[Karl Berry]

I for one have very little idea of what the GNU system is intended to
look like, not with respect to kernel hacking or super-advanced features
or driver implementations, but simply from a basic user and/or sysadmin
perspective.  Which I think is one reason why it is hard for anyone
(outside the inner circle) to figure out how they can contribute.

Is there any specifications, guidelines, roadmaps, examples, or other
documentation about what "GNU" is intended to look like?  I.e., the
target we are presumably all aiming for?

karl

[R. Steven Rainwater]

On Sat, 2007-09-08 at 19:06 -0500, Karl Berry wrote:
> Is there any specifications, guidelines, roadmaps, examples, or other
> documentation about what "GNU" is intended to look like?  I.e., the
> target we are presumably all aiming for?

There seems to be very little but I've found some interesting info here
and there over the last week. It's scattered across different websites
and mailing lists and much of it seems very old. I think a good starting
point might be to gather up everything that exists in one place so we
can sort out what work has been done in the past and try to get
something going again.

How about a wiki for the GNU OS? Something like the wiki Thomas Schwinge
set up for organizing the Hurd info recently. I can set up a DokuWiki
site for the GNU OS on the box where I host Advogato if it sounds like a
good idea.

-Steve

[Alfred M. Szmidt]

   How about a wiki for the GNU OS? Something like the wiki Thomas
   Schwinge set up for organizing the Hurd info recently. I can set up
   a DokuWiki site for the GNU OS on the box where I host Advogato if
   it sounds like a good idea.

Most Wiki are bad since they require people to have network access to
be able to edit them, and a web browser; this includes DokuWiki.  I'd
rather see ikiwiki or similar which stores files as plain text, which
you can put into a CVS repository or similar.

[Alfred M. Szmidt]

   I for one have very little idea of what the GNU system is intended to
   look like, not with respect to kernel hacking or super-advanced features
   or driver implementations, but simply from a basic user and/or sysadmin
   perspective.  Which I think is one reason why it is hard for anyone
   (outside the inner circle) to figure out how they can contribute.

   Is there any specifications, guidelines, roadmaps, examples, or other
   documentation about what "GNU" is intended to look like?  I.e., the
   target we are presumably all aiming for?

I think the short term goal (which is not that short) is to get GNU
into the same state that GNU/Linux is, i.e. have GNOME running nicely,
a simple installer, etc.  I doubt we will ever be immensly different
from GNU/Linux, it is after all a GNU system!

[Filip Brcic]

Дана недеља 09 септембар 2007, Alfred M. Szmidt је написао(ла):
>    How about a wiki for the GNU OS? Something like the wiki Thomas
>    Schwinge set up for organizing the Hurd info recently. I can set up
>    a DokuWiki site for the GNU OS on the box where I host Advogato if
>    it sounds like a good idea.
>
> Most Wiki are bad since they require people to have network access to
> be able to edit them, and a web browser; this includes DokuWiki.  I'd
> rather see ikiwiki or similar which stores files as plain text, which
> you can put into a CVS repository or similar.

Excuse me, but could you name someone who doesn't have access to a computer or
a device with network access and a web browser? I have a decent web browser
and network access on my mobile phone, so I can edit dokuwiki (or *wiki)
while sitting in a bus, and I expect not to be the only one who could do
that. And I don't know of any mobile phone that has cvs (or svn, arch, ...).

Btw, why cvs doesn't require network access?

--
Filip Brcic <brcha@...>
WWWeb: http://purl.org/NET/brcha/home/
Jabber: brcha@...
ICQ# 40994923
Yahoo! brcha
MSN: brcha@...

[Alfred M. Szmidt]

   Btw, why cvs doesn't require network access?

Not to edit files.

You can edit ikiwiki via a web interface as well, if you want.