Why did they go for this expensive solution? so that they could should at someone, demand support and sue someone if the shit hits the fan. With OpenSource the only one liable for fuckups
The problem with that logic is that expensive solutions can be abandoned on a whim. The supplier can make a simple business decision, they can go out of business, or taken over by a competitor. Depending on the contract, is it a term license or a perpetual license? Is the software dependent on other peoples code? With proprietary software, you can be locked out at any moment.
Additionally, have you ever actually tried to get a software company to pay out on a law suit for defective code? It is almost impossible. Check the disclaimers in the contracts.
Some of the ISO-9001 knowledge becomes very long-lived. Stick to things that will work for a very long time. It is not uncommon to see ISO, software, CAD, and project documentation files from 25 years ago. Having to support DOS PCs for legacy projects sucks.
Think about whatever software you use, and make sure it is formed around standards that will persist. For instance, does SharePoint depend on Microsoft Internet Explorer? Is Microsoft Internet Explorer V9 compatible with Internet Explorer V6? Take a look at all the other legacy software inside your organization dependent on Microsoft IE V6. Don't do it again.
In the end, there is a strong argument for keeping PDF, DOC, and XLS files around, and placing a version control system on them. Some systems, try to integrate the entire quality control system into a document management system, and the results cannot be maintained long-term. One expensive system that I deployed, didn't survive the 24-month rollout process. You need to stick to standards, and keep your options open, both short and long term.
This reminds me of the "slowest ever compiler" paper. The compiler generated very unusual and fast code, but the compile time was O(256^n) with n being the bytes of code generated. Essentially, the compiler had two algorithms. A random number generator that generated the code, and a verification algorithm that verified the code was correct. The program then selected the fastest of the randomly generated code vectors as its final output.
You could describe this as the ultimate "Monte-Carlo" compiler. The general idea of randomly testing optimization variables is not new, and is used frequently in other simulation tasks where the designer might not properly understand the impacts of the model parameters. In other fields, it is a variation on "Design of Experiments", DOE, with randomized variables. If you look in the Numerical Methods in C/Fortran books, there are many optimization techniques, structured and monte-carlo, that can be used to optimize systems without a thorough understanding of the input space.
If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.
Precisely. Otherwise, you are always open to a sufficiently sophisticated man in the middle attack.
It may very well have been that the math teaching was so bad in that particular case that no teaching worked better than teaching math badly.
I tend to agree. The overwhelming majority of elementary school teachers are neither math nor science majors. It is quite likely the teachers don't understand the reasons for the math theory. They just know it should be taught. As such, they are not likely to be using approaches that relate the theory in ways that people (kids) would understand it. It is humbling to have a PhD in Engineering, and not be able to understand Grade 6 math homework. If I can't understand the lessons they are trying to teach with regards to digits and digit placement, then what chance do the Grade 6 kids have?
On another occasion, while in first year Algebra, I vividly remember suddenly understanding key concepts from Grade 7 math. For instance, why does one care that numbers have the distributive, associative, and commutative properties? that can be named and explained? The knowledge is not helpful until vector and matrix math is covered. At that point, data types exist where the associative and commutative properties may or may not apply.
I'm just not sure what is the point of introducing concepts to children, without the ability to explain the reasons for the concepts. Why teach math, with no text book? Why focus so much on obscure terminology, to the point that no one understands why you are even asking a question? Math is about understanding why things happen. Not wrote answers to naming conventions.
This list could go seriously wrong when responding to emergencies. It's virtue is that it is a great list for a triage assessment at hospitals. A trained triage nurse could use it to call codes, after quickly examining a patient in front of her. Yellow is "> 5 min", Red is "possibly dead in 5 min", Purple is "almost / already dead", and Green is "No Hurry".
A 911 operator (or a 999 operator) is communicating with paniced people without medical training. These people will not be able to give a "medically accurate" descriptions. For instance, the list differentiates between Cardiac Arrest, Chest Pain (Non-Traumatic), and Abdominal Pain. It even includes Abdominal Pain "not alert" as a yellow, and Chest Pain "not alert" as Red. I don't think the average caller can tell the difference, and some patients will die before anyone figures it out. I'm not sure what the emergency response times are in Swansea, but if you spend more than 60 seconds on the phone debating if a person is Red, then you will be losing a measurable percentage of the Red patients.
The building fire section is also a bit strange. If you have a building on fire, with people reporting it (visual identification), if people are in the building, you have to role an ambulance. Don't wait until the occupants are out of the building, before escalating the call. Do you need 5 people unconscious on the lawn before deciding it is a Code Red (multiple victims)?
Triage lists for 911 / 999 response must be based on what paniced people can communicate. For example: Is the person breathing? Are they conscious? Do you see smoke/flames? Are people in the building? People can answer these questions quickly.
Her husband called 999 and the ambulance at first refused to come because it wasn't a life-threatening emergency.
I must be missing something here. Where I live, if you call for an ambulance, it comes. If something serious is going on, call the fire department and the ambulance, because the fire department has a quicker response time. There is no option for "not show up". Some injuries (like concussions) don't look like emergencies immediately. As such, the procedure is to get you to the hospital, and have the nurses and doctor's deal with the situation.
Sure, if you call an ambulance over a stubbed toe, then the ambulance guys will send you a bill for the ride to the hospital, and the police might charge you for wasting everyone's time. However, the ambulance, police and fire will show up.
Do the ambulances in England have an option to refuse to come in an acute, emergency situation? involving major fractures? dislocations?
If the hardware or system I deploy on doesn't meet spec, it isn't a bug--it's user error. If my compiler, or the microcode it runs on top of have a failing--it's not a bug, it's a vendor failure. Admittedly, the user will never know the difference. But the purchaser should.
These are safety critical user-interfaced systems, and people are dying. It doesn't matter who caused the issue or why. It matters that the purchaser lives to be told about the problem.
You go and throw 5 amps over a 10 milliamp input device, and there'll be magic smoke. You throw 20 over it, and maybe it will start lying to you as it de-calibrates... but those are hardware failings, and also out of spec.
You cannot depend on the hardware performing to specification. If I put 5 amps on a 10 milliamp output, does that mean it will turn on? turn off? turn on then off? turn on until the power is toggled, then appear to work normally, and then turn on by itself at a later time? Will the 5 amps bypass to a power supply, and affect other inputs? Will the system clock oscillator continue to function? properly? Will the analog inputs continue to function properly? Will the power bypass into the Flash EPROM fusing on the watchdog circuit, and disable the hardware watchdog circuit?
What makes safety systems hard, is acquiring detailed knowledge of how the systems fail. Normally, this information is not part of any specification. The result is that in many embedded systems, no one knows for sure what happens when failures start occuring. You have to design embedded systems with the assumption that when failures occur, failures are happening. What does it mean to the software when the hardware is not working correctly? For most practical applications, software is completely dependent on the hardware performing to a specification, and only in the best predicted, most optimistic, and most common failure scenarios, will the hardware meet specification. Design software accordingly.
It's called Haskell with QuickCheck, idiots! Look it up!
And yes! It gives you guarantees on the level of mathematical proof, that it's doing what it's supposed to do!
Software developers that think the cause of most severe software failures is purely software, are the source of many of these software bugs.
The nasty bugs all revolve around complex system interactions, that just happen to involve software. No amount of Haskell code can fix them. Don't believe the marketing hype. Software bugs will be with us, long after the introduction and widespread use of functional programming.
Additionally, it isn't even obvious in a complex environment like an engine, that Haskell's sequential monad order for external I/O is both applicable and correct. Welcome to the modern micro-controller, where I/O sequencing is no longer a function of sequence of program execution.
What bizarre torturous form of "love" demands that you keep dying (sometimes zombified) people in struggling in pain until their last breath?
It is hope. People hope to see their relative healthy again. They remember seeing a person healthy. They miss it, and they want to see it again.
Unfortunately, some of the treatments are ineffective. They might extend life, but they will never restore health. Medical procedures are graded by mortality rate over periods of time. Ex: 50% survival at 5 years. The goal needs to be different. Effectiveness should be judged by time outside the hospital without extensive medical intervention. 50% of the time, this procedure gets you 3 more years with your family. A subtle and significant improvement.
Police are allowed to participate in a ruse to gain the trust of a suspect.
Make no mistake. You were a suspect in a murder case, until cleared. In a police investigation, everyone is a potential suspect. As such, be careful what you volunteer, because until proven otherwise, you are a suspect and can be lied to.
Really? On my newish car (2003) shifting in first at speed would mean conrods flying out of the block and into my face.
You might be surprised. Get a rental car and try it out. My car, a 2003 domestic, will actually *upshift* in low gear. All the Ford and GM cars that I have tested, are set to automatically upshift and downshift to keep the engine revs inside the limits, regardless of gear shift position.
There is a deliberate engineering reason why this happens. The car manufacturers don't want to pay the warranty costs of someone accidentally doing a bad shift with an automatic transmission. As such, Ford and GM use the automatic transmission as a form of a rev limiter. It reduces warranty costs from engine repairs.
Disclaimer: This only works with some models. It does not apply to cars with manual transmissions. It does not apply to performance sports cars. For instance, a Ferrari with a paddle shifter, will shift as commanded.
The clutch is fairly reliable (assuming it is being maintained). Additionally, people use the clutch to drive. They know how to use it, and keep it maintained.
This is not the case for neutral in an automatic transmission. The neutral position is increasingly fly-by-wire. I wouldn't bet on an automatic transmission disconnecting engine power under *fault* conditions. Also, people don't use the neutral position, so it isn't obvious to me that most people really understand it. It can fall out of alignment, and people might not notice the problem and have it fixed. One report has the driver putting the transmission into Reverse, and the transmission still applying full forwards power to the rear wheels. Essentially, putting the transmission into any other gear other than drive and overdrive should limit the cars maximum speed to 50 km/h. Modern transmissions just don't do this. Try throwing an old car into neutral, or new car into first at full speed. On *some* cars, nothing happens...
Currently, the key-start circuit cuts power to a significant portion of the engine controls. There is no way the engine can run, unless the ignition switch fails shorted. However, you are right. With modern technology, the ignition switch could be made fly-by-wire. If the car was an industrial machine, this would be a severe breach of protocol. Actually, for industrial machinery standards, the current ignition switch would not be considered a sufficient safe-disconnect device. However, it is a car. There is no specific legislative requirement for an off switch. As such, why keep an off-switch???
Many other manufacturers have already added a similar piece of code. It really doesn't take to long to debug an interlock. Your primary failure mode will be: if the brake pressed switch fails (ie: the tail lights are stuck on), then the car won't run.
Every interlock has a strong tendency to fail into the safe state. Conversely, omitting interlocks tends to result in fail-dangerous failures, which is what Toyota is experiencing.
GM outsourced an entire R&D division to Canada about 10 years ago. They lowered the cost of real estate, took advantage of a lower Canadian dollar to have lower labour costs, and the health insurance costs were much less. Plus, Canada is close enough to America that they can be sent to Detroit or wherever in the U.S. they needed to go, whenever the situation required it.
If it works for the little guys, it works even better for the big guys...
If I were the U.S., I would hire as many foreign IT workers as possible. They are not that many of the really good IT workers being graduated in the entire world. If you move all the workers to the U.S., then the U.S. maintains a lock on the global IT industry. It was a major mistake to bring H1B's in the U.S., and then send them back. Some of them went home, realized they could still contract with the American corporations, and created an entire outsourcing industry in India. It is a much better strategy to bring everyone to America, and make them want to stay here.
It is important for natural security to encourage highly skilled people to move to the America. Outsourcing to Canada because of health care is a bad idea.
Buried in the safety standards are strong remarks to the effect that the ideal system has an "Emergency-Stop" switch, which is slightly different than an "Emergency-Off" switch. An "Emergency Stop" switch is intended to bring a machine to a sudden, safe stop. The best, and relatively simple implementations, use a single well tested "Emergeny-Stop" circuit that: (a) cuts power, (b) bring the system to a safe stop, and (c) make it safe for the operator to access the machine (and work with the guard interlocks.)
As the parent poster suggests, the automobile equivalent to the Emergency-Stop switch would be the brake peddle. However, the brake peddle is not designed to cut engine power, or to safely disconnect the engine from the wheels. For instance, when at a complete stop, why does a car with automatic transmission move forward when the brake is released? From an operator interface point of view, it should wait until you press the accelerator. Suppose the operator had a heart attack, and managed to stop the car. The car would start moving as the operator died (and this has happened.) As implemented, the brake does not qualify as either a proper Emergency-Stop or Emergency-Off device.
Also, the emergency-stop switch (and the emergency-off switch) does not require that all power be removed (ie: the engine killed.) It just requires that the vehicle be brought to a safe low-energy state. This state should be reached in a doubly-redundant with monitoring, control-safe manner. No system on the automobile, the transmission, the ignition, or the brakes is fully double redundant with monitoring. The transmission is singly redundant, and throwing the car into park will not stop it. Thus, the transmission can't be considered a fail-safe device. Toyota eliminated the ignition switch.
The most reliable system on a car is the brakes. The brakes are doubly-redundant (left and right side), but they can't stop the engine under all fault conditions. Also, with ABS/traction control, the brakes may not even be designed to stop the vehicle under fault conditions, as the ABS system may deliberately release locked wheels. Additionally, the brakes are not monitored safety devices. The brakes should be designed to be tested at every vehicle start, such that all four brakes are known to work (apply) before the driver drives off. Thus, brakes have been tested to at least apply, at least once per startup, before they are required to stop the vehicle in the event of an emergency.
In comparison to most industrial automation, a car has no properly designed emergency-shutdown (off or stop) functionality. If someone built an industrial machine to the same standards as a car, it would not be accepted as a competent design. Someone would say something to the effect of: "Your going to design a device that can potentially crush people, with no emergency stop or emergency off device??? Are you trying to lose your engineering license?"
There are two major problems with the "shift to neutral" solution:
1. It doesn't always work.
2. Only a few auto-mechanic and maybe some race car drives have the reflex to shift the car into neutral.
Most people will not think of shifting to neutral when a problem is encountered, simply because they never need to do it. I'm an engineer, and if my car takes off, it will take me a while to think of shifting to neutral. A car at full acceleration can cover much ground in less than 1 second.
The other problem is that I doubt that auto-transmissions will consistently disengage under *fault* conditions.
Your best chance is to be driving a manual transmission. Every manual transmission driver knows to hit the clutch and brakes at the same time, and will do it instinctively. Additionally, the manual transmission is less vulnerable to simultaneous failure modes than the modern computer controlled automatic transmission. For instance, if you are high gear in a manual transmission, it won't automatically down-shift to apply more torque to the wheels when you brake the car to slow it down. Additionally, if the manual transmission is in low gear, it won't up-shift automatically if the car engine takes off. The engine may rev-high, but in low gear, at least you won't be going fast. The manual transmission is much safer in runaway engine conditions.
This is only a bug depending on what you are doing with your final images. One of the things that annoys me is that many image manipulation programs do not actually explain the primitives they are using. The result can be a complete mess depending on what you are trying to accomplish. This article is an example of this effect.
If you want photo-realistic results, then you need to take Gamma into account. However, very few file formats specify the Gamma, the grey level, the white level, the black level or the colour space of the original image. The result is that the many imaging operations must be wrong, as they can never be accomplished the way intended. For the most part, no one cares. This person found an application where people care.
Essentially, every chip on the modern circuit board is either an MCU, an ASIC, or some kind of specialized power/interface device. Additionally, many of the specialized power, interface devices and ASICs are also MCUs. For instance, some of the older AM/FM radio have two MCUs: one for the radio/tuning, and another to drive the display. I have no idea how many controllers it takes for a modern XM radio, but the number could be significant.
For example:
- The tuner has it's own MCUs, and possibly one per band (XM, AM/FM),
- The CD player servo assembly likely has an MCU,
- The display controller is either an MCU or a firmware programmed device, and
- Most modern DACs use fancy algorithms to optimize the frequency response curve, and as such contain either an MCU or a primitive firmware programmed device.
Essentially, every chip of consequence in the XM Radio is likely either an MCU or some kind of special purpose programmed device. If you start counting programmable chips in terms of the really simple devices, the numbers get large quick.
Actually, other than (c), much of this has already been done. It is just that no one has used all the software (or the standards) for industrial automation in a car. Seriously, if you read some of the industrial automation standards, and knew the specifications that the software was designed too, you would ask: "What were they thinking?"
For instance, it is a requirement in almost every "Emergency-Off" circuit, to have:
a) an emergency-off button,
b) have it clearly labelled and marked, with special identifiers for the application,
c) the switch itself cannot automatically "reset", it requires an additional motion to release,
d) electrically, the switch must disconnect all power to the loads, and cannot self-reset, ie: resetting the "emergency-off" switch does not automatically turn power back on,
e) if required by the application, doubly-redundant wiring with monitoring to ensure the wiring works, and that the power cannot be switched on if any safety device has failed, and
f) if required by the application, provision that if the contacts somehow fall out of the switch, they power switches off (fails safe state),
g) one emergency-off switch is present in every operator location (control panel), and
h) Emergency-off is implemented in hardware!
The above points may appear to be obvious, or just good thinking, until you consider that in one of the models with the unexpected acceleration problem, no way exists to quickly turn off the engine. Toyota eliminated the ignition key! You cannot quickly turn off the engine, and counter intuitively, the engine off control is the engine start control. Essentially, Toyota skipped every single point on the above list, including the requirement to have a clearly marked "emergency-off" switch in an operator accessible location. In an emergency, they have no obvious method to stop the car.
The testing was very rigorous, even after a couple of lines of code there were code coverage tests, unit tests, static code analysis, tests of the hardware with Vector CANoe, you name it.
None of these tests are entirely effective when dealing with embedded applications.
Bluntly, software tests can only prove the existence of a software bug relative to the specification. For an embedded application, toss the specification out, and start looking at real-world failure scenarios. Glitches on the reset line can cause all sorts of interesting results... and that is just one possible failure mode.
On a well designed embedded system, most of the dangerous failure modes involve complex unexpected system level interactions.
Microsoft designed IE6 with all sorts of cool interfaces for corporate developers. They then unleashed a wave of evangelists to encourage people to exploit those non-standard extensions, and encourage them to exploit the non-standard quirks. It was a deliberate strategy to gain and hold market share.
If the coax is sitting loose in the walls, you can use it as a pull cable to thread in replacement UTP cable.
Old Ethernet worked over Coax. I just doubt you have the correct kind of Coax. Also, my experience with residential cable installs is that they tend to have damaged Coax cable, so it is pointless even trying to use it for high-bandwidth applications.
Finally, while it is theoretically possible to substitute 4 "pairs" of twisted pair with 4 Coax cables, my suspicion would be that you would have severe impedance mismatch problems. It might be good at 10 Mb, where the old Coaxial ethernet worked. I doubt it would handle modern 1 Gb Ethernet signals. Also, modern Ethernet expects all 4 pairs to be of approximately the same length, and it is unlikely someone would have 4 matched-length pairs of coaxial cable sitting in their wall.
Slashdot Mirror
The problem with that logic is that expensive solutions can be abandoned on a whim. The supplier can make a simple business decision, they can go out of business, or taken over by a competitor. Depending on the contract, is it a term license or a perpetual license? Is the software dependent on other peoples code? With proprietary software, you can be locked out at any moment.
Additionally, have you ever actually tried to get a software company to pay out on a law suit for defective code? It is almost impossible. Check the disclaimers in the contracts.
Some of the ISO-9001 knowledge becomes very long-lived. Stick to things that will work for a very long time. It is not uncommon to see ISO, software, CAD, and project documentation files from 25 years ago. Having to support DOS PCs for legacy projects sucks.
Think about whatever software you use, and make sure it is formed around standards that will persist. For instance, does SharePoint depend on Microsoft Internet Explorer? Is Microsoft Internet Explorer V9 compatible with Internet Explorer V6? Take a look at all the other legacy software inside your organization dependent on Microsoft IE V6. Don't do it again.
In the end, there is a strong argument for keeping PDF, DOC, and XLS files around, and placing a version control system on them. Some systems, try to integrate the entire quality control system into a document management system, and the results cannot be maintained long-term. One expensive system that I deployed, didn't survive the 24-month rollout process. You need to stick to standards, and keep your options open, both short and long term.
This reminds me of the "slowest ever compiler" paper. The compiler generated very unusual and fast code, but the compile time was O(256^n) with n being the bytes of code generated. Essentially, the compiler had two algorithms. A random number generator that generated the code, and a verification algorithm that verified the code was correct. The program then selected the fastest of the randomly generated code vectors as its final output.
You could describe this as the ultimate "Monte-Carlo" compiler. The general idea of randomly testing optimization variables is not new, and is used frequently in other simulation tasks where the designer might not properly understand the impacts of the model parameters. In other fields, it is a variation on "Design of Experiments", DOE, with randomized variables. If you look in the Numerical Methods in C/Fortran books, there are many optimization techniques, structured and monte-carlo, that can be used to optimize systems without a thorough understanding of the input space.
Precisely. Otherwise, you are always open to a sufficiently sophisticated man in the middle attack.
I tend to agree. The overwhelming majority of elementary school teachers are neither math nor science majors. It is quite likely the teachers don't understand the reasons for the math theory. They just know it should be taught. As such, they are not likely to be using approaches that relate the theory in ways that people (kids) would understand it. It is humbling to have a PhD in Engineering, and not be able to understand Grade 6 math homework. If I can't understand the lessons they are trying to teach with regards to digits and digit placement, then what chance do the Grade 6 kids have?
On another occasion, while in first year Algebra, I vividly remember suddenly understanding key concepts from Grade 7 math. For instance, why does one care that numbers have the distributive, associative, and commutative properties? that can be named and explained? The knowledge is not helpful until vector and matrix math is covered. At that point, data types exist where the associative and commutative properties may or may not apply.
I'm just not sure what is the point of introducing concepts to children, without the ability to explain the reasons for the concepts. Why teach math, with no text book? Why focus so much on obscure terminology, to the point that no one understands why you are even asking a question? Math is about understanding why things happen. Not wrote answers to naming conventions.
This list could go seriously wrong when responding to emergencies. It's virtue is that it is a great list for a triage assessment at hospitals. A trained triage nurse could use it to call codes, after quickly examining a patient in front of her. Yellow is "> 5 min", Red is "possibly dead in 5 min", Purple is "almost / already dead", and Green is "No Hurry".
A 911 operator (or a 999 operator) is communicating with paniced people without medical training. These people will not be able to give a "medically accurate" descriptions. For instance, the list differentiates between Cardiac Arrest, Chest Pain (Non-Traumatic), and Abdominal Pain. It even includes Abdominal Pain "not alert" as a yellow, and Chest Pain "not alert" as Red. I don't think the average caller can tell the difference, and some patients will die before anyone figures it out. I'm not sure what the emergency response times are in Swansea, but if you spend more than 60 seconds on the phone debating if a person is Red, then you will be losing a measurable percentage of the Red patients.
The building fire section is also a bit strange. If you have a building on fire, with people reporting it (visual identification), if people are in the building, you have to role an ambulance. Don't wait until the occupants are out of the building, before escalating the call. Do you need 5 people unconscious on the lawn before deciding it is a Code Red (multiple victims)?
Triage lists for 911 / 999 response must be based on what paniced people can communicate. For example: Is the person breathing? Are they conscious? Do you see smoke/flames? Are people in the building? People can answer these questions quickly.
I must be missing something here. Where I live, if you call for an ambulance, it comes. If something serious is going on, call the fire department and the ambulance, because the fire department has a quicker response time. There is no option for "not show up". Some injuries (like concussions) don't look like emergencies immediately. As such, the procedure is to get you to the hospital, and have the nurses and doctor's deal with the situation.
Sure, if you call an ambulance over a stubbed toe, then the ambulance guys will send you a bill for the ride to the hospital, and the police might charge you for wasting everyone's time. However, the ambulance, police and fire will show up.
Do the ambulances in England have an option to refuse to come in an acute, emergency situation? involving major fractures? dislocations?
These are safety critical user-interfaced systems, and people are dying. It doesn't matter who caused the issue or why. It matters that the purchaser lives to be told about the problem.
You cannot depend on the hardware performing to specification. If I put 5 amps on a 10 milliamp output, does that mean it will turn on? turn off? turn on then off? turn on until the power is toggled, then appear to work normally, and then turn on by itself at a later time? Will the 5 amps bypass to a power supply, and affect other inputs? Will the system clock oscillator continue to function? properly? Will the analog inputs continue to function properly? Will the power bypass into the Flash EPROM fusing on the watchdog circuit, and disable the hardware watchdog circuit?
What makes safety systems hard, is acquiring detailed knowledge of how the systems fail. Normally, this information is not part of any specification. The result is that in many embedded systems, no one knows for sure what happens when failures start occuring. You have to design embedded systems with the assumption that when failures occur, failures are happening. What does it mean to the software when the hardware is not working correctly? For most practical applications, software is completely dependent on the hardware performing to a specification, and only in the best predicted, most optimistic, and most common failure scenarios, will the hardware meet specification. Design software accordingly.
Software developers that think the cause of most severe software failures is purely software, are the source of many of these software bugs.
The nasty bugs all revolve around complex system interactions, that just happen to involve software. No amount of Haskell code can fix them. Don't believe the marketing hype. Software bugs will be with us, long after the introduction and widespread use of functional programming.
Additionally, it isn't even obvious in a complex environment like an engine, that Haskell's sequential monad order for external I/O is both applicable and correct. Welcome to the modern micro-controller, where I/O sequencing is no longer a function of sequence of program execution.
It is hope. People hope to see their relative healthy again. They remember seeing a person healthy. They miss it, and they want to see it again.
Unfortunately, some of the treatments are ineffective. They might extend life, but they will never restore health. Medical procedures are graded by mortality rate over periods of time. Ex: 50% survival at 5 years. The goal needs to be different. Effectiveness should be judged by time outside the hospital without extensive medical intervention. 50% of the time, this procedure gets you 3 more years with your family. A subtle and significant improvement.
Police are allowed to participate in a ruse to gain the trust of a suspect.
Make no mistake. You were a suspect in a murder case, until cleared. In a police investigation, everyone is a potential suspect. As such, be careful what you volunteer, because until proven otherwise, you are a suspect and can be lied to.
You might be surprised. Get a rental car and try it out. My car, a 2003 domestic, will actually *upshift* in low gear. All the Ford and GM cars that I have tested, are set to automatically upshift and downshift to keep the engine revs inside the limits, regardless of gear shift position.
There is a deliberate engineering reason why this happens. The car manufacturers don't want to pay the warranty costs of someone accidentally doing a bad shift with an automatic transmission. As such, Ford and GM use the automatic transmission as a form of a rev limiter. It reduces warranty costs from engine repairs.
Disclaimer: This only works with some models. It does not apply to cars with manual transmissions. It does not apply to performance sports cars. For instance, a Ferrari with a paddle shifter, will shift as commanded.
The clutch is fairly reliable (assuming it is being maintained). Additionally, people use the clutch to drive. They know how to use it, and keep it maintained.
This is not the case for neutral in an automatic transmission. The neutral position is increasingly fly-by-wire. I wouldn't bet on an automatic transmission disconnecting engine power under *fault* conditions. Also, people don't use the neutral position, so it isn't obvious to me that most people really understand it. It can fall out of alignment, and people might not notice the problem and have it fixed. One report has the driver putting the transmission into Reverse, and the transmission still applying full forwards power to the rear wheels. Essentially, putting the transmission into any other gear other than drive and overdrive should limit the cars maximum speed to 50 km/h. Modern transmissions just don't do this. Try throwing an old car into neutral, or new car into first at full speed. On *some* cars, nothing happens ...
Currently, the key-start circuit cuts power to a significant portion of the engine controls. There is no way the engine can run, unless the ignition switch fails shorted. However, you are right. With modern technology, the ignition switch could be made fly-by-wire. If the car was an industrial machine, this would be a severe breach of protocol. Actually, for industrial machinery standards, the current ignition switch would not be considered a sufficient safe-disconnect device. However, it is a car. There is no specific legislative requirement for an off switch. As such, why keep an off-switch???
Many other manufacturers have already added a similar piece of code. It really doesn't take to long to debug an interlock. Your primary failure mode will be: if the brake pressed switch fails (ie: the tail lights are stuck on), then the car won't run.
Every interlock has a strong tendency to fail into the safe state. Conversely, omitting interlocks tends to result in fail-dangerous failures, which is what Toyota is experiencing.
GM outsourced an entire R&D division to Canada about 10 years ago. They lowered the cost of real estate, took advantage of a lower Canadian dollar to have lower labour costs, and the health insurance costs were much less. Plus, Canada is close enough to America that they can be sent to Detroit or wherever in the U.S. they needed to go, whenever the situation required it.
If it works for the little guys, it works even better for the big guys ...
If I were the U.S., I would hire as many foreign IT workers as possible. They are not that many of the really good IT workers being graduated in the entire world. If you move all the workers to the U.S., then the U.S. maintains a lock on the global IT industry. It was a major mistake to bring H1B's in the U.S., and then send them back. Some of them went home, realized they could still contract with the American corporations, and created an entire outsourcing industry in India. It is a much better strategy to bring everyone to America, and make them want to stay here.
It is important for natural security to encourage highly skilled people to move to the America. Outsourcing to Canada because of health care is a bad idea.
I've noticed the number of software startups coming from Europe is increasing.
I think the U.S. is a better place to grow a company. Europe is a better place to grow a new idea (unless it involves manufacturing.)
Buried in the safety standards are strong remarks to the effect that the ideal system has an "Emergency-Stop" switch, which is slightly different than an "Emergency-Off" switch. An "Emergency Stop" switch is intended to bring a machine to a sudden, safe stop. The best, and relatively simple implementations, use a single well tested "Emergeny-Stop" circuit that: (a) cuts power, (b) bring the system to a safe stop, and (c) make it safe for the operator to access the machine (and work with the guard interlocks.)
As the parent poster suggests, the automobile equivalent to the Emergency-Stop switch would be the brake peddle. However, the brake peddle is not designed to cut engine power, or to safely disconnect the engine from the wheels. For instance, when at a complete stop, why does a car with automatic transmission move forward when the brake is released? From an operator interface point of view, it should wait until you press the accelerator. Suppose the operator had a heart attack, and managed to stop the car. The car would start moving as the operator died (and this has happened.) As implemented, the brake does not qualify as either a proper Emergency-Stop or Emergency-Off device.
Also, the emergency-stop switch (and the emergency-off switch) does not require that all power be removed (ie: the engine killed.) It just requires that the vehicle be brought to a safe low-energy state. This state should be reached in a doubly-redundant with monitoring, control-safe manner. No system on the automobile, the transmission, the ignition, or the brakes is fully double redundant with monitoring. The transmission is singly redundant, and throwing the car into park will not stop it. Thus, the transmission can't be considered a fail-safe device. Toyota eliminated the ignition switch.
The most reliable system on a car is the brakes. The brakes are doubly-redundant (left and right side), but they can't stop the engine under all fault conditions. Also, with ABS/traction control, the brakes may not even be designed to stop the vehicle under fault conditions, as the ABS system may deliberately release locked wheels. Additionally, the brakes are not monitored safety devices. The brakes should be designed to be tested at every vehicle start, such that all four brakes are known to work (apply) before the driver drives off. Thus, brakes have been tested to at least apply, at least once per startup, before they are required to stop the vehicle in the event of an emergency.
In comparison to most industrial automation, a car has no properly designed emergency-shutdown (off or stop) functionality. If someone built an industrial machine to the same standards as a car, it would not be accepted as a competent design. Someone would say something to the effect of: "Your going to design a device that can potentially crush people, with no emergency stop or emergency off device??? Are you trying to lose your engineering license?"
There are two major problems with the "shift to neutral" solution:
1. It doesn't always work.
2. Only a few auto-mechanic and maybe some race car drives have the reflex to shift the car into neutral.
Most people will not think of shifting to neutral when a problem is encountered, simply because they never need to do it. I'm an engineer, and if my car takes off, it will take me a while to think of shifting to neutral. A car at full acceleration can cover much ground in less than 1 second.
The other problem is that I doubt that auto-transmissions will consistently disengage under *fault* conditions.
Your best chance is to be driving a manual transmission. Every manual transmission driver knows to hit the clutch and brakes at the same time, and will do it instinctively. Additionally, the manual transmission is less vulnerable to simultaneous failure modes than the modern computer controlled automatic transmission. For instance, if you are high gear in a manual transmission, it won't automatically down-shift to apply more torque to the wheels when you brake the car to slow it down. Additionally, if the manual transmission is in low gear, it won't up-shift automatically if the car engine takes off. The engine may rev-high, but in low gear, at least you won't be going fast. The manual transmission is much safer in runaway engine conditions.
This is only a bug depending on what you are doing with your final images. One of the things that annoys me is that many image manipulation programs do not actually explain the primitives they are using. The result can be a complete mess depending on what you are trying to accomplish. This article is an example of this effect.
If you want photo-realistic results, then you need to take Gamma into account. However, very few file formats specify the Gamma, the grey level, the white level, the black level or the colour space of the original image. The result is that the many imaging operations must be wrong, as they can never be accomplished the way intended. For the most part, no one cares. This person found an application where people care.
Essentially, every chip on the modern circuit board is either an MCU, an ASIC, or some kind of specialized power/interface device. Additionally, many of the specialized power, interface devices and ASICs are also MCUs. For instance, some of the older AM/FM radio have two MCUs: one for the radio/tuning, and another to drive the display. I have no idea how many controllers it takes for a modern XM radio, but the number could be significant.
For example:
- The tuner has it's own MCUs, and possibly one per band (XM, AM/FM),
- The CD player servo assembly likely has an MCU,
- The display controller is either an MCU or a firmware programmed device, and
- Most modern DACs use fancy algorithms to optimize the frequency response curve, and as such contain either an MCU or a primitive firmware programmed device.
Essentially, every chip of consequence in the XM Radio is likely either an MCU or some kind of special purpose programmed device. If you start counting programmable chips in terms of the really simple devices, the numbers get large quick.
Actually, other than (c), much of this has already been done. It is just that no one has used all the software (or the standards) for industrial automation in a car. Seriously, if you read some of the industrial automation standards, and knew the specifications that the software was designed too, you would ask: "What were they thinking?"
For instance, it is a requirement in almost every "Emergency-Off" circuit, to have:
a) an emergency-off button,
b) have it clearly labelled and marked, with special identifiers for the application,
c) the switch itself cannot automatically "reset", it requires an additional motion to release,
d) electrically, the switch must disconnect all power to the loads, and cannot self-reset, ie: resetting the "emergency-off" switch does not automatically turn power back on,
e) if required by the application, doubly-redundant wiring with monitoring to ensure the wiring works, and that the power cannot be switched on if any safety device has failed, and
f) if required by the application, provision that if the contacts somehow fall out of the switch, they power switches off (fails safe state),
g) one emergency-off switch is present in every operator location (control panel), and
h) Emergency-off is implemented in hardware!
The above points may appear to be obvious, or just good thinking, until you consider that in one of the models with the unexpected acceleration problem, no way exists to quickly turn off the engine. Toyota eliminated the ignition key! You cannot quickly turn off the engine, and counter intuitively, the engine off control is the engine start control. Essentially, Toyota skipped every single point on the above list, including the requirement to have a clearly marked "emergency-off" switch in an operator accessible location. In an emergency, they have no obvious method to stop the car.
None of these tests are entirely effective when dealing with embedded applications.
Bluntly, software tests can only prove the existence of a software bug relative to the specification. For an embedded application, toss the specification out, and start looking at real-world failure scenarios. Glitches on the reset line can cause all sorts of interesting results ... and that is just one possible failure mode.
On a well designed embedded system, most of the dangerous failure modes involve complex unexpected system level interactions.
Microsoft designed IE6 with all sorts of cool interfaces for corporate developers. They then unleashed a wave of evangelists to encourage people to exploit those non-standard extensions, and encourage them to exploit the non-standard quirks. It was a deliberate strategy to gain and hold market share.
It worked. IE6 is unstoppable, even by Microsoft.
If the coax is sitting loose in the walls, you can use it as a pull cable to thread in replacement UTP cable.
Old Ethernet worked over Coax. I just doubt you have the correct kind of Coax. Also, my experience with residential cable installs is that they tend to have damaged Coax cable, so it is pointless even trying to use it for high-bandwidth applications.
Finally, while it is theoretically possible to substitute 4 "pairs" of twisted pair with 4 Coax cables, my suspicion would be that you would have severe impedance mismatch problems. It might be good at 10 Mb, where the old Coaxial ethernet worked. I doubt it would handle modern 1 Gb Ethernet signals. Also, modern Ethernet expects all 4 pairs to be of approximately the same length, and it is unlikely someone would have 4 matched-length pairs of coaxial cable sitting in their wall.