Re: Using Hurd features (was: Re: Hurdish applications for persistence)

[Jonathan S. Shapiro]

On Wed, 2005-10-12 at 14:25 +0200, address@hidden wrote:
>    This is about GNU software, that is software which is part of the
>    GNU project.
> 
> And the Hurd is a GNU project.  So worrying about portability for
> non-GNU systems is simply not a priority.

I don't want to disturb the small children in the sandbox. They seem to
enjoy throwing the sand so much!

However, I would like to challenge an assumption about the need for
compatibility. I am not sure how far I would want to push this, and I am
not entirely sure that I fully believe it myself, but it seems worth
looking at.

Q: Why are people so concerned about compatibility?
A: Because rewriting lots of stuff is expensive and slow, and requires
specialized expertise.

But for many of the applications that we are interested in, we do not
*need* to rewrite the applications. What we need to do is *re-factor*
the applications. So perhaps the following questions are worth
considering:

Q: What would it take to re-factor a large body of existing source code
into a more secure architecture?
A: A mid-sized body of programmers who have refactoring skills and know
how to read code. This is actually something that a talented
undergraduate can do. It is exactly the kind of group that open source
projects are most effectively able to leverage.

Q: How hard is it?
A: Depends heavily on the application. In many cases we could do it at
the framework level and leave the application almost entirely alone. In
others we can restrict the initial refactoring to a limited number of
easily described programs.

Q: Could we push the changes upstream?
A: Yes, if we can get a suitable component communication framework built
for linux to provide source compatibility. The refactoring would provide
maintenance, security, and robustness benefits under Linux/UNIX as well
as Hurd.

Q: Does it all need to be done at once?
A: No. We can do it on a prioritized basis, deciding priority on a
combination of risk, cost, and demand.


Perhaps we should not reject the possibility of migrating the
applications if we really believe we can do something compelling.

But I agree, it is a big engineering challenge to contemplate.

Still, that's how Coyotos and EROS planned to do it.


shap