A kernel is very different from an application. It requires some very tricky compiler support in order to function as designed. If you don't want to sit down and write it entirely in assember, you end up picking 1 compiler and using many compiler-specific features to get your results.
We have here a kernel, which is compiled with
1) GCC (ARM, Thumb, MIPS, SH, V850)
2) ARM ADS (ARM, Thumb)
3) ARM SDT (ARM, Thumb)
4) Hitachi HEW (SH)
5) NEC CA850 (v850)
6) Texas Instruments C compiler (TMS470 (ARM core))
"The fun part is that if an intruder observes or intercepts the transmission, those properties get changed -- an unavoidable principle of quantum mechanics -- meaning the sender and receiver can tell if anyone is eavesdropping. "
Of course, in order to encrypt/decrypt something you have to access ("observe") the key, thus changing its "properties".
~velco
PS. Can't wait for the next Crypto-Gram (http://www.counterpane.com/crypto-gram.html)
> Linus pointed out a benefit to using BK: even if the official BK repository were changed, he doesn't > pull from it (because his local copy has all of his changes), and he would get an error the next > time he pushed to it. The repository that would have to be attacked is actually his local disk, > behind a firewall and not set up for anyone else to access at all.
That's rather naive. Changes apparenty do get into the Linus repository, as evident from the large number of Linus published kernels at www.kernel.org.
No firewall or whatever can prevent you from applying changes yourself (and, of course, it shouln't). Thus the question is how to check the integrity of the changes. One option is a visual inspection of the changeset. The only problem is that this does not work -- the sheer size/number of the changes makes it impossible to audit. The other option is to have changesets cryptographically signed and trusted only if they are signed with keys you trust. And these keys would be the ones of Andrew Morton, Alan Cox, David Miller, etc.
Now, this pushes the responsibility for audit further down, where the audit needed is at a much smaller scale, to to level if an individual patch, thus possible.
Needless to say, BK does not provide anything wrt. changeset integrity. Check OpenCM (www.opencm.org) or Monotone (http://www.venge.net/monotone) for the proper way to make an SCM.
Thanks, I can see that much. I can also see the buffer overrun in ``buffer_free()''. What I can't see is the *exploit*, resulting from overwriting the heap with zeroes.
~velco
I think he meant local to a group, not local to exactly one computer.
I think he didn't.
Subversion does not work on anything that isn't all on one machine, unless you have the latest CVS version of Apache.
I think you're trolling and spreading FUD.
This is trivially not true - my version of subversion works together with some debian build of apache2, which is with absolute certainty older than 2002-12-21's version of the Apache's CVS.
Subversion uses CVS versions of Apache Portable Runtime - but this is not Apache.
And that makes a perfect sense for an alpha stage software.
That includes networked file systems; i.e. the subversion repository can't be on NFS, AFS, Coda, etc.
What's you point ? Is this a requirement for a version control system ? Do other version control systems' repositories can be on NFS, AFS, etc. and why a SVN repository can't be ?
Lacking ssh support, and not using a standard apache without addition modules is a huge problem for subversion, but they'll never admit it.
I do not think this is problem _at all_. The subversion filesystem interface is abstracted and can (and in fact has) have many different implementations. One of the existing implementations uses Berkeley DB, another one uses WEBDAV (thus it can communicate with ANY WEBDAV server, NOT only Apache). One CAN provide SSH based implementation, too, as well as a SSL, RPC or completely custom one. So, instead of whining, you can implement SSH support if you need it. As for me, apache+SSL provide enough authentication/security.
It is just that SVN developers have other things to do than implementing zillion versions of libsvn_fs. They have covered the local case with Berkeley DB and the remote case with WebDAV + Apache + Berkeley DB - this should be enough for start.
You still have to compile subversion with apache though. CVS is a whole package while subversion requires a big extern project to compile it.
This is not true. I have compiled subversion a number of times - it doesn't need the apache web server.
~velco
Re:Al Viro's review of subversion
on
Multi-User Subversion
·
· Score: 2, Informative
I would't take it _too_ seriously. You can hardly get Al Viro to say anything nice for anybody's code. And account for the usual Linux kernel arrogance and the difference in the coding style.
How soon we forget history. How soon we forget the events of even two and three years ago. The tech industry's motto used to be "caveat employer". Let the employer beware. We demanded ping pong tables, refrigerators stocked with ale, and the elimination of the dress code. If we didn't get it we walked out. I personally saw a 60% increase in pay over two years, the creation of a corporate cafeteria with a real chef, the creation of a corporate gym, and flex time that made rubber bands look rigid. I got one raise just because management *thought* a recruiter had talked to me.
Now the shoes on the other foot, and we decry our lack of rights. Hah!
Err, doesn't that just mean that besides being lousy managers, you guys have been lousy workers ?
Economy does not collapse because of the high wages. Economy collapses when there's no PRODUCTION !
However, the problem is that you're not ABLE to negotiate, because there are some 10 people outside, waiting for the same job and they have all to insist in same benefits.
Why not - Get an idea - try to find those 10 people - talk to them - organize partnership?
Now, in the past few decades, a few lucky countries have become efficient enough to allow people to work fewer hours (Japan, Europe, America, etc.).
Obviously you know nothing about Japan. Believe me, I'd prefer to be a factory worker in USA than an IT worker in Japan.
But even then, I would not count on it simply being "We're only working hard because of a lie we're being told." Yes, workers in France and Germany work fewer hours at better conditions than American workers do. But on the other hand, France and Germany's economies have been stagnant for the past decade, while America's has been dynamic. And that's not just the bubble - America's GDP growth rate last quarter was much higher than either Germany's or France's, and is predicted to be much higher for next year as well.
Err, why would I fucking care for the "dynamic" economy, whet I get ZERO benefits from it ?
Do you know that in Europe people generally get 4-6 weeks of paid vacation compared to the pathetic 2 weeks in the USA ?
Hell, even in.bg I get 20 workings days per year !
Looking from here in Europe, US workers appear to be trussed and blinded by the american dream as upheld by US corporatism. That and the whole population almost genetically raised to consume, makes you guys look pretty lame. When are you going to get a clue ?
They'll never gonna get it.
"Slaves don't want to be free, they want their own slaves"
Is this Marxism-101? An Anonymous Coward posts something about how we're all exploited by the Bosses, and it makes the Front Page?
Labeling something "Marxism" gets you nowhere and effectively stops the reasonable discussion.
I can too label the current state of the affairs "Wild Capitalism".
Nobody is "exploiting" you. If you work for what they pay, then its a business deal, and done.
That's right.
If you don't like your pay, renegotiate, quit, or SHUT UP.
And that's not, except "renegotiate". However, the problem is that you're not ABLE to negotiate, because there are some 10 people outside, waiting for the same job and they have all to insist in same benefits.
Because your company founder put his brains, personal capital, and personal life on the line to start a company, WHICH PUTS THE FOOD ON YOUR TABLE, and now makes more $$ than you, doesn't mean he's "exploiting" you.
Yes, it means. Because I put my brains too, I put my personal capital too (be it time or knowledge or abilities) and I put my personal life too for the company, WHICH PUTS THE FOOD ON HIS TABLE, and in addition puts the mannor, the spa, the limousine, the jet, etc.
It is OK, if he makes more than me, but making 500 times more is RIDICULOUS.
If that bothers you, start your own company.
This is just outrageous. You effectively claim the workers have no rights, and if they want rights they must become employers first !
No doubt some people will make an analogy with the mainframe timesharing computing style from '60 and '70s. This is not quite the same, the critical difference being that the computing resources will "shift" from company to company. It much more closely resembles the Sun's mantra "The Network Is The Computer".
For me, it looks like a cluster where nodes are automagically added and removed depening upon the demand for computing power.
Corporations do not pay taxes. Owners of the corporations pay taxes. Owners of the corporations are represented in the government just like anyone else and there should not be any difference in your civil rights no matter of you're owner or not.
The big problem with publishing government funded software under a BSD-like license is that this allows part of the population (namely the corporations owners) to deprive others of the rights they have on this software - by creating derived works and claiming copyright, patent and generally IP rights on said software.
Hence the software _must_ be published under GPL, thus providing equal rights to all citizens - including corporation owners.
Well, all of this is logic and common sense, so I do not expect your Congress to act this way.
~velco
... all animals equal, some more equal than others...
The day Larry changes the format to be incompatible with SCCS is the day the kernel developers stop using BitKeeper.
See, kernel developers couldn't care less for the internal format BK stores its files, they have repeatefly stated that they use BK for its superior _features_.
Larry knows this, and he's not likely to shoot himself repeatedly in the foot by doing that.
See the above.
You might ask yourself why BitKeeper is still using the SCCS file format. The answer is for exactly this reason: they don't want to lock their users in by using a proprietary format.
Why wouldn't they want it? They're some form of charity or what ? They do business and, believe me, faced with the loss of couple of millions everyone suddenly loses his high ideals.
What might be a real risk is if Larry loses control of BitMover
He is a businessman, he does what is good for _his_ business, not what is good for community, as he has repeatedly stated himself.
and the new owners decided to make such changes. As it stands, that's not even a mid-term threat, and with any luck the Free alternatives would have caught up enough to be usable if it/did/ happen.
Well, some have not only caught up, but have are way ahead in some respects, case - svn tagging and branching - bk looks pathetic compared to it.
You answered your own question. The kernel developers decided that BitKeeper was the best tool for the job so they used it, and if the FSF comes up with something better then I bet they'll switch to that in an instant.
They'll switch - if they can ! What would happen with the accumulated history of the files ? Sure the BK file format is open _now_, but will it be open in the future ? What would prevent Larry from "creatively extending" the SCCS format at the first sign the Linux (the kernel) project would switch to something else.
That's one of the real strengths of Linux - ideology takes a back seat to getting the job done, and IMO it explains why Linux has been one of the most successful Unix variants.
Welcome to the real world - technology advantages have nothing to do with success. Ask IBM about OS/2 and Microsoft about Windows.
the health care industry needs to go to Microsoft with a joint NDA (nondisclosure agreement) and indemnification agreement, requiring Microsoft to hold their HIPAA-compliant customers harmless should patient information be leaked via this mechanism.
These morons are not worried at all about the patient's information, they seek way to cover their fscking ass.
... secretly breaks the multimedia software and/or revokes access to our patient's data, thus damaging our patient care, who is responsible?
And again "who is responsible" ! In other words "we don't give a shit if the patient dies, as long as we are not held responsible" !
Is this the way that some changesets get into the Linus's bk repo ? If so, I stand corrected.
* distributed repositories have much more benefits than the push/pull model, they are also needed so every developer can do version control on his/her own tree
Distributed repositories are not distributed at all if there isn't communication between them. I can do version control in my own tree with every SCM out there. The very essence of being distributed is in the inter-repository flow of changesets.
* There are a whole number of forks of the Linux kernel tree out there, that wouldn't have been as easily possible without bitkeeper
Why so ?
How about "cvs checkout foo; cd foo && find . -name CVS | xargs rm -rf; cd foo && cvs import foo".
Well, "bk clone" is simpler, indeed, but does this matter ? How often you make clones ?
Given that your conclusions are based on false premises I wouldn't put too much value in them.
False or not is yet to be established:)
Having a distributed SCM does matter.
But, yes! I, in fact, very much like BK exactly because of the distributed repositories. My point is that exactly these features are not used by Linus, which renders bogus the argument "use the right tool for the right job" (or, on a second thought, maybe not. Using roughly the "CVS subset" of BK does not make it less suitable than CVS:)
And who exactly are you, to tell me which products I should or shouldn't use ?
All my patches are available in other formats too, you don't need bitkeeper to access my stuff.
I'm not forcing anybody to use bitkeeper, you shouldn't try to force me to stop using bitkeeper
No, not forcing, but persuading:)
Bitkeeper has improved my productivity and my contribution to open source software. Though it's not a necessary tool for my work, I'm thankful that Larry makes my work easier by allowing me to use his program.
Well, I guess it is time to dissect the supposed advantages of BK over other version control systems.
First, the imporatance of the version control itself. The question is how does using or not using a SCM tool influences the success or failure of a project. Are there any studies, which indicate that software projects generally experience more failures when SCM is not used ? I know of none. And until someone shows my one, I'd stick to my own experience - the SCM tool does not matter at all.
Second - BK advantages. The most cited advantage of BK other other SCM tools are distributed repositiories and the push/pull operations.
Well, I can really see the convenience of using such a tool - but only if the communication between the developers follows thge push pull model.
This is not the case with Linux (the kernel) and Linus.
Fact - the only pushes into the tree are made by Linus himself. Well, it looks like Linux (the kernel) developers are not using exactly the features they claim they're using BK for.
(This is not unexpected, given the overly centralized nature of the Linux (the kernel) development process. Ironically, BK would be much more useful for a project like GCC, which is much more democratically organized (and bigger too)).
To conclude (argumented IMHO, of course):
SCM does not matter. BK is not necessary.
Well, then, if it does not matter (technically) anyway, why don't use something free ?
And, BTW, you DO miss the point - the talk is about licenses that sux0rz - not about techical merits of one or another SCM tool.
Hey, who modded this down ?! It's hilarious!! Even more when you realize the poor schmuck actually believes in it ! :)))))
~velco
We have here a kernel, which is compiled with
1) GCC (ARM, Thumb, MIPS, SH, V850)
2) ARM ADS (ARM, Thumb)
3) ARM SDT (ARM, Thumb)
4) Hitachi HEW (SH)
5) NEC CA850 (v850)
6) Texas Instruments C compiler (TMS470 (ARM core))
~velco
What you describe is trivially attacked with a man-in-the-middle.
"The fun part is that if an intruder observes or intercepts the transmission, those properties get
changed -- an unavoidable principle of quantum mechanics -- meaning the sender and receiver can
tell if anyone is eavesdropping. "
Of course, in order to encrypt/decrypt something you have to access ("observe") the key, thus changing
its "properties".
~velco
PS. Can't wait for the next Crypto-Gram (http://www.counterpane.com/crypto-gram.html)
> Linus pointed out a benefit to using BK: even if the official BK repository were changed, he doesn't
> pull from it (because his local copy has all of his changes), and he would get an error the next
> time he pushed to it. The repository that would have to be attacked is actually his local disk,
> behind a firewall and not set up for anyone else to access at all.
That's rather naive. Changes apparenty do get into the Linus repository, as evident from the
large number of Linus published kernels at www.kernel.org.
No firewall or whatever can prevent you from applying changes yourself (and, of course, it
shouln't). Thus the question is how to check the integrity of the changes. One option is a visual
inspection of the changeset. The only problem is that this does not work -- the sheer size/number
of the changes makes it impossible to audit. The other option is to have changesets
cryptographically signed and trusted only if they are signed with keys you trust. And these keys
would be the ones of Andrew Morton, Alan Cox, David Miller, etc.
Now, this pushes the responsibility for audit further down, where the audit needed is at a much
smaller scale, to to level if an individual patch, thus possible.
Needless to say, BK does not provide anything wrt. changeset integrity. Check OpenCM (www.opencm.org)
or Monotone (http://www.venge.net/monotone) for the proper way to make an SCM.
~velco
Thanks, I can see that much. I can also see the buffer overrun in ``buffer_free()''. What I can't see is the *exploit*, resulting from overwriting the heap with zeroes. ~velco
Some people pointed at this
o /o penssh/buffer.c.diff?r1=1.1.1.6&r2=1.1.1.7&f=h
http://www.freebsd.org/cgi/cvsweb.cgi/src/crypt
though I cannot see how it can be a vulnerability.
~velco
I think he meant local to a group, not local to exactly one computer.
I think he didn't.
Subversion does not work on anything that isn't all on one machine, unless you have the latest CVS version of Apache.
I think you're trolling and spreading FUD.
This is trivially not true - my version of subversion works together with some debian build of apache2, which is with absolute certainty older than 2002-12-21's version of the Apache's CVS.
Subversion uses CVS versions of Apache Portable Runtime - but this is not Apache.
And that makes a perfect sense for an alpha stage software.
That includes networked file systems; i.e. the subversion repository can't be on NFS, AFS, Coda,
etc.
What's you point ? Is this a requirement for a version control system ? Do other version control systems' repositories can be on NFS, AFS, etc. and why a SVN repository can't be ?
Lacking ssh support, and not using a standard apache without addition modules is a huge problem for subversion, but they'll never admit it.
I do not think this is problem _at all_. The subversion filesystem interface is abstracted and can (and in fact has) have many different implementations. One of the existing implementations uses Berkeley DB, another one uses WEBDAV (thus it can communicate with ANY WEBDAV server, NOT only Apache). One CAN provide SSH based implementation, too, as well as a SSL, RPC or completely custom one. So, instead of whining, you can implement SSH support if you need it. As for me, apache+SSL provide enough authentication/security.
It is just that SVN developers have other things to do than implementing zillion versions of libsvn_fs. They have covered the local case with Berkeley DB and the remote case with WebDAV + Apache + Berkeley DB - this should be enough for start.
~velco
You still have to compile subversion with apache though. CVS is a whole package while subversion requires a big extern project to compile it.
This is not true. I have compiled subversion a number of times - it doesn't need the apache web server.
~velco
I would't take it _too_ seriously. You can hardly get Al Viro to say anything nice for anybody's code. And account for the usual Linux kernel arrogance and the difference in the coding style.
~velco
The only problem I have with subversion is its dependences on apache which just gets in the way in a local project
Do your homework first. You don't need apache for local projects.
~velco
IIRC, Samsung develops Alpha processors, I guess the rumours for Alpha's death are greatly exaggerrated.
How soon we forget history. How soon we forget the events of even two and three years ago. The tech industry's motto used to be "caveat employer". Let the employer beware. We demanded ping pong tables, refrigerators stocked with ale, and the elimination of the dress code. If we didn't get it we walked out. I personally saw a 60% increase in pay over two years, the creation of a corporate cafeteria with a real chef, the creation of a corporate gym, and flex time that made rubber bands look rigid. I got one raise just because management *thought* a recruiter had talked to me.
Now the shoes on the other foot, and we decry our lack of rights. Hah!
Err, doesn't that just mean that besides being lousy managers, you guys have been lousy workers ?
Economy does not collapse because of the high wages. Economy collapses when there's no PRODUCTION !
~velco
However, the problem is that you're not ABLE to negotiate, because there are some 10 people outside, waiting for the same job and they have all to insist in same benefits.
... :)
Why not
- Get an idea
- try to find those 10 people
- talk to them
- organize partnership?
You forgot:
-
- PROFIT !
~velco
Now, in the past few decades, a few lucky countries have become efficient enough to allow people to work fewer hours (Japan, Europe, America, etc.).
.bg I get 20 workings days per year !
Obviously you know nothing about Japan. Believe me, I'd prefer to be a factory worker in USA than an IT worker in Japan.
But even then, I would not count on it simply being "We're only working hard because of a lie we're being told." Yes, workers in France and Germany work fewer hours at better conditions than American workers do. But on the other hand, France and Germany's economies have been stagnant for the past decade, while America's has been dynamic. And that's not just the bubble - America's GDP growth rate last quarter was much higher than either Germany's or France's, and is predicted to be much higher for next year as well.
Err, why would I fucking care for the "dynamic" economy, whet I get ZERO benefits from it ?
Do you know that in Europe people generally get 4-6 weeks of paid vacation compared to the pathetic 2 weeks in the USA ?
Hell, even in
~velco
Looking from here in Europe, US workers appear to be trussed and blinded by the american dream as upheld by US corporatism.
That and the whole population almost genetically raised to consume, makes you guys look pretty lame.
When are you going to get a clue ?
They'll never gonna get it.
"Slaves don't want to be free, they want their own slaves"
*sheesh*
~velco
Is this Marxism-101? An Anonymous Coward posts something about how we're all exploited by the Bosses, and it makes the Front Page?
Labeling something "Marxism" gets you nowhere and effectively stops the reasonable discussion.
I can too label the current state of the affairs "Wild Capitalism".
Nobody is "exploiting" you. If you work for what they pay, then its a business deal, and done.
That's right.
If you don't like your pay, renegotiate, quit, or SHUT UP.
And that's not, except "renegotiate". However, the problem is that you're not ABLE to negotiate, because there are some 10 people outside, waiting for the same job and they have all to insist in same benefits.
Because your company founder put his brains, personal capital, and personal life on the line to start a company, WHICH PUTS THE FOOD ON YOUR TABLE, and now makes more $$ than you, doesn't mean he's "exploiting" you.
Yes, it means. Because I put my brains too, I put my personal capital too (be it time or knowledge or abilities) and I put my personal life too for the company, WHICH PUTS THE FOOD ON HIS TABLE, and in addition puts the mannor, the spa, the limousine, the jet, etc.
It is OK, if he makes more than me, but making 500 times more is RIDICULOUS.
If that bothers you, start your own company.
This is just outrageous. You effectively claim the workers have no rights, and if they want rights they must become employers first !
~velco
Damn right! For a geek a strike would mean not touching the computer for an extended period of time.
What a geek would one be without an own computer ?
No doubt some people will make an analogy with the mainframe timesharing computing style from '60 and '70s. This is not quite the same, the critical difference being that the computing resources will "shift" from company to company. It much more closely resembles the Sun's mantra "The Network Is The Computer".
For me, it looks like a cluster where nodes are automagically added and removed depening upon the demand for computing power.
~velco
The big problem with publishing government funded software under a BSD-like license is that this allows part of the population (namely the corporations owners) to deprive others of the rights they have on this software - by creating derived works and claiming copyright, patent and generally IP rights on said software.
Hence the software _must_ be published under GPL, thus providing equal rights to all citizens - including corporation owners.
Well, all of this is logic and common sense, so I do not expect your Congress to act this way.
~velco
The day Larry changes the format to be incompatible with SCCS is the day the kernel developers stop using BitKeeper.
/did/ happen.
See, kernel developers couldn't care less for the internal format BK stores its files, they have repeatefly stated that they use BK for its superior _features_.
Larry knows this, and he's not likely to shoot himself repeatedly in the foot by doing that.
See the above.
You might ask yourself why BitKeeper is still using the SCCS file format. The answer is for exactly this reason: they don't want to lock their users in by using a proprietary format.
Why wouldn't they want it? They're some form of charity or what ? They do business and, believe me, faced with the loss of couple of millions everyone suddenly loses his high ideals.
What might be a real risk is if Larry loses control of BitMover
He is a businessman, he does what is good for _his_ business, not what is good for community, as he has repeatedly stated himself.
and the new owners decided to make such changes. As it stands, that's not even a mid-term threat, and with any luck the Free alternatives would have caught up enough to be usable if it
Well, some have not only caught up, but have are way ahead in some respects, case - svn tagging and branching - bk looks pathetic compared to it.
~velco
You answered your own question. The kernel developers decided that BitKeeper was the best tool for the job so they used it, and if the FSF comes up with something better then I bet they'll switch to that in an instant.
They'll switch - if they can ! What would happen with the accumulated history of the files ? Sure the BK file format is open _now_, but will it be open in the future ? What would prevent Larry from "creatively extending" the SCCS format at the first sign the Linux (the kernel) project would switch to something else.
That's one of the real strengths of Linux - ideology takes a back seat to getting the job done, and IMO it explains why Linux has been one of the most successful Unix variants.
Welcome to the real world - technology advantages have nothing to do with success. Ask IBM about OS/2 and Microsoft about Windows.
~velco
These morons are not worried at all about the patient's information, they seek way to cover their fscking ass.
And again "who is responsible" ! In other words "we don't give a shit if the patient dies, as long as we are not held responsible" !
* Linus does pull from bitkeeper trees
:)
:)
Is this the way that some changesets get into the Linus's bk repo ? If so, I stand corrected.
* distributed repositories have much more benefits than the push/pull model, they are also needed so every developer can do version control on his/her own tree
Distributed repositories are not distributed at all if there isn't communication between them. I can do version control in my own tree with every SCM out there. The very essence of being distributed is in the inter-repository flow of changesets.
* There are a whole number of forks of the Linux kernel tree out there, that wouldn't have been as easily possible without bitkeeper
Why so ?
How about "cvs checkout foo; cd foo && find . -name CVS | xargs rm -rf; cd foo && cvs import foo".
Well, "bk clone" is simpler, indeed, but does this matter ? How often you make clones ?
Given that your conclusions are based on false premises I wouldn't put too much value in them.
False or not is yet to be established
Having a distributed SCM does matter.
But, yes! I, in fact, very much like BK exactly because of the distributed repositories. My point is that exactly these features are not used by Linus, which renders bogus the argument "use the right tool for the right job" (or, on a second thought, maybe not. Using roughly the "CVS subset" of BK does not make it less suitable than CVS
~velco
And who exactly are you, to tell me which products I should or shouldn't use ?
:)
All my patches are available in other formats too, you don't need bitkeeper to access my stuff.
I'm not forcing anybody to use bitkeeper, you shouldn't try to force me to stop using bitkeeper
No, not forcing, but persuading
Bitkeeper has improved my productivity and my contribution to open source software. Though it's not a necessary tool for my work, I'm thankful that Larry makes my work easier by allowing me to use his program.
Well, I guess it is time to dissect the supposed advantages of BK over other version control systems.
First, the imporatance of the version control itself. The question is how does using or not using a SCM tool influences the success or failure of a project. Are there any studies, which indicate that software projects generally experience more failures when SCM is not used ? I know of none. And until someone shows my one, I'd stick to my own experience - the SCM tool does not matter at all.
Second - BK advantages. The most cited advantage of BK other other SCM tools are distributed repositiories and the push/pull operations.
Well, I can really see the convenience of using such a tool - but only if the communication between the developers follows thge push pull model.
This is not the case with Linux (the kernel) and Linus.
See these statistics.
Fact - the only pushes into the tree are made by Linus himself. Well, it looks like Linux (the kernel) developers are not using exactly the features they claim they're using BK for.
(This is not unexpected, given the overly centralized nature of the Linux (the kernel) development process. Ironically, BK would be much more useful for a project like GCC, which is much more democratically organized (and bigger too)).
To conclude (argumented IMHO, of course):
SCM does not matter.
BK is not necessary.
Well, then, if it does not matter (technically) anyway, why don't use something free ?
And, BTW, you DO miss the point - the talk is about licenses that sux0rz - not about techical merits of one or another SCM tool.
~velco