lkml.org 
[lkml]   [1999]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ OFFTOPIC ] Re: The Linux Kernel Project Management System (INITIAL PROPOSAL)
On Mon, Sep 27, 1999 at 10:04:55PM -0400, Nat Lanza wrote:

[noise about not seeing BK yet]

There is a good reason for that. It will be released when I believe the
chance of it screwing up your data extremely unlikely. I actually feel
some responsibility - if BK screws up your tree, I fully expect you to
come screaming after me with sharp pointy objects.

> Larry McVoy <lm@bitmover.com> writes:
> > It is a _fact_ that disks go bad and that file systems can corrupt
> > files. It is a _fact_ that billons of dollars of IP are put into
> > source control systems. And you think it is OK to just say "fix
> > the OS"? Bully for you but hell would freeze over before I'd let
> > you near my source.
>
> There's this invention you might be interested in. It's called
> a "tape drive".

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.

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?

> Sorry for the sarcasm, but he's right. Filesystem corruption is NOT
> the problem of each individual application. If you stand to lose
> billions of dollars worth of data by losing a disk, then perhaps you
> should look into frequent backups.

You'd have a point if RCS told you when there is a problem, but it doesn'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 I download BitKeeper _right now_? If
> not, then it's not a clearly better product in any way.

Yup, you can. You have to sign a beta agreement because I haven't written
down the license yet, but other than that, yes.

> Also, at our lab we have a variety of projects. Some, like the NASD
> code, end up being released as free software. Some, like some of our
> video scheduling work or some of the VIA stuff we're doing, cannot be
> released as free software due to various NDAs or patent restrictions
> (grumble). Because of that, I'm not comfortable with putting my
> changelogs on the web.

Great. I'm equally uncomfortable with you not paying for it in that case.

> Maybe it really is a great product, but
> that's still a lot of money. Say I use a system for three years. By my
> simple little math, I'd have spent $32,600 on Perforce by the end of
> it and $136,000 on BitKeeper. That's over 4 times as much, so pardon
> me if I continue to be interested other source control options.

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.

> > These are serious questions. If you have a good set of answers, I'd just
> > love to hear them. But if you don't, if you aren't going to solve 100%
> > of the problem and give people the assurances that they need that Peter,
> > Inc. is going to stand behind Aegis for the next 20 years, then why are
> > you here? Don't you think it is a little unfair to get people interested
> > in infrastructure that you have no intention of supporting at commercial
> > levels? What happens when you get interested in something else? I watch
> > the Aegis source tree and I'm not seeing this huge wave of development
> > coming in from the free software crowd, so that means I need to depend
> > on you. Are you going to make this work on all platforms? Where's the
> > NT, Windows/98, Mac, etc., ports? Etc.
>
> 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.

> So, basically, please take your marketing elsewhere.

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.
--
---
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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.092 / U:2.592 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site