Yep, we're quickly going back to the days of Compu$erve.
This outcome was decided most firmly in the realm of the Law, by the Court system, and with not one pip of say-so from the programming or engineering community which actually runs and maintains the web.
The programming and engineering communities have no power whatsoever in this society, at least in the US. In the US at least, the lawyers have all the power.
No, proper regulation avoids regulatory capture by enacting laws which forbid it. Other countries don't have a problem enacting and enforcing proper regulation while avoiding regulatory capture. It's just the US (along, probably, with various other corrupt third-world regimes) that has this problem.
If there were no "daddy government", there wouldn't be a ComCast. Corporations exist because of government-made laws; in an anarchy, there are no corporations.
The problem is that our government is totally corrrupt and inept. What we need is a different government, which enacts and enforces proper regulation, like every decent industrialized country in the world.
Losses in man hours world wide, not to mention outages that get extended, while someone has to Google where their tools went, cost the world far more money than MS makes selling the OSs.
Why should MS care about how much money it costs the world? As long as they're profiting handsomely, that's all that counts.
It would be fun to see someone do the math and calculate how many trillion dollars "upgrading" to Windows 2012 will cost the world.
Yet people and companies continue to happily fork their money over to MS, despite all the pain and trouble it causes them.
It's weird how people will happily accept abuse and will even come back, asking for more.
I have no idea. It probably depends on the vehicle. If they implemented it in a smart way, it'd be done with a small microcontroller (like a PIC or AVR) that isn't doing anything else. The assembly code for this would be pretty simple, even if it had some CANbus communication with the ECU.
- Toyota cars have a push to start button that is also a push and hold to stop button. So how do you stop the car quickly? Shouldn't a car that has push-button start, also have a push-button stop, that is a different button and works quickly? Why would Toyota follow the Microsoft standard of using a start button to stop, instead of following the very well thought out emergency stop button standards?
Don't blame this one on Microsoft. With MS, you have to press the "start" button, then select some drop-down box and select "power off" (or "restart", etc.).
They probably got this from the ATX computer standard. If you're old enough, you may remember that computers (back in the XT and AT days) had on-off power switches that did just that. You flip the lever up to turn it on, then flip it down to turn it off. Of course, this made it impossible for the computer to power itself off (or to power itself on with wake-on-LAN), so when the ATX standard came out, they switched to a front-panel on-off pushbutton: you press it once to turn it on, then press and hold for 3 seconds to turn it off.
Today's push-button-start cars have merely adopted the 20-year-old ATX computer standard. (And for all I know, the ATX people might have gotten it from somewhere else.)
In Canada, the public is protected from such software bugs by statute, in the same way the public is protected from medical screw ups: a professional engineer is required by law to write any software code where safety is on the line
Bullshit. This is completely false.
Source: Canada imports most its cars. You really think Canada requires Japanese and German car companies to have all their code written in Canada by professional engineers registered with "PEO"?
Canada doesn't even have any car companies. Any such law is pointless if companies are just going to import stuff that was engineered outside the country.
You press the start button and hold it for several seconds to turn it off.
I do agree, it sucks compared to a regular key-switch that you just turn off without having to wait, but it's not true that you can't turn the engine off. It's just like the ATX power button that computers have had for about 20 years now.
It does seem like it wouldn't be a bad idea to add in an override switch if you have one of these cars, so you can instantly turn off the engine if you need to (the switch would turn off power to the main relay).
Sorry, but you obviously don't work under DO-178 standards. #3 is still in use in highly-reliable systems (or part of it; you can allocate memory, you just can't ever free it. So you allocate all your memory at the beginning of program execution, and everything stays static after that). I don't remember anything about #2 however.
These aren't the result of budget restrictions; these same rules (#1 and #3 again, I think #2 is an error or something) are used currently on commercial and military aircraft.
We can't have driver ed in this country; it's against the philosophy people here have. My driver test, for instance, consisted of three right turns (from parking lot in the corner of two streets into a street, right turn onto next street, right again back into the parking lot), and then parking. That's it. There is no serious driver training or testing in this country, and there never will be.
Cars need to be engineered to be absolutely fault-tolerant and reliable, and yes, that means the same redundancy in a 4 passenger car as for a 400 passenger plane. There's many orders of magnitude more cars built than planes, so the costs will be miniscule. We already require every new car to have tire pressure monitoring, traction control, and yaw control, plus multiple airbags. If we can afford all that complexity, we can afford a couple extra sensors and some more rigorous testing (and DO178 coding standards) on embedded computers.
In addition, you want to be able to turn on the A/C even in the winter, because it'll defog the windshield faster. (This is more helpful when the engine is cold and the engine heat isn't working.)
Hate to be nit-picky here, but that's not true. It's a great idea to not use malloc() in a real-time application, for reasons of performance. But it can't overflow the stack.
You're right about the stack, but you're wrong about the reasons to not use it. Dynamic allocation is forbidden in any decent (safety-critical) real-time application because it's non-deterministic. Anything which isn't deterministic is eliminated or minimized as much as possible. This also includes CPU caches.
What about the public servants here in New York and New Jersey who closed off all but one lane on the George Washington Bridge during rush hour as political payback to a Democrat-voting district on one side of the bridge? Were they "doing work for the good of us all"?
Sounds like they should dump the old vacuum-assisted brakes and move to some type of electric assist, or perhaps just adding an electric vacuum pump rather than bleeding engine vacuum.
If the power is off, the electric fuel pump will stop running. Even if the diesel isn't using electronic fuel injection (which means it's ancient), it still needs fuel to run.
If the problem is that a sensor can fail with catastrophic results, the simple answer is to add redundancy: add a second sensor, and if the two disagree, shut down. Or add a third and use a voting algorithm.
Killing the ignition also means killing power steering and power braking.
No, it doesn't.
Yes, you do lose your power steering without the engine, IF you have hydraulic power steering. If you have a newer car with EPS (electric power steering), this may or may not be the case. I don't really know, but at least in the older cars I drive when you turn off the ignition you can turn the key back to "on" and all your electic power accessories will continue to work even though the engine is not running.
Anyway, it doesn't matter that much. The only time power steering is all that helpful is when you're driving at speeds under 10mph, i.e. in a parking lot. You don't need it at higher speeds. If you just need to pull over on a highway, you should be able to do that just fine without power steering.
For braking, you're completely wrong. Power brakes are driven by vacuum. So even if you kill the engine, you still have enough vacuum built up to apply the brakes once, which is all you need to bring it to a stop.
That's bullshit. 747s are expensive because the high cost of those avionics systems (among many other things) is only amortized over a tiny number of units. They don't make millions of 747s, they make dozens. Cars are made in huge volumes, plus components like ECUs and ABS controllers can be shared across many different models with few or no changes. These components absolutely should be made to aviation standards, by law (at least the software part should be; the hardware doesn't have to be quite as rugged since cars don't go to 60,000 feet and back several times a day). The cost will be insignificant to each car when they're making millions of them.
Because it has the potential to overflow the stack. It's not the only thing that should be forbidden; exception-handling is another one, as is dynamic allocation, and also CPU caches. If you're using any of these things in a mission-critical embedded system, you're doing it wrong.
When it comes to true high-rel software, like that written to DO-178B Level A (an avionics software standard used for things like fly-by-wire) it's almost never the software per se that's at fault. The stuff is amazingly good. It's also amazingly expensive to write and test. You might also find it frustrating because it brings new meaning to the idea of conservative design. For example, I don't think it allows recursion. I know it doesn't allow dynamic allocation.
That's correct. Neither recursion nor dynamic allocation are allowed. C++ is only barely allowed (it's pretty new at this point), and even there most of the C++ features are not allowed: no dynamic allocation (you can never delete an object), no exception-handling, etc. The operating systems used are extremely simple real-time OSes where every timeslice is planned for, and there's no preemptive multitasking (only cooperative). Basically, everything is made to be as deterministic as possible, and anything that reduces determinism is forbidden.
Another big point: caches are not allowed. So all on-CPU caches are disabled. You can imagine what this does for performance. Caches are bad, because they are non-deterministic (it's too hard to predict how long something will take to run, because you don't know if you'll have a cache hit or not).
Slashdot Mirror
Yep, we're quickly going back to the days of Compu$erve.
This outcome was decided most firmly in the realm of the Law, by the Court system, and with not one pip of say-so from the programming or engineering community which actually runs and maintains the web.
The programming and engineering communities have no power whatsoever in this society, at least in the US. In the US at least, the lawyers have all the power.
No, proper regulation avoids regulatory capture by enacting laws which forbid it. Other countries don't have a problem enacting and enforcing proper regulation while avoiding regulatory capture. It's just the US (along, probably, with various other corrupt third-world regimes) that has this problem.
If there were no "daddy government", there wouldn't be a ComCast. Corporations exist because of government-made laws; in an anarchy, there are no corporations.
The problem is that our government is totally corrrupt and inept. What we need is a different government, which enacts and enforces proper regulation, like every decent industrialized country in the world.
Losses in man hours world wide, not to mention outages that get extended, while someone has to Google where their tools went, cost the world far more money than MS makes selling the OSs.
Why should MS care about how much money it costs the world? As long as they're profiting handsomely, that's all that counts.
It would be fun to see someone do the math and calculate how many trillion dollars "upgrading" to Windows 2012 will cost the world.
Yet people and companies continue to happily fork their money over to MS, despite all the pain and trouble it causes them.
It's weird how people will happily accept abuse and will even come back, asking for more.
I don't have problems with dropped calls on my cellphone, at least not at work (maybe if I go out in the boonies somewhere, but that's not often).
Why do I need features like transfer, hold, or conference if I'm making a personal call?
I have no idea. It probably depends on the vehicle. If they implemented it in a smart way, it'd be done with a small microcontroller (like a PIC or AVR) that isn't doing anything else. The assembly code for this would be pretty simple, even if it had some CANbus communication with the ECU.
Who would use a company phone to make personal calls in this day and age anyway? Doesn't everyone have a cellphone now?
- Toyota cars have a push to start button that is also a push and hold to stop button. So how do you stop the car quickly? Shouldn't a car that has push-button start, also have a push-button stop, that is a different button and works quickly? Why would Toyota follow the Microsoft standard of using a start button to stop, instead of following the very well thought out emergency stop button standards?
Don't blame this one on Microsoft. With MS, you have to press the "start" button, then select some drop-down box and select "power off" (or "restart", etc.).
They probably got this from the ATX computer standard. If you're old enough, you may remember that computers (back in the XT and AT days) had on-off power switches that did just that. You flip the lever up to turn it on, then flip it down to turn it off. Of course, this made it impossible for the computer to power itself off (or to power itself on with wake-on-LAN), so when the ATX standard came out, they switched to a front-panel on-off pushbutton: you press it once to turn it on, then press and hold for 3 seconds to turn it off.
Today's push-button-start cars have merely adopted the 20-year-old ATX computer standard. (And for all I know, the ATX people might have gotten it from somewhere else.)
In Canada, the public is protected from such software bugs by statute, in the same way the public is protected from medical screw ups: a professional engineer is required by law to write any software code where safety is on the line
Bullshit. This is completely false.
Source: Canada imports most its cars. You really think Canada requires Japanese and German car companies to have all their code written in Canada by professional engineers registered with "PEO"?
Canada doesn't even have any car companies. Any such law is pointless if companies are just going to import stuff that was engineered outside the country.
You press the start button and hold it for several seconds to turn it off.
I do agree, it sucks compared to a regular key-switch that you just turn off without having to wait, but it's not true that you can't turn the engine off. It's just like the ATX power button that computers have had for about 20 years now.
It does seem like it wouldn't be a bad idea to add in an override switch if you have one of these cars, so you can instantly turn off the engine if you need to (the switch would turn off power to the main relay).
Sorry, but you obviously don't work under DO-178 standards. #3 is still in use in highly-reliable systems (or part of it; you can allocate memory, you just can't ever free it. So you allocate all your memory at the beginning of program execution, and everything stays static after that). I don't remember anything about #2 however.
These aren't the result of budget restrictions; these same rules (#1 and #3 again, I think #2 is an error or something) are used currently on commercial and military aircraft.
We can't have driver ed in this country; it's against the philosophy people here have. My driver test, for instance, consisted of three right turns (from parking lot in the corner of two streets into a street, right turn onto next street, right again back into the parking lot), and then parking. That's it. There is no serious driver training or testing in this country, and there never will be.
Cars need to be engineered to be absolutely fault-tolerant and reliable, and yes, that means the same redundancy in a 4 passenger car as for a 400 passenger plane. There's many orders of magnitude more cars built than planes, so the costs will be miniscule. We already require every new car to have tire pressure monitoring, traction control, and yaw control, plus multiple airbags. If we can afford all that complexity, we can afford a couple extra sensors and some more rigorous testing (and DO178 coding standards) on embedded computers.
In addition, you want to be able to turn on the A/C even in the winter, because it'll defog the windshield faster. (This is more helpful when the engine is cold and the engine heat isn't working.)
Hate to be nit-picky here, but that's not true. It's a great idea to not use malloc() in a real-time application, for reasons of performance. But it can't overflow the stack.
You're right about the stack, but you're wrong about the reasons to not use it. Dynamic allocation is forbidden in any decent (safety-critical) real-time application because it's non-deterministic. Anything which isn't deterministic is eliminated or minimized as much as possible. This also includes CPU caches.
Very interesting. So why is Toyota not following MISRA C coding standards?
What about the public servants here in New York and New Jersey who closed off all but one lane on the George Washington Bridge during rush hour as political payback to a Democrat-voting district on one side of the bridge? Were they "doing work for the good of us all"?
Sounds like they should dump the old vacuum-assisted brakes and move to some type of electric assist, or perhaps just adding an electric vacuum pump rather than bleeding engine vacuum.
If the power is off, the electric fuel pump will stop running. Even if the diesel isn't using electronic fuel injection (which means it's ancient), it still needs fuel to run.
Throttle-by-wire is necessary for traction control, which is a standard feature these days (maybe required by law, I'm not sure).
Easy: you add redundant sensors and compare the results.
If the problem is that a sensor can fail with catastrophic results, the simple answer is to add redundancy: add a second sensor, and if the two disagree, shut down. Or add a third and use a voting algorithm.
Killing the ignition also means killing power steering and power braking.
No, it doesn't.
Yes, you do lose your power steering without the engine, IF you have hydraulic power steering. If you have a newer car with EPS (electric power steering), this may or may not be the case. I don't really know, but at least in the older cars I drive when you turn off the ignition you can turn the key back to "on" and all your electic power accessories will continue to work even though the engine is not running.
Anyway, it doesn't matter that much. The only time power steering is all that helpful is when you're driving at speeds under 10mph, i.e. in a parking lot. You don't need it at higher speeds. If you just need to pull over on a highway, you should be able to do that just fine without power steering.
For braking, you're completely wrong. Power brakes are driven by vacuum. So even if you kill the engine, you still have enough vacuum built up to apply the brakes once, which is all you need to bring it to a stop.
That's bullshit. 747s are expensive because the high cost of those avionics systems (among many other things) is only amortized over a tiny number of units. They don't make millions of 747s, they make dozens. Cars are made in huge volumes, plus components like ECUs and ABS controllers can be shared across many different models with few or no changes. These components absolutely should be made to aviation standards, by law (at least the software part should be; the hardware doesn't have to be quite as rugged since cars don't go to 60,000 feet and back several times a day). The cost will be insignificant to each car when they're making millions of them.
Because it has the potential to overflow the stack. It's not the only thing that should be forbidden; exception-handling is another one, as is dynamic allocation, and also CPU caches. If you're using any of these things in a mission-critical embedded system, you're doing it wrong.
When it comes to true high-rel software, like that written to DO-178B Level A (an avionics software standard used for things like fly-by-wire) it's almost never the software per se that's at fault. The stuff is amazingly good. It's also amazingly expensive to write and test. You might also find it frustrating because it brings new meaning to the idea of conservative design. For example, I don't think it allows recursion. I know it doesn't allow dynamic allocation.
That's correct. Neither recursion nor dynamic allocation are allowed. C++ is only barely allowed (it's pretty new at this point), and even there most of the C++ features are not allowed: no dynamic allocation (you can never delete an object), no exception-handling, etc. The operating systems used are extremely simple real-time OSes where every timeslice is planned for, and there's no preemptive multitasking (only cooperative). Basically, everything is made to be as deterministic as possible, and anything that reduces determinism is forbidden.
Another big point: caches are not allowed. So all on-CPU caches are disabled. You can imagine what this does for performance. Caches are bad, because they are non-deterministic (it's too hard to predict how long something will take to run, because you don't know if you'll have a cache hit or not).