I think that Mark Russinovich has a skewed view of the Linux kernel. He says that the Linux kernel is closing the gap with the Windows kernel, but that statement is inherently biased. The Linux kernel is ahead of Windows in some areas and behind Windows in some areas; to make a blanket "it's behind, but catching up" is pretty shoddy.
From what I understand, PHP 5 will not include a bundled version of the MySQL libraries, with the licensing issue being one of the causes. MySQL finally granted exceptions to some licenses (PHP included), but the whole argument turned some people off to MySQL. Of course, this doesn't mean that the MySQL API is not supported, it simply means that you'll have to install the MySQL libraries separately before you can build PHP 5 with MySQL support.
I can't think of a single reason to prefer PostgreSQL over it, in fact.
I used to think that, until I realized that my programs were twice as complicated as they needed to be due to MySQL's lack of typical relational database functionality. Triggers, views, sub-selects, user-defined functions, transactions, templates... the list of PostgreSQL advantages (feature-wise) over MySQL is long.
MySQL is now trying to catch up to PostgreSQL in the feature category, but is still not even close. That's not to say that MySQL is worthless -- quite the contrary: if you want an indexed file system, MySQL is the way to go. On the other hand, if you want a good, open-source relational database, PostgreSQL is a champ.
Ease of use pushed us away even before we looked at benchmarks, which are all triumphantly in MySQL's favor.
PostgreSQL is a bit harder to initially set up, when compared to MySQL. On the other hand, it isn't rocket science; it is still pretty simple.
In terms of benchmarks, you might want to notice that MySQL is hardly "triumpantly" winning normal benchmarks. Take a typical MySQL table (MyISAM) and try doing lots of concurrent reads and writes. You'll find that MySQL's habit of locking the entire table on writes really is a downer when it comes to performance.
Another thing to note is that MySQL has placed their libraries under the GPL, making them somewhat incompatible with the PHP license. This has caused a bit of a rift in the PHP community, with the result being that MySQL will probably be less supported by the PHP developers while PostgreSQL increases in support.
The law prohibits all religious symbols - including Christian crucifixes and Jewish yarmulkes.
From what I understood, it prohibits conspicuous symbols. So, in other words, you can wear a small crucifix, but not a big one. Head scarves, unfortunately, cannot help but be conspicuous.
Let's be honest about it, too -- the issue that triggered the ban was not religious symbols in general, it was the Islamic head scarf.
ONLY the Moslems have called it "racist".
I'm a Christian and I'm calling it wrong. A little girl wearing a head scarf does not interfere with other people's ability to live free, happy lives. By preventing her from wearing it, you are not allowing her to observe an important part of her faith. That combination make France's law repugnant.
You're completely right. The underlying point was that arguing for Perl because it can be "faster" than C is bogus; high-level, interpreted languages weren't built with speed as the competitive factor. They were built for maintainability and speed of development, with execution speed being secondary.
I spent a good three months with a pencil and paper and taocp vol. 1.
I'm surprised it only took you that long. I figure that it is taking Knuth his entire life to write the series, so I should at least do him the honor of taking the same amount of time reading it. =)
with regards to machine language, if you know binary, you know machine language.
Well, no, not really. That's like saying that knowing the Greek letters means you can speak Greek.
but yes, i have written programs for MIX emulators in Octal.
Then I would say that, yes, you probably do know a machine language.
ASM is a level above that, but close enough that one can see what the machine is doing.
That's mostly true, but not as much as it used to be. On x86, the most prevalent PC architecture, you see a lot of instructions that do not reflect the true situation, due to its decidedly non-RISC approach -- in fact, you could consider x86 to be a more-or-less low-level language with some high-level concepts thrown in for convenience. Plus, the processor doesn't even directly execute the instructions any more: they are first translated to microcode instructions, which are then executed.
Assembly is only half of the picture anymore, too. When writing a low-level piece of code, there are a hundred more things to worry about than there used to be, due to the increased complexity of the processor: L1 & L2 caches, pipelining and superscalar CPUs, branch prediction, virtual memory... it all makes it very hard to really, truly understand what is going on. I agree that knowing assembly language is beneficial, but I don't think that it gives as large of a boost as it used to; a computer architecture class is almost more useful/necessary.
Drew Crampsie -- sending my resume to microsoft as we speak.
Speaking of something that isn't wise to say on Slashdot...;)
Of course, you can't always trust assemblers either. There isn't necessarily a one-to-one correlation between a given assembly instruction and what the computer actually does, especially on architectures like the x86.
To take it even further, you can't even trust machine language all the time -- look at Intel's floating point bug a decade ago. There's a reason why x86 processors now have ways of patching the microcode.
I can't believe that any developer could write and code without some knowlege of ASM.
As unbelievable as it may seem, it happens. Go figure, huh?
More importantly, if you don't know ASM and can't understand machine language, you'd never get through Knuth's tome "The Art Of Computer Programming".
Actually, Knuth sums up the requirements for his book as, "the reader should have already written and tested at least, say, four programs for at least one computer." (Preface, AoCP Vol. 1) Though some assembler skills definitely help, I don't think that a strong background in it is an absolute necessity. Plus, just to be picky, I doubt that you really know machine language.
Any developer worth his/her salt should have at least read and understood these books, and completed at least the simple exercises.
That's odd, because Bill Gates thinks differently: "If you think you're a really good programmer... read AoCP... you should definitely send me a resume if you can read the whole thing." (back cover of AoCP) Assembly language may be important to know, but it isn't the Alpha and Omega of programming.
Depending on where the heavy lifting is, Perl could easily outperform optimized C.
But if Perl is written in C, wouldn't that mean that Perl can never be "faster" than C?
To put it more concretely, couldn't I just write a program in C that does EXACTLY what the Perl program does, down to the last data structure? And if I did, wouldn't that mean that Perl can't ever (theoretically) be faster than C?
You could even take it a step further. You could write an exact duplicate of the Perl program, leave out the parts of the Perl interpreter that you don't use, and you probably would end up with an overall faster program. Thus, in most cases, C could trump Perl.
I agree with the underlying premise that more programmers should learn an assembly language and the intimate details of how a computer works. However, I disagree with several part of the article.
- He faults inefficient coding for the failure of software speed to keep up with CPU speed (or at least, its a "large part".) This is much less true than he lets on; Amdahl's Law means that the CPU is less and less responsible for the speed of an application, while things such as disk seek/transfer times, memory access times, and network latency all play huge roles in the speed of your computer's software.
- He seems to think that it's not terribly hard to become an "efficient" assembly language programmer. Bzzt, wrong! In the modern era of superscalar architectures, pipelining, processor specific instructions, branch delays, and memory heirarchies, it takes a hell of a lot of knowledge and experience to beat the performance of a good compiler.
- He apparently hasn't tried any large assembly language porting efforts lately. I'd love to see the effort involved in porting a large x86 assembly language program to a MIPS architecture, all the while maintaining that coveted "ultra-efficiency". The reality is that a good compiler can be reasonably efficient at porting a program to a new architecture, while a programmer usually isn't.
- He also apparently hasn't tried debugging a large chunk of assembly code lately. It is a fact of life that it is very difficult to debug assembly. By using a high-level language, you are increasing the readability of your software, which tends to decreases the number of bugs.
I could go on, but needless to say, I'm not impressed with the numerous assumptions and generalizations about assembly that he makes. Learning assembly will make your high-level programming better, and limited use of it can be appropriate, but using it all over the place is a huge mistake.
1) The bundled free software (and that's free as in beer.) I don't have to go scrounge around the Internet for a full-featured SSH client, an FTP client, office software, a compiler, a nice text editor, or any number of great little niceties.
2) Virtual desktops. I hear that Windows can do them, too, but I don't have any idea how to enable them. I just can't live without them.
3) Configurability. I love the fact that I can usually alter the behavior of the things that I don't like. For example, I really hate how KDE has a flashing background on the bouncing icon when you start a program, so I just turn that off. With Windows, you rarely have such an option with things that you don't like.
4) Community. There's a different feel to the free software community (that's free as in speech, by the way). They seem to *want* you to know how things work, as opposed to the proprietary world where knowledge is sometimes closely guarded.
5) Mindset. This won't apply to everyone, but as a programmer I find that the applications tend to be designed in such a way that they appeal to me. From terminal programs to vi/emacs to kmail, they all just have a mix of simplicity and complexity that I love.
So, let me get this straight. The product with a non-zero marginal cost to produce (hardware) will be free, yet the product with a zero marginal cost will not be free? Something seems a bit wrong with that logic.
I'm sure glad we elected his ISP to congress so that its contracts were now binding criminal law.
The contract violation isn't criminal, but child pornography is. Unless he is covered by some sort of common carrier status, he's going to be liable for the material downloaded via his connection. So, the contract violation will result in the termination of the contract, and the illegal child porn downloaded via his connection will result in criminal charges.
Besides, the guy can not be found by a court to be a common carrier because the ISP defined him as not being one right there in its contract.
Not only did the ISP define him that way, but the guy agreed to the definition via the contract. When the contract says, "you will be legally responsible for the material downloaded via your connection," and he says, "yes, I agree," then doesn't that mean that he will be legally responsible and thus not a common carrier?
In addition, I would also guess that there are some subtle rules surrounding the common carrier status. I'm not a lawyer, but it probably does take one to understand the hoops you need to jump through to become a common carrier. I doubt that simply disabling the encryption on his network would qualify him for protected status.
Criminal law is a different matter. You either have to commit, be an accessory to or facilitator of the crime. Normally you could have trouble by being grossly neglient, like having an unsecured well, but again: People are so computer illiterate it won't fly.
I don't think that it matters if people in general are computer illiterate, what matters is if you are computer illiterate. So, if the RIAA's lawyers find out that you have a Cisco certification and work as a network admin, you are definitely going to have a hard time claiming you weren't negligent.
I leave my car unlocked. Someone steals it and runs down a child at 100mph in a 30 zone. Is it my fault? Sure I may (morally) share some degree of responsibility, but I don't think there's any legal issue.
IANAL, but I would imagine that there is a legal issue there. Can you prove that it is not your fault? The fact that your car was used to kill someone is evidence that supports the proposition that you were the killer. If you cannot prove that your car was stolen, then you are going to have a harder time proving that you weren't involved.
It's even worse when applied to your bandwidth. If you are not keeping logs and are not actively trying to secure your network, you have no proof that you did not download that illegal MP3 file. Since you are most likely legally obligated to prevent unauthorized access to your bandwidth by your ISP's TOS, you will be the one that takes the fall for it.
At the very least, the RIAA would push for a criminal negligence conviction. I would bet they could easily get it, too, if they could uncover documentation that proves that you (a) had the ability to secure your network, and (b) knew the implications of not securing your network. A computer-related degree or certification is all the evidence they would need to prove both points.
Actually, we also have no desire nor purpose to prevent tainting. The purpose
of the workaround is to avoid repetitive warning messages generated when
multiple modules belonging to a single logical "driver" are loaded (even when
a module is only probed but not used due to the hardware not being present).
Although the issue may sound trivial/harmless to people on the lkml, it was a
frequent cause of confusion for the average person.
Read the entire email for the whole picture. Whether you agree or not, it is important to understand why they partially circumvented the license check.
You should care if you use the Linux kernel. The issue isn't necessarily about "free vs. proprietary", but rather about support. The kernel hackers correctly throw away bug reports that come from "tainted" kernels. The reason is that binary, non-open modules can screw up the kernel in so many ways that it is almost useless to try and debug the problem without all of the relevant source code. By lying about the status of their driver, Linuxant is increasing the amount of effort required to debug problems, which has an inverse effect on the quality of the kernel.
Of course, there are also the "religious" arguments that you so arrogantly toss aside. You may not care about the free software philosophy, but some people do. Is it moral for a company to lie about its product being GPL'd? Is it wrong for someone to expect a module to give an accurate representation of how it is licensed? Though you may not agree with them, there are real reasons why people want to run only GPL-compatible software.
What's the difference between an American and Indian company that both have their sales force in the US and their developers in India?
Profits and taxes. If a company moves its headquarters to India, the profits generated by that company will no longer be "based" in the US. That means that the profits will be more likely to be spent on Indian goods and services than on US goods and services. Perhaps more importantly, the money generated by taxing those profits will go straight to the Indian government instead of the US government.
Why do you think people are so eager to have companies based in their area? If Microsoft moved into Wyoming, the level of services that could be provided by the government would increase without raising the tax rates. As another example, under the "abstract entities" argument, it wouldn't matter where you put military bases, as you still derive the net protective benefit regardless of where they are in the US, yet politicians practially kill each other in an effort to get bases moved to their home states. There are definite benefits to having the physical entities based in your geographic location.
Running a web-site would involve getting out and selling ad space and buying lots of bandwidth.
I can't help but think that they (the Indians) could just outsource the sales part to the U.S. or Europe, while still maintaining the headquarters and development in India.
In addition, it seems to me that the bandwidth isn't a big deal. It is possible to get bandwidth in India, plus you can mirror a site around the world with various service providers.
There's probably some IPO-type money floating around in India, too; it seems that they are experiencing their own.com boom right now.
I think the basic concept (broadcasting cable channels on unused DTV bandwidth) is a great idea. I'd sign up immediately, but for a couple of problems:
USDTV is a bit pricey for what you get. You're basically paying $20/month for a dozen decent channels. I can pay $30/month and get the same channels, plus a couple dozen more, plus a free DVR.
I can't see spending for cable channels without getting some sort of news station, preferrably CNN.
I've also heard that Disney has invested money in USDTV. It appears that this is true, given the some of the channels: 2 pure Disneys, 2 ESPNs, 2 and Lifetimes. It looks like USDTV can't get away from one of the evils of cable: forced bundling.
I didn't see that the writer even HAD a final opinion. He treated the thing as a type of investigative journalism, but wouldn't even summarize his findings into a simple recommendation.
Maybe that's what bugged me about this piece; you can tell the author had a definite opinon but he wouldn't just come out and say it. If he isn't willing to say it, what does that mean about his belief in his own supporting evidence? Did his lawyers tell him to hedge, or did he not believe he had enough real evidence to publicly condemn the guy?
As for your comment on giving money to a scammer, that's hogwash -- that is how investigative journalism works. If the journalist spends X dollars, but ends up saving the public 1000X dollars, it is definitely worth it.
Although the article was interesting, it didn't go all the way in exposing this guy. All they did was question his "benchmarks", track down where he lives, and then tell us, "Make up your own mind." I was expected them to get ahold of an actual computer and post their own benchmarks, but they never did. You can tell that they were completely pulling their punches in an effort to not get sued.
Maybe Tom's Hardware should hire John Stossel if they are going to do these kinds of pieces.
They can put as much data on the wire as they want, but it will still take 100 ms and 25 hops to get there.
That's the point, though; they're trying to put data on the wire more often than before. TCP doesn't start out by saturating the wire, but instead slowly "tests the water" and transfers data more and more frequently until it is confident it has saturated the line.
This protocol, on the other hand, figures out the capacity of the line faster, and thus can saturate it more quickly. The difference between the two is where they get their weird "6000x" figure.
Slashdot Mirror
I think that Mark Russinovich has a skewed view of the Linux kernel. He says that the Linux kernel is closing the gap with the Windows kernel, but that statement is inherently biased. The Linux kernel is ahead of Windows in some areas and behind Windows in some areas; to make a blanket "it's behind, but catching up" is pretty shoddy.
From what I understand, PHP 5 will not include a bundled version of the MySQL libraries, with the licensing issue being one of the causes. MySQL finally granted exceptions to some licenses (PHP included), but the whole argument turned some people off to MySQL. Of course, this doesn't mean that the MySQL API is not supported, it simply means that you'll have to install the MySQL libraries separately before you can build PHP 5 with MySQL support.
I used to think that, until I realized that my programs were twice as complicated as they needed to be due to MySQL's lack of typical relational database functionality. Triggers, views, sub-selects, user-defined functions, transactions, templates... the list of PostgreSQL advantages (feature-wise) over MySQL is long.
MySQL is now trying to catch up to PostgreSQL in the feature category, but is still not even close. That's not to say that MySQL is worthless -- quite the contrary: if you want an indexed file system, MySQL is the way to go. On the other hand, if you want a good, open-source relational database, PostgreSQL is a champ.
Ease of use pushed us away even before we looked at benchmarks, which are all triumphantly in MySQL's favor.
PostgreSQL is a bit harder to initially set up, when compared to MySQL. On the other hand, it isn't rocket science; it is still pretty simple.
In terms of benchmarks, you might want to notice that MySQL is hardly "triumpantly" winning normal benchmarks. Take a typical MySQL table (MyISAM) and try doing lots of concurrent reads and writes. You'll find that MySQL's habit of locking the entire table on writes really is a downer when it comes to performance.
Another thing to note is that MySQL has placed their libraries under the GPL, making them somewhat incompatible with the PHP license. This has caused a bit of a rift in the PHP community, with the result being that MySQL will probably be less supported by the PHP developers while PostgreSQL increases in support.
From what I understood, it prohibits conspicuous symbols. So, in other words, you can wear a small crucifix, but not a big one. Head scarves, unfortunately, cannot help but be conspicuous.
Let's be honest about it, too -- the issue that triggered the ban was not religious symbols in general, it was the Islamic head scarf.
ONLY the Moslems have called it "racist".
I'm a Christian and I'm calling it wrong. A little girl wearing a head scarf does not interfere with other people's ability to live free, happy lives. By preventing her from wearing it, you are not allowing her to observe an important part of her faith. That combination make France's law repugnant.
Does this mean that the text of France's law preventing Muslim head scarves in school will be taken down from the Internet?
You're completely right. The underlying point was that arguing for Perl because it can be "faster" than C is bogus; high-level, interpreted languages weren't built with speed as the competitive factor. They were built for maintainability and speed of development, with execution speed being secondary.
I'm surprised it only took you that long. I figure that it is taking Knuth his entire life to write the series, so I should at least do him the honor of taking the same amount of time reading it. =)
with regards to machine language, if you know binary, you know machine language.
Well, no, not really. That's like saying that knowing the Greek letters means you can speak Greek.
but yes, i have written programs for MIX emulators in Octal.
Then I would say that, yes, you probably do know a machine language.
ASM is a level above that, but close enough that one can see what the machine is doing.
That's mostly true, but not as much as it used to be. On x86, the most prevalent PC architecture, you see a lot of instructions that do not reflect the true situation, due to its decidedly non-RISC approach -- in fact, you could consider x86 to be a more-or-less low-level language with some high-level concepts thrown in for convenience. Plus, the processor doesn't even directly execute the instructions any more: they are first translated to microcode instructions, which are then executed.
Assembly is only half of the picture anymore, too. When writing a low-level piece of code, there are a hundred more things to worry about than there used to be, due to the increased complexity of the processor: L1 & L2 caches, pipelining and superscalar CPUs, branch prediction, virtual memory... it all makes it very hard to really, truly understand what is going on. I agree that knowing assembly language is beneficial, but I don't think that it gives as large of a boost as it used to; a computer architecture class is almost more useful/necessary.
Drew Crampsie -- sending my resume to microsoft as we speak.
Speaking of something that isn't wise to say on Slashdot... ;)
To take it even further, you can't even trust machine language all the time -- look at Intel's floating point bug a decade ago. There's a reason why x86 processors now have ways of patching the microcode.
As unbelievable as it may seem, it happens. Go figure, huh?
More importantly, if you don't know ASM and can't understand machine language, you'd never get through Knuth's tome "The Art Of Computer Programming".
Actually, Knuth sums up the requirements for his book as, "the reader should have already written and tested at least, say, four programs for at least one computer." (Preface, AoCP Vol. 1) Though some assembler skills definitely help, I don't think that a strong background in it is an absolute necessity. Plus, just to be picky, I doubt that you really know machine language.
Any developer worth his/her salt should have at least read and understood these books, and completed at least the simple exercises.
That's odd, because Bill Gates thinks differently: "If you think you're a really good programmer... read AoCP... you should definitely send me a resume if you can read the whole thing." (back cover of AoCP) Assembly language may be important to know, but it isn't the Alpha and Omega of programming.
But if Perl is written in C, wouldn't that mean that Perl can never be "faster" than C?
To put it more concretely, couldn't I just write a program in C that does EXACTLY what the Perl program does, down to the last data structure? And if I did, wouldn't that mean that Perl can't ever (theoretically) be faster than C?
You could even take it a step further. You could write an exact duplicate of the Perl program, leave out the parts of the Perl interpreter that you don't use, and you probably would end up with an overall faster program. Thus, in most cases, C could trump Perl.
- He faults inefficient coding for the failure of software speed to keep up with CPU speed (or at least, its a "large part".) This is much less true than he lets on; Amdahl's Law means that the CPU is less and less responsible for the speed of an application, while things such as disk seek/transfer times, memory access times, and network latency all play huge roles in the speed of your computer's software.
- He seems to think that it's not terribly hard to become an "efficient" assembly language programmer. Bzzt, wrong! In the modern era of superscalar architectures, pipelining, processor specific instructions, branch delays, and memory heirarchies, it takes a hell of a lot of knowledge and experience to beat the performance of a good compiler.
- He apparently hasn't tried any large assembly language porting efforts lately. I'd love to see the effort involved in porting a large x86 assembly language program to a MIPS architecture, all the while maintaining that coveted "ultra-efficiency". The reality is that a good compiler can be reasonably efficient at porting a program to a new architecture, while a programmer usually isn't.
- He also apparently hasn't tried debugging a large chunk of assembly code lately. It is a fact of life that it is very difficult to debug assembly. By using a high-level language, you are increasing the readability of your software, which tends to decreases the number of bugs.
I could go on, but needless to say, I'm not impressed with the numerous assumptions and generalizations about assembly that he makes. Learning assembly will make your high-level programming better, and limited use of it can be appropriate, but using it all over the place is a huge mistake.
2) Virtual desktops. I hear that Windows can do them, too, but I don't have any idea how to enable them. I just can't live without them.
3) Configurability. I love the fact that I can usually alter the behavior of the things that I don't like. For example, I really hate how KDE has a flashing background on the bouncing icon when you start a program, so I just turn that off. With Windows, you rarely have such an option with things that you don't like.
4) Community. There's a different feel to the free software community (that's free as in speech, by the way). They seem to *want* you to know how things work, as opposed to the proprietary world where knowledge is sometimes closely guarded.
5) Mindset. This won't apply to everyone, but as a programmer I find that the applications tend to be designed in such a way that they appeal to me. From terminal programs to vi/emacs to kmail, they all just have a mix of simplicity and complexity that I love.
So, let me get this straight. The product with a non-zero marginal cost to produce (hardware) will be free, yet the product with a zero marginal cost will not be free? Something seems a bit wrong with that logic.
The contract violation isn't criminal, but child pornography is. Unless he is covered by some sort of common carrier status, he's going to be liable for the material downloaded via his connection. So, the contract violation will result in the termination of the contract, and the illegal child porn downloaded via his connection will result in criminal charges.
Besides, the guy can not be found by a court to be a common carrier because the ISP defined him as not being one right there in its contract.
Not only did the ISP define him that way, but the guy agreed to the definition via the contract. When the contract says, "you will be legally responsible for the material downloaded via your connection," and he says, "yes, I agree," then doesn't that mean that he will be legally responsible and thus not a common carrier?
In addition, I would also guess that there are some subtle rules surrounding the common carrier status. I'm not a lawyer, but it probably does take one to understand the hoops you need to jump through to become a common carrier. I doubt that simply disabling the encryption on his network would qualify him for protected status.
I don't think that it matters if people in general are computer illiterate, what matters is if you are computer illiterate. So, if the RIAA's lawyers find out that you have a Cisco certification and work as a network admin, you are definitely going to have a hard time claiming you weren't negligent.
1. You cannot act as a common carrier.
2. You are legally responsibile for all traffic coming from your connection.
Therefore, you're hosed.
IANAL, but I would imagine that there is a legal issue there. Can you prove that it is not your fault? The fact that your car was used to kill someone is evidence that supports the proposition that you were the killer. If you cannot prove that your car was stolen, then you are going to have a harder time proving that you weren't involved.
It's even worse when applied to your bandwidth. If you are not keeping logs and are not actively trying to secure your network, you have no proof that you did not download that illegal MP3 file. Since you are most likely legally obligated to prevent unauthorized access to your bandwidth by your ISP's TOS, you will be the one that takes the fall for it.
At the very least, the RIAA would push for a criminal negligence conviction. I would bet they could easily get it, too, if they could uncover documentation that proves that you (a) had the ability to secure your network, and (b) knew the implications of not securing your network. A computer-related degree or certification is all the evidence they would need to prove both points.
Actually, we also have no desire nor purpose to prevent tainting. The purpose of the workaround is to avoid repetitive warning messages generated when multiple modules belonging to a single logical "driver" are loaded (even when a module is only probed but not used due to the hardware not being present). Although the issue may sound trivial/harmless to people on the lkml, it was a frequent cause of confusion for the average person.
Read the entire email for the whole picture. Whether you agree or not, it is important to understand why they partially circumvented the license check.
Of course, there are also the "religious" arguments that you so arrogantly toss aside. You may not care about the free software philosophy, but some people do. Is it moral for a company to lie about its product being GPL'd? Is it wrong for someone to expect a module to give an accurate representation of how it is licensed? Though you may not agree with them, there are real reasons why people want to run only GPL-compatible software.
Profits and taxes. If a company moves its headquarters to India, the profits generated by that company will no longer be "based" in the US. That means that the profits will be more likely to be spent on Indian goods and services than on US goods and services. Perhaps more importantly, the money generated by taxing those profits will go straight to the Indian government instead of the US government.
Why do you think people are so eager to have companies based in their area? If Microsoft moved into Wyoming, the level of services that could be provided by the government would increase without raising the tax rates. As another example, under the "abstract entities" argument, it wouldn't matter where you put military bases, as you still derive the net protective benefit regardless of where they are in the US, yet politicians practially kill each other in an effort to get bases moved to their home states. There are definite benefits to having the physical entities based in your geographic location.
I can't help but think that they (the Indians) could just outsource the sales part to the U.S. or Europe, while still maintaining the headquarters and development in India.
In addition, it seems to me that the bandwidth isn't a big deal. It is possible to get bandwidth in India, plus you can mirror a site around the world with various service providers.
There's probably some IPO-type money floating around in India, too; it seems that they are experiencing their own .com boom right now.
I've also heard that Disney has invested money in USDTV. It appears that this is true, given the some of the channels: 2 pure Disneys, 2 ESPNs, 2 and Lifetimes. It looks like USDTV can't get away from one of the evils of cable: forced bundling.
Maybe that's what bugged me about this piece; you can tell the author had a definite opinon but he wouldn't just come out and say it. If he isn't willing to say it, what does that mean about his belief in his own supporting evidence? Did his lawyers tell him to hedge, or did he not believe he had enough real evidence to publicly condemn the guy?
As for your comment on giving money to a scammer, that's hogwash -- that is how investigative journalism works. If the journalist spends X dollars, but ends up saving the public 1000X dollars, it is definitely worth it.
Maybe Tom's Hardware should hire John Stossel if they are going to do these kinds of pieces.
That's the point, though; they're trying to put data on the wire more often than before. TCP doesn't start out by saturating the wire, but instead slowly "tests the water" and transfers data more and more frequently until it is confident it has saturated the line.
This protocol, on the other hand, figures out the capacity of the line faster, and thus can saturate it more quickly. The difference between the two is where they get their weird "6000x" figure.