Re: about GNU Hurd

[Michael Banck]

Replying to both, Gianluca nailed most of it already, anyway.

On Tue, Jul 31, 2007 at 09:11:56PM +0200, Anders Breindahl wrote:
> On 200707311150, Michael Heath wrote:
> > I don't think so. Google's SoC is designed to help finance one student to
> > work on a specific task within a project. With a Hurd-specific fund, you
> > would be able to to choose specifically where to spend the money for it to
> > be the most beneficial to the Hurd. 

Uhm, who do you think proposed the project and picked the student?
Actually, GSoC has a much higher chance of actually getting code into
the Hurd, because *the Maintainers mentor the student and provide a CVS
branch for him*.  If you just throw some money at somebody, the best you
can come up with is a patch to bug-hurd unless that money has been spent
directly by the FSF and some FSF officer decrees that this code has to
be applied, at which point I assume the maintainers would apply it
before quitting.  Otherwise, general evaluation by the maintainers will
hold and whether or not that code was good enough and/or fitting will be
seen.

> > You'd also be able to finance work by developers who may not be
> > elligible for SoC. It's a completely different system.

That's a point, but that doesn't invalidate GSoC as a good sandbox for
this.
 
> I agree. If the Hurd wants a kick start towards the end of some of the
> goals that are stated -- update glue code, migrate microkernel, make
> software package $x compatible with the Hurd (or the reverse), implement
> this and that netfs translator, and so on -- paid work would be
> justified.

Those projects you mention differ between each other by several orders
of magnitude both in timescale and complexity.

If somebody wants to buy out Marcus Brinkmann from his current day job
(which is mostly Free Software related as well, AFAIK) to work on his
pet projects, that /might/ result in basing the Hurd on a new
microkernel at some point.  But this is rocket-science, nobody knows
whether it will work out in the end, so I guess Marcus wouldn't consider
such an offer anyway, because he couldn't commit to deliver.  Certainly
just putting up a big bounty and waiting for some random developer to
come along and port the Hurd to a new microkernel won't work.

Then of course you have the issue that people apparently do not want to
code on something which might be obsolete in a couple of years - nobody
knows yet how much of the current codebase could be salvaged for
Hurd/NG.

The other projects (updated glue code, some translators) look quite ok
to have a bounty on, especially if they take advantage of the Hurd's
modular design - You can always release a shiny new translator which can
easily be built against the Hurd, you don't necessarily need to have it
in the Hurd tree - we also have the hurdextras repository at Savannah,
except that it is kind of stalled due to maintainer deadlock currently,
but that will be fixed eventually.

> After all, there isn't so much work that needs to be done, in order for
> the Hurd to be a satisfactory standin for Linux. 

I'm not sure how to comment on this.


Michael