Donating to legal defense funds, unlike buying things, is tax deductable, and is more useful information for everyone involved. It also saves somewhat on overhead.
Filtering technology alone is not the answer. But an authentication scheme where the sender demonstrates the ability to use the From address would eliminate almost all of the spam that forges that information and make filtering or litigating the rest easy.
The issue is that, while weak recipient authentication was built into SMTP, corresponding sender authentication was not; this means that everyone is always anonymous (except for name tags they write themselves), there is no accountability, and people behave badly. Trying to apply technology at the level of behavior is obviously going to be ineffective.
Solution: add a "XM" DNS record type (MX backward), which specifies the hosts which are expected to send emails with the given return address. If a sending machine doesn't have the right XM, MX, or A record, flag the message as likely spam (if it's not spam, the sender should get the DNS updated or their mail routed better).
IBM will be supporting Red Hat in this indirectly. Remember that IBM doesn't actually have their own distribution; they make their money shipping hardware and doing consulting, using Red Hat and SuSE. So they don't really have a good case against SCO. But they'll probably be funnelling extra money into Red Hat through their existing business deals to cover the cost of a good legal team.
In any case, there's not much point in IBM suing SCO. They're already in a court case with SCO, and, if IBM wins, SCO is dead in the water. There's no point in having another lawsuit with essentially the same claims and results at the same time.
Regarding that analogy, two points: Publisher B is claiming that the book plagiarizes private correspondance, which they claim rights to but aren't publishing (copyright holders have the right to suppress the things they've written). Also, they are suing Author X, but it's going to take a while.
OSS is free like national (state, city, etc) parks are free. It exists for a reason unrelated to money. There's no significant charge because keeping people who don't pay out conflicts with the real purpose. Linux was created as a habitat for software, and is open to the public because it's nice for people, too.
There are a number of similar examples people might recognize: streets, except for rare toll roads, don't cost anything to drive on, because there would be terrible traffic. On-street parking and parking lots are free when it's too much of a pain to enforce things. The reference section at the library doesn't charge anything, because it's purpose is to provide access to information.
The programmer doesn't write spam filters for fun. The programmer writes spam filters because he is annoyed by spam and can do something about it. The programmer distributes the spam filter because his friends are annoyed by spam, too, and sometimes get confused and delete his messages. The programmer lets Joe user get the spam filter, despite not knowing Joe personally, because stopping Joe from getting it doesn't benefit him.
Method calls aren't branches; they're jumps (that is, they're always taken). Branches are due to your control structures, and OO doesn't matter (imperative vs. functional does, though).
For method calls, all of your private methods, static methods, final methods, and methods of objects whose compile-time time is final are constant offset jumps, and the loader can resolve all calls to methods of this by making a copy of all of the functions from superclasses and connecting them up. Since you can't modify the method tables of Java objects once they're loaded, the target of a method call in a loop doesn't change if the variable it's on isn't changed; this can be kept in a register the whole time and doesn't need to be predicted on future invocations. A JIT could even generate common-case code with the methods inlined. So:
void foo(List lst) {
for (Iterator it = lst.iterator(); it.hasNext(); ) {
Object item = it.next(); // use item
} }
Can result in native code with no indirect jumps or method calls (except in the "use item" section) when called with an ArrayList.
Note that you can't do any of this with C function pointers, where the compiler can't generally tell that they're even constant in a loop, and certainly can't tell that it might be worth generating a version with a particular set of functions inlined. There's a lot of design and optimization that went into making Java method calls cheap, because the language had them absolutely everywhere from the beginning.
I'm not surprised about the trace; a lot of the Java runtime is actually in Java, and gets run where you can trace it. This lets the runtime use a lot of its own services.
But you mean that the JRE wasn't designed to start up quickly; the language and standard library don't have much to say on the subject. In fact, gcj implements almost all of the specification (except, last I checked, that the code compiled to native doesn't have a Classloader and resource access) without startup overhead. This is, of course, beneficial for some programs but not the main focus of sun's java development.
On modern processors, the performance of a program is affected greatly by the success of the branch-prediction system, which gets hints from the compiler. This means that a compiler that knows what the flow control of the program is actually like is going to generate substantially better code. Traditional compilers have some information about flow control (e.g., most loops are run a lot of times; some are run either not at all or lots of times; few are run exactly once), but JIT compilers have the benefit that they actually get to run the program for a bit and watch what happens.
Probably the best idea would be to cache the compiled result from the JIT, and use that (maybe with a bit of profiling left to notice if you change the system characteristics significantly). But there are actually substantial benefits from doing the optimization the first time you run the program, rather than when you install it.
It's not such a big deal for Eclipse, but it matter a whole lot for command-line programs like jar and javadoc, where the amount of time spend running the program is less than the amount of time spend starting the program; this makes correspondingly more of a difference to programs using the traditional UNIX philosophy.
Of course, java tends toward handling this differently, where java programs invoke each other inside the same runtime, but it makes mixing java and non-java tools annoying.
Actually, that area is considered to be the birthplace of civilization, and therefore of organized religion in general, so it is of some significance even to the Canadian student who wrote those lines (as well as in the context he was writing them for of Nostradamus's text). Baghdad makes sense for the site of the city that God lived in when Adam and Eve were in Eden.
"Major combat" is over. Unfortunately, the US military is really best at major combat, and has not been doing nearly so well at the war since (which, given that the roles of defender and attacker have reversed, might be considered a new war -- the third).
In any case, it fits better than 9/11, in which there was no great leader who succumbed, and no third war in any logical set which began while New York (hardly a better candidate for the "City of God") was burning.
Right, they're actually able to produce power for you (and quite effectively at that), but they aren't an end-user product yet, and probably won't be for a bit longer while people work out how to charge a two-cell pack (or, more likely, two series sets of parallel cells; one of the advantages is that, if you destroy a cell, the rest of the unit will work rather than being destroyed), stop it from collapsing when you discharge it too much, etc.
With packaging and mass production, 2005 is a reasonable schedule for these to be available and useful to the average slashdot reader; meanwhile, the things you see are hybrids.
(I've actually seen some old real polymer battery prototypes, but I didn't do anything with them because there wasn't a charger included; they looked a lot like the little hotel soap bars)
You can put forms into other sorts of things than html in the same way that you'd put them in html.
A form can do some useful extra things without using javascript, which lets browsers get the user better feedback as to what will happen when they activate a control.
The form can specify more information about how the controls go together.
The value submitted by the form is in xml, so it can be structured.
There are a couple of new inputs, and the input tag is replaced with a set of tags, one per type, which matches the rest of xml (and html) better. It also has some additional combinations.
It also gets the specification of what you're trying to ask the user separated from how the form is arranged, allowing the browser to format things better for different devices.
It's reasonable to expect this to be worse than some of the other worms, because it is part of a more central and common service. It seems unlikely that future worms will be less effective than past ones, for that matter, since the past ones have generally been disassembled and discussed, and someone writing a worm is unlikely to start from scratch.
Of course, the vulnerability requires that it be possible to reach the machine with an inbound connection, so firewalled networks will be protected until someone combines this with a document-based vulnerability to attack these networks from inside.
Ah, but flying home to get your Canon digital camera which you forgot to pack for your trip will cost a lot more than getting one of these for the duration (or buying another camera). The point is that people often find themselves with the desire to take a only few pictures and no camera to do it with, even people who own cameras.
But people have not taken the hardline approach in cases of GPL violations. The hardline approach would be to sue the companies for damages, demand settlements, or prohibit them from using the code at all, all of which would be possible approaches. The approaches that have actually been taken have been to inform the companies of the violation and ask them to come into compliance with the terms of the license, with no penalties to compensate for their previous violation.
If anything, this will clarify to companies considering using GPL software their obligations and risks, and those turn out to be less than what many companies may have heard or a bit more than the companies may think they can get away with.
We are in the process of developing a set of precedent as to what options will lead to what requirements: if you follow nVidia's pattern, you're fine; if you follow Linksys, you'll have to contribute a particular set of changes; and so forth. This lets a company evaluate software they could use with an understanding of what work they would have to do to use it, and what of this work would have to be contributed back to the community.
What tends to bother me is that, to add another variable of the same type to a line declaring a number of variables which are the same type, you need to add the right number of *s before the new name.
The standard syntax states that you're declaring two integers, "a" and "*b" (which implies that "b" is a pointer to a int). Of course, you're not actually declaring the int that b points to, so the syntax is misleading, and leads to people failing to initialize their pointers correctly, because a line that starts "struct foo" may or may not create a struct foo, depending on whether the variable has a star. Personally, I'd prefer:
&int b;
That is, declare b to be the address of an int, which is a somewhat more accurate description of what's going on.
The neat thing about morse ham radio is that you can make it out over long distances where you're receiving the signal that the other end is transmitting directly, without any protocol in between aside from what you do yourself and electromagnetism.
In order to do something similar online, the right solution is to use one and two byte ping packets.
First of all, there are three different battery chemistries involving lithium: (metallic) lithium, lithium ion, and lithium polymer.
Lithium batteries aren't generally rechargeable.
Li-ion batteries are rechargeable, but a single cell is about 3.7V (as compared to 1.5V for a alkaline cell or 1.2V for a NiCd or NiMH cell); so they could make a 5/2 AA battery out of it (great for devices that take 10 AA batteries, arranged just so...) or include a bunch of electronics to get a reasonable voltage out and handle charging in a regular charger, which would be a huge pain. There is a standard 7.4 Li-ion battery form factor, though, which is reasonably general.
Lithium polymer batteries are new and somewhat obscure and hard to make (in fact, real lithium polymer batteries are not expected to be available until 2005; currently there are only hybrids). They (like metallic lithium, for that matter) are 3.0V, and not suitable for AA applications, although you can find 3.0V two-AA battery objects. Lithium polymer batteries will also solve the general lithium problem with exploding or bursting into flame if mishandled.
Many of the rechargeable AA batteries you'll find are 1.2V, not 1.5V; make sure that you get 1.5V ones for any application that cares about voltage and doesn't claim to deal with the lower voltage.
But the only pants you can really get tight enough to constrict (without ripping) are jeans, and the slashdot crowd would prefer to wear jeans to work...
(What's with the Clinton jokes, anyway? Isn't he famous for having non-reproductive sex at work with his pants on?)
ARIN ought to charge by the fraction of the total address space. Then IPv6 addresses, being less of an impact on the total address space, will cost less then IPv4 addresses. Actually, since IPv6 addresses would then cost 1/64,000,000,000,000,000,000,000,000,000 of IPv4, there should probably be an additional constant factor for owning addresses...
As far as ISPs not wanting to leave their nice old free IPv4 blocks, what's wrong with::FFFF:address, which is an IPv6 address which addresses whatever is addressed with the IPv4 address specified? They don't have to buy blocks of these. For example,::FFFF:18.7.21.70 is a perfectly good IPv6 address which will reach 18.7.21.70 by IPv6 instead of IPv4.
Personally, I think that IPv6 will catch on in the US by way of something like a cell phone provider giving an address to each phone they serve, which can be used to interact with other IPv6 users. People whose friends have these phones then have an incentive to get the ability to send to them, and IPv6 becomes useful for some obvious end-user application, at which point people will discover that IPv6 is already in place and just not being used for much.
The costs of broadband depend largely on factors like how many sites you need to get it to and what you want at the other end. If you're doing broadband only to a set of internet cafes, it's cheap and easy, because you avoid the last mile (i.e., getting a high-quality wire to every single person from the central point) entirely; the Iraqis walk the last mile, sit down, and use the computer there. You also save a lot in installation costs if you don't have to worry about buildings, roads, and stuff in the way of where you want to put the wire; if the whole country is torn up, you won't have to avoid all the homes and businesses that don't want you digging a trench under their buildings.
Of course, Iraq can't sell bandwidth to the US, because nobody in the US wants bandwidth in Iraq (Next time I want to move some data from Mosul to Baghdad quickly...). People in the US want bandwidth in the US, preferrably in their homes. Iraq's also got a lot of cheap real estate, but they're not going to be able to sell it to silicon valley any time soon.
The people who viewed the code in question had no clue what it was, nor were they able to memorize the "Linux" exerpts in question such that they would be able to find them again. They can tell their friends, "Yeah, there were two files, and there were a bunch of lines that looked the same", but they're not going to be able to find those lines in the Linux source tree.
I have, in fact, seen that one of the people who signed the NDA revealed that the copied lines include a copyright disclaimer, which is particularly mystifying, since, as far as I can tell, all of the Caldera/SCO copyright notices are on files that Caldera contributed to once they were already under the GPL, and it would be particularly damning in court if SCO was claiming that someone else's copyright disclaimer violated their copyright.
There seem to be a couple of char drivers which refer to SCO, but that's about it (and those seem to be third-party drivers written for SCO Unix and then ported to Linux.
Logs of discussion of the lecture would probably make at least as good notes as just writing down what the lecturer says. Personally, I never took notes in lecture, because I found it too distracting (I would end up not learning anything during the lecture, and having to try to learn from my notes; the book was a better record of the material than my notes, and listening and thinking about what was being said was better for learning, but people are different).
I don't think IBM is likely to countersue SCO. IBM intends SCO to lose their suit and go out of business at that point. A countersuit won't make this any quicker.
I think it's more likely that suits (seeking injunctions, primarily) will come from individual developers, Red Hat, and user groups overseas, and the FSF will come in later (because RMS wouldn't miss the chance to finish off the thing that GNU isn't) but not start out because there might not be any disputed code to which the FSF holds the copyright.
Slashdot Mirror
Donating to legal defense funds, unlike buying things, is tax deductable, and is more useful information for everyone involved. It also saves somewhat on overhead.
Filtering technology alone is not the answer. But an authentication scheme where the sender demonstrates the ability to use the From address would eliminate almost all of the spam that forges that information and make filtering or litigating the rest easy.
The issue is that, while weak recipient authentication was built into SMTP, corresponding sender authentication was not; this means that everyone is always anonymous (except for name tags they write themselves), there is no accountability, and people behave badly. Trying to apply technology at the level of behavior is obviously going to be ineffective.
Solution: add a "XM" DNS record type (MX backward), which specifies the hosts which are expected to send emails with the given return address. If a sending machine doesn't have the right XM, MX, or A record, flag the message as likely spam (if it's not spam, the sender should get the DNS updated or their mail routed better).
IBM will be supporting Red Hat in this indirectly. Remember that IBM doesn't actually have their own distribution; they make their money shipping hardware and doing consulting, using Red Hat and SuSE. So they don't really have a good case against SCO. But they'll probably be funnelling extra money into Red Hat through their existing business deals to cover the cost of a good legal team.
In any case, there's not much point in IBM suing SCO. They're already in a court case with SCO, and, if IBM wins, SCO is dead in the water. There's no point in having another lawsuit with essentially the same claims and results at the same time.
Regarding that analogy, two points: Publisher B is claiming that the book plagiarizes private correspondance, which they claim rights to but aren't publishing (copyright holders have the right to suppress the things they've written). Also, they are suing Author X, but it's going to take a while.
OSS is free like national (state, city, etc) parks are free. It exists for a reason unrelated to money. There's no significant charge because keeping people who don't pay out conflicts with the real purpose. Linux was created as a habitat for software, and is open to the public because it's nice for people, too.
There are a number of similar examples people might recognize: streets, except for rare toll roads, don't cost anything to drive on, because there would be terrible traffic. On-street parking and parking lots are free when it's too much of a pain to enforce things. The reference section at the library doesn't charge anything, because it's purpose is to provide access to information.
The programmer doesn't write spam filters for fun. The programmer writes spam filters because he is annoyed by spam and can do something about it. The programmer distributes the spam filter because his friends are annoyed by spam, too, and sometimes get confused and delete his messages. The programmer lets Joe user get the spam filter, despite not knowing Joe personally, because stopping Joe from getting it doesn't benefit him.
For method calls, all of your private methods, static methods, final methods, and methods of objects whose compile-time time is final are constant offset jumps, and the loader can resolve all calls to methods of this by making a copy of all of the functions from superclasses and connecting them up. Since you can't modify the method tables of Java objects once they're loaded, the target of a method call in a loop doesn't change if the variable it's on isn't changed; this can be kept in a register the whole time and doesn't need to be predicted on future invocations. A JIT could even generate common-case code with the methods inlined. So:Can result in native code with no indirect jumps or method calls (except in the "use item" section) when called with an ArrayList.
Note that you can't do any of this with C function pointers, where the compiler can't generally tell that they're even constant in a loop, and certainly can't tell that it might be worth generating a version with a particular set of functions inlined. There's a lot of design and optimization that went into making Java method calls cheap, because the language had them absolutely everywhere from the beginning.
I'm not surprised about the trace; a lot of the Java runtime is actually in Java, and gets run where you can trace it. This lets the runtime use a lot of its own services.
But you mean that the JRE wasn't designed to start up quickly; the language and standard library don't have much to say on the subject. In fact, gcj implements almost all of the specification (except, last I checked, that the code compiled to native doesn't have a Classloader and resource access) without startup overhead. This is, of course, beneficial for some programs but not the main focus of sun's java development.
On modern processors, the performance of a program is affected greatly by the success of the branch-prediction system, which gets hints from the compiler. This means that a compiler that knows what the flow control of the program is actually like is going to generate substantially better code. Traditional compilers have some information about flow control (e.g., most loops are run a lot of times; some are run either not at all or lots of times; few are run exactly once), but JIT compilers have the benefit that they actually get to run the program for a bit and watch what happens.
Probably the best idea would be to cache the compiled result from the JIT, and use that (maybe with a bit of profiling left to notice if you change the system characteristics significantly). But there are actually substantial benefits from doing the optimization the first time you run the program, rather than when you install it.
It's not such a big deal for Eclipse, but it matter a whole lot for command-line programs like jar and javadoc, where the amount of time spend running the program is less than the amount of time spend starting the program; this makes correspondingly more of a difference to programs using the traditional UNIX philosophy.
Of course, java tends toward handling this differently, where java programs invoke each other inside the same runtime, but it makes mixing java and non-java tools annoying.
Actually, that area is considered to be the birthplace of civilization, and therefore of organized religion in general, so it is of some significance even to the Canadian student who wrote those lines (as well as in the context he was writing them for of Nostradamus's text). Baghdad makes sense for the site of the city that God lived in when Adam and Eve were in Eden.
"Major combat" is over. Unfortunately, the US military is really best at major combat, and has not been doing nearly so well at the war since (which, given that the roles of defender and attacker have reversed, might be considered a new war -- the third).
In any case, it fits better than 9/11, in which there was no great leader who succumbed, and no third war in any logical set which began while New York (hardly a better candidate for the "City of God") was burning.
Right, they're actually able to produce power for you (and quite effectively at that), but they aren't an end-user product yet, and probably won't be for a bit longer while people work out how to charge a two-cell pack (or, more likely, two series sets of parallel cells; one of the advantages is that, if you destroy a cell, the rest of the unit will work rather than being destroyed), stop it from collapsing when you discharge it too much, etc.
With packaging and mass production, 2005 is a reasonable schedule for these to be available and useful to the average slashdot reader; meanwhile, the things you see are hybrids.
(I've actually seen some old real polymer battery prototypes, but I didn't do anything with them because there wasn't a charger included; they looked a lot like the little hotel soap bars)
You can put forms into other sorts of things than html in the same way that you'd put them in html.
A form can do some useful extra things without using javascript, which lets browsers get the user better feedback as to what will happen when they activate a control.
The form can specify more information about how the controls go together.
The value submitted by the form is in xml, so it can be structured.
There are a couple of new inputs, and the input tag is replaced with a set of tags, one per type, which matches the rest of xml (and html) better. It also has some additional combinations.
It also gets the specification of what you're trying to ask the user separated from how the form is arranged, allowing the browser to format things better for different devices.
It's reasonable to expect this to be worse than some of the other worms, because it is part of a more central and common service. It seems unlikely that future worms will be less effective than past ones, for that matter, since the past ones have generally been disassembled and discussed, and someone writing a worm is unlikely to start from scratch.
Of course, the vulnerability requires that it be possible to reach the machine with an inbound connection, so firewalled networks will be protected until someone combines this with a document-based vulnerability to attack these networks from inside.
Ah, but flying home to get your Canon digital camera which you forgot to pack for your trip will cost a lot more than getting one of these for the duration (or buying another camera). The point is that people often find themselves with the desire to take a only few pictures and no camera to do it with, even people who own cameras.
But people have not taken the hardline approach in cases of GPL violations. The hardline approach would be to sue the companies for damages, demand settlements, or prohibit them from using the code at all, all of which would be possible approaches. The approaches that have actually been taken have been to inform the companies of the violation and ask them to come into compliance with the terms of the license, with no penalties to compensate for their previous violation.
If anything, this will clarify to companies considering using GPL software their obligations and risks, and those turn out to be less than what many companies may have heard or a bit more than the companies may think they can get away with.
We are in the process of developing a set of precedent as to what options will lead to what requirements: if you follow nVidia's pattern, you're fine; if you follow Linksys, you'll have to contribute a particular set of changes; and so forth. This lets a company evaluate software they could use with an understanding of what work they would have to do to use it, and what of this work would have to be contributed back to the community.
What tends to bother me is that, to add another variable of the same type to a line declaring a number of variables which are the same type, you need to add the right number of *s before the new name.
The standard syntax states that you're declaring two integers, "a" and "*b" (which implies that "b" is a pointer to a int). Of course, you're not actually declaring the int that b points to, so the syntax is misleading, and leads to people failing to initialize their pointers correctly, because a line that starts "struct foo" may or may not create a struct foo, depending on whether the variable has a star. Personally, I'd prefer:
&int b;
That is, declare b to be the address of an int, which is a somewhat more accurate description of what's going on.
In any case, it's far too late to correct this.
Well, he does claim responsibility for getting a book written. Without him, we'd still have C, but nobody would know how to use it.
The neat thing about morse ham radio is that you can make it out over long distances where you're receiving the signal that the other end is transmitting directly, without any protocol in between aside from what you do yourself and electromagnetism.
In order to do something similar online, the right solution is to use one and two byte ping packets.
First of all, there are three different battery chemistries involving lithium: (metallic) lithium, lithium ion, and lithium polymer.
Lithium batteries aren't generally rechargeable.
Li-ion batteries are rechargeable, but a single cell is about 3.7V (as compared to 1.5V for a alkaline cell or 1.2V for a NiCd or NiMH cell); so they could make a 5/2 AA battery out of it (great for devices that take 10 AA batteries, arranged just so...) or include a bunch of electronics to get a reasonable voltage out and handle charging in a regular charger, which would be a huge pain. There is a standard 7.4 Li-ion battery form factor, though, which is reasonably general.
Lithium polymer batteries are new and somewhat obscure and hard to make (in fact, real lithium polymer batteries are not expected to be available until 2005; currently there are only hybrids). They (like metallic lithium, for that matter) are 3.0V, and not suitable for AA applications, although you can find 3.0V two-AA battery objects. Lithium polymer batteries will also solve the general lithium problem with exploding or bursting into flame if mishandled.
Many of the rechargeable AA batteries you'll find are 1.2V, not 1.5V; make sure that you get 1.5V ones for any application that cares about voltage and doesn't claim to deal with the lower voltage.
But the only pants you can really get tight enough to constrict (without ripping) are jeans, and the slashdot crowd would prefer to wear jeans to work...
(What's with the Clinton jokes, anyway? Isn't he famous for having non-reproductive sex at work with his pants on?)
ARIN ought to charge by the fraction of the total address space. Then IPv6 addresses, being less of an impact on the total address space, will cost less then IPv4 addresses. Actually, since IPv6 addresses would then cost 1/64,000,000,000,000,000,000,000,000,000 of IPv4, there should probably be an additional constant factor for owning addresses...
::FFFF:address, which is an IPv6 address which addresses whatever is addressed with the IPv4 address specified? They don't have to buy blocks of these. For example, ::FFFF:18.7.21.70 is a perfectly good IPv6 address which will reach 18.7.21.70 by IPv6 instead of IPv4.
As far as ISPs not wanting to leave their nice old free IPv4 blocks, what's wrong with
Personally, I think that IPv6 will catch on in the US by way of something like a cell phone provider giving an address to each phone they serve, which can be used to interact with other IPv6 users. People whose friends have these phones then have an incentive to get the ability to send to them, and IPv6 becomes useful for some obvious end-user application, at which point people will discover that IPv6 is already in place and just not being used for much.
The costs of broadband depend largely on factors like how many sites you need to get it to and what you want at the other end. If you're doing broadband only to a set of internet cafes, it's cheap and easy, because you avoid the last mile (i.e., getting a high-quality wire to every single person from the central point) entirely; the Iraqis walk the last mile, sit down, and use the computer there. You also save a lot in installation costs if you don't have to worry about buildings, roads, and stuff in the way of where you want to put the wire; if the whole country is torn up, you won't have to avoid all the homes and businesses that don't want you digging a trench under their buildings.
Of course, Iraq can't sell bandwidth to the US, because nobody in the US wants bandwidth in Iraq (Next time I want to move some data from Mosul to Baghdad quickly...). People in the US want bandwidth in the US, preferrably in their homes. Iraq's also got a lot of cheap real estate, but they're not going to be able to sell it to silicon valley any time soon.
The people who viewed the code in question had no clue what it was, nor were they able to memorize the "Linux" exerpts in question such that they would be able to find them again. They can tell their friends, "Yeah, there were two files, and there were a bunch of lines that looked the same", but they're not going to be able to find those lines in the Linux source tree.
I have, in fact, seen that one of the people who signed the NDA revealed that the copied lines include a copyright disclaimer, which is particularly mystifying, since, as far as I can tell, all of the Caldera/SCO copyright notices are on files that Caldera contributed to once they were already under the GPL, and it would be particularly damning in court if SCO was claiming that someone else's copyright disclaimer violated their copyright.
There seem to be a couple of char drivers which refer to SCO, but that's about it (and those seem to be third-party drivers written for SCO Unix and then ported to Linux.
Logs of discussion of the lecture would probably make at least as good notes as just writing down what the lecturer says. Personally, I never took notes in lecture, because I found it too distracting (I would end up not learning anything during the lecture, and having to try to learn from my notes; the book was a better record of the material than my notes, and listening and thinking about what was being said was better for learning, but people are different).
I don't think IBM is likely to countersue SCO. IBM intends SCO to lose their suit and go out of business at that point. A countersuit won't make this any quicker.
I think it's more likely that suits (seeking injunctions, primarily) will come from individual developers, Red Hat, and user groups overseas, and the FSF will come in later (because RMS wouldn't miss the chance to finish off the thing that GNU isn't) but not start out because there might not be any disputed code to which the FSF holds the copyright.