Slashdot Mirror

Larry later released a "free" read-only bitkeeper client.

http://www.bitmover.com/bk-client2.0.shar

under the "no whining" license. Earlier this year I submitted a few security patches to it, so he made it GPL.

Larry never exposed BK source code, the code being pulled is the Linux kernel, it's just being pulled off a BK repository, which it is perfectly OK to do.

Larry McVoy, BitMover Founder, gave a great talk about BitKeeper and the delta development model at SCALE 3x (Southern California Linux Expo) last month. Its available online here. -Ilan

Sun had alot of interesting technology that could of kept them on top. Only if they weren't profit minded with certain parts of it. Their management doesn't seem to see things longterm but who could truly blame them. Who would of thought opensource would of been viable.

A while ago I read a paper by Larry McVoy which essentially detailed the current threats to Sun at the time. One of those threats was NT (well no one who actually knew anything about Unix at the time saw it as a threat but those were geeks not business minded people) and the other was Linux and what he termed Sourceware at the time.

The paper is still available http://www.bitmover.com/lm/papers/srcos.html to read.

I had the good fortune of speaking with LM about what happened to the Spring OS which is mentioned in the paper. His response was that nothing happened, it essentially died. Some of the interesting and functional bits made it into Solaris but thats about it.

From the paper A royalty free operating system. Sun wants this so badly that they are currently spending roughly the same amount as the Unix royalty stream to fund development of a royalty free operating system called Spring.

Obviously Sun didn't want it so badly and instead of seeing Linux as a moving target gaining speed many just shrugged it off. This, again, a mistake. I like Sun, they have extremely good hardware, documentation and support. They need to find a viable business plan and it would start by maybe re-reading this paper and compiling a new one assessing their current and future threats.

If Sun genuinely wanted to they could be a dominant player in the linux market, ahead of Redhat and Novell. No one does support like Sun; period. However, they just let the ball drop way too many times. If you read the paper carefully you'll see that Novell even though they are late to the game are pushing through with what they want. I wish them the best of luck.

Sun still has enough money to make a change but sometimes it's hard to let go of certain things. The reality is that Sun doesn't have to let go of it's main babies such as the Sparc or Solaris. If they truly want to keep them they could recommend them for high end usage in certain critical performance server areas. There's a whole host of different configurations they could keep those things specialized for but they just aren't serious.

Still, I wish Sun the best of luck. If this rumor is true, they are going to fumble the ball one last time.

If your statement is really true, isn't that quite a bit constraining to linux kernel development? This should not be a anti-BK-rant (I never used BK and can't say anything about it's qualities), but I think this would be a good argument against it. In the M$/SCO world, one expects such NDAs. But not in the Linux world.

This is exactly my concern. There is even this question: Do you anticipate implementing a source management system in the next: [Please select] on BitKeeper's download form, where providing your real name and email address is mandatory.

Let me quote Bitkeeper issue from Linux, GNU, and freedom by Richard M. Stallman:

[...]

Bitkeeper issue

The use of Bitkeeper for the Linux sources has a grave effect on the free software community, because anyone who wants to closely track patches to Linux can only do it by installing that non-free program. There must be dozens or even hundreds of kernel hackers who have done this. Most of them are gradually convincing themselves that it is ok to use non-free software, in order to avoid a sense of cognitive dissonance about the presence of Bitkeeper on their machines. What can be done about this?

One solution is to set up another repository for the Linux sources, using CVS or another free version control system, and arranging to load new versions into it automatically. This could use Bitkeeper to access the latest revisions, then install the new revisions into CVS. That update process could run automatically and frequently.

The FSF cannot do this, because we cannot install Bitkeeper on our machines. We have no non-free systems or applications on them now, and our principles say we must keep it that way. Operating this repository would have to be done by someone else who is willing to have Bitkeeper on his machine, unless someone can find or make a way to do it using free software.

The Linux sources themselves have an even more serious problem with non-free software: they actually contain some. Quite a few device drivers contain series of numbers that represent firmware programs to be installed in the device. These programs are not free software. A few numbers to be deposited into device registers are one thing; a substantial program in binary is another.

The presence of these binary-only programs in ``source'' files of Linux creates a secondary problem: it calls into question whether Linux binaries can legally be redistributed at all. The GPL requires ``complete corresponding source code,'' and a sequence of integers is not the source code. By the same token, adding such a binary to the Linux sources violates the GPL.

The Linux developers have a plan to move these firmware programs into separate files; it will take a few years to mature, but when completed it will solve the secondary problem; we could make a ``free Linux'' version that doesn't have the non-free firmware files. That by itself won't do much good if most people use the non-free ``official'' version of Linux. That may well occur, because on many platforms the free version won't run without the non-free firmware. The ``free Linux'' project will have to figure out what the firmware does and write source code for it, perhaps in assembler language for whatever embedded processor it runs on. It's a daunting job. It would be less daunting if we had done it little by little over the years, rather than letting it mount up. In recruiting people to do this job, we will have to overcome the idea, spread by some Linux developers, that the job is not necessary.

Linux, the kernel, is often thought of as the flagship of free software, yet its current version is partially non-free. How did this happen? This problem, like the decision to use Bitkeeper, re

Is that true that Linux is developed using the proprietary BitKeeper? Why not Subversion or CVS or RCS? I just tried to download BitKeeper and there's a strange question in the download form: "Do you anticipate implementing a source management system in the next: [Please Select]" What's the deal? Don't just tell me that if I want to contribute to Linux, than I cannot contribute to Subversion... If that is indeed the case, then what are they nuts? No wonder that Subversion is maturing so slowly, when all of the Linux contributors are legally obligated to not help it. But is that really fair? I'm sure Linus Torvalds would never choose software with such an EULA, so who has made that decision? Was BitKeeper always proprietary and anticompetitive?

Sun are taking all the risks, by investing so much time and effort in Linux development.

Larry McVoy recognized the GNU/Linux model as a lifesaver for UNIX back in 1993, when he still was on Sun's payroll. The company executives ignored him. Apparently, not much has changed during the last ten years in the mindset of those people, even though the future of the company is at stake.

LMbench is great for testing the subsystems of different UNIX systems. It is probably one of the most useful benchmarks other than whatever applications you will actually be running.

Has anyone tried this with BitKeeper?

It looks like the janitor(Dave) over at bitmover noticed the tampering and this clown is taking all the credit.

Cleanse Your Soul

Basically, you write "cssh host1 host2 host3 .... hostn' and cssh will open up a window for each host + 1 "control window" that will need ho have focus when you type on the keyboard..

It's as simple as that ..

There is a screenshot Here

ssh remotehost cat /proc/cpuinfo | grep flags > temp.txt

Have a look at BitCluster, it opens up a window for each of your remoter machine and allows you to do everything simultanously, over SSH of course.

Actually it was. Larry McVoy tried to get SUN to open up their OS a _while_ ago, but instead Sun dropped the BSD version of their OS for the AT&T version (UnixWare). Allot of the history of this is available in "rebel code" - Glyn Moody
(c) 2001, ISBN 0-7382-0333-5

Thanks for your explanations.

I think the FSF makes it perfectly clear that they don't like the LGPL. As for the rest, I am mostly documenting myself now as I wish to understand what these licenses really mean. I use for myself some tools distributed, under either the GPL or the LGPL and I want to make sure I understand fully what their licensing implies before I am asked about it in a company (not gonna happen for some time so I should have enough time to get to know what I may be asked to talk about).

It is now more obvious to me why the file bk-3.0.1-x86-static-linux.bin mentionned in BitKeeper's Products.Downloads.html page is nowhere to be found in the Download section (you have to fill a form to get the login and the pass). They may be in the process of removing it afterthe revisionnists interpretation you mention (I am not aware of these being relatively new to the problem)

Thanks for your explanations.

I think the FSF makes it perfectly clear that they don't like the LGPL. As for the rest, I am mostly documenting myself now as I wish to understand what these licenses really mean. I use for myself some tools distributed, under either the GPL or the LGPL and I want to make sure I understand fully what their licensing implies before I am asked about it in a company (not gonna happen for some time so I should have enough time to get to know what I may be asked to talk about).

It is now more obvious to me why the file bk-3.0.1-x86-static-linux.bin mentionned in BitKeeper's Products.Downloads.html page is nowhere to be found in the Download section (you have to fill a form to get the login and the pass). They may be in the process of removing it afterthe revisionnists interpretation you mention (I am not aware of these being relatively new to the problem)

Thanks for your explanations.

I think the FSF makes it perfectly clear that they don't like the LGPL. As for the rest, I am mostly documenting myself now as I wish to understand what these licenses really mean. I use for myself some tools distributed, under either the GPL or the LGPL and I want to make sure I understand fully what their licensing implies before I am asked about it in a company (not gonna happen for some time so I should have enough time to get to know what I may be asked to talk about).

It is now more obvious to me why the file bk-3.0.1-x86-static-linux.bin mentionned in BitKeeper's Products.Downloads.html page is nowhere to be found in the Download section (you have to fill a form to get the login and the pass). They may be in the process of removing it afterthe revisionnists interpretation you mention (I am not aware of these being relatively new to the problem)

He always goes on about how he is doing Linux a huge favor, but his company is getting by far the better end of the deal.

When was the last time you heard BitKeeper mentioned on any article or site where Linux was not also mentioned? Linux is probably the reason the vast majority of Slashdot readers have even heard of BitKeeper. Go to the BitKeeper site and look how almost all of their news items are about Linux.

This guy is a complete asshole and almost a charicature of all the worst things about proprietary software.

RMS nailed this one.

http://www.bitmover.com/bitcluster/

Just an FYI for people getting into kernel stuff with RedHat-ish systems:

Getting Linux via bitkeeper.

First, get BitKeeper:

http://www.bitmover.com/cgi-bin/download.cgi [bitmover.com]

Follow the instructions and it will tell you how to download and install BitKeeper.

Then, clone the main Linux tree using BitKeeper:
$ cd /usr/src/linux-2.5.40
(or wherever you would like your stuff)
$ bk clone bk://linux.bkbits.net/linux-2.5
$ ln -s linux-2.5.40 linux
$ (optional if needed, ln -s linux-2.5.40 linux-2.4 ; ln -s linux-2.5.40 linux-2.5) - sometimes dists and weird driver SRPMS look for linux/include in all sorts of places
$ cd linux
$ bk -r co

I would like to also mention cvsup and FreeBSD. I like cvsup quite a bit and its free and open. I only wish the linux kernel was using the same method FreeBSD does. I like FreeBSD for its coherency speed and ease of maintenance, and that the kernel is released with a system for a very smooth ride. If you havent tried FreeBSD, please try it.

rsync is also very good. use it. I would also like to promote the purchasing of very cheap CDroms to get your started, and FreeBSD CD is great because you can use CVSUP to diff the whole thing with minimal bandwidth abuse.

To get bitkeeper, go to this url. If that doesn't work, the username is 'bitkeeper' and the password is 'get bitkeeper'.

Egad, the kernel source is being maintained with a proprietary, binary-only tool!??! Does this strike anyone else as severely ironic? (Not to mention maybe a bad idea?)

First, get BitKeeper:

http://www.bitmover.com/cgi-bin/download.cgi

Follow the instructions and it will tell you how to download and install BitKeeper.

Then, clone the main Linux tree using BitKeeper:
$ cd /usr/src/linux-2.5.40
(or wherever you would like your stuff)
$ bk clone bk://linux.bkbits.net/linux-2.5
$ ln -s linux-2.5.40 linux
$ (optional if needed, ln -s linux-2.5.40 linux-2.4 ; ln -s linux-2.5.40 linux-2.5) - sometimes dists and weird driver SRPMS look for linux/include in all sorts of places
$ cd linux
$ bk -r co

Probably even more important. XFS has finally been integrated into Linus' BK tree as well.

XFS Changset

As everyone else here, I don't know either. But I'd say it's quite a different kernel than the stock 2.4/2.5 kernel. I'd gues something like

1) A K42 -like exokernel with some parts of the linux kernel bolted on.

2) Something like Larry McVoys idea of OsLets, i.e. many kernels running on the system collaborating to provide a single system image to the user.

3) The traditional way, i.e. implementing super-fine-grained locking in the linux kernel. This would of course make linux hard to maintain and slow on "normal" hardware, just like say, solaris.

I'd think you appreciate the quote on threads attributed to Alan Cox on Larry McVoy's page.

... and if so, what will the overall approach be? Fine grained locks? Coarse grained locks? Something very different (perhaps like this)?

We need the profit motive to keep the gears turning, those gears crank out the new stuff. It's great that free software gives us free versions of existing products, but who is going to pay for the next generation of new products?

Compare that to this paragraph from his 1993 Sourceware OS paper:

Almost every good feature in computer operating systems today, including most features in DOS, Windows, and Windows/NT, came from the mind of one hacker or another. Typically, the work was not commissioned by a company.

(Highlighted in the original).

How could you hurt this face!? What a hunk!

i was going to come us with some informed rely, but seeing as I'm a moron, I'm just going to offer this.

Your incredulity shows your almost unspeakable insularity. Your use of a Unix-based, system-specific command to provide evidence against me is solid proof of that insularity.

So it is valid under some circumstances to say "an MMU is not good". However, Chuck Moore makes all sorts of statements like that one *as general laws*, which really squicks me. E.g., this page which says "The word */ multiplies by a ratio, with a double-length intermediate product. It eliminates the need for floating-point." Eliminates. Not "eliminates fp when you have a known and small dynamic range", but "eliminates". This has got to be one of the stupidest things I've ever seen. Another example: This is Chuck "Yes, that's all it takes." Moore's IDE driver. Puh-leeze. It's the "Hello World" of IDE drivers. It does *nothing*. No DMA. No locking for running on SMP machines. No autodetection and adaptation to drive capabilities. No workarounds for chipset bugs. No blacklisting of drives that are buggy. If you want to play in the real world, you need code like this (the Linux IDE driver).

Look at this page where he says "With the huge RAM of modern computers, an operating system is no longer necessary, if it ever was." Idiocy, written by a person who has never designed a system of significant complexity. RAM has *nothing* to do with whether an operating system is needed: it has everything to do with complexity. E.g., the only sane way to use floppy, IDE, SCSI, flash, CD-ROM, and network-mounted drives in the same system is to have a generic drive-access layer. Then you'll add a generic removeable drive layer to support things like CD-ROMs and flash drives that might suddenly disappear. If you want to support tons of hardware and software, you have to have an operating system.

This page is *full* of idiocy. "Don't try for platform portability. Most platform differences concern hardware interfaces. These are intrinsically different. Any attempt to make them appear the same achieves the lowest common denominator. That is, ignores the features that made the hardware attractive in the first place." Except, of course, for the usual case where the hardware has an upgrade that is easy to turn on and use, and which hardware is available is not known until runtime.

I guess I've answered my own question. Here are Larry McVoy's lmbench results for AIX, Linux, FreeBSD, IRIX, and SunOS.

If lmbench is a standard benchmark, I wonder what the same tests runs across FreeBSD 2/3/4 and Windows NT 3.51/4/2000 would show.

For those who are interested, here is the LMbench home page.

The current Linux development model has some problems and Linus needs tools to help solve those problems. Without a decent distributed source management system, all of the merging and tracking work falls on Linus' shoulders and that is getting to be way too much for any one person, even someone like Linus. The goal of the Bitkeeper effort is to provide tools that help the Linux kernel effort, and more specifically, help Linus.

Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.

By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:

• If you send him each and every patch, that represents a huge number of patches to evaluate, and if they're tiny and keep changing all the time as developers experiment things, it is certainly not a perspicuous set of changes.
• If you send him patches periodically, they'll bulk up, hopefully meaning that some of the little changes that go back and forth as people experiment before resolving to Regis' "Final Answer" will fold together.

  But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.

• If you wait longer between times that updates get released to Linus, the deltas will get bigger and bigger, and become just too big and unperspicuous to get applied to the "official" kernel.

This is certainly spelled "dilemma," as all the alternatives are pretty poor...

The current Linux development model has some problems and Linus needs tools to help solve those problems. Without a decent distributed source management system, all of the merging and tracking work falls on Linus' shoulders and that is getting to be way too much for any one person, even someone like Linus. The goal of the Bitkeeper effort is to provide tools that help the Linux kernel effort, and more specifically, help Linus.

Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.

By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:

• If you send him each and every patch, that represents a huge number of patches to evaluate, and if they're tiny and keep changing all the time as developers experiment things, it is certainly not a perspicuous set of changes.
• If you send him patches periodically, they'll bulk up, hopefully meaning that some of the little changes that go back and forth as people experiment before resolving to Regis' "Final Answer" will fold together.

  But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.

• If you wait longer between times that updates get released to Linus, the deltas will get bigger and bigger, and become just too big and unperspicuous to get applied to the "official" kernel.

This is certainly spelled "dilemma," as all the alternatives are pretty poor...

The current Linux development model has some problems and Linus needs tools to help solve those problems. Without a decent distributed source management system, all of the merging and tracking work falls on Linus' shoulders and that is getting to be way too much for any one person, even someone like Linus. The goal of the Bitkeeper effort is to provide tools that help the Linux kernel effort, and more specifically, help Linus.

Unfortunately, it has sat in "ready Real Soon Now" status for a long time now. I'd hazard the guess that a bunch of developers are feeling rebellious about the fact that it is not free software.

By the way, the "let's set up a CVS repository" idea has the conspicuous demerit at "send the patch to Linus time" that it is still going to take a lot of effort to make sure that the patches that get sent on to Linus are reasonably perspicuous. You're still left with the dilemma that:

• If you send him each and every patch, that represents a huge number of patches to evaluate, and if they're tiny and keep changing all the time as developers experiment things, it is certainly not a perspicuous set of changes.
• If you send him patches periodically, they'll bulk up, hopefully meaning that some of the little changes that go back and forth as people experiment before resolving to Regis' "Final Answer" will fold together.

  But this will tend to "bulk up" into something that involves a horde of changes, which again will not be terribly perspicuous.

• If you wait longer between times that updates get released to Linus, the deltas will get bigger and bigger, and become just too big and unperspicuous to get applied to the "official" kernel.

This is certainly spelled "dilemma," as all the alternatives are pretty poor...

BitKeeper is a CVS like utility, free for non commercial use, which provide some functionnalities besides the ones of CVS. The main one is the sub-repository which can be shared by a sub team and act as a buffer between private checked-out versions and the main repository.
Check out http://www.bitmover.com/bitkeeper/

About page coloring, this is something I heard freebsd does and not linux. myth or reality? I don't know.

I heard the same. However I tried running lmbench on a XP1000 running Linux and FreeBSD; if page coloring is there the difference wasn't really noticeable. I'm still investigating though.

"FACT: Linux doesn't use threads nearly as often as it should. By having the kernel and libraries heavily threaded, and with fine-grained locking, performance really improves."

Not so fast...

There is a ton of solid evidence that fine-grained locking can kill performance, not to mention making code more complicated, harder to write for, and harder to maintain.

Granted, threading *can* improve performance, but the impact tends to differ depending on use and the type of machine you're running on. The kernel crew has taken a moderate stance on threading, not wishing to hurt low- and mid-end hardware performance to accomodate slightly higher performance on high-end hardware. IMO, this moderation is a good thing, since it keeps the kernel and associated libraries maintainable over the long run, and it allows Linux to run on things like embedded systems, as well as mainframes, with a minimum of performance penalties on any given platform type.

BTW, Larry McVoy (one of Linus' right-hand-men) gave a great talk at the CLIQ in Denver about this very issue. here are the slides from that talk.

BitKeeper is a source management system that claims to be "especially tuned to the needs of the Linux team". It has some interesting features for distributed development. The "trees of repositories" looks particularly useful for open source projects.

I'm impressed with what I read about BitKeeper, but since CVS does the job for me I've never tried it. Anyone used it?

You can get more info here

I am talking, of course, Larry McVoy's thoughts on scalability and SMP clusters. Here is a link on the problems with SMP, and here are the slides without explanation.

The theory goes like this. In an SMP system all of the CPUs have to be made to pay attention when any of the CPUs wants to do something where races would be bad. To do that you need good latency, which means that you need to fine-tune what is locked where and for how long. This introduces a lot of overhead.

Instead what Larry wants is to have a machine with a lot of CPUs turn itself internally into a cluster of Linux machines that just happen to network Really Fast. There are good theoretical reasons why this should scale Really Well.

One of the key items in this vision is the ability to run virtual machines within Linux. Guess what User Mode Linux is? :-) The other piece of the puzzle is making a cluster work like one machine, and Ron Minnich has been doing some work there.

In 2 years, care for a 1000 CPU multi-threaded database server? With failover? :-) :-) :-)

Cheers,
Ben

The kind of material is not very suited to an OS course, just because it isn't about interacting with the OS. However, it is useful for students that haven't had a hands-on course in OS-specific programming. Anyway, besides other linux-based projects for other classes (writing an ADA-CS compiler for LinuxPPC among the more interesting,) we also have an OS class that is very interactive with the Linux Kernel. It's a third-year course, but I'm taking it now. Here are some of the projects I have encountered so far:
1) (starting easy) Become familiar with Linux by installing it on a machine, and then download some kernel source from www.kernel.org, and reconfigure and recompile the kernel.
2) make your own system call. What's involved here is learning how to pass user information to the kernel, and how to set up your system call in the linux kernel (with include/asm/unistd.h and (for us) arch/i386/kernel/entry.S).
3) Implement your own scheduling algorithm. Incorporate it into the Linux kernel by writing a system call to allow the superuser to switch between the default scheduler and the one you wrote. Then, using lmbench, compare the performance benchmarks of your scheduler with that of the builtin Linux scheduler. The more complicated the algorithm, the more points it may be worth (so implementing a lottery-based scheduling algorithm is worth more than a simple least-first algorithm)
4) Something involving cooperative user-space threads (we haven't gotten that far in class yet; the assignment has only been hinted at.)

In all of these projects a major emphasis was that the kernel must not crash under any circumstances (otherwise we might as well do windows programming.) So we had to check all kinds of possible dangerous situations (somebody passes a null buffer for the kernel to store information in, etc.) Also, for these projects, we are allowed to work in groups of up to 4 people. While the coding itself does not lend itself directly to group work, the brainstorming is definitely helped along (four heads are usually better than one.)

For more information about our operating systems course, check out www.cs.nmt.edu/~cs325.

kudos on trying to include linux in the standard CS curriculum.

(rathstar)

This is different from Linux; in some ways it's slower and more restrictive, but I rather like it.

Huh? It's not at all different from Linux. Linux also is developed by a large cadre who sync up their trees at least daily and test changes....

The only difference is the packaging layer through which patch differences are sent. *BSD tends to use CVS, whereas most of the Linux architectures use straight patches (though some of the ports use CVS trees which then get merged to Linus through straight patches). And that's about to change for Linux, since Linus is going to try Larry McVoy's stuff on the kernel.

There's a bit of info at his homepage and resume. I think you might have found your sophisticated know-how.

There's a bit of info at his homepage and resume. I think you might have found your sophisticated know-how.

Personally, I think it's wonderful. My most extensive experience with it has been in the glx project, and it's worked very well. Not being a professional programmer, it's the most sophisticated system I've every used. From talking to some of my friends, I understand it has some advantages over a lot of the commercial offerings, so we may not be missing much. :) I also use it to keep track of the data and analysis routines for my scientific work.

That said, there are lots of problems. It's not been terribly stable in my experience. It has poor support for binary files. Administration isn't fun (or easy) and it's difficult to set up securely. It's not very smart: particularly glaring ommisions are that you can't remove directories once they're added to the source tree (!), and moving files around is a pain. The notion of "code branches" could be more powerful and easier to use. (This is probably the part linus objected to--I couldn't imagine trying to track all the kernel patches that way. maybe with a gui front-end and database to keep track of the options... :) It's not easy to perform clean backups or mirrors either, and the command line options are neither elegant nor consistent. Oh yes, and it could be faster. That's my personal list so far.

Basically, it's a hack on top of rcs, and it's starting to show. It could probably benifit from a complete rewrite in the next year or so, with the addition of things like a security model and support for distributed (and mirrored) repositories. bitkeeper is something like this, but not free software. prcs is another, gpl'd, attempt headed by Josh MacDonald, author of xdelta; there's no client/server for it yet, though. Personally, I'd like to see a cross between cvs, an eternity server, and Debian's apt package tool. :)

Nevertheless, I think it works fine for medium sized projects and really helps facilitate/speed up internet-based development. Beats mailing patches around!

Personally, I think it's wonderful. My most extensive experience with it has been in the glx project, and it's worked very well. Not being a professional programmer, it's the most sophisticated system I've every used. From talking to some of my friends, I understand it has some advantages over a lot of the commercial offerings, so we may not be missing much. :) I also use it to keep track of the data and analysis routines for my scientific work.

That said, there are lots of problems. It's not been terribly stable in my experience. It has poor support for binary files. Administration isn't fun (or easy) and it's difficult to set up securely. It's not very smart: particularly glaring ommisions are that you can't remove directories once they're added to the source tree (!), and moving files around is a pain. The notion of "code branches" could be more powerful (and easier to use). It's not easy to perform clean backups or mirrors either, and the command line options are neither elegant nor consistent. That's my personal list so far. :)

Basically, it's a hack on top of rcs, and it's starting to show. It could probably benifit from a complete rewrite in the next year or so, with the addition of things like a security model and support for distributed (and mirrored) repositories. bitkeeper is something like this, but not free software. prcs is another, gpl'd, attempt headed by Josh MacDonald, author of xdelta; there's no client/server for it yet, though.

Obviously this guy is a visionary, I wonder what his views are today? Has he published any
other documents?

Larry is Da Man!! He was the engineer at Sun largely responsible for SunOS 4 being the quality OS it was, and he added a lot of the cool / fast features of it which were new at the time. He left for SGI when they dumped his work and switched to Solaris. At SGI, he did more kewl fast shit, before leaving for full-time Linux stuff. He was involved with Cobalt Micro (yeah, *those* guys) when they were getting off the ground, and now he's at BitMover ( http://www.bitmover.com/) writing the source control software to end all source control software (he hopes). I don't think I've ever heard him suggest something stupid. Truly a great, if not well-known, hacker.

The html version of this paper can be viewed at Larry's site here.

#kenP-)}

Ken Coar

So now the new kernel is out, are there any plans to start moving to a new system such as Bikeeper?