(Please don't Cc me on mail to -devel, it confuses my tiny brain)
On Sat, Oct 21, 2000 at 05:32:27AM +0300, Eray Ozkural wrote:
> Anthony Towns wrote:
> > We've already uncovered such bugs in da-katie. And in the testing scripts.
> > And no doubt in dinstall as it already exists. And in most programs on the
> > planet. Sure, bugs *shouldn't* happen, people *shouldn't* make mistakes,
> > but they do.
> so get these working and people can detect bugs earlier :)
They are working, and we are detecting bugs pretty early. It's difficult
to fix bugs before the program that has them is written...
> > > ext2 isn't a good filesystem. and linux isn't a good kernel. the fact
> > > that we're running them doesn't entail that their philosophy is correct.
> > > we're running them because they're the best [in some aspect or another]
> > > in the free world.
> > It's not really that useful to talk about things as being "good" or
> > "bad" when even the "best" isn't "good".
> you're confusing the scope of the best :) i meant "best in the free world
> in some aspect". this means that there may be better kernels/filesystems
> in the non-free world. :)
Sure, I realise that.
But you seem to be limiting the word "good" to things that are considered
best-practice in academia. Things that have best known or best possible
asymptotic complexity, for example. Which is all very well in academic
circles: you don't want to waste your time working with things that we
already know are second best when you're trying to solve the problems of
tomorrow; but it's not really meaningful when real problems are involved.
In that sort of context a "good" solution is one that solves today's
problem today.
Solving academic problems and solving actual problems are really quite
different domains. They're both difficult and interesting and worthwhile,
but solutions in one or the other are (quite rightly) held to very
different standards.
> > The disagreement is about whether it's worth retaining the possibility
> > of doing *without* that automation in future. Whether the archive should
> > be physically maintainable by hand, even if it's grown too large for that
> > to be feasible as a whole.
> I think it's already too large to modify manually. I'd prefer that
> a software archive avoids human intervention as much as possible.
It's too large to manage manually on a fulltime basis. There are roughly
100 new source packages uploaded every day (well, last time I counted
anyway), and no one has the time or patience to handle that day in day out.
And we don't. They're processed by dinstall (which da-katie is backwards
compatible with) around midday American-West Coast time every day. Good
updates are installed, bad updates are rejected.
Not everything's automatic though: new packages are reviewed by the ftp
maintainers (generally Michael Beattie these day) to ensure they're not
completely daft and that they're copyright is reasonable; and a number of
"byhand" packages (most noticably dpkg and boot-floppies) also require
the attention of the ftp masters for varying reasons.
I'd sugges that you might like to spend some time looking into how the
existing byhand packages might be better automated (they're already are
somewhat); but I'm hesitant to do so because I suspect any solution you'd
come up with be overly intrusive. That if we ever applied it, and decided
we didn't like it, or that it didn't work for some situation we'd not be
able to ignore it, work around it, or rip it out as a whole.
> I understand your point, but still disagree :) I mean, the code is already
> bent that way, so just keep it like that. Maybe someone else later
> comes up with an implementation that's designed differently :)
Once again, you're severely underrating the benefits of direct human
comprehensibility. Sure, it's not *always* possibile, but when it is,
it's usually well worth whatever other prices you might have to pay.
Cheers,
aj, amazed that he's making the "maintainability not efficiency hacks"
argument, let alone to someone who was chiding about "design" just
a few posts ago. Ah, the buzzwords of CS.
--
Anthony "goto" Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``We reject: kings, presidents, and voting.
We believe in: rough consensus and working code.''
-- Dave Clark
Attachment:
pgp94_L74Mc7w.pgp
Description: PGP signature