Slashdot Mirror
Tridgell Reveals Bitkeeper Secrets
wallykeyster writes "The Register is reporting on Andrew Tridgell publicly demonstrating how to interoperate with Bitkeeper. During his keynote at the Linux.Conf.Au, Tridgell connected to a BitKeeper site via telnet and used the mostly forgotten "help" tool. Ethical arguments of aside, what really counts as reverse engineering anyway?"
Well, I think it's safe to say that Linus Torvalds is wasting his time on his new RCS, 'git'. He may as well just go ahead and write a BitKeeper-compatible system, since he liked BK so much. Oh, wait. That's morally "wrong". So says the guy working on a clone of the UNIX operating system. Something doesn't quite add up here.
Bethanie: Whore...
Fan Whore
A man named Johan Mikelson who keeps track of every bit inside his head!
Does anyone remember taking thier first radio apart "just to see how it works". This in the most base form was reverse engineering. Personally if you have the resources and the desire, by all means. Find out what makes it tick. The only reason Bit-Keeper is annoyed is because they see a free product competing with thier own. Not yet persay, but in the very near future.
If we don't make light of everything, we are just stumbling in the dark - Blank
Actually I think it is good for bitkeeper. No one at my company had ever heard of BitKeeper until this controversy started. Now they're looking into using it.
Any publicity is good publicity
One of the reasons BK kept their stuff closed was so they could take accountability if anything went wrong and now exactly how every client was accessing it. That's one of the advantages most managers see with going with a commercial company rather than a OSS solution.
This isn't just copying functionality, it's putting a widely used system at risk because you don't agree with their practices. That's the same philosophy espoused by a lot of virus writers.
You're kidding right? If the BK system is so brittle that it cannot protect itself against a hostile client then it should not be hosting any source code.
If a friendly client (trying to obtain interoperability) can fundamentally break a server, just imagine what a script kiddie would do..
I've read a few exchanges from the /. crowd, read a few statements by Linus and the gang, have read McVoy's interpretation of the BK saga, and have come to one conclusion:
No one but the three people involved in this fiasco *really* knows what happened to get this situation to the stage where people begin a verbal free-fire in public.
McVoy is a business man; true to his heart, he needs to keep the BK user strung out on his code. Hell, I would feel the same sense of outrage that he feels if someone threatened to kill my cash cow. Don't pretend that every one you wouldn't feel the same way if it was *your* revenue stream. To me, anyone who claims an absolute vow of poverty is looking for a monastery to live in. Everyone I know would fight to protect a source of financial income.
Selfish? You bet. But nature has created more selfish beings than egalitarian ones. Nature favors pragmatism.
But McVoy could have let this one ride a bit more. It is just a matter of time before someone cracks his model. Then he will have to play the same game as Microsoft and Adobe only on a different level. Too bad for him, though, that his inexpensive advertising scheme didn't last. That is another little detail that goes relatively "un-remarked" upon in the various forums I've read. Larry had one of the hottest programmers in FOSS using his SCM. In fact, this Man Of The Year lavished all kinds of praise on his progeny! You would have to pay more than the "free" license fee for that kind of advertising. Shit, probably A LOT more. If Linus had been paid for his endorsements, that could have added up to quite a sum of money. Larry has wisely kept those funds securely in his pocket.
Again, I'd do that too. The monks of this world can keep their vows.
Linus? Well, it was kind of hard to turn down a free license for one of the best SCMs on the market. If I had been in his position, I would have grabbed the product and ran. In fact, I would like to personally thank Larry for helping juice the Linux kernel development. I know SCO has been rummaging around in the Linux closet for evidence that it was their intellectual property that made the kernel advance so quickly. I believe that Larry's BK contribution probably made the significant increase in kernel production possible. Judging from Linus' angst and outrage, I think he believes that too.
But Linus is being a bit thin skinned. Does he believe he is the ONLY programmer that has been burned by relying on a proprietary product for their work? Didn't he listen to all the people who had been telling him about *their* bad experiences with proprietary lock-in? From what I've read in the past, they had plenty of legitimate worries that this was going to happen. I'm sure that Linus knew it would happen someday too. He's just pissed that it happened NOW as opposed to LATER.
Boo hoo, get over it, this too will pass, etc. But why attack Tridgell in public? Hmmm.... That does raise some interesting questions. And why get all bitchy about it?
There is something we are not getting in this little soap opera. Tridgell is silent, probably for good reason. But why would Linus take him to task knowing that he would not be able to respond publicly?
And Perens? This is a slugfest that only Gates, Darl, and RMS would love - all for differing reasons. Why does Perens feel compelled to call out Linus over his treatment of Tridgell?
I thought the points made by some posters about just how Tridgell was sniffing packets to see the metadata protocols is extremely insightful. To have BK protocols running on his network would require that he be operating a client and server somewhere where he could see it, no? What network was he sniffing if he didn't have a license?
What amazes me is that the attempt to get BK's protocols didn't happen *sooner*. With all of the pissing and moaning that erupted when Linus started using BK, I would have thought there would have been someone doing what Tridgell was accomplishing years
"Rocky Rococo, at your cervix!"
These political spats are fun, but realistically speaking, this is degenerating into an episode of "The Simple Life."
Next thing you know, Torvalis will be breaking up with Perens because "well, he knows what he did."
Person 1 liked a tool. Person 2's actions caused the first person to lose rights to his tool. Person 1 vents. Person 3 vents on Person 1. BFD.
Soon, there will be a group hug and an exchange of hair care products. End of story. Welcome to "life in the big leagues of software." Tune in next week, when Person 5 attempts to purchase a voltage regulator.
Replace "AIM" with "BK" in the above text, and see if you still believe what you're asserting.
I forget what 8 was for.
Am I the only one here who things that real freedom is achieved only when you can tollerate an opposing point of vew?
Why can't BK develop, and sell software under any liscense they choose? Why isn't Linus free to use that solution if he so chooses? Why is it ok for us to rip on the MS type people for behavior that is OK for us to emulate in support of free and open software?
Why is it ok to try and screw BK over, who spent a great deal of money to develop this?
But this is slashdot. A slashdoter who didn't build his own computer is like a Jedi who didn't build his own lightsaber!
You can take accountability for a product when it is used according to a contract and not take accountability for it when it is misused. The manufacturer/service provider takes accountability under specific conditions.
Your suggestion that it is necessary to keep the BK protocol closed because the BitKeeper people want to be held accountable is just plain bogus. They did it to prevent competition.
Also, you still can't get docs on a whole lot of BIOS stuff which was reverse engineered years ago, because of indefinite-duration contractual obligations.
In any case, certainly, using telnet to type "help" and reading the resulting documentation does not count as reverse engineering. It is instead a form of RTFM/RTFD.
> One of the reasons BK kept their stuff closed was so they could take accountability if anything went wrong and now exactly how every client was accessing it.
Yeah, I know and I think it is bullshit.
Nobody should rely on the client to be nice.
A while ago, any computer running ICQ could simply be shot down by a wrongly formatted package that ICQ would parse and break on it and (in the days of Windows 9x) take the OS with it.
From what I read, BitKeeper has the same problem : a client can completly trash the repository if it doesnt respect the protocol. Which I call slopy design.
I client shouldnt be able to make more damage than the user has rights and HEY! it's a f*cking version control system. I DEMAND that any change done by any client can be reversed easly (after all, this is what I use a VCS for).
For me, it looks like BitKeeper has a HUGE reliability problem in that it relies far too much on clients respecting the protocol and that they cry out that loud to avoid people from looking closer at this design problem.
I have discovered a truly remarkable proof for my post which this sig is too small to contain.
Not if you were invited.
Scenario: Bob is forced to buy a client for a SCM he doesn't like. Bob invites Ted to come over to his house and poke around on the client. Bob has permission to use the client AND interact with the server. Ted is looking at the server from the client that his friend purchased.
I don't think that would be something that could be construed as "illegal". It might be "actionable" in a civil tort sense.
That might be why Tridgell is keeping quiet.
"Rocky Rococo, at your cervix!"
Of course that is until people look deeper into what the publicity is all about. McVoy pretty much illustrated the inherent dangers of not being Open Source -- that at a whim (of a madman?) all your data are belong to them.
Worse yet, we've illustrated that here's someone who's willing to do just that...yank his product from under a high profile project.
If your company is looking into using BK, you may wish to take these recent events into consideration or at least bring them up to those making the decisions.
Most BK servers are part of the internet, opening a simple telnet connection to a well known port is no secret at all. If Tridge could corrupt BKs database any blackhat could. There's really no excuse for implementing poor security or none at all in BK. For the benefit of BitMover i assume that they did put proper security in place and safeguarded against accidental corruption of the BK database. Regardless of that your argument is moot.
"By the way if anyone here is in advertising or marketing... kill yourself." -- Bill Hicks
Maybe it's the absence of audience laughter cues or something, I don't know, but the irony in Tridgell's demo and in The Register's writeup of it was entirely obvious to me. I had a really good chuckle.
... so Tridgell made his point admirably that there has been a mountain made up out of a molehill of nothingness.
Didn't you RTFA, maybe? Here are the relevant sentences:
Tridgell demonstrated the procedure to disprove accusations that his detractors in the Torvalds/McVoy camp had made against him. Principally, that he was some kind of "an evil genius" reverse engineer.
The demo showed that the work was obviously not reverse engineeering in any real sense of the word, nor was it even remotely describable as "genius" work
And he made us laugh at the same time too. You didn't?
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
What's suprising is how many people actually believe that's all Tridge had to do reverse engineer the BK protocol. While I'm willing to buy that he didn't need a BK client, the demo is obviously at best a trivial first step.
Unlike most people, I can actually respect McVoy's decision to remove the free client (though not necessarily in the angry way he did it). The SAMBA and BK situations aren't exactly identical. Tridge's reverse engineering for SAMBA is not *that* big a deal to MS. So what if a Windows server gets fooled into thinking that some Linux or VMS box is a Windows machine? While this service is immeasurable to many of us, we represent a small part of MS's customer base. It's unlikely that such a thing will enable anyone to budge MS in it's golden goose OS or office productivity markets.
But I think the situation is a little different with the BitMover guys. It's probably not THAT incredulous to imagine someone coming up with a free BK client that is better than the free version, and at least competitive with the paid-for version. If such a client is released, then no one would have a reason to buy BitMover's non-free client, thus putting a dent in BitMover's income. After all, it's not like BitKeeper has the channels to force their product down people's throats while threatening vendors who dare to sale someone else's product. They don't have the power to articially manipulate the "free" market for their benefit.
So, IMHO, the difference is this: The Free Open Source development community doesn't have the resources to affect a goliath like MS in any significant way. But a smallfry like BitMover? The FOSS bandwidth is there to bring a company like this to its knees and McVoy knows it. No doubt he's reaped many benefits from the free BK client and his company's association with Linux, but now the other shoe has officially dropped...
Now, I'm not arguing that BitMover doesn't deserve such a fate or that I'm siding with them. It is an open market after all and may the best man win. However, I can at least understand why McVoy and crew would be threatened by a free product competing with their non-free product. Yes Tridge building a new client *does* release Linux source from propietary SCM lock-in which is good for the *rest* of us. But let's at least admit that it's also a valid economicthreat to BitMover as well. Again, why buy their non-free client, if I can get a good enough free client off sourceforge? On a purely economic and pragmatic basis, both sides can be right.
For the record, I don't think Tridge is in the wrong and I don't think he's "out to get" BitMover or McVoy. However, I think an unintended side-effect of his development could be the downfall of BitMover.
Tridgell = Samba = Screws Microsoft = Good
Any questions?
Please explain what is illegitimate about reverse engineering Bitkeeper's network protocol in an effort to distribute a free software program which is network-compatible with the proprietary Bitkeeper program.
Digital Citizen
Truer words were never spoken, and I thank you for posting them. Sad thing is the rest of your comment indicates you have set them aside already, or perhaps never had them.
There is absolutely nothing unethical in what Tridge did here, at least insofar as has been mentioned in any of the reporting on this in the past few days that we've both had access to. There is absolutely no ethical obligation to keep an agreement you were not a party to. The rest of your rant assumes facts not in evidence, without any source, and has the definate whiff of BS to me.
In fact, what Tridge has done here is the epitome of ethical behavior. Linus is stung now, understandably disoriented and angry because he's been proven wrong and, being human, his first response is to lash out at Tridge instead of thanking him. Give it a few years though... once his wounded pride settles down I'm sure he will, in fact, thank Tridge for this.
Locking your data into a proprietary single-vendor format for the sake of temporary convenience was never a good idea. Everyone told Linus this, but he was too smart to listen. Now exactly what he was warned about has happened. And it was inevitable all along - if Tridge hadn't done it someone or something else would have - McVoy was a ticking time bomb. The fact that the guy isn't very stable didn't help, but honestly - McVoy could have been a saint and the thing would have still been a ticking time bomb. If Tridges actions resulted in it going off a little sooner than otherwise, then he saved Linus and many others trouble in the long run. Replacing BK wasn't going to get any easier...
=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Friends don't let friends enable ecmascript.
cePuller was written for two reasons. First, because the terms of the free BitKeeper license are not suitable for some members of the free software community. This can occasionally lead to frustrating situations where a free software developer wishes to access a BitKeeper repository, and is either unable to, or can only access it via a gateway that translates the repository into another format, possibly losing some information.
The second reason for writing SourcePuller was to provide a open library of routines that can talk to BitKeeper servers and manipulate local BitKeeper repositories. It is hoped that this library will be used by the authors of other source code management systems to allow them to interoperate with BitKeeper. Eventually this should result in an improvement in the quality of the various bk repository gateways.
SourcePuller is not intended to be a full replacement for BitKeeper. Instead, you should use SourcePuller as an interoperability tool for situations where you cannot use bk itself. SourcePuller is missing a large amount of core functionality from BitKeeper, and thus is not suitable as a full replacement.
Update - April 2005
-------------------
As you probably know, there has been quite a fuss lately about this code and the fact that BitMover has now withdrawn the free version of bk. First off, I would like to say that this result was not the intention when I wrote this code. I had hoped that an alternative open client would be able to coexist happily with the proprietary BitKeeeper client, as has happened with so many other protocols. An open client combined with the ability to accurately import into other source code management tools would have been a big step forward, and should have allowed BitMover to flourish in the commercial environment while still being used by the free software community.
I would also like to say that BitMover is well within its rights to license BitKeeper as it sees fit. I am of course disappointed at how BitMover has portrayed some of my actions, but please understand that they are under a lot of pressure. Under stress people sometimes say things that perhaps they shouldn't.
As I have stated previously, my code was written without using bk. Some people expressed some skepticism over that, perhaps because they haven't noticed that bk servers have online protocol help (just type 'help' into a telnet session). I don't think it is unreasonable to assume that this help was intended for people like myself who wished to implement new clients.
I would like to thank all the people who have supported me in the development of this tool by providing useful advice both before, during and after the development of the code. I tried to consult with a wide range of interested parties and the feedback I got was certainly appreciated.
Finally, I would like to point out the obvious fact that Linus was perfectly within his rights to choose bk for the kernel. I personally would not have chosen it, but it was his choice to make, not anyone elses. Linus is now in the unenviable position of changing source code management systems, which is a painful task, particularly when moving away from a system that worked as well as bk did. If you want to help, then help with code not commentary. There have been enough flames over this issue already.
One of the reasons BK kept their stuff closed was so they could take accountability if anything went wrong and now exactly how every client was accessing it.
Client-side security is no security at all.
Security through obscurity is no security at all.