Slashdot Mirror

What PJ & company have done is assemble the pieces to show that what was being contributed by Christoph Hellwig (and other peons at SCO) was well understood by both his immediate boss and by corporate management. There is no plausible deniability.

Probably the best thing to come out of all the GrokLaw digging is this quote:

"From: Jeff V. Merkey (jmerkey@timpanogas.com)
"Date: Wed Aug 23 2000 - 12:19:53 EST

"This whole SCO thing is overrated. I worked on the Unixware code base at Novell, and it's putrid in comparison to Linux. It's got a lot of good apps, but so does Linux. This kind of tripe propaganda is what the "cult" followers of Unixware are good at. They lost @ $ 38,000,000 dollars each year at Novell ramming UnixWare down our throats and pissing of our customers -- Novell finally cut rheir losses and sold it. Don't get me wrong, it's decent Unix stuff, but Linux is tons better as a general purpose PC Unix. Just remember, Caldera is a LINUX company -- they will take the best of both, and use it to improve Linux ...."
v :-)

Jeff

"Insofar as this interrogatory seeks information as to whether plaintiff has ever distributed the code in question or otherwise made it available to the public, SCO has never authorized, approved or knowingly released any part of the subject code that contains or may contain its confidential and proprietary information and/or trade secrets for inclusion in any Linux kernel or as part of any Linux distribution."

Cross your heart and hope to die, SCO? Or cross your fingers behind your back? Let's see what the evidence shows.

SCO has specifically mentioned the following four as being code at issue in this case: JFS, NUMA, RCU, and SMP, and while it is conceivable that the "subject code" they are talking about in this response to IBM's interrogatory is referring to some other code, it seems reasonable to look at the code they have mentioned publicly. Actually, it's more than reasonable. It's our only choice, until they tell us exactly what code they are complaining about with specificity. Is it true that they never "authorized, approved or knowingly released" any of this code for inclusion in any Linux kernel or as part of any Linux distribution?

Let's start with JFS. In the case of JFS, they not only distributed Linux with JFS, one of Caldera's employees, Christoph Hellwig, contributed code to JFS, as Groklaw reported on July 18. Here is a snip from that article:

"Here is an email in which he tells an inquirer how to contribute to JFS, including this tidbit: 'I've run native sysvfs tools under linux, but as now that I'm Linux sysvfs maintainer I'm looking into implementing free versions of it. . . . The JFS/Linux core team has setup a CVS commitinfo, but currently I'm the only one who receives it.'

"And here he encourages someone to donate to the main JFS repository at IBM and talks about his role:

"'I'm one of the main commiters to JFS outside IBM and I'm really happy to see more people involved :)

"'First I'd like to encourage you to contribute your userspace changes to the main JFS repository at IBM. For the 1.0.11 release I have added autoconf/automake support to easify portability and a bunch of portablity patches (mostly getting rid of linuxisms) is under way to the Core team.'

"He also posts to the freebsd list as freebsd-fs at freebsd.org.

"Here is the press release when SCO in 2002 released 'SCO Linux Server 4.0 for the Itanium (R) Processor Family' and which mentions that the product is based on United Linux. This SCO page lists JFS as one of its features. . . .

"They are complaining that IBM contributed JFS to Linux, but their own employee, from this evidence, was involved in helping out. On the day IBM announced JFS was being given to Linux, Hellwig is listed as making five contributions to the kernel."

And he is listed on this page of JFS contributors. Here is IBM's page on Who Is Using JFS? and it lists United Linux. So they not only released a distro with JFS in it under the GPL, their employee helped make it h

I didn't realize that it was abuse to want to keep your code yours.

No, but using other people's code in ways that they have forbidden is abuse.

If it's so difficult, what are MODULE_LICENSE and EXPORT_SYMBOL_GPL for?

You are on the right track. If your drivers are dynamically loadable, not static and they avoid using any symbols marked with EXPORT_SYMBOL_GPL(), then you will be OK. Furthermore, no cheating and writing two drivers one a GPL'd one that exists to re-export the EXPORT_SYMBOL_GPL symbols and then the real driver that makes use of the re-exported symbols. More info available here.

As a rule of thumb, your company must offer (and make good on the offer) to provide source such that an end user can build the software as you've distributed it. Technically you don't have to provide the binaries for your own closed loadable modules, but if the user is able to extract them from the product/device then they better work with whatever kernel source and build configuration you do distribute to comply with the GPL. You can count on at least one person being motivated enough to test your company's compliance on this too, no matter how hard you may try to hide or protect the binary-only modules.

So, what's going on here? Are these simply two unrelated attacks? Is it an attempt by an immature highschooler with some cracking talent to boast to his friends "LOL 1 hax0rred debian.org!?" Is it an attempt by some sort of anti-Linux commandoes to undermine Linux's public image? I almost suspect the latter, but the prime suspect there is Microsoft, who have far too much to lose by going that route and plenty of money for traditional FUD that will make it into "traditional" news channels better anyway. SCO might be crazy enough to do it, but they probably wouldn't want to divert resources away from spewing lawsuits at everyone in existence.

From what I understand of the cracker community, Linux is held in fairly high regard (although I admit I don't try to keep up on the latest in the cracker community). You'd think that black-hats, who tend to be rather immature, when armed with a brand new exploit, would attack a site seen by the general public and post goatse.cx images on the front page, rather than subtly changing Debian packages. So, who's behind all this?

Now that you can use NDIS drivers under Linux, it will be that much harder to convince these companies that providing a native Linux driver would be good for their business...

2. It MUST have widespread hardware support. That means it supports the latest graphics cards, sound cards, network cards and I/O cards at full functionality of the device.

The only entity who really has control over this is the hardware manufacturer. If they release full specifications, or they develop drivers themselves, then it will probably be supported. Otherwise if you get support under Linux you should consider yourself lucky and praise the coder(s) who figured out how to do it on their own. I know the average user isn't going to understand this, but the people complaining here probably can.

The situation is really not all that bad right now - a huge amount of hardware already works very well with Linux. It will improve further as Linux increases in popularity and hardware companies start to realise the value in being open, or at the very least develop their own closed-source Linux drivers for their products.

Dramatic steps forward can occur when large deals (involving significant numbers of hardware units) are contingent on Linux support - eg. the recent addition of Promise SATA support to the Linux kernel. I suspect if more people emailed hardware companies who don't actively support Linux letting them know (politely!) that they chose some competing product instead of theirs because of Linux support, they might pay a little more attention.

I don't mean to imply that you are one but, sadly too many people jumping on Linsys without really havening the story.

The short version is that Brodcom was subcontracted by Linksys to develop the imbeded software and Linksys wasn't fully aware of the obligations under the GPL.

Linksys GPL code (or most of it) can now be found here.

Uhm, no...

read http://www.ussg.iu.edu/hypermail/linux/kernel/0311 .0/0651.html

. Linus resonds exactly to this.

It's worth mentioning that it would be close to impossible to add the
same to change to BK unnoticed. It's possible but the accountability
would be a lot better and the bad user could be tarred and feathered.

it was the power of BitKeeper, or at least BitKeeper's authors, that prevented this, not CVS itself.

Hopefully more information comes out as to how this happened and how widespread this is.

Keep reading the thread - you'll read a bid of Linus, and a comforting explaination of whats happenin' back there.

However, realise that this backdoor attempt was caught very early on, and by reading the comments posted on LKML, it almost certainly couldn't have been included in the main BK source tree, as updates to it would have stopped working (locally stored versions being different from the server version, this would have been immediately noticed.) So I'd say that there is already a proper verifications preventing backdoors.
Of course, more verifications can't hurt.

Its definately an FCC problem. The newest a/b/g chipset drivers are what's called "software defined radios". SDR is a major regulartory nightmare for the FCC because they can be reprogrammed by the user (more or less). Hence, the FCC wants to see infrastructure on the card to authenticate the code that runs there [kernel discussion]. Annoyingly.

The madwifi project is developing drivers for the Atheros a/b/g chipset. I've been using them and they appear to be reasonably good, for the moment. But, the distribute with a uuencoded binary blob that unpacks into a kernel module... I hear there are access points on the market that are basically Atheros a/b/g mini-PCI cards inside a plastic casing.

On the flip side, at least Intel sees the need to convince the FCC to open spectrums [quote]:

A third major challenge facing SDR technology is convincing the FCC to open the radio spectrum. In the past, the FCC has regulated specific radio bands for different types of communications. A radio device is then licensed for use in only a specific frequency range. Intel and other industry leaders would like to see devices licensed for multiple radio spectra, rather than for only one communications band. This would allow manufacturers to make a single device that could broadcast and/or receive at any appropriate frequency. The frequency used for a specific type of communication could then depend on the device or user identification, such as for National Guard, police, fire, Air-Sea Rescue, animal control, border patrol, road construction, clean-water works, and so on.

Anonymous karma whore?. Strange.

Absolutely not! That would be totally unprecedented!

If the process ends catastrophically (e.g. sudden power failure), it will never close() the file. As you mentioned, the file is no longer referenced elsewhere in the file system. So does this orphan the data on the hard drive?


There are in-memory structures (in the kernel) that maintains a list of open files. These structures have reference counts of their own. This reference count (the open count) is separate from the on-disk reference count (the link count). I think what happens in your scenario is the link count was already zero, but the open count is 1. So the total reference count for that inode is > 0, so the file is still considered used. When you reboot the machine, the in-memory strcutres are cleared, so the open count goes to 0, so the total is now 0 and the file (the inode sepcifically) is considered "deleted".

If this isn't correct, then maybe fsck just figures it all out and corrects it on reboot.

I wasn't 100% sure on this but I became curious myself and I found the following pages that provide nice explanation of it:

Re: rm-ing files with open file descriptors

This one has a nice diagram and explanation near the bottom, although it doesn't talk about link counts vs. open counts, just reference counts:
some class lecture notes

Why is this useful? I do a lot of numerical/engineering work. Say I have a root finding algorithm that throws a bunch of methods at a function in an attempt to find roots. It might first try doing some interval arithmetic to bound the roots and then when it's close enough go in for the kill with a newton solver. So I need to be able to write a polymorphic function that can be evaluated on the types appropriate to these methods (first intervals and then maybe doubles) but also be able to hand it in as an argument to a solver routine (which in this case would be rank-2 polymorphic though people will tell you C++ can't do that!). The above is the only way I know, And the cool thing is that It can also be a partially evaluated function (ie. in the simple example I gave I'm passing in the two argument function + but partially evaluating it by giving one of the arguments 'a'). This is all routine stuff in the functional world and is beginning to be routine in C++, but not yet. It's kinda object oriented but the object oriented frame of mind really is the wrong way to look at it.

Greenspun's rule. Yes, someone said that about some code of mine recently. But I have a response. For one thing the primary function of Greenspun's rule is to provide strokes for Lisp programmers' egos but these are the wrong people! C++ is a typed language and Lisp isn't. This makes a big difference. These methods push C++ more towards typed functional languages like ML or Haskell. Secondly: The example I gave is of a closure, written as (a+) in Haskell. But look where the work is happening: I haven't written any kind of interpreter, the compiler's doing the work. In fact if you take this stuff to its logical conclusion you're not implementing a Lisp interpreter but instead twisting the C++ compiler into a Haskell compiler. And if you don't believe me, here is that logical conclusion. If you look closely very little of that code is executed at run time (the lazy lists are), instead that minor mountain of code is directives to the compiler telling it how to behave like a Haskell compiler.

As for performance penalties: yup, they exist. It's the so-called abstraction penalty. I don't really understand why it exists because it takes only simple rewriting rules to eliminate the overhead but compiler writers don't use them. Luckily people like Veldhuizen are writing papers showing the compiler writers how they should be doing their job.

Actually, I am of the opinion that less an less investigation is going into cases before suing someone. I don't wish to go on ad-neasueam here. But please recall the alleged (then dropped) DMCA charges by Vivendi against bnetd, the group alleging that GenToo was distributing PACMAN. Please recall that DMCA allegation are made under the onus of perjury. If you make a DMCA claim you are stating that you believe this to be infringement. if its not you have perjured yourself. Then we have the whole SCO circus who aren't even following established practice as to stop the alleged infringement.

So in short, no I believe less and less companies are researching before they file suits.

Here's a link that might be faster:
http://www.ussg.iu.edu/hypermail/linux/kernel/0310 .1/0187.html

I got nothing at the link posted in the article, Heres a link to the conversation at another archive: http://www.ussg.iu.edu/hypermail/linux/kernel/0310 .1/0187.html

The entire tty layer locking is terminally broken

Other non-karma whoring mirror contributions accepted, you bozos.

http://www.ussg.iu.edu/hypermail/linux/kernel/01 09 .3/1579.html
Look at this thread, there is some miscommunication about what exactly protection is provided by reiserfs in the face of unexpected system shutdown ; note that they seem to have a problem with file content corruption due to lazy writebacks.

Now at a station near you !
Windows : Linorg Projeto Brasil ISC | IndianaU | BinaryCode | ibiblio.org | PAIR | SecsUp | Telentente | Umbc Vienna UT

Linux : IndianaU | ISC | BehrSolutions | BinaryCode | ibiblio.org | pair | SecsUp | Telentente | Umbc Vienna UT Belnet | KULeuvenNet CVUT Sunsite FUNET

Now at a station near you !
Windows : Linorg Projeto Brasil ISC | IndianaU | BinaryCode | ibiblio.org | PAIR | SecsUp | Telentente | Umbc Vienna UT

Linux : IndianaU | ISC | BehrSolutions | BinaryCode | ibiblio.org | pair | SecsUp | Telentente | Umbc Vienna UT Belnet | KULeuvenNet CVUT Sunsite FUNET

http://www.ussg.iu.edu/hypermail/linux/kernel/0309 .3/1058.html

I had my lawyer send the first of several letters (nice and polite) on 8 May... After several additional letters (increasingly less polite) my lawyer and I were finally contacted by Cisco on June 20. They stated at that time "We are in the process of determining what code is subject to the distribution obligation; once we have done so, all such code will be made available under the terms of the GPL."

So how does this affect your comment?

I should take my own advice and read the followups to the followups.

Eric Andersen's reply to Rob Landley points out that Cisco has had quite a few months (and several lawyer letters) to get into compliance, and are foot-dragging. (Although Linksys' letter seems to confirm that they outsourced the code development and they may not have the source themselves. Stupid.)

In particular, Rob Landley's well thought out response.

If Cisco/Linksys is deliberately violating the GPL, then yes, they should be raked over the coals as appropriate. However, given that they've already tried to cooperate with the GPL, it may be that there was just a disconnect between the guys putting stuff up on the website and the actual developers of the Linksys kernel (which, as Landley points out, might even have been outsourced -- and Cisco is probably pretty upset with them about now.)

The only thing that is meaningful is "performace at the same time of general availability". At which point the P4 beats the Itanium 2 senseless with a 25% higher SpecInt. And last I heard, by the time Itanium 2 is up at 2GHz, the P4 is apparently going to be at 5GHz, comfortably keeping that 25% lead.

IA64 made all the mistakes anybody else did, and threw out all the good parts of the x86 because people thought those parts were ugly. They aren't ugly, they're the "charming oddity" that makes it do well. Look at them the right way and you realize that a lot of the grottyness is exactly _why_ the x86 works so well (yeah, and the fact that they are everywhere ;).

And I further bet that using a native distribution (ie totally ignoring the power and price and bad x86 performance issues), ia-64 will work a lot worse for people simply because the binaries are bigger. That was quite painful on alpha, and ia-64 is even worse - to offset the bigger binaries, you need a faster disk subsystem etc just to not feel slower than a bog-standard PC. Code size matters. Price matters. Real world matters. And ia-64 at least so far falls flat on its face on ALL of these

I'm definitely not saying that the x86 is perfect. It clearly isn't. But a lot of people complain about the wrong things, and a lot of people who tried to "fix" things just made them worse by throwing out the good parts too.

IA64 made all the mistakes anybody else did, and threw out all the good parts of the x86 because people thought those parts were ugly. They aren't ugly, they're the "charming oddity" that makes it do well. Look at them the right way and you realize that a lot of the grottyness is exactly _why_ the x86 works so well (yeah, and the fact that they are everywhere ;).

And I further bet that using a native distribution (ie totally ignoring the power and price and bad x86 performance issues), ia-64 will work a lot worse for people simply because the binaries are bigger. That was quite painful on alpha, and ia-64 is even worse - to offset the bigger binaries, you need a faster disk subsystem etc just to not feel slower than a bog-standard PC. Code size matters. Price matters. Real world matters. And ia-64 at least so far falls flat on its face on ALL of these

I'm definitely not saying that the x86 is perfect. It clearly isn't. But a lot of people complain about the wrong things, and a lot of people who tried to "fix" things just made them worse by throwing out the good parts too.

IA64 made all the mistakes anybody else did, and threw out all the good parts of the x86 because people thought those parts were ugly. They aren't ugly, they're the "charming oddity" that makes it do well. Look at them the right way and you realize that a lot of the grottyness is exactly _why_ the x86 works so well (yeah, and the fact that they are everywhere ;).

And I further bet that using a native distribution (ie totally ignoring the power and price and bad x86 performance issues), ia-64 will work a lot worse for people simply because the binaries are bigger. That was quite painful on alpha, and ia-64 is even worse - to offset the bigger binaries, you need a faster disk subsystem etc just to not feel slower than a bog-standard PC. Code size matters. Price matters. Real world matters. And ia-64 at least so far falls flat on its face on ALL of these

I'm definitely not saying that the x86 is perfect. It clearly isn't. But a lot of people complain about the wrong things, and a lot of people who tried to "fix" things just made them worse by throwing out the good parts too.

That should be:

20 CONTINUE
25 C++ faster than Fortran

Remember, jumping to a line number that's not on a CONTINUE statement can break things. :-P

20 C++ faster than Fortran

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

Being a LKML lurker, here are a few of the new features.

• In-kernel Module Loader and Unified parameter support [kernel.org]
• Nanosecond Time Patch [iu.edu]
• Fbdev Rewrite [iu.edu]
• Linux Trace Trollkit (LTT) [iu.edu]
• statfs64 [theaimsgroup.com]
• POSIX Timer API [theaimsgroup.com]
• Shared Pagetable support [theaimsgroup.com]
• Hotplug CPU Removal Support and Kernel Probes (no link provided)

The self-documenting aspect of the community actually makes "RTFM" useful, because there is documentation written by people who have had your problem for the community to point you at. It's more helpful than people trying to write a new explanation of the solution every time someone has a question. Asking your question and getting told "RTFM" is sometimes more effective than trying to determine for yourself whether TFM will answer your question, or even finding the applicable documentation.

It also starts the dialogue about TFM, which may be out of date or have gotten lost somewhere, as was reported on linux-kernel recently about some documentation.

Actually, while I find this quite funny, I also find it a bit odd (and perhaps telling). I have read several previous interviews with Linus Torvalds on various topics and he almost never says something like this. (At least that's how I remember it. I'm sure many will correct me if I'm mistaken.) Although he always clearly states his opinion, he usually avoids getting into this sort of direct attack on an organization or person. This quote from him could mean a few different things. It's possible his nerves are getting a little frayed from all the SCO threats and related media blitz. I know I'm starting to get tired of it and I'm just a random, lazy slashdot poster. It must be much more uncomfortable where Linus is at. Also, although MS has frequently tried to marginalize Linux or say it doesn't count for anything, they never actually tried to claim ownership of it. Perhaps Torvalds considers that more of a personal attack.

There's another possibility you failed to consider: you don't know what you're talking about.

Or to put it more gently, perhaps you don't follow lkml. In fact, that's just perfectly normal Linus-speak.

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?

IIRC, Christoph Hellwig mentioned something about SCO likely having code that wouldn't survive review on lkml. Seems that it didn't.

Whatever, it does not ring any bells searching the kernel list either.

In a paranoid world... Did patch@hp.com ever exist?

Is there a connection with the compromisation of the FSF databases?! Wheeew...

Reference to Linux-Kernel posting

SCO is screwed.

This doesn't particularly matter since ate_utils.c was removed from the kernel some time back.

Beyond that though, Caldera put the ancient unix under a BSD license AFTER ate_utils.c was available on kernel.org. It wasn't in the main tree at the time, but it was available as in the ia64 port.

It's rather funny that SCO would show this piece of code. It does illustrate that someone at SGI pulled these functions from a bad source (it has appeared in print also, so it's possible the programmer got it from a book rather than a Unix tree), but the actual functions are trivially simple to replace. If you really think it through you're left wondering why in the world someone would use the Unix version of malloc and free rather than the slew of better written and untainted versions that are available.

Previous slashdot discussion is here. LKML thread is here.

Start of Thread

Conclusion

Start of Thread

Conclusion

Looks like it was published in Lion's book, thus rendering it Not A Trade Secret (i.e. there's probably no reason to obfuscate the code below the comment on the SYSV side of the slide).

In addition, it appears that Caldera put V1-V7 under a BSD-like license in 2002, and that code's there. See this e-mail.

The follow-on e-mails suggest that there's a good chance that function is going away anyways, because it was poorly written (and the job could be done by other, pre-existing code).

Looks like it was published in Lion's book, thus rendering it Not A Trade Secret (i.e. there's probably no reason to obfuscate the code below the comment on the SYSV side of the slide).

In addition, it appears that Caldera put V1-V7 under a BSD-like license in 2002, and that code's there. See this e-mail.

The follow-on e-mails suggest that there's a good chance that function is going away anyways, because it was poorly written (and the job could be done by other, pre-existing code).

Question is about the SGI code's Unix licence.

Answer is the answer that caldera itself put the questionable code under a BSD licence in 2002.