I shut the machine down so that we can reinstall it.
cvs.kernel.org is in NO WAY the "primary site for the linux kernel", it's a BK/CVS/SVN server that BitMover and Penguin Computing provided to the kernel developers.
The primary BitKeeper site is up and functioning and even if it wasn't, that's no problem because BK is replicated. Unlike CVS/SVN you'd have to find every single replica and kill that to shut down all the BK trees. It's impossible, there are 10's of thousands of replicas.
This is just a CVS problem, inspite of the noise on the kernel list the CVS server is very lightly used, maybe 3-4 people, so it's just not a big deal. The trojan horse is a big deal but the fact that it got into CVS is fairly minor and it was caught by us immediately.
No BitMover infrastructure was compromised, the machine in question is a public machine maintained by the kernel developers.
I think your anti-BK colors are showing when you can take a situation where we prevented a trojan horse from being added to the kernel and your reaction is that we screwed up.
I'm the CEO of BitMover, we produce BitKeeper, an SCM tool which has some similarities to Arch. We're quite a bit farther along, we're 5+ years old and have a fairly large team, so I have some idea of what it takes to turn something like Arch into a real product from what it is today, which is more of a work of charity or altruism.
We've been taken to task here and elsewhere for not making BitKeeper be open source. This is a reasonable opportunity for us to explain why we haven't done so.
Tom's managed to raise $10K this year in support of all of his fine projects, arch being only one of them. We're not trying to do everything he is doing, all we do is source management. The problem is that we spend $10K every day or so in salaries. And we are dramatically understaffed compared to any other SCM company, when they figure out how small our engineering staff is they are amazed that we are able to do what we do.
The reality is that we should be at more like $100K per day in salaries to really have a good product. The problem is that all you lovely slashdot folks want to get everything for free. And you'll insist on it if you can get away with it. Given that the SCM market is so small, the only way to get the money for the salaries is if you have a product which is based on IP and requires people to pay for it. Face it, if we gave BitKeeper away for free but asked you to support us with "donations" not one of you would do so. Remember, Tom is a really bright guy doing really nice work and he's managed to gather all of $10K this year. Which we spend in a day or two. And we're also really bright people doing really nice work, but that doesn't mean you'll give us or him money.
The point is that certain market spaces simply don't work based on the tradition open source support style model. That model works great for things where there is a huge market and the product is broken so you can ask for support and people will want to pay for it. That model fails completely if you ever provide a product which works. It also fails if the market is small.
The point is that if you want Arch to succeed, encourage Tom to make it a closed source product and get some funding and create a business. Anything less is a joke in poor taste. It's great to imagine that you'll get all your problems solved for free, but that's just not going to happen.
It's not what you want to hear but I can't help that. If any of you can show how to support the salary cost it actually takes to support a product like Arch/Subversion/BitKeeper/whatever with an open source business model, we'll happily do so. We would like it much better if we could. As far as we can tell, we can't and we can also see that Tom can't either. Prove us wrong. Show us how. We'd love be shown that we don't understand. Just make sure that you show up with $100,000/day rather than $40/day which is what Tom is raising.
That response was probably me and I'm sorry if you didn't like it.
As to your comments about teamware, I agree with them and we fixed them in BitKeeper.
For example, a null update of 15MB tree over a modem takes a second or less.
An update which contains 50K of diffs to 50 files will take about 4 seconds.
One of the primary BK developers is stuck behind a modem, that's his only access.
BK is blazingly fast over a modem, I'll give $100 to the first person who shows me a system which
can do the same basic hack/checkin/commit operation faster over a slow speed link.
As for locking, we only lock the tree when doing tree operations, such as an update from another tree.
And those operations are pretty fast. We do run an integrity check over the tree after updates, which takes
90% or more of the update most time.
Arch is a subset of BitKeeper. Mr Perens claimed that arch is 'revolutionary" and that is nonsense.
The model that arch attempts to emulate was first seen by me back at Sun more than 10 years ago, I
implemented the prototype which became teamware
and it had distributed repositories. BitKeeper is largely an outgrowth of that effort.
Bob Young (redhat) once pointed out that he loved our license because
"If all the software in the world were developed out the open,
noone would give you any money. So you are encouraging the right thing".
That's true. If the world is 100% free software, noone will pay us and that's fine.
There is enough commercial software out there that we can survive.
If we ever hit the "no more customers" problem, we'll find something else to do.
Re:Where are Open Logging Repositories stored?
on
Linus Tries Out BitKeeper
·
· Score: 2, Informative
www.bkbits.net is a free hosting service we provide.
It is not the same as openlogging, those logs are on www.openlogging.org.
I got an OK from Linus to put his trees on linux.bkbits.net,
you may go poke at them there.
Note that bkbits.net sort of looks like it might evolve into sourceforge
but that's not our intent. What we want is to provide that infrastructure
so that different people can host their own projects.
bkbits.net is a cache, you go there to fill your cache but then you have everything.
BitKeeper replicates the metadata so you are nowhere near as reliant on a centralized server
like sourceforge.
Re:critical information demands replication
on
SourceForge Drifting
·
· Score: 1
http://www.bitkeeper.com
Source management where the repositories are all
replicated and peer to peer.
It's not just source management, it also does
bug tracking, in the same repositories. All
replicated, all peer to peer.
In a thread about the clustering cabal, someone apparently confused the BitKeeper licensing model with the clustering stuff. The two are seperate, BitKeeper has it's own license, and as far as I know 100% of the work we are doing for clustering is GPLed, not even LGPLed, straight GPL.
That said, I'll respond to some of the innaccurate summaries of the BK license:
a) you can't take bits of the product and use it.
That's basically true, you have to ask first. But for chunks that don't compete with BK directly, we'll happily free them. The most obvious one is the mmaped / anonymous DBM lib we wrote and that will be released under the GPL. A somewhat different version of the same code is in the process of being released under the GPL by SGI, or so I've been told.
b) You can't redistribute the product. That's just plain false. You absolutely can redistribute it, without fee. However, if you modified it, it has to pass our extensive regression test.
Etc. Since the BK license isn't complete yet, I'd thank people like Anonymous Coward to wait and see. We're trying to be good guys and make a living. Since we did all the work, we get to choose how we make that living. But we are definitely committed to letting people who are working on public projects to use this for free, and we will try to be accomodating to people at research institutions (hey, Nat) who want to use it but can't afford it.
Brian Feldman claims that CVSup is the answer to working disconnected. I can't really fault him for that since BK is publicly released yet, but I think he'll agree once he plays with it that it blows CVSup out of the water. Here are a few points: null resyncs take a few seconds in BK over 28.8 modems. BK can recreate the tree as of any point in the past trivially. I do this all the time to work on old releases: bk resync -r..beta9/home/bk/tmp/beta9 BK tracks renames. BK works through email if you want. BK supports compressed repositories (8 years of linux history takes 38MB).
When I said "you can't run CVS disconnected" I mean really disconnected. As in on a laptop on a plane. Before you say "yes you can" please consider that your definition of "can" is limited. Yes, you can edit and modify files. Can you check them in? Nope. Can you browse old history? Nope. Can you reconstruct an old version of the repository and work on that? Nope.
In short, yes, you can modify files. Hardly what people want when they say "source management". Just being able to modify files is about the same as Linus' current tarball approach.
With BitKeeper, the repository on your laptop is *identical* to the one on your server back home. In fact, if the server gets blown up, you've lost nothing. Everything is on your laptop.
It wasn't an HP representive, it was me, Larry McVoy.
While I appreciate the image of a "laser-guided Clue Anvil" it wasn't really intended that way. Eric sometimes gets going about stuff and he sometimes forgets about certain areas. I was just reminding him. I think people are making a much bigger deal out of this than I had intended.
I'm the guy who "flung" this at Eric. I meant no ill will by it and the writer who suggested that Open Source Summit turned "nasty" clearly didn't understand. Eric and I may disagree on some things, but in general, we agree on far, far, far more than we disagree on.
My point to Eric was in response to one of his statements that I found problematic. He doesn't run a business and so he isn't in tune with some of the business issues. This is an area of open discussion between myself, the OSI board, and other business people. We're making progress.
Eric did point out in his summary that I and the suits in the room were all trying to feel our way through this stuff and that the general sentiment was very positive and cooperative. I concur. It was a positve meeting, I'm glad I was there and I was honored to be included.
That would be me. I used to be a kernel hack at Sun and SGI (and before that at ETA which means you are really old if you remember them).
I don't do anywhere near as much kernel hacking as I would like to do anymore. I'm working on the source management system which will be (I hope) used for the 2.3 Linux development effort. You can get an overview at http://bitmover.com/talks/linuxworld/index.html
I'm also someone who argues with Eric a lot about business models. I've invested around $300K of my own money in working on BitKeeper and I need to make a return on my investment. But I'm also trying very hard to be a good guy in the open source world, so I'm creating a business model which works both for money and for free use of the product. I am very proud of the business model I've come up with, it is quite clever and it actually meets the current open source definition and still generates revenue.
Eric is doing his best. It is a hard job, one which most of us would be unwilling to take on, so tr and cut him some slack.
I don't mean this as a blanket endorsement of his actions - there are things he does which make me quite unhappy. But he is trying to do the right thing.
If you are unhappy with what Eric does, you should propose a better plan. Take the time and write it up and send it to the OSI. Maybe you'll be their next prez.
Slashdot Mirror
I shut the machine down so that we can reinstall it.
cvs.kernel.org is in NO WAY the "primary site for the linux kernel", it's a BK/CVS/SVN server that BitMover and Penguin Computing provided to the kernel developers.
The primary BitKeeper site is up and functioning and even if it wasn't, that's no problem because BK is replicated. Unlike CVS/SVN you'd have to find every single replica and kill that to shut down all the BK trees. It's impossible, there are 10's of thousands of replicas.
This is just a CVS problem, inspite of the noise on the kernel list the CVS server is very lightly used, maybe 3-4 people, so it's just not a big deal. The trojan horse is a big deal but the fact that it got into CVS is fairly minor and it was caught by us immediately.
It's in the LKML archives, read the thread there.
No BitMover infrastructure was compromised, the machine in question is a public machine maintained by the kernel developers.
I think your anti-BK colors are showing when you can take a situation where we prevented a trojan horse from being added to the kernel and your reaction is that we screwed up.
I'm the CEO of BitMover, we produce BitKeeper, an SCM tool which has some similarities to Arch. We're quite a bit farther along, we're 5+ years old and have a fairly large team, so I have some idea of what it takes to turn something like Arch into a real product from what it is today, which is more of a work of charity or altruism.
We've been taken to task here and elsewhere for not making BitKeeper be open source. This is a reasonable opportunity for us to explain why we haven't done so.
Tom's managed to raise $10K this year in support of all of his fine projects, arch being only one of them. We're not trying to do everything he is doing, all we do is source management. The problem is that we spend $10K every day or so in salaries. And we are dramatically understaffed compared to any other SCM company, when they figure out how small our engineering staff is they are amazed that we are able to do what we do.
The reality is that we should be at more like $100K per day in salaries to really have a good product. The problem is that all you lovely slashdot folks want to get everything for free. And you'll insist on it if you can get away with it. Given that the SCM market is so small, the only way to get the money for the salaries is if you have a product which is based on IP and requires people to pay for it. Face it, if we gave BitKeeper away for free but asked you to support us with "donations" not one of you would do so. Remember, Tom is a really bright guy doing really nice work and he's managed to gather all of $10K this year. Which we spend in a day or two. And we're also really bright people doing really nice work, but that doesn't mean you'll give us or him money.
The point is that certain market spaces simply don't work based on the tradition open source support style model. That model works great for things where there is a huge market and the product is broken so you can ask for support and people will want to pay for it. That model fails completely if you ever provide a product which works. It also fails if the market is small.
The point is that if you want Arch to succeed, encourage Tom to make it a closed source product and get some funding and create a business. Anything less is a joke in poor taste. It's great to imagine that you'll get all your problems solved for free, but that's just not going to happen.
It's not what you want to hear but I can't help that. If any of you can show how to support the salary cost it actually takes to support a product like Arch/Subversion/BitKeeper/whatever with an open source business model, we'll happily do so. We would like it much better if we could. As far as we can tell, we can't and we can also see that Tom can't either. Prove us wrong. Show us how. We'd love be shown that we don't understand. Just make sure that you show up with $100,000/day rather than $40/day which is what Tom is raising.
Making BK support TestFirst is trivial, it's done with a pre-incoming trigger in the integration repository.
You're recollection of BK repositories is mistaken, there is *zero* difference between your repository and the so called global repository.
As to the firewall issue, we've supported sync over the http protocol for a long time now.
Enjoy,
--lm
That response was probably me and I'm sorry if you didn't like it.
As to your comments about teamware, I agree with them and we fixed them in BitKeeper.
For example, a null update of 15MB tree over a modem takes a second or less.
An update which contains 50K of diffs to 50 files will take about 4 seconds.
One of the primary BK developers is stuck behind a modem, that's his only access.
BK is blazingly fast over a modem, I'll give $100 to the first person who shows me a system which
can do the same basic hack/checkin/commit operation faster over a slow speed link.
As for locking, we only lock the tree when doing tree operations, such as an update from another tree.
And those operations are pretty fast. We do run an integrity check over the tree after updates, which takes
90% or more of the update most time.
Arch is a subset of BitKeeper. Mr Perens claimed that arch is 'revolutionary" and that is nonsense.
The model that arch attempts to emulate was first seen by me back at Sun more than 10 years ago, I
implemented the prototype which became teamware
and it had distributed repositories. BitKeeper is largely an outgrowth of that effort.
Bob Young (redhat) once pointed out that he loved our license because
"If all the software in the world were developed out the open,
noone would give you any money. So you are encouraging the right thing".
That's true. If the world is 100% free software, noone will pay us and that's fine.
There is enough commercial software out there that we can survive.
If we ever hit the "no more customers" problem, we'll find something else to do.
www.bkbits.net is a free hosting service we provide.
It is not the same as openlogging, those logs are on www.openlogging.org.
I got an OK from Linus to put his trees on linux.bkbits.net,
you may go poke at them there.
Note that bkbits.net sort of looks like it might evolve into sourceforge
but that's not our intent. What we want is to provide that infrastructure
so that different people can host their own projects.
bkbits.net is a cache, you go there to fill your cache but then you have everything.
BitKeeper replicates the metadata so you are nowhere near as reliant on a centralized server
like sourceforge.
http://www.bitkeeper.com
Source management where the repositories are all
replicated and peer to peer.
It's not just source management, it also does
bug tracking, in the same repositories. All
replicated, all peer to peer.
We couldn't agree more with replication idea.
In a thread about the clustering cabal, someone
apparently confused the BitKeeper licensing model
with the clustering stuff. The two are seperate,
BitKeeper has it's own license, and as far as I
know 100% of the work we are doing for clustering
is GPLed, not even LGPLed, straight GPL.
That said, I'll respond to some of the innaccurate
summaries of the BK license:
a) you can't take bits of the product and use it.
That's basically true, you have to ask first. But
for chunks that don't compete with BK directly,
we'll happily free them. The most obvious one
is the mmaped / anonymous DBM lib we wrote and
that will be released under the GPL. A somewhat
different version of the same code is in the
process of being released under the GPL by SGI,
or so I've been told.
b) You can't redistribute the product.
That's just plain false. You absolutely can
redistribute it, without fee. However, if you
modified it, it has to pass our extensive
regression test.
Etc. Since the BK license isn't complete yet,
I'd thank people like Anonymous Coward to wait
and see. We're trying to be good guys and make
a living. Since we did all the work, we get to
choose how we make that living. But we are
definitely committed to letting people who are
working on public projects to use this for free,
and we will try to be accomodating to people at
research institutions (hey, Nat) who want to use
it but can't afford it.
Brian Feldman claims that CVSup is the answer to working disconnected. /home/bk /tmp/beta9
I can't really fault him for that since BK is publicly released yet, but I think he'll agree
once he plays with it that it blows CVSup out of the water.
Here are a few points: null resyncs take a few seconds in BK over 28.8 modems.
BK can recreate the tree as of any point in the past trivially. I do this all the time to work
on old releases:
bk resync -r..beta9
BK tracks renames.
BK works through email if you want.
BK supports compressed repositories (8 years of linux history takes 38MB).
Jim's best year was about 3/100th of 1% of the annual SCM market according to IDC.
Those people who are unhappy about him bowing out of the game would
have been better served by purchasing support from him.
People can't be expected to work for free.
Jim's best year was not enough to support one engineer at SGI or SUN.
When I said "you can't run CVS disconnected" I mean really disconnected.
As in on a laptop on a plane.
Before you say "yes you can" please consider that your definition of "can" is limited.
Yes, you can edit and modify files. Can you check them in? Nope.
Can you browse old history? Nope.
Can you reconstruct an old version of the repository and work on that? Nope.
In short, yes, you can modify files. Hardly what people want when they say "source management".
Just being able to modify files is about the same as Linus' current tarball approach.
With BitKeeper, the repository on your laptop is *identical* to the one on your server back home.
In fact, if the server gets blown up, you've lost nothing. Everything is on your laptop.
Linus doesn't use RCS, he uses nothing for the kernel - just tarballs.
He doesn't like CVS because it has obvious limitations which haven't been addressed in years:
- no file name tracking
- no change sets, grouping of changes across files
- no support for disconnected operation
That's why we wrote BitKeeper, check it out at
http://www.bitkeeper.com - the Linux port to
Merced is happening as we speak under BitKeeper.
It wasn't an HP representive, it was me, Larry McVoy.
While I appreciate the image of a "laser-guided Clue Anvil" it wasn't really intended that way. Eric sometimes gets going about stuff and he sometimes forgets about certain areas. I was just reminding him. I think people are making a much bigger deal out of this than I had intended.
I'm the guy who "flung" this at Eric. I meant no ill will by it and the writer who suggested that Open Source Summit turned "nasty" clearly didn't understand. Eric and I may disagree on some things, but in general, we agree on far, far, far more than we disagree on.
My point to Eric was in response to one of his statements that I found problematic. He doesn't run a business and so he isn't in tune with some of the business issues. This is an area of open discussion between myself, the OSI board, and other business people. We're making progress.
Eric did point out in his summary that I and the suits in the room were all trying to feel our way through this stuff and that the general sentiment was very positive and cooperative. I concur. It was a positve meeting, I'm glad I was there and I was honored to be included.
That would be me. I used to be a kernel hack at
Sun and SGI (and before that at ETA which means you are really old if you remember them).
I don't do anywhere near as much kernel hacking as
I would like to do anymore. I'm working on the
source management system which will be (I hope) used for the 2.3 Linux development effort. You
can get an overview at http://bitmover.com/talks/linuxworld/index.html
I'm also someone who argues with Eric a lot about business models. I've invested around $300K of my own money in working on BitKeeper and I need to
make a return on my investment. But I'm also trying very hard to be a good guy in the open source world, so I'm creating a business model which works both for money and for free use of the product. I am very proud of the business model I've come up with, it is quite clever and it actually meets the current open source definition and still generates revenue.
Eric is doing his best. It is a hard job, one which most of us would be unwilling to take on,
so tr and cut him some slack.
I don't mean this as a blanket endorsement of his
actions - there are things he does which make me
quite unhappy. But he is trying to do the right
thing.
If you are unhappy with what Eric does, you should
propose a better plan. Take the time and write it
up and send it to the OSI. Maybe you'll be their
next prez.