The Torvalds Transcript (InformationWeek)

Posted Mar 25, 2007 0:17 UTC (Sun) by vonbrand (subscriber, #4458)
In reply to: The Torvalds Transcript (InformationWeek) by malor
Parent article: The Torvalds Transcript (InformationWeek)

He was widely and strongly criticized for choosing BitKeeper, and as it turns out, the critics were correct for doing so. Code that can hold you hostage is bad.

Yes, Linus was criticized for using BitKeeper. No, he was absolutely right in doing so: The then imminent "Linus meltdown" was avoided, the kernel development picked up speed, and in the end all have got better SCM tools.

Was it painless? No. Was it worth is? Yes!

to post comments

The Torvalds Transcript (InformationWeek)

Posted Mar 25, 2007 0:41 UTC (Sun) by malor (guest, #2973) [Link] (3 responses)

It was unnecessary pain. If he had simply refused to be chained in the first place, the whole fiasco wouldn't have happened. Kernel development essentially came to a dead stop for ages while they redid their tools; had they simply done the tools in the first place, they'd never have had the problem.

Code that can hold you hostage is bad. It's always bad. Anytime someone wants to tell you how or when you can use code, you're at a profound disadvantage.

I can't believe you're painting BitKeeper as a net positive. You sound like a Republican spinning the Plame outing.

The Torvalds Transcript (InformationWeek)

Posted Mar 25, 2007 2:34 UTC (Sun) by bronson (subscriber, #4806) [Link] (1 responses)

First, it really wasn't as painful as you describe. Kernel development definitely did not come to a standstill. While Linus ran off and wrote Git for a bit, everyone else continued using whatever tool they liked. No big deal (unless you happen to think that only Linus can develop the kernel...?)

Because existing distributed SCMs were crap (they were), Linus had to write his own tool no matter what. It isn't like one path involved great pain and the other path involved zero pain. What scenario are you picturing where pain is somehow avoidable and there's no need to write Git?

Now, would you rather:

- Linus write his tool cold, having very little first-hand experience of distributed development.

- Linus write his tool after thoroughly using the most advanced distributed development tool available at that time.

Seems to me like either way works pretty well.

For the record, I agree that the Republican spin on Plame (and now Gonzales) are just stupefying. But they have pretty much zero in common with Linus choosing an SCM.

BK and git: Lessons learned (or not)

Posted Mar 25, 2007 3:05 UTC (Sun) by kevinbsmith (guest, #4778) [Link]

Linus (and the world) got lucky with git, and many folks have learned the wrong lesson from the whole affair. I don't mean that Linus isn't a great programmer or that git isn't a great tool. What I mean is that the BK folks *chose* to give the kernel folks several weeks to stop using BK, rather than terminating all kernel dev licenses immediately (which they could have done). And git turned out to be relatively quick and painless for Linus to write.

If either of those (or other factors) had come out differently, the kernel could have been hurt very badly by the whole BK experience. Was BK net positive? With hindsight, I would say yes. Could it have been a disasterous net strong negative? Absolutely. The risk was high (and was known at the time BK was selected), the bet was made, and Linus got lucky and won.

Wrong lesson: Depending on closed source for a key tool is fine, because git easily replaced BK.

Right lesson: Depending on closed source for a key tool is very risky, and you really don't know how things might turn out.

The Torvalds Transcript (InformationWeek)

Posted Mar 25, 2007 4:33 UTC (Sun) by dlang (guest, #313) [Link]

if he had refused to use bitkeeper at all then kernel development would have ground to a halt as Linus overloaded, and people would not have had the experiance with distributed SCM tools to be able to create git or it's equivalent.

if the opensource SCM systems weren't up to the job of being able to handle the kernel after several years of bitkeeper being an example, what makes you think that any of them would have been suitable for it back then?

as far as I can tell, other then git, there is still no opensource SCM that can handle the scale and distribted workflow of the kernel development.

yes bitkeeper was a gamble, but the options at the time were gambles as well (what decision isn't a gamble for that matter). Yes, if Larry McVoy had been an evil person out to scramble the kernel development process things could hve turned out worse then they did

remember that even stallman says that you are justified in useing a closed source tool if there are no opensource options.