Re: A proposed Roadmap

[Arguri]

Hi,
> Like I said, though, this is going to take more widespread consensus 
> to move forward with this idea.
>
> Richard:
> I realize that this is a sensitive issue and controversial, but I was 
> wondering if we could get your opinion on it. There seems to be a lot 
> of support for this idea from the posting on here and other threads, 
> but it would probably take your endorsement for anything to happen.
Actually no one involved in hacking the Hurd agreed with this. 
> Michael Heath
>
> On 9/9/07, *Sprink* <address@hidden <mailto:address@hidden>> wrote:
>
>     I for one still think creating the initial versions of the GNU OS
>     using solely the Linux kernel would be a great start. Once the
>     system is stable enough to stand side to side with other GNU/Linux
>     distributions, we could start the development process of migrating
>     any Hurd specific software to the GNU OS which would be using
>     Linux. I don't know a whole heap about the technical details of
>     the Hurd OS, but I assume there are still plenty of userspace
>     applications/features (any hurd specific IPC stuff) that could
>     easily be integrated into the distribution without actually having
>     a hurd/mach kernel present at the time  (I could be wrong). As for
>     the actual kernel transition itself, from Linux to the hurd, I
>     don't think it would be too difficult of work to create a binary
>     compatibility layer to help with this transition. I think it would
>     mostly be more tedious work than actual difficult problem solving
>     work.
>     Of course this would all take plenty of time, but just stepping
>     back and looking at the big picture of the entire process, I don't
>     see any reasons not to take this path for the development of the
>     Hurd/GNU OS.

I personally strongly disagree, it would require too much work in the 
wrong direction. On the other hand there was a much better propsal: 
Using a special Linux Distro for developing. This Distro could be made 
of gNewSense and might include all the documentation of the Hurd and 
associated parts (which must be improved) and a qemu image with the Hurd 
installed and set up properly. Then you do not need to work on any 
compatibility or transition between the kernels. One big point is: Many 
software, even the one designed for the Hurd was only used with Linux in 
the last, hmm... , lets say 7 years, which resulted for instance in many 
PATH_MAX problems (I hope, you know what I talk about). What I want you 
to realize is that many people are in fact working to improve the GNU 
OS, but think the things, which work under Linux will work with the GNU 
Kernel, too. So giving them the official GNU OS and it works on it would 
require changes of such mistakes too. You might argue, that such things 
might be fixed by changing Linux itself, but on the other hand, this 
would require even more work then.

And, as Steve mentioned himself, his roadmap and this transition looks 
like: do magic, do more magic, do even more magic and then benefit.

If you really want to release something called GNU OS and attract new 
people, a possible roadmap might look like this:
1) Release a gNewSense based GNU/Linux Distribution including all things 
neccessary to start hacking the Hurd (esp. Documentation)
( Release Roadmaps for some associated projects, like Hurd, Mach, etc...)
2) Release GNU Mach 1.4, or even 1.5
3) Release GNU Hurd 0.3
4) Release something like GNU Installer
5) Release something like GNU Packager
6) Release some other important stuff
7) Put it all together to release something like GNU OS 0.1
8) Release even more.

Whereas Point 2-6 might be done simultaneously.
Concerning for instance Point 2, the task list for 1.4 is actually 
released on savannah, so you don't need to think about what to do, but 
how to do it.
Things for Point 3 are also mentioned on savannah, but are not sorted 
out good enough yet.
Points 4 and 5 are things which need clearing and hacking, but it seems 
many people are willing to work on such things, at least this is what I 
interpret in those many calls for a release of the GNU OS.
The big point is that more work should be done on the helpers for the 
Hurd (ie installer, package management), than on the Hurd itself. The 
Hurd developers do what they can and really need a bit help, but many of 
there work recently was to just to keep packages building on the Hurd, 
which is a much bigger dependency for releasing a running Hurd system, 
than you might believe. This takes a lot of time which could and should 
have been spended on learning Hurd internals or hacking the Hurd.

Only my ideas...

Regards
   Arguri