Because not complying with China's demands would mean that Google would (most likely) have to pull out of China. If they pulled out of China, the Chinese still wouldn't have access to Google's search results. IMO, this is also be a loss. In a loose-loose situation, I'm not surprised Google took the more profitable route, even though it may have opened them up for more criticism.
There's a big difference.
You see, Korea actually has WMDs. if Iraq did, do you think Bush would have the guts to go after them to take away their WMDs?
Also how can they possibly enforce it? Block at the ISP level? Using what? ports? They can change. Checking individual packets for p2p signatures? Might be possible if you want your bandwidth to be non-existant.
The same way they do traffic shaping. It's fast enough to allow ISPs to inspect packets and throttle Bittorrent (like my ISP does, sadly -- google "Rogers traffic shaping"), so I don't see any reason why it wouldn't it be fast enough to block p2p off entirely?
My question is why the VM factors into the developer time at all?
A VM is a convenient distribution means, but I don't see why a language such as Java or C# needs a VM, or why it's a significant advantage? As a matter of fact, I'd say that the existance of GCJ proves that Java does not need a VM in order to work well (although GCJ currently sucks, it can be treated as a valid proof of concept)
In my opinion, the real advantage to bytecode is nothing more than ease of distribution. With bytecode and virtual machines, you don't need to worry that one of your boxen is a Mips processor, another one is running a Sparc, and the gaggle of other boxen are x86es. It also allows for much easier sandboxing.
However, Bytecode loses a fair amount of speed, slows down loading time, gives no extra amounts of safety, and is, in general, compiled while it's running anyways (Just In Time compilation). Additionally, for most applications (not applets), sandboxing is disabled. The runtime checks may just as well be inserted into assembly code directly, rather than checked by a virtual machine. Even binary code can be created during runtime and executed from compiled code (well, unless you enabled W^X in the OS, in which case a VM is a way of cheating and working around that security). As a matter of fact, this "generated code" method is used from within Gnu C for closures (nested functions that can reference the enclosing scope).
In my opinion, any program tied to a single machine for most of it's life (eg: something that would run on Windows.NET) should probably be compliled, since there is absolutely no advantage to a virtual machine. For things like Java applets, I can see a purpose.
Perhaps the best way of dealing with laws like this that are both unenforcable, far-reaching, and generally ignorant of the way things are is by removing the ability of legislators to propose laws outside their area of expertise, leaving this to a panel of experts. Leave the discussion and passing of laws to parliament, but remove the ability to propose stupid laws.
And somehow putting X in kernel space will magically make it more secure? Especially since putting X into kernel space gives it direct access to all the other program's private address spaces, and the ring 0 instructions on the processor?
Somehow, I think that it'll do the opposite.
Also, as a side note, I would like to see you -- or anyone else -- write a program that doesn't use hardware registers at some level. Even the canonical "hello world" program uses (on Linux x86, at least) %eax, %ebx, %ecx, and %edx to do the "write" system call. "_exit()", as well, uses registers %eax and %ebx. Depending on the compiler and libraries, it would use a plethora of others.
Slashdot Mirror
Just because it's being reused internally doesn't mean some other app doesn't need it more.
Deallocating/Reallocating is preferable to being swapped out because a different app needs the space.
Because not complying with China's demands would mean that Google would (most likely) have to pull out of China. If they pulled out of China, the Chinese still wouldn't have access to Google's search results. IMO, this is also be a loss. In a loose-loose situation, I'm not surprised Google took the more profitable route, even though it may have opened them up for more criticism.
Well, people have always been telling me that compromise is an important part of life...
There's a big difference.
You see, Korea actually has WMDs. if Iraq did, do you think Bush would have the guts to go after them to take away their WMDs?
My question is why the VM factors into the developer time at all?
A VM is a convenient distribution means, but I don't see why a language such as Java or C# needs a VM, or why it's a significant advantage? As a matter of fact, I'd say that the existance of GCJ proves that Java does not need a VM in order to work well (although GCJ currently sucks, it can be treated as a valid proof of concept)
In my opinion, the real advantage to bytecode is nothing more than ease of distribution. With bytecode and virtual machines, you don't need to worry that one of your boxen is a Mips processor, another one is running a Sparc, and the gaggle of other boxen are x86es. It also allows for much easier sandboxing. However, Bytecode loses a fair amount of speed, slows down loading time, gives no extra amounts of safety, and is, in general, compiled while it's running anyways (Just In Time compilation). Additionally, for most applications (not applets), sandboxing is disabled. The runtime checks may just as well be inserted into assembly code directly, rather than checked by a virtual machine. Even binary code can be created during runtime and executed from compiled code (well, unless you enabled W^X in the OS, in which case a VM is a way of cheating and working around that security). As a matter of fact, this "generated code" method is used from within Gnu C for closures (nested functions that can reference the enclosing scope). In my opinion, any program tied to a single machine for most of it's life (eg: something that would run on Windows .NET) should probably be compliled, since there is absolutely no advantage to a virtual machine. For things like Java applets, I can see a purpose.
However, someone once said "The pen is mightier than the sword."
And it's a hell of a lot easier to write with, to boot!
Perhaps the best way of dealing with laws like this that are both unenforcable, far-reaching, and generally ignorant of the way things are is by removing the ability of legislators to propose laws outside their area of expertise, leaving this to a panel of experts. Leave the discussion and passing of laws to parliament, but remove the ability to propose stupid laws.
And somehow putting X in kernel space will magically make it more secure? Especially since putting X into kernel space gives it direct access to all the other program's private address spaces, and the ring 0 instructions on the processor?
Somehow, I think that it'll do the opposite.
Also, as a side note, I would like to see you -- or anyone else -- write a program that doesn't use hardware registers at some level. Even the canonical "hello world" program uses (on Linux x86, at least) %eax, %ebx, %ecx, and %edx to do the "write" system call. "_exit()", as well, uses registers %eax and %ebx. Depending on the compiler and libraries, it would use a plethora of others.