This is not even CLOSE to hacking oracle's data files and then complaining.
It is exactly like hacking oracle's data files and then complaining. If you don't understand that, you don't understand BitKeeper's mode of operation. Here's a hint, you get a repo by running 'bk clone'.
We are not interested in what BitKeeper does, except as far as what Linus requires.
On the contrary, people seemed to be very interested on what BK does. Otherwise, the BK-CVS bridge was good enough. The only reason for wanting BK's metadata was to import the history into another system in the same way BK did the history.
If people were really deriving their own answers, all they needed was the patches. That's all BK got in the beginning. The rest was BK's work.
If you don't understand that, you just don't understand the community.
I didn't realize you had been appointed spokesman for the Open Source community.
Read this again "Of course you can. It's trivial to get the entire version graph using bk."
What part of 'using bk' did you not understand?
I think the whole point of not allowing people working on both bk and another SCM at the same time boils down to not checking your results against bk.
It's easy to see Open Source developers going "Hmm, this merge is really thorny, let's see what BK does... ah! maybe if I change my algorithm like this".
McVoy's license basically said "Compete with us, but derive your own answers, don't peek at what we did". I think this is fair. Linus seems to thing this is fair. Tridge doesn't seem to think this is fair. He seems to like looking at the answers.
He is claiming two things; that reverse engineering is wrong, and that tridge's client may somehow break BK. To the first point, he is wrong; not only is it a legally-protected activity (at least in the U.S.) but it is a fundamental engineering method that has been guiding engineering as long as there's been engineering, and then some.
Sorry to inform you that it is you who is wrong. Reverse engineering is legal only in the context where you paid for something, and you want to make your software interoperate with that something. The key here is you paid for that something. Reverse-engineering something you got for free with the condition that you would not reverse-engineer has not really been tried in court.
To the second point, he is again wrong; clients do not break servers. Servers break servers, when they do something stupid in response to a client request.
Wrong again. As soon as you talk about clients and servers, it shows you have not worked on distributed systems. The problem is more like copying Oracle's.dbf files over and hacking them with your own tool and then going to Oracle and telling them "my database broke" than accessing them with SQL.
The corruption that McVoy mentioned is not only entirely plausible. It's almost a cerainty.
Of course you can. It's trivial to get the entire version graph using bk. This is the kind of FUD that makes BitMover look bad. There was never any locked-in data. Even the so called meta-data people argued over and over in the kernel mailing lists was always available using nothing more sophisticated than the 'bk prs' command.
Repeat after me; anything coming in over the Internet is evil. Never, never trust any information coming in over the Internet. Nothing an user can do should be able to corrupt the repository. Nothing.
Repeat after me; software must be bug-free. Nothing a user can do should be able to crash the computer. Nothing.
Yeah right. Just because this one guy has started a pre-alpha project to reverse-engineer BK, suddenly BitMover is going to go out of business and all its programmers are going to lose their jobs.
As a matter of fact, yes. It seems you've never worked in a distributed system before. If you allow some pre-alpha software to start messing with the integrity of a repository, the messed-up changes propagate and suddenly everybody is experiencing the same problems.
If you search the linux kernel archives for this, you'll find that it has happened before. Someone hand edited one of the metadata files under BitKeeper control and the repository corruption propagated. BitMover had to put in special code and release a new version of BK that specifically checked for the problem.
What I'm saying is: allowing someone who doesn't know the invariants that BitKeeper maintains to start messing with repositories is bound to cause BitMover an enourmous ammount of support. If (as they claim) they were already spending $500,000/yr supporting the Free Product, that number could have easily tripled by allowing a pre-alpha tool to be used in the wild.
Oh, and that makes it OK? So if I hate the GPL because it doesn't let me do what I want with the software, and I refuse to use GPL products, then it's OK to flame Richard Stallman, boycot the Free Software Foundation, and criticize anyone who uses GPL software?
Wouldn't my time be better spent creating a proprietary solution?
Go read the previous interviews to Linus and Larry McVoy. Larry had worked on TeamWare at Sun. He was already known for his ability to write source control management systems. He explained to Linus what he could give him. He would have succeeded selling BitKeeper anyway.
It's true that BitMover got marketing from Linux, but to say they got more than what they gave is plainly wrong.
I don't think Larry needs any help in selling his software. If he did at the beginning, well, the Linux Kernel has already given it to him. He has enough momentun now, and the product is so far ahead of any alternative, that he'll easily continue selling it.
He's basically cuting loose a bunch of open-source fanatics that constantly whine, are a big support load, and don't pay!
Frankly, I'm surprised he kept going for so long. If I had to take that sort of personal harassment from customers that are paying me money, I would think twice before doing business with them. If I had to take it from people who are getting my product for free, I would have walked away a long time ago.
Slashdot Mirror
It is exactly like hacking oracle's data files and then complaining. If you don't understand that, you don't understand BitKeeper's mode of operation. Here's a hint, you get a repo by running 'bk clone'.
On the contrary, people seemed to be very interested on what BK does. Otherwise, the BK-CVS bridge was good enough. The only reason for wanting BK's metadata was to import the history into another system in the same way BK did the history.
If people were really deriving their own answers, all they needed was the patches. That's all BK got in the beginning. The rest was BK's work.
If you don't understand that, you just don't understand the community.
I didn't realize you had been appointed spokesman for the Open Source community.
Read this again "Of course you can. It's trivial to get the entire version graph using bk." What part of 'using bk' did you not understand? I think the whole point of not allowing people working on both bk and another SCM at the same time boils down to not checking your results against bk. It's easy to see Open Source developers going "Hmm, this merge is really thorny, let's see what BK does... ah! maybe if I change my algorithm like this". McVoy's license basically said "Compete with us, but derive your own answers, don't peek at what we did". I think this is fair. Linus seems to thing this is fair. Tridge doesn't seem to think this is fair. He seems to like looking at the answers.
He is claiming two things; that reverse engineering is wrong, and that tridge's client may somehow break BK. To the first point, he is wrong; not only is it a legally-protected activity (at least in the U.S.) but it is a fundamental engineering method that has been guiding engineering as long as there's been engineering, and then some. Sorry to inform you that it is you who is wrong. Reverse engineering is legal only in the context where you paid for something, and you want to make your software interoperate with that something. The key here is you paid for that something. Reverse-engineering something you got for free with the condition that you would not reverse-engineer has not really been tried in court. To the second point, he is again wrong; clients do not break servers. Servers break servers, when they do something stupid in response to a client request. Wrong again. As soon as you talk about clients and servers, it shows you have not worked on distributed systems. The problem is more like copying Oracle's .dbf files over and hacking them with your own tool and then going to Oracle and telling them "my database broke" than accessing them with SQL.
The corruption that McVoy mentioned is not only entirely plausible. It's almost a cerainty.
Of course you can. It's trivial to get the entire version graph using bk. This is the kind of FUD that makes BitMover look bad. There was never any locked-in data. Even the so called meta-data people argued over and over in the kernel mailing lists was always available using nothing more sophisticated than the 'bk prs' command.
Repeat after me; anything coming in over the Internet is evil. Never, never trust any information coming in over the Internet. Nothing an user can do should be able to corrupt the repository. Nothing.
Repeat after me; software must be bug-free. Nothing a user can do should be able to crash the computer. Nothing.
Ahh, now it doesn't seem so easy, does it?
As a matter of fact, yes. It seems you've never worked in a distributed system before. If you allow some pre-alpha software to start messing with the integrity of a repository, the messed-up changes propagate and suddenly everybody is experiencing the same problems.
If you search the linux kernel archives for this, you'll find that it has happened before. Someone hand edited one of the metadata files
under BitKeeper control and the repository corruption propagated. BitMover had to put in special code and release a new version of BK that specifically checked for the problem.
What I'm saying is: allowing someone who doesn't know the invariants that BitKeeper maintains to start messing with repositories is bound to cause BitMover an enourmous ammount of support. If (as they claim) they were already spending $500,000/yr supporting the Free Product, that number could have easily tripled by allowing a pre-alpha tool to be used in the wild.
As a businessman, you should understand that businesses are not nice, they are not generous, and they cannot be trusted at their word.
And OSDL is different from any business because?
Oh, and that makes it OK? So if I hate the GPL because it doesn't let me do what I want with the software, and I refuse to use GPL products, then it's OK to flame Richard Stallman, boycot the Free Software Foundation, and criticize anyone who uses GPL software?
Wouldn't my time be better spent creating a proprietary solution?
Go read the previous interviews to Linus and Larry McVoy. Larry had worked on TeamWare at Sun. He was already known for his ability to write source control management systems. He explained to Linus what he could give him. He would have succeeded selling BitKeeper anyway.
It's true that BitMover got marketing from Linux, but to say they got more than what they gave is plainly wrong.
I don't think Larry needs any help in selling his software. If he did at the beginning, well, the Linux Kernel has already given it to him. He has enough momentun now, and the product is so far ahead of any alternative, that he'll easily continue selling it.
He's basically cuting loose a bunch of open-source fanatics that constantly whine, are a big support load, and don't pay!
Frankly, I'm surprised he kept going for so long. If I had to take that sort of personal harassment from customers that are paying me money, I would think twice before doing business with them. If I had to take it from people who are getting my product for free, I would have walked away a long time ago.
Uh, did you read Linus's comments? He is still endorsing his product, even if he won't use it anymore.
I only steal on my own free time. They can't fire me for that.