On Tue, Sep 28, 1999 at 12:23:32AM -0400, Nat Lanza wrote:
> Also, I'm not claiming that having an SCM do extra stuff like
> corruption checking is bad. It's pretty cool, actually. But you made
> it sound like Peter should be run out of town and have small children
> publically mock him for not building it into his system.
If you say so. Regardless of how much you don't like the way it was
said, the point remains: source management systems which don't provide
integrity checks, when it is known that such checks are needed, especially
because without them the users won't know that the data is bad, those
source management systems are bad, bad, bad.
As to your argument that this doesn't need to be in the application,
I happen to think you are wrong. So does Red Hat, for that matter,
run rpm --verify lately? It's got the same sort of thing built in.
Perhaps you should start a crusade to get it removed, it's obviously
not useful according to, in your world nothing ever goes wrong.
> "you and your buddies"? "you aren't exactly representative"?
>
> Larry, could you do me a favor? Could you be a little more condescending?
Sorry about that, I'll try harder. Really, I promise.
> We have over five years worth of research code in our repository. I
> think that's more than a little effort, and we're definitely worried
> about protecting it. That's why we make sure it's regularly backed up
> and we often burn snapshots to CDROM.
Pick one of your backups and go extract every old version and try and
build it. Give us some status on whether they all worked. If you have
a shred of intellectual integrity (see, I'm trying harder), you'll admit
it when you find out you've been backing up corrupted data. And I'll
bet you 40 BK licenses that when you find out that there is bad data in
there, you can't find the right tape to correct it. Because remember,
you've got 5 years of backups and no way of know when in those five
years things got screwed up.
In 10 or more messages you've failed to get the point. Doing backups of
bad data is not very useful. How the hell do you know that you need to
restore from tape if the system never tells you that anything is wrong?
RCS / CVS store the latest version in clear text - every earlier version
could be completely corrupted and you'll cluelessly (through no fault of
your own) be backing up, mirroring, raiding, and CDROM burning COMPLETE
AND UTTER GARBAGE. Which you won't find out until you need to get an
_OLD_ version to fix a bug.
See the problem? Backing up corrupted bits is of no help. Having a
source management system which doesn't tell you when they are corrupted,
and has no means to tell you that, is completely insane and, yes, people
who advocate this should certainly NOT have any part in designing a
source management system. Sorry, I won't budge on that one. No sane
person would. No person with an ounce of responsibility would.
> If the system breaks, then fundamentally I really
> don't care whose fault it is, I just want my data back.
Exactly. So what are you going to do when you realize that it broke
5 years ago and that code, which you swore up and down was worthless,
you'd never need to go back to it, now you need it and you need it bad?
> > You'd have a point if RCS told you when there is a problem, but it doesn't.
>
> RCS shouldn't have to do this. If I need my data uncorrupted, I'd
> better use mirrored disks with parity.
You are at a good university; perhaps they have a copy of an old but
famous paper by Dave Clark on end-to-end error checking. Read it.
If you can't find it, I'll fax you a copy. Then think about how much
use those mirrored disks are going to be if the page cache is busted and
puts the wrong page in the file, or you have an undetected memory error,
or the bus corrupts, or any of the many other errors occur. Once again,
you're mirroring GARBAGE. And the source system, which could have warned
you about this, didn't.
> > You'd also have a point if this didn't happen in practice, but it does.
> > So you have no point. He's wrong. If you disagree, you can use a stupid
> > application to store your data but don't pretend that you speak for the
> > majority.
>
> Can you explain to me where you got this "Nat uses raw RCS with no
> other safeguards" strawman from? I'd really love to know.
You use CVS. You're advocating another system which uses the same broken
file format. In fact, I've just gone over the entire thread and 100%
of the places you mention something specific, it's RCS based. Forgive
me for listening to you, it won't happen again.
> > > If I use BitKeeper, what assurance do I have that BitMover will stand
> > > behind it for 20 years? I don't want to be a doomsayer, but we've all
> > > heard the statistics on how many startups make it. If the unfortunate
> > > happens and BitMover tanks, what happens to me and my BitKeeper
> > > license? Am I screwed?
> >
> > Nope. As I have publicly stated before: if the openlogging.org domain
> > BK servers go away and stay away for an extended period (3-6 months),
> > and the company refuses (or is unable because they are gone) to maintain
> > them, then the software becomes GPLed.
>
> Right, so I'm at exactly the same place I would be if I used
> Aegis. Since something Linux shows us that users can keep free
> software alive and make it great, I'm not screwed. I'm okay. Except,
> wait, no, I'm not. I'm also out an eighth of a million dollars.
Sheesh. If I had read this first, I wouldn't have bothered replying.
So you whine and whine and whine and then when I say that your recourse
is exactly what you have been holding up as the perfect answer, you
whine some more.
Jeeze, I'm sorry Nat. I didn't realize your importance. Let me get
Cindy Crawford on plane in the morning with 10,000 copies of BitKeeper
plus a check for $50,000,000 made out to you personally. Because I want
you to be happy. Really.
----- Larry McVoy lm@bitmover.com http://www.bitmover.com/lm- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/