BitKeeper Love Triangle: McVoy, Linus and Tridge 850
erktrek writes "NewsForge has given a brief interview to the parties involved in the (inevitable?) BitKeeper debacle." Here is some of our previous coverage.
This discussion has been archived.
No new comments can be posted.
BitKeeper Love Triangle: McVoy, Linus and Tridge
Related Links Top of the: day, week, month.
It is easier to write an incorrect program than understand a correct one.
Uh, a summary? (Score:3, Insightful)
Quick Summary (Score:5, Informative)
Linky [com.com]
BitKeeper sees two problems (Score:5, Informative)
Larry McVoy sees two problems with Andrew Tridgell's reverse-engineered, free tool. One is "condoning reverse engineering". The other is, in his words:
Re:BitKeeper sees two problems (Score:5, Insightful)
Re:BitKeeper sees two problems (Score:4, Informative)
Andrew Tridgell is the author or rsync, and one of the founders and major developers of samba (you know, that program that lets you connect to windows file sharing), and I don't really see how this is different from samba (and surely no-one wants rid of that?)
Re:BitKeeper sees two problems (Score:4, Informative)
This has happened before. See for the discussions about LMcV and lmbench in the 90-es. In fact, the moment I saw that Linus has AGAIN selected a Larry McVoy tool my first thoughts were "Oh no, not another lmbench". I bet I was not the only one.
Considering that he is also known to be litigation happy I am not going to qualify his behaviour that time and this time. Just read the LKM on both occasions as well as some of his musings. They are selfexplanatory.
Re:So it's about control (Score:5, Insightful)
Let's look at reverse engineering for a minute. First of all, even the DMCA has a clause that protects reverse engineering for the purposes of interoperability. That's right, one of the most draconian media laws we've ever seen protects the right to figure out what something does so that you can interface to it. This is precisely what Tridge was attempting to do.
For the user, Free Software is about not being locked into a proprietary solution. BK is apparently the antithesis of this - they would very much like to lock you into BK. This is made abundantly clear when McVoy says "If we sat back and did nothing about Tridge then we are implicitly condoning reverse engineering."
For me, that tells me everything I need to know about bitmover. Reverse engineering is a necessary and even protected activity. If you want to lock people into your solution, you just don't get it.
What McVoy is saying, and what you are apparently agreeing with, is that it's reasonable that BK should be such a house of cards that it is possible to knock it over in such a way that you can't put it back again. McVoy tells us how unreliable and unmaintainable BitKeeper is in the following bit:
Why on earth is there no way to fix them by hand? Why, in fact, can I not just turn back the clock to a point where the system was not corrupted? Are they really passing information around without sanity checking? I'm sure a lot of people are saying "I can tell this asshole isn't a programmer" as they read this, but does something like this really give you a warm fuzzy feeling, knowing that if your BK DB is somehow corrupted, you're going to need a custom release of the BK software?
Was going to provide? If bitmover had seen interoperability as a goal from the beginning (the very least I will accept out of proprietary software that is part of a core business process) then it would have been provided already, Tridge would never have had reason to write tools that interfaced to BitKeeper via its internal protocols (Assuming that is what is happening, which all of this strongly implies - I don't know just what was written obviously) and this whole thing never would have happened. Instead, what happened here is that bitmover decided that they didn't want what they saw as competition, and wants to be able to lock their customers into their product, preventing them from retrieving the entirety of the data - data which belongs to them.
Tridge's efforts were entirely prudent. Functionality was needed and was not present, and he sought to add it. Bitmover was apparently not very interested in providing it; otherwise why write anything? Tridge's efforts may not have been helpful - I'll wait to see some code (or not) before I pass judgement there. However, I am inclined to say that they were helpful, in that I do not believe that the Linux development process should involve proprietary tools when there are free tools that will do the job. If Linux needs functionality not currently present in Free software, IMO the proper course to follow
Re:BitKeeper sees two problems (Score:4, Funny)
That's not true. We here at Slashdot never take quotes out of context. What possible reason could you have for trying to mislead the readers like this?
Disclaimer: I am... ...affiliated with BK.
Ahh, now the sordid truth comes out!
Re:The article in summay (Score:4, Funny)
Re:The article in summay (Score:3, Funny)
Re:Uh, a summary? (Score:4, Interesting)
Probably something to do with the fact that while the horse was giving rides to one Linus it was also biting bystanders, kicking anyone who ever even thought about getting another horse and kept leaving copious amounts of manure on various people's front lawns. Not to mention that after a short while it became apparent that the "gift horse" was not in fact a horse at all but an obnoxious ass named Larry dressed up in horse-skin who concocted the whole sharade in order to satisfy his greed and pitiful need for accolades for his "unique" and oh-so-impossibly-clever Capital Horse Idea(tm). So after the ass was indeed beaten and its teeth pulled before it run away heehoing, Linus was left with a decaying horse-skin of sentimental value to him and a lot of people with clean lawns and out of range of hoofs and thus much better for it. And the world kept on turning...
You git! (Score:5, Funny)
Or is this Linus making a not-so-subtle pot-shot at Larry McVoy?
Re:You git! (Score:5, Informative)
Quote Linus:
Seems clear who he is a bit bitter at.
Re:You git! (Score:5, Insightful)
Re:You git! (Score:5, Insightful)
I think "Tridge" is being scapegoated because Larry McVoy is Linus' buddy, so he doesn't want to lay the blame on him.
Re:You git! (Score:4, Insightful)
According to the article Andrew Tridgell may have worked for ODSL, but he didn't use BK. I'm not sure how you can be bound by the licence of software you're not using.
My opinion hasn't changed (Score:5, Insightful)
Reverse engineering is particularly warrented for the purposes of interoperability, and this seems to have been the motivation of Andrew "Tridge" Tridgell. He wasn't reverse engineering BitKeeper to "steal" McVoy's ideas, he was doing it so that he could gain access to the Linux kernel without using non-free tools. McVoy's position is one that you might expect from Microsoft on Samba, but not from someone that claims to support the ideals of free software.
Bottom line? I'm with Tridge on this one, McVoy is wrong, what he wants and seems to expect is effectively patent-level protection of his ideas.
Re:My opinion hasn't changed (Score:3, Interesting)
What is interesting is if other open-source projects will follow Linus' footsteps. KDE, I believe, still uses BK.
Re:My opinion hasn't changed (Score:5, Informative)
J
Re:My opinion hasn't changed (Score:4, Informative)
The joke started about a week before April 1 when the admins were comfortable doing the switch to subversion and just needed a date and 12 hours to do it. The first proposal when they announced this to kde-devel was do to the conversion on March 31, so that everyone would wake up to an announcement that KDE has switched to subversion, and then have to figure out if it was a joke or not.
The switch didn't happen then, but it is close if it hasn't happened already.
Comment removed (Score:4, Informative)
Re:My opinion hasn't changed (Score:5, Insightful)
Re:My opinion hasn't changed (Score:4, Insightful)
I'm not familiar with BitKeeper, but I use to do pre/post sales technical work on one of the big (at the time) SCM tools, and I see nothing in Bitkeepers description that looks terribly original.
That is not to criticise it, the real value in SCM tools is doing their job well, being well integrated into the programmer work environment, and keeping out of the way except where they add value, not being innovative computer science.
It is possible Bitkeeper have devised mysterious complex mathematical enhancements on the theory of changesets - but I doubt it, and even if they have I doubt that is what adds much of the value perceived in BK.
Indeed many "old time" developers use to complain bitterly when we were selling SCM that the modern tools often lacked integration features the older tools had.
Although this was largely market driven, trying to appeal to as big a market as possible, where as many of the earlier tools targetted a much smaller toolset (Cobol on IBM Mainframes for example), not least because there were less tools around then, and interoperability and portability were more talked about than actually implemented before the late 1980's.
Re:My opinion hasn't changed (Score:5, Insightful)
I say McVoy was trying to tie his proprietary product to the linux kernel development. Can't fault him, really, he's acting as a suit. The geeks that let him do that: shame. The ones that called his shenanigans: kudos.
It doesn't matter if it's the best tool for the job. What matters is that the tool is not entirely within your control. It's like the chinese buying aircrafts from the americans, and the americans building a remote shutoff switch in the target aquisition radar. (bad analogy, I know... Sowwy.)
Re:My opinion hasn't changed (Score:5, Insightful)
Reverse-engineering is perfectly legal (when done correctly) and is employed by proprietary folks regularly. How do you think the PC-clone market got started?
What? (Score:5, Insightful)
Wow, I had better call my lawyer next time I decide to surf the web!
Re:What? (Score:5, Informative)
Re:What? (Score:5, Insightful)
Re:What? (Score:5, Informative)
Jeremy Allison,
Samba Team.
Re:What? (Score:4, Insightful)
I find it difficult to believe that you know more about clean-room development of software compatible with proprietary software than does tridge at Samba.org. :-)
Re:What? (Score:5, Informative)
Re:What? (Score:5, Insightful)
Given his success at SAMBA, it's a reasonable bet that
he can do it
he's ethical
The obvious question is, how much better will we all be when a good merging application is as free as the fundamental theorem of calculus?
Re:What? (Score:5, Interesting)
Wait a second, that is how BitKeeper works? _They_ host the server and you use a non-free client to access it? And Linux uses _that_ as its main repository? Someone wake me please.
Re:What? (Score:4, Interesting)
It is a bit disturbing, isn't it? Almost as disturbing as these various people trying to claim that Tridge is immoral and/or evil for reverse-engineering Bitkeeper's file format(s) and/or network protocol(s). Bizarre.
I've lost a fair chunk of respect for Linus over this. Mind you, Linus has a hell of a lot of my respect he can easily afford to lose :), but the cheek of him slagging off Tridge (when Tridge almost certainly did nothing wrong) is pretty offensive.
I'm glad it's finally over and Larry has taken his bat and ball and gone home to sulk. Maybe he can buy himself a few new toys with that half a million per year (or whatever) he'll now be saving in free-bitkeeper-maintenance costs *roll of eyes*.
As an aside, (begin sarcasm) I've often wondered how it is that FreeBSD can possibly maintain a kernel even remotely comparable to the Linux kernel. After all, they use CVS, which is the crappiest source control system there is... right? :-)
Server Should Enforce Immutability (Score:4, Insightful)
Someone looks at the source and makes it better.
What happens if it corrupts older files?
That sounds like a problem that can only occur if the server doesn't enforce proper ACLs. Older files cannot be corrupted by "updates" or "checkouts" unless there's an architectural problem with the server.
A source control system should enforce immutability of older revisions. Only administrators should have any delete powers at all to clean up, and the idea of modification of committed revisions should be right out! I expect the server to enforce this.
If word gets out that that damn BitKeeper source control system has corrupted 6 months worth of work, that's bad publicity.
And it's their own fault for that bad publicity. They should have written code that properly enforced immutability of older stuff.
Of course, if that data cannot be recovered from backups, then it's Linus's fault.
Re:My opinion hasn't changed (Score:5, Insightful)
He hasn't even clicked through one. He wasn't useing the BK client, and was thus compleatly unbound by what BitMover thought and in the right to do what he was doing.
The day he installs the BK client and clicks through it's liscence, you'll be 101% right, until then I'm with tridge on this one.
Re:My opinion hasn't changed (Score:4, Insightful)
IMO, it seems a little hypocritical that he's starting the name-calling only after the reverse-engineering isn't benefitting himself.
Re:My opinion hasn't changed (Score:4, Informative)
What project? What OS?
AFAIK Linux is a "forward" engineering project (the device drivers might be different in some (most?) cases)
Re:My opinion hasn't changed (Score:5, Insightful)
I'm not sure you know what reverse engineering means. Linux does not need to, and never needed to, reverse engineer Unix or any operating system. Linux is an independent implementation of freely published POSIX specs. The way it works internally is entirely a new invention. Similarly, many Linux programs are designed to emulate the same core functionality as other programs (some of them non-free), but can do so without reverse engineering because the protocols and file formats are freely available, and the implementation can simply be reinvented from scratch.
There are only three areas where reverse engineering happens in Linux development: writing tools (like OpenOffice) that open proprietary file formats, writing emulators like Wine that implement the Windows API, and writing device drivers for devices that don't have full specs. However, I don't think that those account for the majority of the focus of Linux, and it's certainly not hard to make use of Linux without ever running across any of these three areas. (For example, there are lots of device drivers that did not make require any reverse engineering.)
Reverse engineering has a very particular meaning. Writing something similar to something else is not reverse engineering.
Can't have your cake... (Score:4, Insightful)
Re:My opinion hasn't changed (Score:5, Insightful)
McVoy is trying to lock people - his customers, for chrissakes - into BitKeeper by preventing them from getting data out of the BK repository in any way of which they do not approve. 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. 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. A client request that would result in database corruption should be denied. There should be nothing you can do, for example, in a SQL query, that will stop the RDBMS from working. A SCMS is supposed to maintain old revisions and let you work on new revisions, and handle merging code, right? Where in there does it say that the client should be able to corrupt the database? This is what McVoy is saying is a risk with a third party client. In other words, BK is not designed with reliability in mind. Do you trust BK? Do you think McVoy is making reasonable statements? McVoy IS down the same creek as Microsoft. Vendor lock-in, trying to prevent people from developing interoperating tools, and placing blame for failure of their systems on other companies. That sounds quite a bit like Microsoft to me. If they ever get a monopoly, we'll see how they do on the fair trade practices, but in the meantime they're Microsoftian enough for me to avoid them like the plague that they apparently are. It may be a fantastic product when you don't want to do anything it doesn't provide for, but frankly I think that's a bullshit way to purchase (or, as we do today, license) software and not at all good for the long haul.
Ewww (Score:5, Funny)
Paraphrase ... (Score:4, Insightful)
So whether you take the view that Bitkeeper isn't compatible with the principles of the Linux project, or vice versa, is moot. It's simply a wonder it took so long for things to come to a head.
CC.
What the... (Score:3, Insightful)
Larry has a very clear moral standpoint: "You can compete with me, but you can't do so by riding on my coat-tails. Solve the problems on your own, and compete _honestly_. Don't compete by looking at my solution."
And that is what the BK license boils down to. It says: "Get off my coat-tails, you free-loader". And I can't really argue against that.
That's bollocks. Reverse-engineering is not riding on the coat-tails of anyone. It ensures that the product is 100% compatible.
If Linus truly believed that, he'd have worked to drop Tridge and keep BitKeeper. However, I'm quite disappointed in Linus implicating Tridge as the evil in this situation.
Re:What the... (Score:3, Interesting)
It's worse than that (Score:5, Insightful)
It's not just bollocks, it's rank hypocrisy coming from Linus Torvalds, who would be a completely unknown, minor software developer in Finland if he hadn't ridden -- dry-humped, actually -- on the coattails of Unix. The same goes for his last employer, whose business is built on a reverse-engineering of x86 microcode.
Ordinarily, I'm quite fond of Linus, but in this case, he's being a ridiculous ass.
The whole idea behind free software, IMHO, is that by encouraging reverse-engineering, among other forms of transparency, it ensures that software development is accelerated because you can't rest on your laurels. Your good ideas become the community's (and your competitors') good ideas, and you have to keep coming up with new good ideas to stay ahead.
This is the reverse of the closed source world where having had good ideas once entitles you to maintain a monopoly to the detriment of the consumer.
Re:What the... (Score:3, Insightful)
Riding of Coat-tails. (Score:5, Insightful)
Hmm.. and where does that end? Is it dishonest to not re-invent the wheel for your new automobile? This is a tricky area because outright copying of someone elses work without their permission is not right, but figuring out how someone else has solved a problem is kind of the way progress works.
Interesting (Score:3, Interesting)
Curiouser and curiouser.
And, incidentally, since Larry is so offended by Tridge's reverse engineering, I take it that he's taken the moral stand, and backed up his strong principles by making sure that none of BitMover's employees use Samba, either at work or in their spare time.
Re:Interesting (Score:5, Insightful)
Re:Interesting (Score:5, Interesting)
Usually, "reverse engineering" means that I've written code that does what someone else's code does, and I wrote it after studying the other code's behavior but not the code itself. Now, maybe Tridge saw the BK code, maybe he didn't; I can't tell. But it seems that what he wrote doesn't really mimic what BK did. He was adding a new capability as a sort of add-on. So his work fails to satisfy the first part of the definition, and isn't "reverse engineering".
But I haven't really seen much in the way of details.
Could someone who says that "reverse engineering" is involved please explain 1) how you define the phrase, and 2) why it applies in this case?
It's always good to get a common definition of terms before we start condemning someone for doing something that they say they didn't do.
Re:Interesting (Score:3, Informative)
What Tridge did was exactly "reverse engineering"
When Is Reverse Engineering Wrong? (Score:5, Interesting)
From the article (Torvald's statement):
" What Larry is _not_ fine with, is somebody writing a free replacement by just reverse-engineering what _he_ did."
I always am sympathetic to reverse engineering efforts, because frankly interoperability is ultimately a good thing. I am not sure what sort of principle we can follow if reverse-engineering is bad in this case. Where is the line? Is it a property line?
Re:When Is Reverse Engineering Wrong? (Score:5, Insightful)
Come on, folks (Score:3, Interesting)
Good for its time, now it's time to move on (Score:5, Insightful)
I am not a zealot, so I do not think it was a sin to temporarily use non-free software, especially when there were a lot of circumstances at the time leading to this at the time - we didn't want a Linux fork or Linus having a nervous breakdown, or so on. You have to look at things like a war - there is an objective, there is strategy and there is tactics. Bitkeeper was a necessary tactical retreat, but now that Linux is moving beyond Bitkeeper, we can see it fit in with the overall good objective and strategy behind Linux. The thing people like me worried about was the fortitude of the Linus core team as they began using Bitkeeper - is this a tactical retreat, or are they going over to the dark side? With recent events, we can see they did the right thing.
I think people should have sympathy with the situation at the time that led to Bitkeeper. It's alright for Richard Stallman to be pure and a zealot - that's his job. But it was a tactical necessity. On the other side of the coin are the little worms who whine how some developer floating around out there tried to reverse engineer Bitkeeper and offended the tender sensibilities of Bitmover and Larry McVoy, and how Linus doesn't crawl in subjugation before Bitmover and by implication other short-term corporate concerns. I don't think these people really understand even corporate America, never mind industrial or information production in general. Corporate America doesn't respect little worms that crawl around and do whatever are ordered, they just get used up until they're of no use any more and are then thrown away. And who ever said Linux was for corporate America anyway? I always thought of Linux as by engineers, for engineers. Which is not the same things as by engineers, for corporate America. That's what most of us do for our day jobs.
Re:Good for its time, now it's time to move on (Score:5, Insightful)
And let us not forget that one of Richard Stallman's most important efforts, porting of gcc to the x86, was not done in a vacume. It required a commercial version of UNIX for the x86, and the commercial version of ATT's C compiler and Assembler. All quite legally done, too.
RMS and the rest of the world moved on from that as well, and the results are the Linux world we have today.
Bottom Line (Score:3, Insightful)
Copyrights are not a "reasonable" position anymore (and please don't go off about how the GPL is a copyright license without reading it first either) Because the "right" to micro-controll and manipulate how every last person uses information in the information age is no longer, workable tenable, or acceptable any more.
Re:Bottom Line (Score:3, Insightful)
If you don't like the license ... don't use it.
That's such bullshit. First off, the guy who was reverse engineering wasn't party to the license. And second off, that logic is like the saying "if you don't like slavery - don't own slaves".
PS: I'm not liberal, I'm more like libertarian, and copyrights are not a property right - they are a bullshit regulation on how people use information.
Re:Bottom Line (Score:3)
If he has access to the binary he's party to the license.
If he didn't than it's not reverse engineering now is it?
First off, this is a red herring, the notion that he violated any ethical boundaries either way is bullshit morality.
Second, studying the formatted output of a product is a lot different that using that product or being party to the license, now isn't it?
Really? (Score:5, Insightful)
I don't think many of NewsForge's readers are going to be anti-reverse engineering. Like Sanity says, McVoy appears to want patent-level protection of his work. He doesn't have patent-level protection of his work, whether that's because he doesn't hold patents or because Tridge lives somewhere safe.
I don't think McVoy is exactly a villain here either. He just needs to quit acting like he got taken advantage of. He was doing a service and now it's not worth it to him so he's stopped. Larry McVoy, quit your bitching for your business' sake. However well founded you think it is, it only makes you sound like an asshole.
Definitely disagree with McVoy (Score:3, Insightful)
1. BitKeeper is a technically good program
2. Larry McVoy is an arrogant a******.
3. I have absolutely no problem with Tridge
Sure, Larry might not like people cloning his program. Well, tough. A clone is what is needed for interoperability. Sure, the Samba team could probably have built their own networking protocol, probably even a better one, but that wasn't the point!
Bitkeeper is hardly 100% original (Score:5, Insightful)
more history (Score:5, Informative)
McVoy: Ultimate Open Source Advocate? (Score:5, Insightful)
Right now, he is saying this to potential BitMover clients: "If you use BitKeeper, then I will control your development process. I am free to change how you work at just a whim." Can you imagine even ONE company that would accept terms like this? I can't.
Therefore, his actions now will have the result of destroying his company. That means that he is either incredibly stupid or has some other plan so clever that nobody (or almost nobody) sees it. I think it's the latter.
He's said many times that he is a big advocate of Open Source. Now, he is showing an object lesson on how horrible proprietary software can be. "Look at how much I can screw you over," he is telling us. "I wouldn't be able to do this if BitKeeper was Open Source."
Very clever! By sacrificing his company, he gets his point across much more strongly than mere words could ever do. Bravo McVoy!
$35,000 for a tweaked ChangeSet? (Score:4, Interesting)
a) Corruption. BK is a complicated system, there are >10,000 replicas of the BK database holding Linux floating around. If a problem starts moving through those there is no way to fix them all by hand. This happened once before, a user tweaked the ChangeSet file, and it costs $35,000 plus a custom release to fix it.
I really don't get how a single ChangeSet file could wreak havoc to all those repositories out there.
Copyrights on binaries (Score:4, Insightful)
If rewarding authors for that purpose is required, then they will be rewarded.
Copyrights on binaries however, reward authors while stifling the progress of science and useful arts.
It encourages people to create secretly-operating software that helps them get revenue but does not inspire new works, does not enter the public domain and does not help anyone else in the long run.
It is rediculous that binaries are copyrightable and the law that allows it is actually quite new (from the late 70's) and should be reverted.
I find it appauling that people actually buy it that reverse engineering here is immoral.
Should all reverse-engineering be allowed? (Score:5, Insightful)
But if he's okay with competition, reverse engineering is always a part of competition and he should be fine with it.
After RTFA, what I get is, if you reverse engineer BK, learn how it works, and implement something that's not plugged into BK's network, and compete with McVoy, he's fine with it. The "riding on his coat-tails" is when you reimplement his solution using BK's network, and compete with BK directly.
Before you jump into conclusion the network is open so everyone can use it, consider this: you are not just reading information from BK's network, but also changing the information, and possibly corrupting the network data. You can say it's a flaw.
So it comes to this: should reverse-engineering, on the third party's property, that could cause harm to the third party be allowed?
I'm not sure letting an implementation that potentially render the whole network useless should be protected as valid reverse-engineering.
and thus, R.Stallman was right all along... (Score:4, Insightful)
It's a bit silly to say 'I told you so" - especially since I didn't actually say it. I thought the arguments made by Linus had some logic behind it too (the technical-merit-before-anything-else approach). Often I thought both sides (Stallman and Linus) had some valuable viewpoint on it, and it was difficult to say who actually was right on the matter.
It seems now, after all, it was R.Stallman all along. Yes, Linus has a good point in chosing for technical superior alternatives...BUT, in the end, as is clearly shown now, you can't just devide the political/ideological/proprietary issue from the mere technical one. When push comes to shove, an alternative that isn't really free, isn't really an alternative. You are always dependend on the goodwill of whomever owns the product- even when buying it, I may add.
So, it would seem the viewpoint of Linus, in this instance, is the weaker one, because now he doesn't have a 'tecnological superior' product anymore, and what is he going to do? Go for another proprietary product, because it's technologically better? And have the same thing happen to him again? I don't think so. I think he learned his lesson, and he will go for the really free alternatives that R.Stallman suggested, which, albeit not as good, at least allow you to continue with it as you see fit.
Stallman can be a nag sometimes because of his gnu/linux diatribe, but in this instance, he was right.
But using BitKeeper has been *good* (Score:5, Insightful)
"...we did get three very productive years out of it, and we not only learnt how SCMs can work, we also taught a lot of people what to expect of a _good_ SCM, so anybody who claims that it was a waste of time to go with BK obviously doesn't have his head screwed on right. BK did good."
There seems to be the idea that now that they've got to move off BitKeeper that it's the end of the world. It isn't. What if they hadn't used BitKeeper - kernel development would not have progressed at nearly the rate that it has and they'd still be in the same position they are in now, but with less work done on the kernel. They'd still have had to work out some alternative SCM, they might just have had to do it sooner.
I really don't see what the big deal is. Linus hasn't lost anything by using BitKeeper - you say that he was "dependent on the goodwill of [BitMover]", but dependent for what? we still have the Linux source - the only thing he was dependent on them for was the productivity that no open source product was capable of offering. So all he's done is gain, and lost nothing.
The sky hasn't fallen.
Re:weak answer from Tridge (Score:5, Insightful)
a) getting sued and his lawyers have advised him not to release too many details
b) worried about getting sued and his lawyers have advised him not to release too many details
Re:weak answer from Tridge (Score:5, Insightful)
He made the relevant points, that he did not use Bitkeeper at all in developing his tool and was never subject to the Bitkeeper license.
KFG
Re:weak answer from Tridge (Score:5, Insightful)
for legal reasons
Re:weak answer from Tridge (Score:5, Insightful)
Please lets get this straight - there is nothing immoral about reverse engineering, particularly in the interests of interoperability as seems to be the case here.
Its sad to see people put celebrity before principal, if this were Microsoft making these arguments against Samba, rather than Linus' friend making them against this Tridge guy, there would be no question as to which side most slashdotters would come down on.
The principal doesn't change just because the people in question claim to be friends of free software.
Re:weak answer from Tridge (Score:5, Insightful)
Why wait until some undefined "later" point to explain one's self, if one has nothing to hide?
That's a good question. We should immediately execute anybody who insists on talking to a lawyer when arrested. After all, why wait until some undefined "later" point to explain one's self, if one has nothing to hide?
Re:weak answer from Tridge (Score:4, Insightful)
INSIGHTFUL?! I've seen some amazing moderator goofs, but this one takes the cake!
No, this is not insightful, this is called trolling. It's akin to, "have you stopped beating your wife?"
However -- to answer his question -- if you have nothing to hide, you keep you lips sealed if:
I get the impression... (Score:3, Insightful)
The BK guy claims that he would be ok with a OSS clone, so long as it was not reverse enginerred from BK. Who knows? We may never really know now.
Linus, who is in a position to know (and I consider trustworthy), doesn't seem convinced that Tridge wasn't just trying to torpedo BK from the get-go. (based on his statements here and in the eariler article)Re:weak answer from Tridge (Score:5, Insightful)
Chris DiBona
Re:weak answer from Tridge (Score:5, Interesting)
But one thing I will say is that tridge has done *nothing* wrong in this matter.
As for his short reply to the question, unfortunately this is for reasons outside his control.
Jeremy Allison,
Samba Team.
Re:Nice to annonuce dumping Bitkeeper, but.. (Score:5, Informative)
Being Linus works for OSDL, that pretty much means BitKeeper has to go or Linux has to leave OSDL. It is the same case for Andrew Morton. I think Linux prefers to drop Bitkeeper.
Re:Nice to annonuce dumping Bitkeeper, but.. (Score:3, Informative)
Re:I really think Tridge needs..... (Score:5, Insightful)
What exactly do you want him to say? He's never agreed to the BitKeeper license, and he's not bound by it. How could his defense possibly be any stronger?
What is this, some kind of astroturfing effort by McVoy to try to make us think that "everyone" feels like Tridge's defense is weak? What, exactly, is deficient in his statement?
Re:I really think Tridge needs..... (Score:3, Insightful)
The fact that it doesn't explain his apparently antisocial behavior. Both Linus and BK dude sound as though they were working together and attempting to find an equitable solution, including a natively supported SCM-independent export format. Tridge sounds like he was given an opportunity to negotiate and come up with a solution everyone could be happy with, and he sent them all a fuck you instead.
Of course, I don't know if that's the case, because he didn't b
Re:I really think Tridge needs..... (Score:4, Interesting)
The other guys told their side of the story. He could tell his. For example, I'd like to know
There could be great answers to all of these things. I could even make up some reasonable guesses. But until he speaks up, we'll never know. Maybe he has a genius master plan to advance open-source projects everywhere, the Linux kernel included. Maybe he's just an ultra-dork obsessed with his legal right to reverse-engineer something, giving no thought to the practical results. I hope for the former, but based on what Linus and McVoy said, I fear it's the latter.
Re:I really think Tridge needs..... (Score:4, Insightful)
But to answer for him anyway:
Why did he do it? Because he wanted to.
Is OSDL paying for it? Ask OSDL.
Why he kept going when OSDL promised he'd stop? He's not OSDL.
Was it worth it? Ask McVoy.
Why was reverse-engineering the only way? Because of the BitKeeper license.
Will he keep going with the project? If Linux falls back to BitKeeper.
Seriously this is just pissed-off.com 101. Reverse-engineering a protocol is not wrong, immoral or impolite. It does not require justification. Purposely keeping a protocol closed however, does.
Re:Freedom Matters (Score:5, Informative)
Freedom to have you post duped? (Score:3, Insightful)
Nice catch.
Especially ironic given the title of the post, and the copyright issues the gpl uses as its core.
Re:Freedom Matters (Score:3, Informative)
Amazing. The exact same post was made by Concern, here [slashdot.org]. And then Squiggleslash replies [slashdot.org] with the exact same reply that Redswinglinestapler replies with here [slashdot.org].
Are you guys just all the same people, or what?
Moderators: this is redundant, and overrated.
Balancing freedom and zealotry (Score:5, Insightful)
While McVoy may be overstating things a bit, I get this sort of vibe from some F/OSS people, most notably RMS, who adovcated outlawing proprietary source code in the GNU Manifesto.
I run SuSE 9.2 at home, and I use Firefox and OpenOffice on Windows at work. I also provide the "freedom" angle for every tool we consider using or purchasing. We use GCC instead of commercial compilers so that we never have to renew a license or pass around a dongle. We use a libre and gratis source code management tool. Our lab machines and test stations run linux.
Even in hardware, I try to inject freedom: we are buying a Bitscope [bitscope.com] instead of a competitor's product because their gratis (but not libre, duly noted) software runs on Windows or Linux, while the slightly-more-capable competitor only runs on Windows. Additionally, the Bitscope interface is documented well enough that we will be writing one for an automated hardware validation test, something that would be much more difficult if we had to reverse-engineer the protocol.
I found myself explaining this philosophy to our FNG (f-ing new guy) recently, when he asked why we didn't buy tool X from vendor Y: "we want to control our tools, rather than have our tools control us."
Contrast this to our JTAG/ICE which used to support Motorola and IBM PowerPC chips until the company was bought a few times and wound up in the Motorola family of companies. We had to upgrade the firmware and software to support a new Mot chip, and with that we lost the support for the IBM PPC chips.
F/OSS is great, but we will not make inroads if we have an attitude like that attributed to Tridge; we cannot [openly] "look down" on those who are stuck in the land of proprietary software, or we come across as self-righteous zealots, and we all know how well that sort of attitude is taken these days.
-paul
Re:Zealotry? (Score:5, Interesting)
On the other hand, I see plenty that is ugly about BitMover trying to impose the terms of their license on a guy who apparently didn't even use their software to build a free replacement for it.
Re:Zealotry? (Score:5, Insightful)
I have also seen no reason to suggest that Tridge cannot be trusted when he claims that he didn't use BitKeeper, and since Tridge is the free software developer in this debate, I am more inclined towards sympathy with him than towards a guy that thinks reverse engineering for interoperability is immoral.
Re:Zealotry? (Score:5, Informative)
He hardly "Came along", if I remember right he wrote most of rsync and was the initial author of (and is still a major developer of) Samba. Devising and reverse engineering protocols is what he does.
Re:Zealotry? (Score:3, Interesting)
Yes. And why can't he? What's immoral or unethical about trying to interoperate with a program which performs a task very well, is popular and has restrictions attached to its usage that someone sees as making the program inaccessible to themselves, completely within the bounds of the law?
"Then, while a temporary cease-fir
Re:Confused (Score:5, Insightful)
Seeing as Tridge is the main SAMBA dev, I think he has lots of experience doing reverse engineering work on closed systems with zero access to the source.
Sorry, not
Soko
You sure are confused (Score:5, Insightful)
Case 1: CherryOS violates the license to some open source software by taking it, adding some slight functionality, and renaming it, claiming it's 100% original code.
Case 2: Tridge reverse-engineers the bitkeeper protocol / binary format, intending to release an open-source version.
Case 1: Violates source code license, used to do something illegal, taking open software and making it closed.
Case 2: Adheres to all laws and licenses, takes something closed and makes it open.
Tridge didn't use proprietary code, and he wasn't reverse engineering an open-source project. (What open-source project did you think he was reverse-engineering? Linux? Why would you need to reverse-engineer an open source project anyhow, rather than reading the source and chatting with the original developers?)
Re:Confused (Score:4, Informative)
No.
How Samba was written by Andrew Tridgell (Score:5, Informative)
Go, AT! [samba.org]
How Samba was written
---------------------
Andrew Tridgell
August 2003
Method 1:
---------
First off, there are a number of publicly available documents on the
CIFS/SMB protocol. The documents are incomplete and in places rather
inaccurate, but they are a very useful starting point. Perhaps the
most useful document is "draft-leach-cifs-v1-spec-02.txt" from 1997
which is a protocol specification released by SNIA and authored
primarily by Microsoft (with significant input from many other people,
including myself). This document has expired as an IETF draft, and
Microsoft has dropped their attempts to get CIFS accepted as an IETF
standard, but the document is still available if you look hard enough
with an internet search engine.
There are numerous other public specifications for various pieces of
the protocol available. I maintain a collection of the ones I know
about in http://samba.org/ftp/samba/specs/
Method 2:
---------
I call this method the "French Cafe technique". Imagine you wanted to
learn French, and there were no books, courses etc available to teach
you. You might decide to learn by flying to France and sitting in a
French Cafe and just listening to the conversations around you. You
take copious notes on what the customers say to the waiter and what
food arrives. That way you eventually learn the words for "bread",
"coffee" etc.
We use the same technique to learn about protocol additions that
Microsoft makes. We use a network sniffer to listen in on
conversations between Microsoft clients and servers and over time we
learn the "words" for "file size", "datestamp" as we observe what is
sent for each query.
Now one problem with the "French Cafe" technique is that you can only
learn words that the customers use. What if you want to learn other
words? Say for example you want to learn to swear in French? You would
try ordering something at the cafe, then stepping on the waiters toe
or poking him in the eye when he gives you your order. As you are
being kicked out you take copious notes on the words he uses.
The equivalent of "swear words" in a network protocol are "error
packets". When implementing Samba we need to know how to respond to
error conditions. To work this out we write a program that
deliberately accesses a file that doesn't exist, or uses a buffer that
is too small or accesses a file we don't own. Then we watch what error
code is returned for each condition, and take notes.
Method 3:
--------
Method 3 is a greatly expanded variant of the "swear words" technique
I have already mentioned. It involves writing something called a
"protocol scanner". A protocol scanner is a program that tries all
possible "words" in some section of a protocol and uses the response
to automatically deduce new information about the protocol. It is like
the French Cafe technique but with a very patient waiter.
For example, some section of the protocol might contain a 16 bit
"command word" that tells the server what operation to perform. There
are 64 thousand possible command words, so we try all of them and note
which ones give an error code other than "not implemented". Then we
need to work out how much supplementary data each command word needs,
so the program tries 1 byte of blank data, then 2 bytes then 3 bytes
etc until the server changes its response in some way. When the
response changes then you know (with a fairly high level of confidence
at least) that you are using the right quantity of data. You then try
using non-blank data, putting in a filename or a directory name or a
username until the server changes its response again. After a large
number of tries the program eventually finds a combination of data
that gives no error code at all - the server
Re:What replacement systems are being considered ? (Score:4, Informative)
Linus specifically mentioned Monotone, and he's working on his own tool called git. There have been positive rumblings about Bazaar-NG.
What features are needed/why BK is so great is a long topic, but being fully decentralized and being able to run over email are some of the major features.
Shouldn't a really good SCM server system have a standardized, controlled interface that can allow simple, third-party clients, anyway ?
In fully distributed SCM, there may be no server, so all the work has to be done in the client. For exmaple, merging is one of the trickier parts of SCM, and it has to be done on the client side.
Re:Reverse engineering (Score:5, Interesting)
A bit of pickiness is in order here. Strictly speaking, linux was an independent implementation of POSIX, not Unix(TM). Yes, POSIX was a rubber-stamping of Unix Sys/V as an industry standard. But the distinction is important, legally and ethically. When governments require that you follow an official standard if you are to sell to them, it's really not right to tell me that I can't follow the standard without getting into legal trouble with some corporation. Publishing a spec as an official standard should give me permission to build tools to the standard. This is what Linux did, and everyone outside SCO seems to agree that it was legal.
Saying it's "reverse engineering" to implement a published, official standard stretches the meaning of the phrase so far that it becomes nearly meaningless. Next I expect to hear that if I use meters or grams, I'm "reverse engineering" a measurement system.
Of course, this doesn't really apply to the current discussion, since BK isn't exactly a published standard.
I'm still looking for an explanation of exactly what Tridge did that qualifies as "reverse engineering". TFA and other supposed explanations don't seem to explaining anything. I can't tell what the offending code actually did, and why it's considered "reverse engineering". Tridge seems to say that it did something that BK didn't do already. Or am I misreading something?
Re:Tridge knew this would happen..... (Score:4, Insightful)
-russ