Messages in this thread | | | Subject | Re: [ OFFTOPIC ] Re: The Linux Kernel Project Management System (INITIAL PROPOSAL) | From | Nat Lanza <> | Date | 28 Sep 1999 00:23:32 -0400 |
| |
Larry McVoy <lm@bitmover.com> writes:
> In RCS files, the way the file format is layed out, you'll never know > that a revision is bad unless you ask for it and discover that it is > bad. In other words, you can have the middle of a file (like one > block or sector) go bad, and you may not find out until a long time > later. When RCS processes the files, it does nothing to verify that > the old data is valid. So months, years, can go by before you need that > old release to support an important customer. And then those lovely > tapes which you made (you did make them, right?) may well be bad. > > And you are suggesting that this is OK? Fine, go to the head of the > line of people I want nowhere near my data.
No, I'm not. I'm not suggesting that no compensation for the fact that disks and filesystems go bad is needed. What I'm saying is that that compensation should not need to be application-level. If I need to do a lot of checksumming and manual parity calculation and such in my application, then either the OS author or whoever put together my machine seriously fucked up somewhere. If my data gets silently corrupted without me noticing for months or years, then there are problems that no SCM can solve.
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. That's not just wrong, it's rude.
> And another thing: while you and your buddies may not think that this > is a problem to worry about, you aren't exactly representative. If > people put money and/or effort into using a source management system, > don't they have the right to know that the vendor did something to make > sure that things wouldn't break?
"you and your buddies"? "you aren't exactly representative"?
Larry, could you do me a favor? Could you be a little more condescending? I almost got the impression for a second there that you might possibly have the tiniest smidgeon of respect for someone who might dare to disagree with you.
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. We may be a little insignificant research group and not big important Captains Of Industry, but we do care about our code. Our sponsors, who _are_ Captains Of Industry, also care about our code and us not losing it, so that's a little extra motivation right there.
Also, if I buy BitKeeper, store lots of important code in it, and it fucks up my repository, what can I do? I mean, I can whine about it a lot in public, which might make me feel better, but can I do anything that gets me my code back or provides me with actual compensation? Can I get a refund? Can I sue you? Can I say "He did it! Blame him!" to my boss or my sponsors? If the system breaks, then fundamentally I really don't care whose fault it is, I just want my data back.
> 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. If I might need data for months or years, I'd better have offsite backups and burn important bits onto CD in case a tape dies.
It's nice if my application helps me out there, but if I'm depending on it doing so, then I deserve to lose my data when it fails. I'm sure BK's integrity system is nice, but I think I'd prefer to have more than a single piece of software to fall back on.
> 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.
In practice, stuff breaks and overheats and catches fire and get stolen and deleted and lost and water damaged and what have you. Will BitKeeper protect me from that too? If so, cool, sign me up. If not, pardon me for wanting to have safeguards other than some piece of software.
> Great. I'm equally uncomfortable with you not paying for it in that case.
I'm glad to know our research isn't pure enough for you, Larry. Will you admit that maybe all the people who complain that when you call BitKeeper "open" you don't actually mean "open" have a point now, please?
> Feel free. I have no interest in getting you to use something you don't > need. In fact, when people say "why should I use BK instead of XYZ" I > respond with "Is XYZ working for you? If so, you shouldn't". You'd be > amazed to know that 95% of the people say "No, it isn't working". But if > Perforce or CVS is working for you, why are you in this conversation? > If you're happy, you're happy. If not, and BK costs you less than the > problems cost you, that's a win.
Funny, a few messages ago you seemed to be saying something totally different -- it was more like "Why would you be stupid enough to use Aegis when you could use BitKeeper instead, which will solve all your problems and make toast for you in the morning?".
Part of the point here is that those of us outside of BitMover and the beta groups really have no idea whether BK will solve ANY of the problems that CVS, Perforce, ClearCase, Aegis, or whatever don't. You say they will, but you haven't produced anything to back it up with.
You attack Peter for having the temerity to think that he's produced a good system by waving your ridiculously expensive vaporware around, and then when someone mentions a much cheaper product that a lot of people are pretty happy with from an actual commercial company with support, you get huffy. I'm just trying to point out that BitKeeper is not the only game in town, no matter how much you love it. Yelling at people will never convince them that BitKeeper is good. Only BitKeeper itself can do that. Yelling will only make them think you're arrogant and obnoxious, and wonder what kind of support you'll provide. That's no help.
> > 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. Fuck, I guess I _am_ screwed.
> Hey, Nat, my man. Go back to the start of the thread and notice I didn't > start this, it wasn't my marketing, it was that Aegis guy who got the > ball rolling.
But you jumped into it and harangued him about it. "He started it" is not and never has been a good excuse for this sort of thing, Larry. Uh, I mean, "Larry, my man".
(hint: take the marketing hat off. talk about the technical details. give us reasons other than "because I say so". accept that others can be more than just mouth-breathing annoyances. we'll like you for it. really. we might even buy your software.)
(especially if you consider adding an educational discount. education is the future, y'know.)
--nat
-- nat lanza --------------------- research programmer, parallel data lab, cmu scs magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/ there are no whole truths; all truths are half-truths -- alfred north whitehead
- 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/
| |