Messages in this thread | | | Date | Mon, 27 Sep 1999 22:15:59 -0700 | From | Larry McVoy <> | Subject | Re: [ OFFTOPIC ] Re: The Linux Kernel Project Management System (INITIAL PROPOSAL) |
| |
[Not for the faint of heart]
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/
| |