Home opinion-and-analysis Open Sauce Linus Torvalds: looking back, looking forward

Author's Opinion

The views in this column are those of the author and do not necessarily reflect the views of iTWire.

Have your say and comment below.

iTWire: What about the BitKeeper episode back in 2005? Was that one of the more stressful moments? And how is your relationship with Andrew Tridgell after that?

LT: So having to drop BK was annoying, but it actually was not nearly as stressful as the events that led up to me _starting_ to use it.

To explain the background, one of the less happy times in kernel development around 2001, with the release of 2.4.0 (and subsequent events). It was one of those major releases, and we'd been doing 2.3.x for a long time, and that was also when the interest in Linux was really taking off in a big way. So things were changing a lot, and the whole development process was really feeling some pain. There were long discussions about patch acceptance (or rather, lack of it - google for "Linus doesn't scale" etc) and we had some serious problems with the VM (largely about that HIGHMEM thing, actually), that were very, very painful.

So that was, I think, the timeframe where the kernel development process _really_ could have failed, and people were unhappy (for various good reasons).

And that timeframe is what explains why I love BitKeeper so much, and have so much respect for Larry McVoy. We ended up solving the VM problems (more or less - there's no way to ever really get the Intel PAE model to work perfectly), but what solved many of the fundamental development problems was getting a source code management system that was really distributed.

That may sound obvious _today_, when people are finally getting pretty used to 'git', and it's widely used even outside the kernel, but in early 2002 when I then started using BitKeeper, not only were there no open source alternatives that were close to viable, almost nobody out there even really _understood_ the point of distributed SCMs. I give Larry McVoy a lot of kudos for pushing BitKeeper, and teaching the world how things should be done. Sure, nothing comes from a vacuum, but still - BK was simply on a different level from anything I had ever seen. To the point that several years later, when I had to drop using it, most everybody _still_ didn't get the point. Due to the licence issue, BK didn't get huge traction even in the kernel community, and so only a fairly small subset of maintainers really "got it" (but enough that during the BK years we had several major subsystems that could be merged through BK, and that made a lot of the scalability issues go away).

So on a stress level, 2001 and 2002 were pretty high. We had serious development flow problems, and me learning the distributed SCM model and just telling people that that's how we're going to do things was certainly not pain-free. But despite all the crap people still give about BK, I'm 100 percent convinced it was absolutely the right thing to do. Because people really don't remember how big a development issue we had before we could have submaintainers that could maintain their own distributed trees and handle distributed merging.

In comparison to that, the couple months of pain in 2005 when BK went away was a walk in the park. It was an annoyance, it wasn't a big fundamental problem with the development model, or a time when I was worried about fundamentals. I even had a ton of fun doing git for a few months.

And yeah, it resulted in awkwardness with Tridge. For a while I really tried very hard to try to find some acceptable common ground where people would be happier with BK, and looking at some way to get Tridge and Larry to come together at some middle ground. For a while I thought that if I could get some nice export format for the BK data, we could get around the major issues. Because at the time there _still_ was no even remotely acceptable open source alternative to BK. And during that time of me looking for solutions, I ended up feeling that "Free Software" (Tridge) vs "Open Source" (me) really hit home at a very practical level.

But as mentioned, I did have fun with git. It resulted in kernel development being shut down for a couple of weeks (and then several months of learning experience and pain for early git adopters), but the end result obviously turned out ok. But I did end up despising most SCM developers out of it all.


Does your remote support strategy keep you and your CEO awake at night?

Today’s remote support solutions offer much more than just remote control for PCs. Their functional footprint is expanding to include support for more devices and richer analytics for trend analysis and supervisor dashboards.

It is imperative that service executives acquaint themselves with the new features and capabilities being introduced by leading remote support platforms and find ways to leverage the capabilities beyond technical support.

Field services, education services, professional services, and managed services are all increasing adoption of these tools to boost productivity and avoid on-site visits.

Which product is easiest to deploy, has the best maintenance mode capabilities, the best mobile access and custom reporting, dynamic thresholds setting, and enhanced discovery capabilities?

To find out all you need to know about using remote support to improve your bottom line, download this FREE Whitepaper.


Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.