lkml.org 
[lkml]   [1999]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Subject[ OFFTOPIC ] Re: The Linux Kernel Project Management System (INITIAL PROPOSAL)
From
Date
I don't remember seeing any pronouncement stating that no one is
allowed to even consider systems other than the much-hyped and
not-so-much-seen BitKeeper, so pitching this kind of fit at
Peter Miller is a bit presumptuous.

Yes, you think you have a great product. Good. It'd really be a
problem if you didn't. But you have to accept that not everyone will
be immediately convinced, especially since very few of us have ever
seen it.

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". It's pretty new, so I'll understand if you haven't
heard of it. It's pretty cool, though -- it actually lets you make
backup copies of your files in case something bad happens. If it does,
you can restore from tape, and just like magic your files are back!
You can even automate the use of one of these amazing things.

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.

> Any source system which doesn't detect corruption immediately should
> be tossed out the door. My personal feeling is that BK should be
> more paranoid about this, not less.

Sure, having an application detect corruption can be cool. But with a
reasonably stable operating system and a tiny bit of effort put into
backups, it's not even close to the showstopper you make it out to be.

My lab uses CVS for its work. We keep our repository in an AFS volume
that gets backed up every now and then. Sometimes CVS fucks up and
trashes something. When that happens, we send mail to the department's
computer facilities folks, and they restore the volume for us. Over
time, I lose far more data to my own idiocy than to CVS not handling
file corruption.

> BitKeeper is as open as it can be. You get source, you get to wack
> it and redistribute it for free. The license isn't as open as you
> want but that's because we need to make money in order to support BK
> and move on to developing the next generation of tools: bug tracking,
> binary file revisioning, project management, etc. It's wonderful that
> your tool is open source, but I'm a little concerned with your roadmap.
> I'd really like to know when it will solve the same set of problems BK
> can solve (making it a clearly better product), and when you are going
> to integrate bug tracking in, mailing list and web server support, etc.
> And how are you going to pay for all that development?

"clearly better product". Can I download BitKeeper _right now_? If
not, then it's not a clearly better product in any way. It's simply a
prettier cloud of vapor. Boast about how cool it is when it's
released, not before.

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.

From the pricing on the chart at www.bitkeeper.com, it seems that
BitKeeper would cost me $136,000 to use for the roughly 40 grad
students, faculty, staff, and undergrads around here, using the "one
time buyout" plan. By contrast, Perforce would cost $1000/year, since
they have an educational discount. But even if they didn't, it'd be
$23,000 for the first year plus $4800/year of support after that.

$136,000 is a lot of money. 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.

> 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?

The worst cases you're talking about for Aegis are exactly the same as
the worst cases for BitKeeper. Actually, they're better -- I may not
get much support, but at least I'm not out an eighth of a million
dollars.

So, basically, please take your marketing elsewhere. To take a common
phrase from the free software world, don't talk, show us the code.


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

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