Re: Bug#139945: ITP: prokyon3 -- a multithreaded MP3 manager and tag editor for Linux.
On Thu, Mar 28, 2002 at 09:22:20PM -0500, Michael Stone wrote:
> It's iterative development in the flesh. First, I think you overstate by
> saying "throw away."
It was you who said "rewrite from scratch", not me.
> Even when code is rewritten there is a learning
> process involved and a set of basic techniques and constraints that can
> be carried from prior revisions.
Of course. I never said that rewriting code is a bad idea (I read the
Mythical Man Month).
> It's not an easy thing to
> come up with a framework that's general enough to deal with the unknown
> and still has good performance.
That is not an excuse for not to try at all. You can rewrite a driver
framework, andyou can often do it in a way to make it easy to upgrade.
> patches. Those are sometimes intrusive (not at all portable outside a
> particular kernel), but absolutely critical for performance. The hurd
> guys aren't worrying about that just yet, are they?
We are worrying, but we are sometimes willing to trade off performance
initially until we have solved the design problems involved with the
solution (for example, the reursive pager approach in L4 seems to be a good
way to avoid copying).
> I think it's pure arrogance if not stupendous self delusion for
> the hurd developers to poo-poo that model (calling it a "fairly bad
> kernel" and "a bad joke")
That is not what "the hurd developers" say, this is what I said.
And I didn't say it is a fairly bad kernel in general, it is fairly bad in
some aspects of its code and design, aspects I bothered to explain at
length. I am happy to say that it is a wonderful kernel for day-to-day use,
it get's the job done, it is stable, it is fast, and it supports a lot of
my hardware. As long as I am just using it, I am simply stunned.
As soon as I try to get some work done with the actual kernel code, as for
example updating the pfinet server in the Hurd where we use the tcp/ip stack
from Linux, or trying to fix bugs in gnumach where we use its device
drivers, I am getting the other side of the picture, too. And that is what
I was talking about in my mail.
> when their model frankly has so little to show
> for itself--we've heard a lot of "when our grand design is finally
> finished..." from the hurd folks over the years. I'll be damned if I
> want to see someone criticizing a working project in favor of one that
> can't meet the requirements the first project already fulfills.
My point is that it is exactly the other way round for the aspects I am
talking about. Our code and it history is well commented, stable, has clean
interfaces and has been backward compatible ever since. We never ever broke
an external interface [1], and we will not do so. We write code that will still
work years from now (just as we use code written five years ago unmodified
because it just still works, even if everything else surrounding it has
changed). And the same Hurd developers who you belittle have written code
that has been reused and reintegrated into the GNU system and is now used by
you and other people in the context of the GNU/Linux system. One prominent
example is the GNU C library itself (with for example argp which was
initially written by Miles for the Hurd servers). For the aspects I was
specifically addressing and criticizing Linux, we already do way better.
Even if the Hurd itself fails miserably and withers and dies, there will be
(rather large) bits of pieces that were written specifically for it but
live on in other GNU projects because we took the care that this can and
will be the case. I would like to say the same of the Linux kernel (and
it will be true nowadays anyway, and if it is just because of the enormous
size of driver code in it).
Thanks,
Marcus
[1] I am meaning the Hurd server interfaces here, but also the command line
interface of Hurd tools etc to some extent.
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: