Slashdot Mirror
BitKeeper Love Triangle: McVoy, Linus and Tridge
erktrek writes "NewsForge has given a brief interview to the parties involved in the (inevitable?) BitKeeper debacle." Here is some of our previous coverage.
← Back to Stories (view on slashdot.org)
"Linux leader Linus Torvalds has begun looking for a new electronic home for his project's source code after a conflict involving the current management system, BitKeeper"
Linky
"With sufficient thrust, pigs fly just fine." -- RFC 1925
Quote Linus:
Seems clear who he is a bit bitter at.
They didn't drop BitKeeper. BitMover dropped the free version BitKeeper and refused to license the paid version to any employees of OSDL.
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.
So nice of you to copy this comment from an earlier story, verbatim, without crediting the original author.
Auto-reply to ACs: "Truly, you have a dizzying intellect."
Larry McVoy sees two problems with Andrew Tridgell's reverse-engineered, free tool. One is "condoning reverse engineering". The other is, in his words:
KDE never used BK. That was an April Fool's joke. Apparently they are switching from CVS to Subversion, though.
J
Exactly. And Tridge was NOT hosting a BK site. What he did was perfectly ethical. Furthermore, reverse engineering is a vital part of our economy, and McVoy needs to stop making himself look foolish by vilifying it.
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.
Context is everything. I posted this article (written at the time of Linus' adoption of bitkeeper) from Linux World in the last BK thread. Casts the current events in an interesting (and not McVoy-friendly) light.
grammar-lesson free since 1999. (rescinded - 2005)
(prostituting anonymously)
Go, AT!
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
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I was using Microsoft networking back in the late eighties, on a network of something called a Research Machines Nimbus, at school. Oddly enough, we ran Windows 1.0 over it, with hilarious results (ie it was slow and crashed a lot.)
Anyway, the point is Microsoft's SMB protocols pre-date Windows. Windows interoperated with them without any problems, they were just DOS drives, after all.
You young'uns! You don't know how hard it was then! We used to have to wire coax to the back of PCs to get out Ethernet networks, kid!
</TONE>
You are not alone. This is not normal. None of this is normal.
You are wrong. tridge does not use bk as part of his OSDL work (which is entirely on Samba4).
Jeremy Allison,
Samba Team.