Hurd Roadmap for Woody Release

[Marcus Brinkmann <Marcus.Brinkmann@ruhr-uni-bochum.de>]

Hi,

Note: The subject does not imply that we make the decision to release with
woody or not now. This is meant as a list of conditions that must be
fulfilled before we even can consider this. Maybe it is a motivation for you
to help to reach those conditions.

I am forwarding and replying to the debian-hurd list, so interested folks
know what'll come up in the next months. Short answer: I don't know if the
Hurd will make it with the next release, this depends on a zillion of
things, but we will have something, even if it is not an officially released
version, at least a quite useable snapshot.

On Fri, Oct 20, 2000 at 12:34:22PM +1000, Anthony Towns wrote:
> On Fri, Oct 20, 2000 at 04:04:04AM +0200, Marcus Brinkmann wrote:
> 
> Completely irrelevently, congrats on getting HURD boot-floppies, even if
> they're not native. It'd probably be good to start thinking about what
> sort of requirements we want to have for releasing an architecture/OS.

Yes, thanks for the list.
 
> Some minimal ones:
> 
> 	* boot-floppies, some way of installing the system in an
> 	  automated, fairly standard way that doesn't require hacking around

debian-boot discusses the new setup, Glenn McGrath was succesfully compiling
busybox. This will require more work, I can't even guess how much because I
didn't put my nose into boot-floppies at all yet.
 
> 	* debian-cd support

Philip Charles had some success here. Unfortunately, I had not yet the
time to improve the cooperation so that Phil can concentrate on the CD
issues as opposed to genuine Hurd issues, but it seems that the current way
is a mixture of vanilla Debian scripts and the existing install scripts for
the Hurd.

Is any volunteer who has a rudimentary idea about what's going on on the
Hurd side interested in this and can lend Phil a hand?

> 	* an autobuilder that keeps up to date with a majority of packages,
> 	  and someone maintaining that and fixing or working around the
> 	  rest

I have a machine set up, though not locally, and so it is a bit tough to
keep it running for everyone involved. Also, the Hurd is not super-stable
under heavy load, so it crashes quite often. Anyway, this is something I
had and will have under control (the autobuilder software is there at
sourceforge.net/projects/turtle).

> 	* someone taking care of the port in general

Well, of course.
 
> 	* all the relevant parts of standard ported, and most of optional
> 	  ported too

Finally a point where we look good. All of standard and up that can be
reasonably expected is there, although partly out of date because of the out
time of the autobuilder. No serious problems to be expected when catching up.

What is missing is mostly heavy linux specific stuff.

>From optional, we have a selection, and even X and some gnome stuff,
although it's not worth to speak of the latter because of lack of
performance due to lack of pthreads.
 
> For Linux, these are pretty adequate: most of the interesting features
> come for free just by using the kernel and making sure it works and
> getting the toolchain complete. Firewalling and X for example. Well,
> free's obviously too strong, but it's obvious what should be able to be
> ported and what shouldn't.
> 
> For Hurd, though, more thought's required. Obviously ipfwadm and
> ipchains and iptables won't be ported to the Hurd directly, but should
> *some* firewalling stuff be available before we present Hurd as a stable
> environment that people should be able to install and use? I don't think
> it's unreasonable, but it requires thought. How stable the TCP stack is,
> and how vulnerable the system is to local and remote DoS attacks is,
> and what not might be things to look at too.

The TCP stack is from Linux glued in, and after some destabilizing changes,
the network server seems to have shaked out by now. However, when talking
about new features beside basic networking, that's upstream coding required,
and this is something where currently not much efforts go in. So, a big
minus point here, if you want.

But this is true in general of course. The overall security is probably
quite low, because too few eyes are pondering it. This can only get better
with more people poking around, so if we release it, it must be made clear
that this is at the core a completely different system with a much different
(read: worse) security footprint. We can probably not say much about it
except shortly before the final decision has to be made.

> Given the five bulleted points above though, I think the Hurd could
> legitimately release though, so maybe a woody release is perfectly
> reasonable at this point.

Yep, no surprising desasters popping up, there is a chance we can make the
bulleted points above.

> I haven't been following -hurd very much recently, so maybe you're already
> considering this.

I have not eyed for a release yet, but in general, I am working my way
through the bulleted list in reverse order.

> If you're not, it'd probably be good to though. Feel
> free to forward, quote or paraphrase this mail, if it helps. Getting an
> architecture into Debian proper will be a bit more gradual and paced this
> time though, so if we want to do it, it'd be good to commit to it in a
> month or so (after katie and testing have settled in a bit, hopefully).

"The Hurd" and "hurry" don't mix well, as we use to say here ;)

Thanks a lot for the heads up,
Marcus


-- 
`Rhubarb is no Egyptian god.' Debian http://www.debian.org Check Key server 
Marcus Brinkmann              GNU    http://www.gnu.org    for public PGP Key 
Marcus.Brinkmann@ruhr-uni-bochum.de,     marcus@gnu.org    PGP Key ID 36E7CD09
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/       brinkmd@debian.org