LWN: Comments on "How scalable is too much?"

Larry McVoy and his BitKeeper advertisements

leandro — Mon, 15 Jul 2002 10:21:17 +0000

I guess it's the guy's right to advertise his proprietary system, and it's Linus' right to use the tools he wants to.

But what's fishy is that, even in a totally unrelated presentation, he keeps advertising his proprietary stuff. And few people probably realise that, if Linus had taken the same kind of decision, Linux itself wouldn't be copylefted, not even free, but some kind of freeware or nagware stuff, and we would be all using BSD or the Hurd. Linux probably would never got much farther than Minix did.

Because Linux got so successful basically because it became the oficious GNU kernel, and that wouldn't have been possible with LM's BitKeeper licensing model. Linus would have to have created all the userland tools he just got free from The GNU Project.

OTOH LM proposes to make his code free only to free software, but it's not really free in itself; bringing this to its logical conclusion, if everyone would follow suit there would be no more free software, only freeware and nagware, and we would be back to the old "free only for non-commercial use" or some variation of it.

Or it was just me who realised that BitKeeper couldn't be used to develop another BitKeeper by the community, since it would require payment to develop a proprietary tool? So Larry is actually like preempting the appearance of a free software competitor!

Disgusting.

How scalable is too much?

DeletedUser2560 — Fri, 12 Jul 2002 20:21:44 +0000

Each lock should have an identifier associated with it. If a piece of code needs multiple locks, it could call a single system call, and specify all the locks it needs as parameters to it. It would be the job of this system call to grab the locks in order (or, block until all the requested locks are availble, in an atomic operation)

How scalable is too much?

iabervon — Thu, 11 Jul 2002 18:21:50 +0000

A minor point: the number of required ordering relationships between locks grows only linearly with the number of locks, because it has to be a total order (i.e., a simple list of all the locks in order). What grows exponentially is the number of orderings you could pick.

At least in the simple cases (global locks, ordered lists of objects with locks), it should be possible to check automatically that a set of predefined rules are followed (The hard problem is determining whether a piece of code is actually free of deadlocks; but it is a bug if locks are taken in the wrong order even if the code will not deadlock anyway). I expect the kernel checker to determine lock safety (if it doesn't already) pretty soon; if the checker can't figure it out, it's probably too complicated and likely to get broken.