Look, I don't care if YOU don't want to use DRM'd services like Netflix, but some of us DO, and we'd like to be able to use these sorts of services without proprietary plugins like Silverlight dictating what operating systems we can use it on.
I'm a realist. DRM is idiotic and useless, but the people holding the cards are too dumb to realize that. If that means that I have to accept unobtrusive and transparent DRM to view content because of that, so be it. DRM done right doesn't get in the user's way, and a standardized form of DRM will help keep it from getting in the way. This needs to happen.
The basic gist is that any dinosaur DNA would be completely degraded. DNA has a half-life of 521 years with variations based on environmental conditions. A 2012 study showed that DNA would degrade past the point that we could read anything useful out of it after 1.5 million years, and would degrade completely after 6.8 million, and those are under optimal conditions. The Jurassic period ended 145 million years ago.
It's not really meant for that, though. Google Documents or some other solution intended for many people editing the same document at the same time would work better.
Define "commercial". Can I go out to the store and buy something with a PowerPC in it? Yes, there are lots of consumer devices with PowerPC chips. Can I call a distributor and purchase a "bare" PowerPC chip? Yes, they do make them in packages that can use ZIF sockets, for POWER servers if nothing else (also PowerPC processor upgrade kits).
The thing is PowerPC has never caught on for PC use, and isn't nearly as prevalent in the embedded space as MIPS or ARM, so I'd argue that having their processors in all the consoles didn't do much to help them in that regard. Consider that people were still buying desktop and laptop computers from Apple that used PowerPC chips when the XBox 360 came out in 2005 (Apple wasn't shipping any Intel macs when the 360 came out, and didn't finish their transition away from PowerPC until a year later).
Perhaps because Tom Dickson (and isn't it crazy that the CEO of a blender maker is a household name?) is shown sticking a crowbar into a blender in the intro of the WiB videos? They've even done some gags about it.
All indications are that this AMD APU has way more graphics hardware onboard than anything you'd find in a consumer part, though. This also seems to be the first proper consumer 8-core chip that AMD has produced; they've never put anything out with that sort of core count before in the consumer market that didn't use the quasi-multicore design where every set of two cores were sharing a lot of the hardware (their answer to SMT). The point is that they're already scaling this thing way the heck up from what they've done before.
Could the same not be true for nVidia? Sure, as you point out, ARMv8 isn't ready yet, but the Cortex A15 supports 8-core chips in a 2x4 arrangement, and nVidia could have scaled their GeForce ULP way the heck up. I think the CPU performance would still have lagged way the heck behind, even if they had pushed the clockspeeds much higher than you'd find in a mobile device (Cortex A15 chips are shipping in smartphones at speeds like 1.2 GHz, while the architecture is rated for up to 2.5 GHz).
Because of the CPU limitations (even if CPU power is less important than GPU power in consoles), Intel might have been a more likely target. People don't realize quite how much Intel's GPU performance has improved over the past few years, and at this point they've got a pretty decent platform that they could likely have simply scaled up in execution unit count, if they were willing to do a completely custom part for Sony/Microsoft. On the other hand, while the CPU performance would be a clear and obvious win over an AMD solution, I'm not sure how Intel's existing GPU stuff would perform when scaled up a bunch, or if their architecture is even capable of supporting several times more execution units.
However, these systems are targeted at larger deployments.
And this part:
Buy a whole rack of them and the price comes down to $352 per server node, or about $8500 per server. We have some experience with medium quantity sales, and our best guess is that you get typically a 10 to 20% discount when you buy 20 of them. So that would mean that the Xeon E5 server would be around $6500-$7200 and the Boston Viridis around $8500.
It's still more expensive, but the gap narrows substantially.
The" Cluster Compute" instances might be better suited to cluster computing, although they're not cheap. But a single one of them, a dual-CPU eight core Xeon E5-2670 (dedicated, so they don't list EC2 compute units), probably has more computing power than the entire Core 2 Duo cluster being proposed.
But as I said, not cheap. It comes out to $400 per month for a reserved instance. A spot instance could be slightly cheaper. Then again, at the 150W of power usage you specified, times 1.8 to use the industry typical datacenter power usage efficiency (which accounts for air conditioner cooling, UPS losses, and other overhead), we get 3,780W, which in a single month is 2721.6 kilowatt hours, and at $0.12 that amounts to $326.59 in power alone!
So, it seems that the Amazon server at $400 per month, is barely more expensive than the power required to run those 14 Core 2 machines!
Iron dome takes down artillery shells. The reporting on it says so, and the manufacturer says so. What's your source to claim that the manufacturer is lying?
Phalanx is a CIWS; the C standing for "close". It doesn't seem like a CIWS would be an effective way to protect a very large city.
I'm not all that convinced that North Korea can effectively invade South Korea. Do serious damage to Seoul, sure. But South Korea's active armed forces aren't that much smaller than North Korea (640k SK plus 29k USFK) versus 1,106k), South Korea's military is enormously better equipped (they have far greater force multiplication), is far healthier and better fed, and South Korea would enjoy total air superiority (North Korea's air force exists largely on paper). On top of that, South Korea could help on additional backup from the US (beyond USFK) as soon as the US could get it there, while North Korea would be entirely on their own. China is highly unlikely to fight their war for them this time (North Korea is sufficiently unimportant to China at this point that they wouldn't risk it). Even then, China only entered the Korean war in the first place because the US ignored Chinese warnings not to cross the 38th parallel as they were retaking the country (they didn't want a US-controlled country on their borders).
I think South Korea could pretty effectively repel any infantry assault. Heck, South Korea has bloody automated sentry turrets (made by Samsung) in the DMZ (or at least they deployed a trial run in 2010)... The bigger question is all that artillery pointed at Seoul. It makes me wonder if South Korea has anything up their sleeves like Iron Dome? Certainly South Korea expressed interest in purchasing Iron Dome units in 2011, and artillery shells are one of the things Iron Dome is intended to counter. The system only works against ballistic projectiles/rockets, but that's all the North has anyhow...
To put the relative disparity of the military resources in perspective, South Korea's military budget is about $30 billion USD. North Korea's is about $10 billion USD, and a pretty good chunk of that is probably going to their nuclear program (their rocket launches alone have cost them $1.3 billion)...
Well, the spirit of such a license is open to interpretation. We seem to now agree that the VLC C&D is against the letter of the GPL, but disagree as to if it's against the spirit of it. For my part, I think that holding back the proliferation of open source software (emphasis on the "source" part) in such a manner is against the spirit of the GPL, while others feel that it is not.
This also made me laugh. Any international agreement relies on all parties adhering to it to function. If one party in a two party agreement decides to ignore it entirely, then the legal fabrications of a powerless third party are kind of meaningless. As you say, North Korea can start shooting anytime they want, and waving around the armistice saying "You can't do this, this armistice is still in force!" is worse than useless.
Ultimately, any sanctions the UN might try to impose are limited to individual nations' willingness to adhere to them, and since China is the source of the majority of all North Korean imports, it largely comes down to if China is willing to adhere to them. If China cuts off North Korea, they'd collapse pretty quickly, but China doesn't want millions of refugees flooding their borders any more than anybody else would want that...
How does the device refusing to run the code equate to preventing distribution? In fact, the GPLv2 specifically does not cover that, which was the whole reason that the "tivoisation" clauses were added to the GPLv3.
The App Store is a distribution platform, is there any part of the App Store license that specifically requires a modification to the application license, or does it merely govern the use of the App Store as a distribution platform? If so, there is no sub-licensing occurring. This is not mental gymnastics, conditions for the use of a distribution service don't mean the license of the program itself is changing.
The part of the GPLv2 that you're quoting is stating that the *GPLv2* does not restrict this, not that it requires that nothing else do so. You're quoting the part of the license that says what the GPL applies to... Indeed, the preceding sentence to what you're quoting says "Activities other than copying, distribution and modification are not covered by this License", which means that "the act of running the program" is completely outside the scope of the GPLv2.
The GPLv2 does not prohibit the use of Apple's app store just because people want it to. If they do want this to be the case, there are other licenses that do have this sort of restriction. I believe the GPLv3 has this sort of restriction.
Because Apple doesn't want to get in the middle of a copyright fight between people posting the content and people issuing C&Ds for the content. Apple was happy enough to post it, and when they got a C&D, they pulled it. If anybody else tried to post VLC, the zealot would just C&D Apple again.
There's a ton of GPL content in the app store, and there's nothing about the way it does DRM that violates the GPL. But that doesn't matter to some people, they just plain hate Apple and will send a C&D regardless.
Firstly, there are zero restrictions against the rendering engine. Mozilla could use Gecko if they wanted, and Google could use their version of Webkit. The restriction is against the javascript engine, and Gecko/Webkit would not be very useful in a web browser without one. That's why they have to use Apple's library. There is at least two browsers out there that don't use Apple's library. Opera executes the javascript on their remote proxy and their local rendering engine communicates with that to feed the results in. Then there's that other one that actually does the rendering itself server-side and sends the results as images.
In terms of Chrome, it's no more a gui wrapper than Firefox is a GUI wrapper of the Gecko engine... Yes, the API being used to access it is likely more restrictive, but not enough to stop them from adding a whole bunch of features not available in Safari. The key one for me is unlimited tabs, but the interface in general is better, incognito mode is sometimes useful, you get a little bit of user-agent control (they only expose it as a "request desktop site"), syncing with your google accounts (including automatic authentication to google sites, which implies deeper integration than a GUI wrapper), the benefits of the "omnibox", etc.
There are obviously a bunch of features that they could implement if they could use their own rendering and javascript engine (and getting a full-speed javascript engine would be nice, only Safari gets that), but if they implemented the current feature set with their own rendering and javascript engine, there probably wouldn't be any differences noticeable to the user.
I'd love for Apple to remove those restrictions, but Chrome on iOS is not a thin GUI wrapper, and more people should check it out; it's a lot better than Safari.
Give it time; Intel originally expected this state of ubiquitous computing to happen for x86 by 2020 (5nm). Cedar Trail's SoC is 56mm^2, the same chip at 5nm would about 1.4mm^2. If they were specifically designing an SoC for size, they could get this a bunch lower.
There is a big difference between somebody advocating against believing in something like Richard Dawkins does, and somebody advocating active persecution of people because they're different like Card does.
In addition, a lot of transistors are wasted doing instruction decoding because x86 instructions are variable length. Great when you needed high code density, but now it's legacy cruft that serves little other than complicate instruction caches, inflight tagging and complicate instruction processing as instructions require partial decoding to figure out their length.
Depends what you mean by "a lot". On the low end RISC will always win.
When AMD first introduced x86-64, they claimed the percentage of the die dedicated to decoding x86 was 10%. That was on 130nm. Next year, we hit 14nm, which assuming the amount of logic required to support x86 is constant (it's not, but it doesn't change much), that would mean that about 0.1% of a 2014 CPU will be dedicated to decoding x86...
So yes, the x86 overhead has become basically inconsequential.
Slashdot Mirror
Look, I don't care if YOU don't want to use DRM'd services like Netflix, but some of us DO, and we'd like to be able to use these sorts of services without proprietary plugins like Silverlight dictating what operating systems we can use it on.
I'm a realist. DRM is idiotic and useless, but the people holding the cards are too dumb to realize that. If that means that I have to accept unobtrusive and transparent DRM to view content because of that, so be it. DRM done right doesn't get in the user's way, and a standardized form of DRM will help keep it from getting in the way. This needs to happen.
The basic gist is that any dinosaur DNA would be completely degraded. DNA has a half-life of 521 years with variations based on environmental conditions. A 2012 study showed that DNA would degrade past the point that we could read anything useful out of it after 1.5 million years, and would degrade completely after 6.8 million, and those are under optimal conditions. The Jurassic period ended 145 million years ago.
Source: http://m.mnn.com/green-tech/research-innovations/stories/scientists-dash-hopes-for-dinosaur-cloning
It's not really meant for that, though. Google Documents or some other solution intended for many people editing the same document at the same time would work better.
Define "commercial". Can I go out to the store and buy something with a PowerPC in it? Yes, there are lots of consumer devices with PowerPC chips. Can I call a distributor and purchase a "bare" PowerPC chip? Yes, they do make them in packages that can use ZIF sockets, for POWER servers if nothing else (also PowerPC processor upgrade kits).
The thing is PowerPC has never caught on for PC use, and isn't nearly as prevalent in the embedded space as MIPS or ARM, so I'd argue that having their processors in all the consoles didn't do much to help them in that regard. Consider that people were still buying desktop and laptop computers from Apple that used PowerPC chips when the XBox 360 came out in 2005 (Apple wasn't shipping any Intel macs when the 360 came out, and didn't finish their transition away from PowerPC until a year later).
Perhaps because Tom Dickson (and isn't it crazy that the CEO of a blender maker is a household name?) is shown sticking a crowbar into a blender in the intro of the WiB videos? They've even done some gags about it.
"We produce both the CPU and GPU of all modern game consoles, don't you want to buy our chips?"
The Wii U stuck to an IBM PowerPC processor, although it does have an AMD GPU.
IBM made the processors in all three of last generation's consoles (360/PS3/Wii), what impact did that have on IBM's processor sales?
All indications are that this AMD APU has way more graphics hardware onboard than anything you'd find in a consumer part, though. This also seems to be the first proper consumer 8-core chip that AMD has produced; they've never put anything out with that sort of core count before in the consumer market that didn't use the quasi-multicore design where every set of two cores were sharing a lot of the hardware (their answer to SMT). The point is that they're already scaling this thing way the heck up from what they've done before.
Could the same not be true for nVidia? Sure, as you point out, ARMv8 isn't ready yet, but the Cortex A15 supports 8-core chips in a 2x4 arrangement, and nVidia could have scaled their GeForce ULP way the heck up. I think the CPU performance would still have lagged way the heck behind, even if they had pushed the clockspeeds much higher than you'd find in a mobile device (Cortex A15 chips are shipping in smartphones at speeds like 1.2 GHz, while the architecture is rated for up to 2.5 GHz).
Because of the CPU limitations (even if CPU power is less important than GPU power in consoles), Intel might have been a more likely target. People don't realize quite how much Intel's GPU performance has improved over the past few years, and at this point they've got a pretty decent platform that they could likely have simply scaled up in execution unit count, if they were willing to do a completely custom part for Sony/Microsoft. On the other hand, while the CPU performance would be a clear and obvious win over an AMD solution, I'm not sure how Intel's existing GPU stuff would perform when scaled up a bunch, or if their architecture is even capable of supporting several times more execution units.
Except nVidia has never had their own fabs, so that's not an advantage for AMD.
I think you missed this part:
However, these systems are targeted at larger deployments.
And this part:
Buy a whole rack of them and the price comes down to $352 per server node, or about $8500 per server. We have some experience with medium quantity sales, and our best guess is that you get typically a 10 to 20% discount when you buy 20 of them. So that would mean that the Xeon E5 server would be around $6500-$7200 and the Boston Viridis around $8500.
It's still more expensive, but the gap narrows substantially.
The" Cluster Compute" instances might be better suited to cluster computing, although they're not cheap. But a single one of them, a dual-CPU eight core Xeon E5-2670 (dedicated, so they don't list EC2 compute units), probably has more computing power than the entire Core 2 Duo cluster being proposed.
But as I said, not cheap. It comes out to $400 per month for a reserved instance. A spot instance could be slightly cheaper. Then again, at the 150W of power usage you specified, times 1.8 to use the industry typical datacenter power usage efficiency (which accounts for air conditioner cooling, UPS losses, and other overhead), we get 3,780W, which in a single month is 2721.6 kilowatt hours, and at $0.12 that amounts to $326.59 in power alone!
So, it seems that the Amazon server at $400 per month, is barely more expensive than the power required to run those 14 Core 2 machines!
Does the company's correct name, Canipre, also autocorrect to Vampire?
Iron dome takes down artillery shells. The reporting on it says so, and the manufacturer says so. What's your source to claim that the manufacturer is lying?
Phalanx is a CIWS; the C standing for "close". It doesn't seem like a CIWS would be an effective way to protect a very large city.
I'm not all that convinced that North Korea can effectively invade South Korea. Do serious damage to Seoul, sure. But South Korea's active armed forces aren't that much smaller than North Korea (640k SK plus 29k USFK) versus 1,106k), South Korea's military is enormously better equipped (they have far greater force multiplication), is far healthier and better fed, and South Korea would enjoy total air superiority (North Korea's air force exists largely on paper). On top of that, South Korea could help on additional backup from the US (beyond USFK) as soon as the US could get it there, while North Korea would be entirely on their own. China is highly unlikely to fight their war for them this time (North Korea is sufficiently unimportant to China at this point that they wouldn't risk it). Even then, China only entered the Korean war in the first place because the US ignored Chinese warnings not to cross the 38th parallel as they were retaking the country (they didn't want a US-controlled country on their borders).
I think South Korea could pretty effectively repel any infantry assault. Heck, South Korea has bloody automated sentry turrets (made by Samsung) in the DMZ (or at least they deployed a trial run in 2010)... The bigger question is all that artillery pointed at Seoul. It makes me wonder if South Korea has anything up their sleeves like Iron Dome? Certainly South Korea expressed interest in purchasing Iron Dome units in 2011, and artillery shells are one of the things Iron Dome is intended to counter. The system only works against ballistic projectiles/rockets, but that's all the North has anyhow...
To put the relative disparity of the military resources in perspective, South Korea's military budget is about $30 billion USD. North Korea's is about $10 billion USD, and a pretty good chunk of that is probably going to their nuclear program (their rocket launches alone have cost them $1.3 billion)...
Well, the spirit of such a license is open to interpretation. We seem to now agree that the VLC C&D is against the letter of the GPL, but disagree as to if it's against the spirit of it. For my part, I think that holding back the proliferation of open source software (emphasis on the "source" part) in such a manner is against the spirit of the GPL, while others feel that it is not.
This also made me laugh. Any international agreement relies on all parties adhering to it to function. If one party in a two party agreement decides to ignore it entirely, then the legal fabrications of a powerless third party are kind of meaningless. As you say, North Korea can start shooting anytime they want, and waving around the armistice saying "You can't do this, this armistice is still in force!" is worse than useless.
Ultimately, any sanctions the UN might try to impose are limited to individual nations' willingness to adhere to them, and since China is the source of the majority of all North Korean imports, it largely comes down to if China is willing to adhere to them. If China cuts off North Korea, they'd collapse pretty quickly, but China doesn't want millions of refugees flooding their borders any more than anybody else would want that...
How does the device refusing to run the code equate to preventing distribution? In fact, the GPLv2 specifically does not cover that, which was the whole reason that the "tivoisation" clauses were added to the GPLv3.
The App Store is a distribution platform, is there any part of the App Store license that specifically requires a modification to the application license, or does it merely govern the use of the App Store as a distribution platform? If so, there is no sub-licensing occurring. This is not mental gymnastics, conditions for the use of a distribution service don't mean the license of the program itself is changing.
The part of the GPLv2 that you're quoting is stating that the *GPLv2* does not restrict this, not that it requires that nothing else do so. You're quoting the part of the license that says what the GPL applies to... Indeed, the preceding sentence to what you're quoting says "Activities other than copying, distribution and modification are not covered by this License", which means that "the act of running the program" is completely outside the scope of the GPLv2.
The GPLv2 does not prohibit the use of Apple's app store just because people want it to. If they do want this to be the case, there are other licenses that do have this sort of restriction. I believe the GPLv3 has this sort of restriction.
Because Apple doesn't want to get in the middle of a copyright fight between people posting the content and people issuing C&Ds for the content. Apple was happy enough to post it, and when they got a C&D, they pulled it. If anybody else tried to post VLC, the zealot would just C&D Apple again.
There's a ton of GPL content in the app store, and there's nothing about the way it does DRM that violates the GPL. But that doesn't matter to some people, they just plain hate Apple and will send a C&D regardless.
Firstly, there are zero restrictions against the rendering engine. Mozilla could use Gecko if they wanted, and Google could use their version of Webkit. The restriction is against the javascript engine, and Gecko/Webkit would not be very useful in a web browser without one. That's why they have to use Apple's library. There is at least two browsers out there that don't use Apple's library. Opera executes the javascript on their remote proxy and their local rendering engine communicates with that to feed the results in. Then there's that other one that actually does the rendering itself server-side and sends the results as images.
In terms of Chrome, it's no more a gui wrapper than Firefox is a GUI wrapper of the Gecko engine... Yes, the API being used to access it is likely more restrictive, but not enough to stop them from adding a whole bunch of features not available in Safari. The key one for me is unlimited tabs, but the interface in general is better, incognito mode is sometimes useful, you get a little bit of user-agent control (they only expose it as a "request desktop site"), syncing with your google accounts (including automatic authentication to google sites, which implies deeper integration than a GUI wrapper), the benefits of the "omnibox", etc.
There are obviously a bunch of features that they could implement if they could use their own rendering and javascript engine (and getting a full-speed javascript engine would be nice, only Safari gets that), but if they implemented the current feature set with their own rendering and javascript engine, there probably wouldn't be any differences noticeable to the user.
I'd love for Apple to remove those restrictions, but Chrome on iOS is not a thin GUI wrapper, and more people should check it out; it's a lot better than Safari.
Give it time; Intel originally expected this state of ubiquitous computing to happen for x86 by 2020 (5nm). Cedar Trail's SoC is 56mm^2, the same chip at 5nm would about 1.4mm^2. If they were specifically designing an SoC for size, they could get this a bunch lower.
http://www.anandtech.com/show/6253/intel-by-2020-the-size-of-meaningful-compute-approaches-zero
There is a big difference between somebody advocating against believing in something like Richard Dawkins does, and somebody advocating active persecution of people because they're different like Card does.
In addition, a lot of transistors are wasted doing instruction decoding because x86 instructions are variable length. Great when you needed high code density, but now it's legacy cruft that serves little other than complicate instruction caches, inflight tagging and complicate instruction processing as instructions require partial decoding to figure out their length.
Depends what you mean by "a lot". On the low end RISC will always win.
When AMD first introduced x86-64, they claimed the percentage of the die dedicated to decoding x86 was 10%. That was on 130nm. Next year, we hit 14nm, which assuming the amount of logic required to support x86 is constant (it's not, but it doesn't change much), that would mean that about 0.1% of a 2014 CPU will be dedicated to decoding x86...
So yes, the x86 overhead has become basically inconsequential.
Should not a 7.5x larger pixel collect 7.5x more light? It's 7.5x the area, not the linear dimensions.
Could not doing 3x3 binning on the existing 18MP sensor (if the controller supported it) produce similar results?