Slashdot Mirror

They are not closing the source, they just stopped providing a tarball.
If you want the tarball anyway (5.2 or whatever version), just type:

bk clone http://mysql.bkbits.net:8080/mysql-5.2 mysql-5.2
tar -cf mysql-5.2.tar mysql-5.2/
bzip2 mysql-5.2.tar

There you go.. you have the tarball!

> Every time a product starts to get good, some greedy fugknuckle on the project decides to close the source.
> We've seen it again and again.

They are not closing the source. To fetch the source you just have to type:

bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1

Is that so hard? What they are not providing is a TARBALL. If you want the tarball anyway:

bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1
tar -cf mysql-4.1.tar mysql-4.1/

> Every time a product starts to get good, some greedy fugknuckle on the project decides to close the source.
> We've seen it again and again.

They are not closing the source. To fetch the source you just have to type:

bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1

Is that so hard? What they are not providing is a TARBALL. If you want the tarball anyway:

bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1
tar -cf mysql-4.1.tar mysql-4.1/

http://mysql.bkbits.net/ is still there, and AFAIK it isn't going away anytime soon.

Of course, there are a lot of things that programmers can do to make code easy to read, but I'm quite interested in the things that computers can do to make code easy to read.

For example lxr.linux.no is great but it would be even better if it was integrated into the editor. They say etags is the same, but I've never been able to make it work.

Another thing that would be great would be color coding for bugginess. There are a bunch of different static analysis tools that could generate a bugginess value for each line of code. Also really picky indent color coding would be nice.

Another thing would be better integration with the CVS. Something like this perhaps. It would be handy to know if a bug only affected 2.6 or if it went back to 2.4 as well.

Those are some ideas. Gotto run.

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)

the number of people who have examined the code isn't equivalent to the number of people who have contributed to the code

And the number of people listed in MAINTAINERS isn't equivalent to the number of people who contributed code either. If the MS shill had given some source for his data, we could probably make better speculations.

It would be very hard to count even by looking at the changelog. Most of the IBM patches for example are submitted by a couple of people, but were developed by other people in or around IBM.

Go grab the patches. They're commited into the BK repositories already. Sheesh.

Patches for 2.4 can be found in this changeset.

Patches for 2.6 can be found in this changeset.

Click on the little "diff -Nur style" link for a an actual usable patch.

In the course of a few hours, you have the fixes already. Yay for open source.

Btw, nice troll :p

Go grab the patches. They're commited into the BK repositories already. Sheesh.

Patches for 2.4 can be found in this changeset.

Patches for 2.6 can be found in this changeset.

Click on the little "diff -Nur style" link for a an actual usable patch.

In the course of a few hours, you have the fixes already. Yay for open source.

Btw, nice troll :p

As far as I've read, Linux can be run on iBooks but the hardware support is seriously lacking, which disables some important functions like power saving...

This now works with a patch from BenH, probably going into 2.6.11 (not a typo).

I doubt that Apple has yet documents available on controlling G5's fan system, enabling driver writing?

It works since a long time.

Name one feature of C++ that is compelling and useful for the kernel that can't be accomplished in C in a maintainable fashion?

It's a simple question, one I posed before. Are you going to answer it or call me a troll for pointing that until the last 2 years, there wasn't a decent C++ compiler. The 2.4 kernel series still lits in it's documentation, that egcs-1.1.2 (which I believe corresponds to gcc-2.91), is still being supported. So it's not a completely irrelavent point.

http://linux.bkbits.net:8080/linux-2.5/hist/Docume ntation/Changes?nav=index.html%7Csrc/%7Csrc/Docume ntation

Look for the entry that says "Enforce gcc 2.95 compiler as the minimum". Hey, look at that, right next to it that says, 19 months ago that was the minimum. So as off 19 months ago, it sorta follows that they had to support the what you seem to reguard as a substandard C++ compiler. I believe that 2.91 is still used as the compiler of choice for older Sparcs. That's during the 2.5 development kernel.

http://linux.bkbits.net:8080/linux-2.5/anno/Docume ntation/Changes@1.33?nav=index.html%7Csrc/%7Csrc/D ocumentation%7Chist/Documentation/Changes%7Cdiffs/ Documentation/Changes@1.33

Hey, look at that, in the 2.6.0 Documentation/Changes, the required version is still 2.95.X (x>=3). So which version of the C++ compiler did you want to you?

So while you might think they are 4 years old, and unsupported, it is still the version that Linus says is the correct version of the compiler to use. You might think I'm a troll, but at least I know the details of the projects I use. *sigh*, I wish people paid attention to details once in a while. The kernel is very sensitive to the version of GCC it is compiled with. As a general rule that means they are very reluctant to require newer versions, or even support newer versions.

Actually, assembly is syntactical sugar, do in in machine code (or if your into Turing machine, with punched paper tape). It's nice of you to call me a troll, but you still have yet to state a compelling reason why C++ is a good idea to have in the Linux kernel. C++ and Objective C (I've programmed in both professionally), are very slick ways of accomplishing things that can be done in straight up C (especially Objective C). C++ is much nicer to program in then C if only because it means I never have to null terminate a string again. Given a choice, I'd never ever write a line of C again in my life.

The subset of C++ that is actually hard to do a good job of in C is nearly identically the subset that wouldn't be useable in the Linux kernel. Most of the best ideas for using C++ in the kernel are type checking and virtual functions. Type checking is already a problem (Linus points out that GCC emits spurious warnings about code that is obviously correct to anyone who takes a cursory look at the code w/ the 3.X series of GCC, it would only get worse with G++). He's writting his own set of tools to do type-checking that is tailor made for the Linux kernel.

http://www.kerneltraffic.org/kernel-traffic/kt2004 1019_278.html#5

Virtual functions are nothing but a table of function pointers. They do this all the time in the Linux kernel. I'm asking a simple question, name something besides those two features of C++ that are a tool that needs to be used in the Linux kernel that would be impossible to maintainably implement in C.

I wish they had namespaces, but that's not something that is impossible to do in

Name one feature of C++ that is compelling and useful for the kernel that can't be accomplished in C in a maintainable fashion?

It's a simple question, one I posed before. Are you going to answer it or call me a troll for pointing that until the last 2 years, there wasn't a decent C++ compiler. The 2.4 kernel series still lits in it's documentation, that egcs-1.1.2 (which I believe corresponds to gcc-2.91), is still being supported. So it's not a completely irrelavent point.

http://linux.bkbits.net:8080/linux-2.5/hist/Docume ntation/Changes?nav=index.html%7Csrc/%7Csrc/Docume ntation

Look for the entry that says "Enforce gcc 2.95 compiler as the minimum". Hey, look at that, right next to it that says, 19 months ago that was the minimum. So as off 19 months ago, it sorta follows that they had to support the what you seem to reguard as a substandard C++ compiler. I believe that 2.91 is still used as the compiler of choice for older Sparcs. That's during the 2.5 development kernel.

http://linux.bkbits.net:8080/linux-2.5/anno/Docume ntation/Changes@1.33?nav=index.html%7Csrc/%7Csrc/D ocumentation%7Chist/Documentation/Changes%7Cdiffs/ Documentation/Changes@1.33

Hey, look at that, in the 2.6.0 Documentation/Changes, the required version is still 2.95.X (x>=3). So which version of the C++ compiler did you want to you?

So while you might think they are 4 years old, and unsupported, it is still the version that Linus says is the correct version of the compiler to use. You might think I'm a troll, but at least I know the details of the projects I use. *sigh*, I wish people paid attention to details once in a while. The kernel is very sensitive to the version of GCC it is compiled with. As a general rule that means they are very reluctant to require newer versions, or even support newer versions.

Actually, assembly is syntactical sugar, do in in machine code (or if your into Turing machine, with punched paper tape). It's nice of you to call me a troll, but you still have yet to state a compelling reason why C++ is a good idea to have in the Linux kernel. C++ and Objective C (I've programmed in both professionally), are very slick ways of accomplishing things that can be done in straight up C (especially Objective C). C++ is much nicer to program in then C if only because it means I never have to null terminate a string again. Given a choice, I'd never ever write a line of C again in my life.

The subset of C++ that is actually hard to do a good job of in C is nearly identically the subset that wouldn't be useable in the Linux kernel. Most of the best ideas for using C++ in the kernel are type checking and virtual functions. Type checking is already a problem (Linus points out that GCC emits spurious warnings about code that is obviously correct to anyone who takes a cursory look at the code w/ the 3.X series of GCC, it would only get worse with G++). He's writting his own set of tools to do type-checking that is tailor made for the Linux kernel.

http://www.kerneltraffic.org/kernel-traffic/kt2004 1019_278.html#5

Virtual functions are nothing but a table of function pointers. They do this all the time in the Linux kernel. I'm asking a simple question, name something besides those two features of C++ that are a tool that needs to be used in the Linux kernel that would be impossible to maintainably implement in C.

I wish they had namespaces, but that's not something that is impossible to do in

The ability to compute dependencies automatically in Clearcase is worth it's weight in gold (I believe Rational have patented it ? Can't say for sure though). It saves a huge amount of hassle because it "just works". Sure, if you have the time you can hang around and mess around with strace and gcc -M, but if your time is invaluable having something that works out of the box is a great boost. Clearmake can even work out when you've changed the makefile itself or other included makefiles; that's very hard to do under regular make.

I've been trying to get my place to move away from Clearcase (slow; dodgy cross-platform support; hard to use away from the office; no real process flow model without extra cost) and the one hard part to tear people away from is the clearmake capability.

Some folks have had some ideas about how to do this on Linux, the best idea being to patch glibc to track file accesses, ie this idea.

Well, I put that in my list because, as much as it doesn't seem kernel-related, there has been a bug in one of the last DRM merge in the kernel, causing AGP access by X to fail (and thus falling back to PCI mode). This slowed glxgears by a factor of four on my laptop...
The bug was due to some 2.4 related code not being stripped when merged in the 2.6 kernel, but the #ifdef guardian itself had been stripped. See this changeset.

Well, yes that is the patch if you are running x86_64.

The 2.4 patch for i386 is here:
http://linux.bkbits.net:8080/linux-2.4/diffs/inclu de/asm-i386/i387.h@1.5??nav=index.html|ChangeSet@- 7d|cset@1.1447

I'm not sure, but I think this may be the fix--

http://linux.bkbits.net:8080/linux-2.6/diffs/inclu de/asm-x86_64/i387.h@1.12?nav=index.html|ChangeSet @-4w|cset@1.1754.6.3

patch for i386

http://linux.bkbits.net:8080/linux-2.5/diffs/inclu de/asm-i386/i387.h@1.16?nav=index.html|src/.|src/i nclude|src/include/asm-i386|hist/include/asm-i386/ i387.h

is there a site where i can just browse through the sources without downloading them?

To see the source tree as Linus updates it, go to http://linux.bkbits.net:8080/linux-2.5 and click on Browse the source tree (Yes, even though it says "2.5", it's really 2.6 these days...)

is there a site where i can just browse through the sources without downloading them?

To see the source tree as Linus updates it, go to http://linux.bkbits.net:8080/linux-2.5 and click on Browse the source tree (Yes, even though it says "2.5", it's really 2.6 these days...)

I still think you do need to treat the cooling system in the G5 like a black box

Or give a look at this driver.

The patch is from 9 weeks ago... I wonder if the exploit writer got the idea from looking at the kernel changelog...

Earlier today BenH released a G5 fan control driver for Linux.

So those damn hippies don't like /.? How dare :p

Interesting post to the linux mailing list here

Another thing to note, how come the file is no longer in bit keeper? Am i looking in the wrong place? Got removed?

More importantly it was release PRIOR to Caldera relicensing the Ancient Unix code.

Not quite; the Caldera BSD-style licence arrived on Jan. 23, 2002. The earliest date on the file itself is 2002/02/28 17:31:25, in the initial 2.4 patch that added this file. The patches themselves were added on March 9 and 13, 2002.

2.4 initial patch.
2.5 initial patch.

However, the required copyright notice is not there, so if an SGI employee submitted this file to the Linux IA-64 implementation under the assumption that the UNIX copyright issues had been cleared by the Caldera announcement, that employee blew it by not adding a proper copyright notice. If the file in question, however, comes from SGI's IRIX code, then the issues changes to whether SGI's changes to SysV code become property of the SysV owner under the AT&T licence, or whether SGI managed to get an IBM-like exemption on the derivative works clause.

Either way, it appears to me that the breach of copyright was initially committed by an outside coder, who submitted the code as part of the IA64 implementation to the kernel maintainers without adding proper attribution.

I think some more investigation needs to be done into the origins of the code. It would be very helpful if the individual who initially submitted this code for addition to the kernel spoke up.

More importantly it was release PRIOR to Caldera relicensing the Ancient Unix code.

Not quite; the Caldera BSD-style licence arrived on Jan. 23, 2002. The earliest date on the file itself is 2002/02/28 17:31:25, in the initial 2.4 patch that added this file. The patches themselves were added on March 9 and 13, 2002.

2.4 initial patch.
2.5 initial patch.

However, the required copyright notice is not there, so if an SGI employee submitted this file to the Linux IA-64 implementation under the assumption that the UNIX copyright issues had been cleared by the Caldera announcement, that employee blew it by not adding a proper copyright notice. If the file in question, however, comes from SGI's IRIX code, then the issues changes to whether SGI's changes to SysV code become property of the SysV owner under the AT&T licence, or whether SGI managed to get an IBM-like exemption on the derivative works clause.

Either way, it appears to me that the breach of copyright was initially committed by an outside coder, who submitted the code as part of the IA64 implementation to the kernel maintainers without adding proper attribution.

I think some more investigation needs to be done into the origins of the code. It would be very helpful if the individual who initially submitted this code for addition to the kernel spoke up.

Since it looks like this may be a piece of code covered by a BSD-type licence that does not adhere to the licence restrictions (namely, proper copyright notice and attribution), it may be a good idea to start tracking down who is responsible for submitting this patch in the first place.

The file is in 2.4.21, but got dumped about eight weeks ago.

That particular defunct file in 2.5 was submitted by what looks like a generic HP patch submission address. In 2.4, it came from patch@conectiva, which leads me to believe Marcelo added this as part of a large ia64 patch (he has a conectiva.com address). The code has an SGI copyright notice, so I'd be interested to discover if this piece of code exists in IRIX, and what SGI's Unix contract looks like.

A jbarnes@sgi.com patched the file in question twice before it was deleted in 2.5 by chadt, while a jh@com[helgaas] patched and deleted it in 2.4.

At this point, I would need to know what SGI's Unix contract specifies, and where SGI got this code from in order to rate a copyright notice on the file.

The relevant histories of ate_utils.c for 2.4 and 2.5.
Apparently the code was removed because it was "ugly as hell" (or worse).

The relevant histories of ate_utils.c for 2.4 and 2.5.
Apparently the code was removed because it was "ugly as hell" (or worse).

Check this out

patch@hp.com according to bitkeeper.

Also, this has been removed in 2.6, mainly because it was a stupid implementation.

There's also a very informative lkml thread about this and it's already been removed from the source tree, but apparently not because of copyright issues but because it was just "ugly as hell".

In March, SCO Group surprised the world with a lawsuit seeking more than $1 billion against IBM in the case. An amended complaint filed Monday in U.S. District Court in Utah added more claims against IBM, tripled damages to at least $3 billion, sought an injunction prohibiting IBM from selling Unix and detailed some accusations of technology moved to Linux.

SCO seeks at least $1 billion in damages from IBM's alleged breach of its contract with SCO; another $1 billion for breach of the Unix contract signed by Sequent, which IBM acquired in 1999; and another $1 billion for unfair competition. SCO also seeks more for misappropriation of trade secrets and punitive damages.

The amended suit also asserts that SCO holds copyrights to Unix, a point that could be key in future Linux and Unix litigation. Novell, which owned Unix intellectual property before selling it to SCO's predecessor, initially disputed SCO's ownership, but later relented.

However, the suit still makes no claims of copyright violation, which several independent attorneys believe could lead to stronger claims than that of trade secret infringement. After the Novell spat, SCO said it had not registered those trademarks. Independent attorneys say SCO must register the trademarks before basing legal action on them.

SCO has made no secret in recent months that it hired high-profile attorney David Boies to spearhead its case against IBM, but the company's legal representation in Utah courts is also noteworthy. The company retained Brent O. Hatch and Mark F. James of the law firm Hatch, James & Dodge. Hatch is the son of Sen. Orrin Hatch, R-Utah, a representative for SCO confirmed Monday.

The suit specifically blames Linux founder and leader Linus Torvalds for allowing proprietary Unix code into Linux.

"As IBM executives know, a significant flaw of Linux is the inability and/or unwillingness of the Linux process manager, Linus Torvalds, to identify the intellectual property origins of contributed source code that comes in from those many different software developers. If source code is code copied from protected Unix code, there is no way for Linus Torvalds to identify that fact," the suit said. "As a result, a very significant amount of Unix protected code is currently found in Linux 2.4.x and Linux 2.5.x releases in violation of SCO's contractual rights and copyrights."

Torvalds said in an e-mail interview that the Linux developer community's process is transparent and called on SCO to reveal what its specific complaints are.

"It's not our side that isn't identifying the code. We'll work damn hard to identify everything they care to name," Torvalds said. "In fact, the source control system is out there in the public, and it identifies the source and the reason for patches," mentioning the BitKeeper repository he's used for the past two years to keep track of code in the heart, or kernel, of Linux.

Torvalds sided with IBM over what rights Big Blue has over its code. "IBM, as the original sole author to a particular piece of code, has full copyright rights, and they (not SCO) can use the code they wrote themselves in any way they see fit," Torvalds said.

In its amendment, the Lindon, Utah-based company toned down some of the language questioning the abilities

I use it and I'm very happy with it. Heck, even Linux kernel is maintained with it.

I haven't tried it myself yet, but I found no reference to this ptrace vulnerability [google.com] in the changelog. I suspect this is still a problem (it was in 2.4.19).

I haven't tried it myself yet, but I found no reference to this ptrace vulnerability [google.com] in the changelog. I suspect this is still a problem (it was in 2.4.19).

Hey, my linux box has a SAK too!

Does it do the same thing that MS SAK does?

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

Despite staunch opposition from certain developers, Linus has recently started to maintain the kernel using the non-free BitKeeper SCM product, which is not only proprietary but also uses undocumented file formats, making interoperability difficult or impossible. Do you think it's fair to encourage developers who would otherwise keep to Free Software to turn to a proprietary solution and what is in effect, shareware?

Just to point something out in RMS's argument that makes absolutely zero sense -- you do NOT need to install the BK client in order to track the changes in the Linux kernel. All you need is an open-source, "free" web browser (i.e. Mozilla, Konqueror, Galeon, Lynx) to go and view the source, patches, etc. Don't believe me? Point your web browser (free or non-free -- which ever you prefer) to -> Linux 2.5 Development Tree. If you are interested in the Linux 2.4 tree, try this link to Marcelo's tree.

So how is that I need to install a non-free client app to closely track the progress of kernel development RMS? This interface lets me see the entire version history of the kernel -- file by file or patch by patch from any web broswer (free or non-free). I can even search the change set comments for particular information (e.g. search for SCSI to find all of the SCSI patches). It seems to me that this interface is better than anything this community has previously had to track the progress of the kernel. Not to mention, we get more informative change logs now. Just for grins, I even accessed this site from a Kyocera Palm phone. Slow as all get out, but it worked.

Just to point something out in RMS's argument that makes absolutely zero sense -- you do NOT need to install the BK client in order to track the changes in the Linux kernel. All you need is an open-source, "free" web browser (i.e. Mozilla, Konqueror, Galeon, Lynx) to go and view the source, patches, etc. Don't believe me? Point your web browser (free or non-free -- which ever you prefer) to -> Linux 2.5 Development Tree. If you are interested in the Linux 2.4 tree, try this link to Marcelo's tree.

So how is that I need to install a non-free client app to closely track the progress of kernel development RMS? This interface lets me see the entire version history of the kernel -- file by file or patch by patch from any web broswer (free or non-free). I can even search the change set comments for particular information (e.g. search for SCSI to find all of the SCSI patches). It seems to me that this interface is better than anything this community has previously had to track the progress of the kernel. Not to mention, we get more informative change logs now. Just for grins, I even accessed this site from a Kyocera Palm phone. Slow as all get out, but it worked.

I like especially the new openness that's achieved with this.

It's exciting to see what's being done to the kernel Right Now: ChangeSet Summaries for kernel 2.5

Before this it always seemed to be a miracle of when and how the kernel evolves and why this Linus guy is doing the releases... ;) (joke, Laugh Now!)