Perhaps instead you should read the paper that this woman wrote. It lists statistics for the number of pacemaker recalls for software defects, and some of the reasons - pretty scary how poor quality the software is, as many of them would have been caught by even basic testing.
I admit that the fact that it's possible to remotely stop Dick Cheney's heart using simple off-the-shelf hardware seems like it might be a useful feature...
Any safety-critical system in a commercial aircraft is subject to FAA approval. This requires things like multiple independent teams working on implementing the same specification, formal methods employed during the development, and so on. I'm not sure if the FAA audits the code, but I'm pretty sure that they can require a third-party audit. In addition, if a software bug causes an aircraft to crash, the customers' families will sue the airliner and the airliner will sue boeing.
Now, compare that with this case: The software is known to contain remotely exploitable vulnerabilities. The FDA approved the device without doing any code review, or even with access to the code. The FDA's approval means that the manufacturer is not liable for any flaws in the device.
If you watch the talk, you'll see that there are several issues with this:
First, the software is known to be buggy. In fact, it is remotely exploitable. One group found an exploit that lets you remotely control someone's heart rate.
Secondly, because this is approved by the FDA, the manufacturer is exempt from liability for this kind of problem. The FDA does no review of the software at all, but their review of the hardware means that the manufacturer is completely immune to lawsuits if someone dies as a result of a bug in their software.
It's easy to provide a different email address to each one. Lots of people do for spam filtering and there are even third-party sites that will give you a randomly generated email address that forwards to a real one.
The reason for keeping the instruction set secret is that sure as hell you don't want to get stuck with it.
Why would you be stuck with it? You're stuck with x86 because it was the target for compiled code decades ago. No one is going to be distributing binary code for the latest nVidia or AMD code, at the most they're going to be distributing some kind of IR like PTX, or Gallium IR. Each generation of AMD and nVidia GPU has a different instruction set, and distributing code in binary form for every GPU would be insane (especially since even ones that share an instruction set often have different performance characteristics, so JIT or install/launch-time compiled code will be faster on any random target machine).
As a secondary point, you just as much don't want to be stuck with having to document it.
You have to document it for your compiler team anyway...
Both get even more weight since you don't really want people to know about all the undefined behaviour and sometimes even ridiculous bugs your compiler has to work around.
Why not? CPUs have errata, as do most devices. When was the last time you avoided a CPU or a NIC because of the documented errata that drivers / microcode need to work around?
Which is amplified by that you also don't want your competitors to write a demo that does something ridiculous just to run into one of your bug-workarounds and thus giving horrible performance only one your GPU.
Security through obscurity doesn't work. It's easy to profile binary code on any GPU, find something it sucks at, and write a contrived demo that performs badly on it. It is for CPUs too. This is why no one trusts benchmark suites written by a single vendor. You may remember in the late '90s a certain vendor tried this, and their reputation suffered - reviewers really don't like companies that cheat on benchmarks.
PTX is already a high-level abstraction, but if you use it directly then you are basically stuck with your code only working on nVidia GPUs (or, on a subset of recent nVidia GPUs, depending on which PTX features you use). If you write assembly directly for any given GPU, then you lose portability. This means that 99% of developers won't, because no one will buy a game that requires a specific make and model of GPU (unless it happens to be a model used in a console). For some categories of user, however, that doesn't matter. If you are running a simulation on a 1,000-node cluster of nVidia GPUs and tweaking the assembly can make it 10% faster, then that's the equivalent of buying 100 more nodes for your cluster: a huge saving. The cost in terms of portability is pretty low, because you're probably going to rewrite the code before you get a different cluster anyway.
writing good compilers is hard and costs lots of money
And GPU companies, by and large, suck at it. Qualcomm has recently been hiring as many people as they can with compiler experience, but neither AMD nor nVidia has a particularly impressive compiler team. Intel does... but they don't work on their GPU stuff.
Add to that, most modern GPUs also have a variety of coprocessors for things like H.264 decoding. These are quite often licensed as IP cores from a third party, so a company like nVidia or AMD may not even legally be allowed to provide you with their programming interfaces. To make life even more fun for reverse engineers, they don't document where they licensed these coprocessor cores from anywhere, so it's generally very hard to work out who to contact with a request for documentation. This is why open source drivers tend to miss off some of the features of the proprietary ones: once you've reverse engineered the GPU, there's still a load of other stuff left...
I would disagree. The main advantage that humans have over other animals is the scale of cooperation. No other animal is capable of cooperation beyond a family group (a pack or similar). Humans are. To give a counter to your claim that
When two sides of a war have a technical equality, the one willing to perform the most egregious atrocities will be the one to prevail.
Consider the Second World War. The Japanese were willing to perform atrocities far beyond what the allies would consider - genocide or subjugation of entire populations. They lost. And the main reason that they lost was that the allies were willing to cooperate with people that the Axis powers were not. Jewish scientists in Germany were persecuted and fled the country. They were welcomed into other countries and went to work on things like the Manhattan project. The side that fostered the greatest level of cooperation defeated the side that was interested only in the supremacy of a single racial group.
You can find a lot more examples in the last thousand years or so.
No, by this logic government should get out of marriage entirely. If two or more people want to form a legal entity that shares income, asset ownership, and liability then they should be allowed to, irrespective of gender, whether they are engaged in a sexual relationship, or whether they want some religious ceremony. If people want to have a big party when they sign such an agreement and call it a marriage, then that's totally irrelevant to the government.
Increasingly, GPUs are just general-purpose processors that are optimised for a very different set of algorithms to CPUs (i.e. stream-based access to memory instead of lots of locality of reference, primarily floating-point vector data instead of integer data, and few branches instead of about one every 7 instructions on average for CPUs). This means that a GPU driver is increasingly just a compiler. There is a lot less of a reason to keep the details of the hardware instruction set secret, because, as with something like ARM or x86, the valuable bit is how it's implemented, not the instruction set itself. This also means that there's a lot of incentive to keep the in-house drivers secret, because the difference between a bad compiler and a good one can easily be a factor of two in terms of performance with real code and sometimes a lot more.
thats why a DP to VGA connector or DP to dual DVI costs so much in comparison to the basic pinout mapping of the older connections adapters iw DVI-A to VGA
I paid £5 for my miniDP to VGA adaptor. Including delivery. From China. The same supplier also makes ones with VGA, DVI, and HDMI outputs for under £10, although some reviews said they were less reliable than the single-output ones.
Huh, I thought your karma was so bad you weren't allowed to post anymore.
No, you won't have to throw it away, these ports simply won't appear on new equipment. Being able to connect to VGA is still useful for old projectors, but it's no longer sufficiently important to waste board space on it. I bought a mini DisplayPort to VGA adaptor for £5 including delivery. It contains a set of three 10-bit DACs to generate the VGA signal and works well. I take it with me when I'm going to give presentations, but the rest of the time my laptop is quite happy without VGA.
I suppose that if your existing computer dies and you can afford a new computer, but can't afford a £5 adaptor then you may have to throw them away...
The problem is thinking that portability is an all-or-nothing proposition. The choices aren't just 'recompile your codebase for every platform with no porting required' or 'rewrite the entire thing for each platform'. Most software is 90% model, 10% UI, and you can quite easily share the model code between different systems, you just need to rewrite the UI and maybe some of the platform integration code (e.g. accessing the calendar store), which you can do from the rest of the code via a thin abstraction layer.
There's no way of writing code that is portable between iOS and Android
There are several ways. If you want something using exactly the same codebase, companies like Adobe will sell you development platforms that wrap the native APIs and give you something that doesn't quite look or feel native on either. A better approach is to use GNUstep-base to provide an implementation of the Foundation framework on Android and then rewrite your UI for each platform but share the model code.
We've been through this before with desktop apps. If you want a good cross-platform application, make sure that your code uses a very clean MVC separation and rewrite the UI part for each platform. Otherwise you end up with something that, at best, only behaves well on one platform, and at worst feels wrong on all of them.
Picketing the EU Parliament won't do anything anyway. An email from my MEP in December:
Dear constituent,
Last week, EU government ministers agreed to the Anti-Counterfeiting Trade Agreement (ACTA). The agreement can now be signed by the Council Presidency on behalf of the EU. I strongly criticise this decision as concerns persist about the legality of the deal and the implications for fundamental rights.
Plaid Cymru's group in the European Parliament will continue to push for an assessment of the ACTA deal by the European Court of Justice.
Best wishes over the festive season,
Jill
Jill Evans MEP
Plaid Cymru
She's not the only one, but the Parliament can't do anything if the council of ministers decides to ignore it.
The MEP that I voted for campaigns for the FFII and she is part of a coalition that opposes ACTA. Unfortunately, this is being pushed through without the approval of the Parliament.
They see a great deal of benefit. It fulfills the contractual conditions required for them to be able to sell the movie studio's products.
And their costs go up because they need to completely redevelop their entire customer-facing software stack. And, because Silverlight is not really portable, they then have to spend more money on apps for various mobile platforms. This is less money that they have to pay the content providers, so the content providers also lose. The only winners are Microsoft, who get to push their crap on everyone else. Oh, except that Silverlight isn't going to work in the Metro environment in Windows 8 (but HTML 5 video will)...
So then there is no legal remedy for them if they use DRM and someone cracks it and starts handing out their product for free,
Correct.
and no effective legal remedy if they don't even try to stop copying?
Huh? Books that I write are available in a DRM-free format, but they are covered by copyright. If someone is distributing them without my permission (or my publisher's permission) then they are committing copyright infringement. In the USA, they are liable for large statutory fines. The fact that is no DRM does not prevent me from seeking legal remedies.
Plus they get the a **AA kind of reputation if they don't do DRM but do try to chase down copyright violations?
You mean suing individuals for hundreds of times their actual damages? If they do that, they get the reputation that they deserve.
If you object to them using DRM, don't buy their product.
I pay for the service to rent DVDs (which don't have DRM - at least none that isn't so completely cracked that it may as well not exist), the streaming service is bundled with it. I do avoid buying any products that come with DRM.
The company that I rent DVDs from just switched its streaming service over to Silverlight from Flash 'to prevent piracy' because the movie studios required this as a condition of making their work available. This means that I can no longer use it on the machine connected to my projector (running FreeBSD, but could easily be running one of the embedded Linux distributions that various media centres use), nor can I watch it on my TouchPad. I could, however, download pretty much anything that they have available on their streaming service from various illegal sources, without DRM, and watch them online (e.g. copy them to my TouchPad to watch while on the train).
They have lowered the value of the service that they offer me, for no benefit. Want to fix the system? Pass a law that says DRM XOR Copyright. If you, or your authorised distributors, use DRM, then you don't get any protection from copyright.
It wouldn't solve anything if it were a one-off occurrence. If shooting corrupt politicians happened all of the time, then politicians would at the very least try not to appear corrupt. Arresting and imprisoning them would probably work just as well.
Most IPv6 stacks will periodically acquire a new random address, so tracking the IP only gives you the network, just as it does with NAT. More importantly, they are required to support multiple IPv6 addresses, so you can have a static address for all incoming connections and multiple dynamic ones for outgoing connections. If Google gets two connections from different IPv6 addresses on the same subnet, they can't tell whether they're from the same computer or from two different machines (without using some other technique, like browser fingerprinting). Some stacks have a paranoid mode where each new outgoing connection gets a new IPv6 address.
Slashdot Mirror
Perhaps instead you should read the paper that this woman wrote. It lists statistics for the number of pacemaker recalls for software defects, and some of the reasons - pretty scary how poor quality the software is, as many of them would have been caught by even basic testing.
I admit that the fact that it's possible to remotely stop Dick Cheney's heart using simple off-the-shelf hardware seems like it might be a useful feature...
Any safety-critical system in a commercial aircraft is subject to FAA approval. This requires things like multiple independent teams working on implementing the same specification, formal methods employed during the development, and so on. I'm not sure if the FAA audits the code, but I'm pretty sure that they can require a third-party audit. In addition, if a software bug causes an aircraft to crash, the customers' families will sue the airliner and the airliner will sue boeing.
Now, compare that with this case: The software is known to contain remotely exploitable vulnerabilities. The FDA approved the device without doing any code review, or even with access to the code. The FDA's approval means that the manufacturer is not liable for any flaws in the device.
If you watch the talk, you'll see that there are several issues with this:
First, the software is known to be buggy. In fact, it is remotely exploitable. One group found an exploit that lets you remotely control someone's heart rate.
Secondly, because this is approved by the FDA, the manufacturer is exempt from liability for this kind of problem. The FDA does no review of the software at all, but their review of the hardware means that the manufacturer is completely immune to lawsuits if someone dies as a result of a bug in their software.
It's easy to provide a different email address to each one. Lots of people do for spam filtering and there are even third-party sites that will give you a randomly generated email address that forwards to a real one.
It seems to suffer from the problem that all other similar systems do: it makes it easy to tie multiple independent accounts to a single person.
The reason for keeping the instruction set secret is that sure as hell you don't want to get stuck with it.
Why would you be stuck with it? You're stuck with x86 because it was the target for compiled code decades ago. No one is going to be distributing binary code for the latest nVidia or AMD code, at the most they're going to be distributing some kind of IR like PTX, or Gallium IR. Each generation of AMD and nVidia GPU has a different instruction set, and distributing code in binary form for every GPU would be insane (especially since even ones that share an instruction set often have different performance characteristics, so JIT or install/launch-time compiled code will be faster on any random target machine).
As a secondary point, you just as much don't want to be stuck with having to document it.
You have to document it for your compiler team anyway...
Both get even more weight since you don't really want people to know about all the undefined behaviour and sometimes even ridiculous bugs your compiler has to work around.
Why not? CPUs have errata, as do most devices. When was the last time you avoided a CPU or a NIC because of the documented errata that drivers / microcode need to work around?
Which is amplified by that you also don't want your competitors to write a demo that does something ridiculous just to run into one of your bug-workarounds and thus giving horrible performance only one your GPU.
Security through obscurity doesn't work. It's easy to profile binary code on any GPU, find something it sucks at, and write a contrived demo that performs badly on it. It is for CPUs too. This is why no one trusts benchmark suites written by a single vendor. You may remember in the late '90s a certain vendor tried this, and their reputation suffered - reviewers really don't like companies that cheat on benchmarks.
PTX is already a high-level abstraction, but if you use it directly then you are basically stuck with your code only working on nVidia GPUs (or, on a subset of recent nVidia GPUs, depending on which PTX features you use). If you write assembly directly for any given GPU, then you lose portability. This means that 99% of developers won't, because no one will buy a game that requires a specific make and model of GPU (unless it happens to be a model used in a console). For some categories of user, however, that doesn't matter. If you are running a simulation on a 1,000-node cluster of nVidia GPUs and tweaking the assembly can make it 10% faster, then that's the equivalent of buying 100 more nodes for your cluster: a huge saving. The cost in terms of portability is pretty low, because you're probably going to rewrite the code before you get a different cluster anyway.
writing good compilers is hard and costs lots of money
And GPU companies, by and large, suck at it. Qualcomm has recently been hiring as many people as they can with compiler experience, but neither AMD nor nVidia has a particularly impressive compiler team. Intel does... but they don't work on their GPU stuff.
Add to that, most modern GPUs also have a variety of coprocessors for things like H.264 decoding. These are quite often licensed as IP cores from a third party, so a company like nVidia or AMD may not even legally be allowed to provide you with their programming interfaces. To make life even more fun for reverse engineers, they don't document where they licensed these coprocessor cores from anywhere, so it's generally very hard to work out who to contact with a request for documentation. This is why open source drivers tend to miss off some of the features of the proprietary ones: once you've reverse engineered the GPU, there's still a load of other stuff left...
When two sides of a war have a technical equality, the one willing to perform the most egregious atrocities will be the one to prevail.
Consider the Second World War. The Japanese were willing to perform atrocities far beyond what the allies would consider - genocide or subjugation of entire populations. They lost. And the main reason that they lost was that the allies were willing to cooperate with people that the Axis powers were not. Jewish scientists in Germany were persecuted and fled the country. They were welcomed into other countries and went to work on things like the Manhattan project. The side that fostered the greatest level of cooperation defeated the side that was interested only in the supremacy of a single racial group.
You can find a lot more examples in the last thousand years or so.
No, by this logic government should get out of marriage entirely. If two or more people want to form a legal entity that shares income, asset ownership, and liability then they should be allowed to, irrespective of gender, whether they are engaged in a sexual relationship, or whether they want some religious ceremony. If people want to have a big party when they sign such an agreement and call it a marriage, then that's totally irrelevant to the government.
Increasingly, GPUs are just general-purpose processors that are optimised for a very different set of algorithms to CPUs (i.e. stream-based access to memory instead of lots of locality of reference, primarily floating-point vector data instead of integer data, and few branches instead of about one every 7 instructions on average for CPUs). This means that a GPU driver is increasingly just a compiler. There is a lot less of a reason to keep the details of the hardware instruction set secret, because, as with something like ARM or x86, the valuable bit is how it's implemented, not the instruction set itself. This also means that there's a lot of incentive to keep the in-house drivers secret, because the difference between a bad compiler and a good one can easily be a factor of two in terms of performance with real code and sometimes a lot more.
That's what we in the creative industry refer to as an embedded watermark.
thats why a DP to VGA connector or DP to dual DVI costs so much in comparison to the basic pinout mapping of the older connections adapters iw DVI-A to VGA
I paid £5 for my miniDP to VGA adaptor. Including delivery. From China. The same supplier also makes ones with VGA, DVI, and HDMI outputs for under £10, although some reviews said they were less reliable than the single-output ones.
Huh, I thought your karma was so bad you weren't allowed to post anymore.
No, you won't have to throw it away, these ports simply won't appear on new equipment. Being able to connect to VGA is still useful for old projectors, but it's no longer sufficiently important to waste board space on it. I bought a mini DisplayPort to VGA adaptor for £5 including delivery. It contains a set of three 10-bit DACs to generate the VGA signal and works well. I take it with me when I'm going to give presentations, but the rest of the time my laptop is quite happy without VGA.
I suppose that if your existing computer dies and you can afford a new computer, but can't afford a £5 adaptor then you may have to throw them away...
The problem is thinking that portability is an all-or-nothing proposition. The choices aren't just 'recompile your codebase for every platform with no porting required' or 'rewrite the entire thing for each platform'. Most software is 90% model, 10% UI, and you can quite easily share the model code between different systems, you just need to rewrite the UI and maybe some of the platform integration code (e.g. accessing the calendar store), which you can do from the rest of the code via a thin abstraction layer.
There's no way of writing code that is portable between iOS and Android
There are several ways. If you want something using exactly the same codebase, companies like Adobe will sell you development platforms that wrap the native APIs and give you something that doesn't quite look or feel native on either. A better approach is to use GNUstep-base to provide an implementation of the Foundation framework on Android and then rewrite your UI for each platform but share the model code.
We've been through this before with desktop apps. If you want a good cross-platform application, make sure that your code uses a very clean MVC separation and rewrite the UI part for each platform. Otherwise you end up with something that, at best, only behaves well on one platform, and at worst feels wrong on all of them.
Picketing the EU Parliament won't do anything anyway. An email from my MEP in December:
Dear constituent,
Last week, EU government ministers agreed to the Anti-Counterfeiting Trade Agreement (ACTA). The agreement can now be signed by the Council Presidency on behalf of the EU. I strongly criticise this decision as concerns persist about the legality of the deal and the implications for fundamental rights.
Plaid Cymru's group in the European Parliament will continue to push for an assessment of the ACTA deal by the European Court of Justice.
Best wishes over the festive season,
Jill
Jill Evans MEP
Plaid Cymru
She's not the only one, but the Parliament can't do anything if the council of ministers decides to ignore it.
The MEP that I voted for campaigns for the FFII and she is part of a coalition that opposes ACTA. Unfortunately, this is being pushed through without the approval of the Parliament.
They see a great deal of benefit. It fulfills the contractual conditions required for them to be able to sell the movie studio's products.
And their costs go up because they need to completely redevelop their entire customer-facing software stack. And, because Silverlight is not really portable, they then have to spend more money on apps for various mobile platforms. This is less money that they have to pay the content providers, so the content providers also lose. The only winners are Microsoft, who get to push their crap on everyone else. Oh, except that Silverlight isn't going to work in the Metro environment in Windows 8 (but HTML 5 video will)...
So then there is no legal remedy for them if they use DRM and someone cracks it and starts handing out their product for free,
Correct.
and no effective legal remedy if they don't even try to stop copying?
Huh? Books that I write are available in a DRM-free format, but they are covered by copyright. If someone is distributing them without my permission (or my publisher's permission) then they are committing copyright infringement. In the USA, they are liable for large statutory fines. The fact that is no DRM does not prevent me from seeking legal remedies.
Plus they get the a **AA kind of reputation if they don't do DRM but do try to chase down copyright violations?
You mean suing individuals for hundreds of times their actual damages? If they do that, they get the reputation that they deserve.
If you object to them using DRM, don't buy their product.
I pay for the service to rent DVDs (which don't have DRM - at least none that isn't so completely cracked that it may as well not exist), the streaming service is bundled with it. I do avoid buying any products that come with DRM.
Nope, it's entirely accurate. In related news, people who quite my Slashdot posts owe me $1m in lost revenue.
The company that I rent DVDs from just switched its streaming service over to Silverlight from Flash 'to prevent piracy' because the movie studios required this as a condition of making their work available. This means that I can no longer use it on the machine connected to my projector (running FreeBSD, but could easily be running one of the embedded Linux distributions that various media centres use), nor can I watch it on my TouchPad. I could, however, download pretty much anything that they have available on their streaming service from various illegal sources, without DRM, and watch them online (e.g. copy them to my TouchPad to watch while on the train).
They have lowered the value of the service that they offer me, for no benefit. Want to fix the system? Pass a law that says DRM XOR Copyright. If you, or your authorised distributors, use DRM, then you don't get any protection from copyright.
It wouldn't solve anything if it were a one-off occurrence. If shooting corrupt politicians happened all of the time, then politicians would at the very least try not to appear corrupt. Arresting and imprisoning them would probably work just as well.
Most IPv6 stacks will periodically acquire a new random address, so tracking the IP only gives you the network, just as it does with NAT. More importantly, they are required to support multiple IPv6 addresses, so you can have a static address for all incoming connections and multiple dynamic ones for outgoing connections. If Google gets two connections from different IPv6 addresses on the same subnet, they can't tell whether they're from the same computer or from two different machines (without using some other technique, like browser fingerprinting). Some stacks have a paranoid mode where each new outgoing connection gets a new IPv6 address.