Slashdot Mirror
BitMover Releases Open Source BitKeeper Client
diegocgteleline.es writes "Larry McVoy, the owner of BitKeeper (also one of the guys behind LMbench) has posted a message to linux-kernel where he announces a open source client of BitKeeper, which would only allow synching against BK trees. It looks like it's licensed under the NWL (No Whining License) that will force you to 'not whine about this product or any other products from BitMover, Inc.'"
Actually he said in the email that the whining license was a joke and he's actually licensing it as BSD (and later said it could even be considered public domain), though until the source code is re-released with proper license headers, I doubt his statement to lkml is legally binding in any way.
-Tupshin
The original implementation of GNU Arch was done in bourne shell. Pyhton is a big step up from that.
In any case, I think it is a fine combination when the core functionality of a program is written in a statically typed language, and UI binding it together is written in a dynamically typed language.
The point of this article is that you no longer need to use the "we own your soul" closed source BK client just to download the kernel; you can use the open source client instead.
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
Gosh, get a clue, will you! Or read the lkml archives. Linus chose bitkeeper precisely because all the alternatives you mention don't cut it.
This is exactlythe attitude that keeps holding open source back. It's not about whether the source is open or not, it is about choosing the right tool for the right job. More people should understand this...
No, your attitude is the one with the problem. No current open source solution adequate? Then help make one that is- either by improving an existing alternative, or starting your own. If you don't have the skills/time to do so, encourage others who do to take it up. Just criticizing without doing anything about it helps noone.
I still have more fans than freaks. WTF is wrong with you people?
No, your attitude is the one with the problem. No current open source solution adequate? Then help make one that is- either by improving an existing alternative, or starting your own.
...if you're trying to do the community a service. If you're looking to put food on the table doing something completely unrelated (where this is simply a support function), it is mindnumbingly stupid. Most likely you're long out of business by the time it is working.
Sure, if all you need is some minor customization, maybe. But if it clearly isn't anywhere near being up to the task, pick something non-OSS. Earn some money, help out the projects where it is feasible to replace proprietary with OSS.
That is the way OSS projects prospers. I make a 98% solution a 100% one. That makes it a 98% solution for someone else, who'll make it a 100% solution for them. And the snowball is rolling. Not by one company breaking its back trying to bring it from 40% to 100%.
Kjella
Live today, because you never know what tomorrow brings
However, having said this, it's still quite understandable for people to not want Linux development being tied to a closed-source product with nasty gotchas in it's free license. That's not whining in the least.
The problem is that people who whined about BK being propietary should have shut their mouth up, but they didn't. When Linus switched to BK, he made clear that he would NOT force to anyone to use BK, and that's how it has been: Linux kernel.org releases are released in GNU diff format, so everybody can code and contribute. The one reason why all^Wmost of the kernel developers use BK is because they aren't stupid, BK is a great tool and can save hours of work, and it lets them to work easier between those who use BK. When someone wants to get a patch to get merged they also made the GNU diff format patch available, and even if they didn't, bkbits.net provides you a link to get a GNU diff patch for every changeset out there. Those who claim that "anyone who wants to closely track patches to Linux can only do it by installing that non-free program" to develop the kernel are just wrong because you have access to the latest kernel changes without installing a non-free tool. -mm and -ac tree are maintained using open tools, so I don't see where is BK being "required".
The one reason why people whine is because they want to have the advantages of BK, but without using a propietary tool. That's not possible, there's not a OSS tool comparable to BK, subversion arch and friends are not even close. Everybody agrees that having such tool would be great (Linus even tried to convince Larry to release BK under a open license) but there's not one.
IMHO is just like when RMS had to use propietary tools to start developing GNU - Linux developers just use BK because using a OSS SCM would mean the linux kernel development would slow down a lot, and that's not good (and again, if you are going to propose to use subversion, arch, etc, it probably means that you do not understand the frenetic kernel development needs and the power of BK)