I agree with others that this problem skinks of an electrical/software issue.
Drive-by-wire can be made safe. All fighter jets made since the 70s have been fly-by-wire. Their airfoils are inherently unstable (unstable airframes are more maneuverable) and computers keep the plane from flopping out of the sky. The yolk is a glorified joystick talking to a computer which controls the flight control surfaces. Some aircraft even have programs for recovering from various emergencies (stall, flat-spin, etc).
I believe most comercial aircraft are fly-by-wire too, and I know all the Airbus planes are.
Doing fly-by-wire safely is done with a lot of very expensive QA, correctness proofs and redundancy. If I remember right, all or most planes with fly-by-wire have 3 computers that all vote on how to move the control surfaces. Those 3 computers' software is created in 3 completely separate groups in hopes that 2 groups won't have the same bug. The voting system means a software single glitch or hardware failure doesn't result in a crash.
I really doubt Toyota (or any other car manufacturer) is putting that much effort into their embedded computers. Hopefully this recall forces manufacturers to think more critically of these systems.
I absolutely agree, but I'd still like a kill-button on my car (ie, ignition switch), and brakes should have a physical backup in worst-case-scenario. And, frankly, I don't trust any one company to do it right; it's the sort of thing that's ideal to make really public, so others can spot problems before they happen.
The ejection seat in those fighter jets aren't exclusively by-wire, last I checked, though they're probably enhanced somehow (not implying I'm an expert on fighter ejection seats, though). Your ultimate-backup should ALWAYS be an independent, simple, physical system that effectively cannot go wrong.
Sure, if you're willing to spend 70 million dollars on a car.
Snarky one-liners aside, this hits on one of my pet peeves: software quality. I mean, there's no reason why my IDE should die every time it tries to open a .sql file bigger than about 500K, but it does; there's no reason why MacOS X shouldn't have a "refresh" command in its Finder views, but it doesn't; there's no reason why I have to bang my head against software issues every single day, but I do.
So, while the optimistic technologist in me would like to see what cars could do with more advanced computer-controlled systems, the experienced and pragmatic technician in me is really not looking forward to it.
there's no reason why MacOS X shouldn't have a "refresh" command in its Finder views
What would you use it for? It already updates in less than a second. If you're looking for extremely up-to-date info, you're probably not a "Finder-only" user, and know how to use the terminal, so use that.
OSX is tiered, it doesn't give you all options at the simplest level, which is a HUGE reason for its success. Correctly so, IMO. No option overload, it "just works". Want more control? The terminal is right there. Learn how to use it and you'll pick up better practices than mashing the refresh button. (not implying you are, just making a general statement)
The Finder frequently loses sync over Samba networks; the "updates in less than a second" doesn't work perfectly (or even really all that well in a lot of cases).
The only fix for such a situation is to restart the Finder.
I don't see how Command-R wouldn't be a better solution.
Incidentally, I'm far from the only technician dealing with mixed environments on a daily basis that's had this complaint.
Samba networks do that for me on Windows too, despite the ability to refresh the window. More often, it'll crash Explorer rather than actually update the info if something is already clogging the tubes. Plus, network shares almost never update that quickly, and expecting them to do so is rather ridiculous. Round-trip time to a server clearly wasn't implied as part of the Finder update speed.
And again, I'll point out that the terminal is right there. If it's Finder that's slow, the terminal will still work. If the terminal doesn't keep up-to-date, then it's a problem with their implementation of Samba, not Finder, and a refresh button would do nothing (except maybe nail your network with unnecessary requests by most people mashing it when something doesn't work).
Well, I guess we can continue to dicker about the relative merits of a "Refresh" command in the MacOS X Finder, except:
1) It's not just Samba networks, it's other things too, up to and including 10.5 [1].
2) People have gone to the trouble to write Applescripts to do the job for them. [2]
3) "Just use Terminal" does not justify a broken auto-update system, which...
4) ...is all fine and dandy when it works, but really needs some kind of sensible fall-back system when it doesn't, which...
5) ...brings us to the original point, which was that continuing to integrate software of this quality into automobiles, without manual override systems, is just plain stupid.
So, would you like to continue to beat this dead horse?
Drive-by-wire can be made safe. All fighter jets made since the 70s have been fly-by-wire. Their airfoils are inherently unstable (unstable airframes are more maneuverable) and computers keep the plane from flopping out of the sky. The yolk is a glorified joystick talking to a computer which controls the flight control surfaces. Some aircraft even have programs for recovering from various emergencies (stall, flat-spin, etc).
I believe most comercial aircraft are fly-by-wire too, and I know all the Airbus planes are.
Doing fly-by-wire safely is done with a lot of very expensive QA, correctness proofs and redundancy. If I remember right, all or most planes with fly-by-wire have 3 computers that all vote on how to move the control surfaces. Those 3 computers' software is created in 3 completely separate groups in hopes that 2 groups won't have the same bug. The voting system means a software single glitch or hardware failure doesn't result in a crash.
I really doubt Toyota (or any other car manufacturer) is putting that much effort into their embedded computers. Hopefully this recall forces manufacturers to think more critically of these systems.