Microsoft will be "exempt" from the GPLv3 simply because they will
never distribute or pay others to
distribute GPLv3 code: since the FSF foundation has made clear they believe that
paying others counts as distribution, the Novell deal will not encompass any
GPLv3 stuff.
So for all those who hope that Microsoft will somehow get caught with their hand
in the GPL cookie-jar/trap, forget about it. They are already very careful, and
GPLv3 makes them even more careful.
Rather, what the GPLv3 does is make a large amount of future open-source
development unavailable to Apple. Apple, unlike Microsoft, ships a large amount
of GPL based software: GCC, emacs, a lot of random utilities, etc.
And Apple's solution is to buy up the copyright when possible (CUPS), replace
(I've heard talk about replacing gcc), and/or fork at the last GPLv2 version.
The GPLv3 is designed to be unpalitable to many companies: TiVo, Apple, Google,
etc, and they will sooner forgoe anything released under GPLv3 than deal with
the liscence. This is a feature of the
GPLv3, not a bug.
But it is a feature that will only be noticed by its absence: large companies
avoiding GPLv3 code except for internal use.
The original Half Life was a really classic example of this. You could make a decent monster movie along the same plot, but you wouldn't have quite the tension.
EG, the tension where you are creeping through the silo with the giant tentacles, the first time you meet the big shark-thingy, the elation and then horror as the marines come, etc....
So once again, I'll read up to the first Dvorak mistake, and then stop.
The first one I got: WGA can't "fail closed", otherwise pirates would just filter the communication to the WGA servers.
Rather, what WGA needs is a signed "check back later" message, where Microsoft's public key is used to sign a "check back by day X" message, so that a server outage can be handled in the future. And I'd bet that there is, by next Patch Tuesday, an upgrade to WGA to support such functionality.
And its not like people's home/office computers are so reliable, making this segque ridiculous.
"So according to VMware ESX actually has two kernels - the vmkernel, and a Linux kernel. This sounds a bit odd, given a computer can only run one kernel at a given time otherwise which one determines who gets access to the CPU, memory, and other hardware?"
Uhh, this is a virtualization system. The ESX kernel provides a hardware abstraction layer which the linux kernel in the service console can access.
So yes, it IS running two kernels, the ESX kernel which has priority, and the linux kernel running on top of it in a VM like every other virtualized kernel, once it gets running. Duh.
But the meat of the FA seems to be that "Because a Linux kernel is used to initiate the ESX kernel, and because the linux kernel has a binary blob driver to help in the bootstrap process, QED ESX kernel is considered a derivitive work, because Linus says that things which require kernel changes are derivitive works" WTF?
FUD is bad. No matter the source.
The Linux kernel allows binary blobs. VMWare uses an F@#)(* huge binary blob to bootstrap ESX and other stuff. OOOHHH SCARY bogeyman violate GPL. Either sue (Linus does have standing. The SCSI author actually does have standing if it includes his code anywhere in the hacked up kernel) or get off the pot.
The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows, so why code for 2% of the market when you can code for 92% of the market?
Thus you will only get games where the developer has gone out of their way to ensure complete portibility and provides a port mostly out of courtousy.
The scheduler details are irrelevant for this: what Linux Games need is 10%+ marketshare on the desktop.
I don't have the stats for SSL, but for a simple SSH it takes.17 seconds to do a simple handshake, authenticated login, echo, exit (to a system that is.9 ms RTT latency), while only.06 seconds to do a shell script locally of "echo ".
So I'm a little high on my.1 CPU second, but its not THAT far off. RSA in software is slow...
The bulk encryption is cheap, but thats another story.
This is a war however which we can make damn difficult by using virus-like mutation techniques, so that every checker looks different: force THEM to solve the AV defender arms race.
As long as the actual API used by the Javascript is common enough that the ad-injectors can't recognize and block our code by keeing in on the API calls rather than the overall Javascript.
The proper solution, adding integrity checking to all HTTP, seems like its not happening.
b) CPU isn't free. It costs ~.1 CPU second to do an SSL handshake. This is actually a big-deal amount, there is a reason why Gmail defaults to http except for authentication.
One of the big reasons is the certificate model...
If you self-sign, everyone gets a nag panel everytime they visit your web page. If you have verisign or someone else provide you with a certificate, it costs real money.
Also, the HTTPS handshake is expensive, figure ~.1 CPU second per visitor to handle the public key exchange, and it starts to add up. There is a reason why GOOGLE doesn't use https for gmail by default (you have to manually type in https://mail.google.com/ to get gmail through SSL), the key echange is expensive, even by Google's standards.
I agree that doing things cryptographically-authenticated would be a good thing (one could probably do a more lightweight opportunistic mechanism, myself and others at ICSI have an upcoming paper in HotSec on the possibility), but most people don't use https, and a lot of web sites don't SUPPORT https for many things.
We are specifically worried about this case. But we have some thoughts on how to make it more difficult for someone to do that, which will probably end up in a full paper later.
We've seen a couple cases of NebuAdd, one other that looks interesting, and a fair amount of addblocking/firewall software (eg, ZoneAlarm does some modifications)
We are waiting for the Slashdot and DIGG deluges to pass, however, before we have a more detailed analysis.
Slashdot Mirror
Linux vs BSD on liscencing isn't a kernel issue. Linux is GPLv2 only, so it doesn't matter much.
Where it matters is the toolchain and utilities, and (*)BSD is as dependent on the FSF toolchain as anybody else.
So for all those who hope that Microsoft will somehow get caught with their hand in the GPL cookie-jar/trap, forget about it. They are already very careful, and GPLv3 makes them even more careful.
Rather, what the GPLv3 does is make a large amount of future open-source development unavailable to Apple. Apple, unlike Microsoft, ships a large amount of GPL based software: GCC, emacs, a lot of random utilities, etc.
And Apple's solution is to buy up the copyright when possible (CUPS), replace (I've heard talk about replacing gcc), and/or fork at the last GPLv2 version.
The GPLv3 is designed to be unpalitable to many companies: TiVo, Apple, Google, etc, and they will sooner forgoe anything released under GPLv3 than deal with the liscence. This is a feature of the GPLv3, not a bug.
But it is a feature that will only be noticed by its absence: large companies avoiding GPLv3 code except for internal use.
-Nicholas Weaver
The original Half Life was a really classic example of this. You could make a decent monster movie along the same plot, but you wouldn't have quite the tension.
EG, the tension where you are creeping through the silo with the giant tentacles, the first time you meet the big shark-thingy, the elation and then horror as the marines come, etc....
A movie wouldn't be nearly as immersive.
So once again, I'll read up to the first Dvorak mistake, and then stop.
The first one I got: WGA can't "fail closed", otherwise pirates would just filter the communication to the WGA servers.
Rather, what WGA needs is a signed "check back later" message, where Microsoft's public key is used to sign a "check back by day X" message, so that a server outage can be handled in the future. And I'd bet that there is, by next Patch Tuesday, an upgrade to WGA to support such functionality.
And its not like people's home/office computers are so reliable, making this segque ridiculous.
Its like hundreds of megabits of bandwidth suddenly cried out and were suddenly silenced.
"So according to VMware ESX actually has two kernels - the vmkernel, and a Linux kernel. This sounds a bit odd, given a computer can only run one kernel at a given time otherwise which one determines who gets access to the CPU, memory, and other hardware?"
Uhh, this is a virtualization system. The ESX kernel provides a hardware abstraction layer which the linux kernel in the service console can access.
So yes, it IS running two kernels, the ESX kernel which has priority, and the linux kernel running on top of it in a VM like every other virtualized kernel, once it gets running. Duh.
But the meat of the FA seems to be that "Because a Linux kernel is used to initiate the ESX kernel, and because the linux kernel has a binary blob driver to help in the bootstrap process, QED ESX kernel is considered a derivitive work, because Linus says that things which require kernel changes are derivitive works" WTF?
FUD is bad. No matter the source.
The Linux kernel allows binary blobs. VMWare uses an F@#)(* huge binary blob to bootstrap ESX and other stuff. OOOHHH SCARY bogeyman violate GPL. Either sue (Linus does have standing. The SCSI author actually does have standing if it includes his code anywhere in the hacked up kernel) or get off the pot.
And Just say no to FUD.
If cross platform requires more than 10% additional effort, that's why...
This is irrelevant to the gaming front.
The limit to games on Linux is market share. Its not (much) easier to develop a good 3D game for linux as it is Windows, so why code for 2% of the market when you can code for 92% of the market?
Thus you will only get games where the developer has gone out of their way to ensure complete portibility and provides a port mostly out of courtousy.
The scheduler details are irrelevant for this: what Linux Games need is 10%+ marketshare on the desktop.
I don't have the stats for SSL, but for a simple SSH it takes .17 seconds to do a simple handshake, authenticated login, echo, exit (to a system that is .9 ms RTT latency), while only .06 seconds to do a shell script locally of "echo ".
.1 CPU second, but its not THAT far off. RSA in software is slow...
So I'm a little high on my
The bulk encryption is cheap, but thats another story.
Also, detecting the absence of the checker is insufficient, because Javascript might be turned off.
This is a war however which we can make damn difficult by using virus-like mutation techniques, so that every checker looks different: force THEM to solve the AV defender arms race.
As long as the actual API used by the Javascript is common enough that the ad-injectors can't recognize and block our code by keeing in on the API calls rather than the overall Javascript.
The proper solution, adding integrity checking to all HTTP, seems like its not happening.
Talk to the UC Berkeley Financial Aid Office
No, it is amazingly good. AMAZINGLY good.
Try it.
As I mentioned in another reply:
a) Certificates are a pain and cost $$$
b) CPU isn't free. It costs ~.1 CPU second to do an SSL handshake. This is actually a big-deal amount, there is a reason why Gmail defaults to http except for authentication.
Some of the ISP advertising injectors are distinct, so those we can detect positively.
The spyware vs MITM is harder to detect in general, this may be one of the suspicious cases we need to look at for.
We do not check for either of those cases (yet).
Because people don't use SSL, and ISPs are actively inserting adds into web pages.
ANd click the link anyway, we want to have as many people try it as possible.
One of the big reasons is the certificate model...
If you self-sign, everyone gets a nag panel everytime they visit your web page. If you have verisign or someone else provide you with a certificate, it costs real money.
Also, the HTTPS handshake is expensive, figure ~.1 CPU second per visitor to handle the public key exchange, and it starts to add up. There is a reason why GOOGLE doesn't use https for gmail by default (you have to manually type in https://mail.google.com/ to get gmail through SSL), the key echange is expensive, even by Google's standards.
Strauss Creamery Soft Serve vanilla with sea salt and olive oil from Pizzeria Picco in Larkspur
Partially, we want to encourage people to pass it on to their nontechnical friends.
Our initial goal is to not map the space completely, but to
1) Validate the tool operationally
2) Try to find some cases, and analyze those cases.
Also, I think the tech savvy might be MORE vulnerable, as it seems to be small ISPs which are doing this, not the big ones.
Because people don't use HTTPs for everything.
I agree that doing things cryptographically-authenticated would be a good thing (one could probably do a more lightweight opportunistic mechanism, myself and others at ICSI have an upcoming paper in HotSec on the possibility), but most people don't use https, and a lot of web sites don't SUPPORT https for many things.
We are specifically worried about this case. But we have some thoughts on how to make it more difficult for someone to do that, which will probably end up in a full paper later.
HTTPS, when certificates are properly used, is designed to prevent man in the middle viewing and modification.
We've seen a couple cases of NebuAdd, one other that looks interesting, and a fair amount of addblocking/firewall software (eg, ZoneAlarm does some modifications)
We are waiting for the Slashdot and DIGG deluges to pass, however, before we have a more detailed analysis.
We (the authors of the page) will be answering questions in this thread.