How many accidents are due to pilot error (and would not have happened without pilots), and how many accidents did pilots actively prevent from happening? Only if the first is greater than the second, there may be an argument for doing away with human pilots on airliners.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Market share is relevant for reaching critical mass (which is what MS is missing in the phone world). Total market size is relevant for profits.
The operational limits of a robot car are arguably much wider than those of a human.
No fatigue; radar that can see through fog and in the dark; no map reading errors and usually more up-to-date maps (I recall driving using 10 year old paper maps to get around); never taking calls while driving..
Given that operator handoff is most likely to happen either under relatively hairy conditions, or when some system failure has left the automated systems unable to cope,
Euhm... let me get this right... you expect cars to drive automatically, except when it gets difficult or something else unexpected happens it suddenly gives back control to the driver. That's what you mean, right?
Bad idea. Very bad idea. The driver is probably reading the paper, or is dozing off, or otherwise simply not paying attention to the road, as the car is doing the driving and he has nothing to do. He's not supposed to do anything about driving, as the car is in full automatic driving mode. Suddenly asking for attention, then expecting the driver to handle a difficult situation instantly, is asking for accidents. Many more than when the driver was in control already, and possibly sees the situation coming, so anyway has much more time to react.
To allow the driver to fully hand off control to the car, the car should be able to handle it all. The driver assist functions we have available on certain cars nowadays are a great start in working towards full control by the car: now the car will intervene in certain emergency situations, when that's all settled, we can think about giving off control of the rest of the ride as well. For fully automatic drive, the car should not rely on human intervention, ever.
Even if you can account for such things, how will your autonomous vehicle handle malfunctioning sensors? Aerospace has been working at this for decades and still hasn't figured it all out.
Detecting a malfunction in a sensor is hard, really hard. You'll need more than one sensor, preferably different types, to realise there's an error, and then you have to decide which of the contradictory sensor results is the correct one. As naturally sensors will always return slightly different results, you'll have to account for that as well.
So let's say we solved this. Then you know there's a problem. For an autonomous car it's simple: it could decide to continue (minor problem), or stop (e.g. tyre blow-out or other major problem that makes it unable to continue, or simply "I don't know how to handle this situation, so I pull over to the side of the road and stop to have my human overlords sort it out"). In the second scenario an automated call to the repair service could be included, so the human(s) in the car can continue to sleep while it's being fixed and after that be sent on their way again.
An airplane doesn't have this fail safe stop option, and needs to have human overlords present at all times to take control if something happens the programmers didn't foresee.
For a user, the UI is the OS.
"... and provide an experience very much like the desktop"
Or does this mean that the desktop gets a phone-type experience again, like on Win 8?
For both those numbers to be true Apple must be making about 40 times more profit per sale than Android.
And that wouldn't surprise me at all.
Samsung is massively profitable - but almost certainly their margins are lower than Apple's - if only because they develop about ten models for every one Apple model. After all, Apple just has iPhone in two, three incarnations, while Samsung has a whole lineup of phones.
Secondly, there are many, many companies in the Android phone market, many of whom must be loss making. It's just impossible with all that competition for all to be really profitable. That "compensates" for the high profits of Samsung, and pushes the whole Android segment down.
Please read the thread before you reply.
This was about firmware images provided on the web site of the manufacturer. Not about reading/modifying the firmware of a drive - which indeed we know is possible by design (otherwise this whole discussion would be pointless to begin with).
As many already pointed out: you can not trust the firmware image provided by the drive itself, for the simple reason that you have to talk to the very firmware you try to verify, and which may be compromised.
Think of the kid calling "are there any monsters under the bed?", and the monster under the bed answering "no!".
If you don't have proper reading comprehension skills, you are unqualified to reply.
No-where did I try to say it's not a big deal.
Copying some data is quite different from replacing data, and far easier to do unnoticed. The NSA copied existing SIM encryption keys; they did not attempt to replace them with their own keys or so.
It is pretty hard to detect an intrusion, access to data, and copying of that data. Especially if the attacker gets access through an authorised account by getting their hands on someone's login credentials.
It is much easier to detect the replacement of data: this can be done with e.g. automated cryptographic checksum tests against remotely stored known good checksums, or against a freshly compiled copy.
A lot of data will have to be replaced unnoticed (source code is being read by humans, who may detect changes if it happens to be the part they work with) to stand any chance of getting a compromised binary on someone else's site unnoticed.
I doubt you need much, really.
All the malware part has to do is to read the rest of the software from disk upon boot, then hide that part of the drive from the OS. This way you could hide a pretty big piece of software on the disk, and with today 500 GB kind of capacities being the norm, the user won't notice unless they look really really carefully at the numbers.
How can you even know if the code you download off the manufacturers' web sites hasn't been tainted during production?
You can't, but you can be quite sure that the manufacturer will take serious measures to make sure this doesn't happen. This protection against tampering to compromise computers just piggybacks on more general protections to keep firmware sound, such as tests to make sure there are no bugs in the firmware that cause data loss, and that software published on the web site is the software the company intends to publish.
This for the simple reason that one mistake here may result in bankruptcy, as people may lose trust in the whole company. Without trust in its products by its customers, a company can't survive - especially when it's about storing valuable data.
Most likely there are no such tools as no-one thought it could be a vector of infection. Just like the BIOS; which used to be a non-reprogrammable ROM chip. I for one didn't know current hard drives even had firmware that can be replaced by the user, let alone that it may be a potential attack vector for malware.
Depending on how hard it is to read the installed firmware from a hard drive (is this even possible in the first place?) it shouldn't be too hard to write a tool that can read the firmware, and calculate a checksum for verification. The hard part is going to be, how do you know that your software gets the actually installed firmware - or just a known good but inactive piece of code provided by a compromised firmware, pretending that this is the software that's installed? The moment a firmware is installed, you probably need to call onto that very firmware to get a copy of it from the drive. Unless this read-firmware routine is provided by a special, hard coded circuit.