It is not even the satellite data. Merely the variation in carrier frequency between hourly "pings" caused by doppler effect: at first the plane was flying south from the north side of the equator, bringing it closer to geostationary satellites causing a doppler shift to slightly higher observed frequency, then another ping near the equator with no apparent doppler shift followed by lower carrier frequencies as the plane started moving away from the equator.
They could have gotten the same doppler pattern if the plane turned around at the equator and started going north after the equator ping. That's why the Inmarsat staff cannot rule out the northern route with absolute certainty.
If they had logs from two satellites, they would have been able to make 100% certain.
While you can technically call that narrowed, this narrower area is still the broadest search area ever. The Inmarsat pings are only accurate within something like 500km since they are only once per hour events. There is an additional ~10km uncertainty from altitude, probably a few more km due to signal noise since I doubt the Inmarsat satellites recorded the raw RF signal for a real Doppler analysis. They probably deduced the Doppler effect from the carrier lock frequency of individual handshake packets. After that, you have all the unknowns from winds, surface/depth currents and who knows what else.
Once they find something on the surface, they will have 17+ days of ocean currents and storms to back-track and those can displace stuff by 100+km/day.
They knew where the Air France plane crashed yet it took them five days to find the wreck itself and two more years to find the recorders. Here, we're at 17 days and we have no confirmed debris yet; only sightings of potential candidates by satellites and planes that they are having trouble finding again by sea to pick them up for analysis.
Unless they get incredibly lucky, this could take a very long time.
The point he was probably trying to make is that if the government wanted to make things more efficient, they should have converted most of those 30 years of paper backlog to digital form since they probably have to do that to make things fit with current administrative systems anyway.
Doing as-needed data entry spares the trouble of converting documents before they are necessary but has more overhead for hunting down files on a case-by-case basis while bulk data entry spares the trouble of hunting down individual files at the expense of filing some data that might never get called up for. Bulk entry done right would also have the benefit of automated cross-checking to highlight discrepancies and potentially dead files.
In other words, if the government wanted to be efficient about it, they would re-file data electronically for their primary working set and keep paper records for backup/reference purposes in case someone disputes electronic records instead of relying on paper records as their primary source.
Another problem with the fire theory is that it would still take several minutes for the fire to break out of fire-resistant cargo partitions and cause any actual damage to the plane or passengers. With the number of smoke detectors on planes these days, pilots would have gotten the alarm long before systems would start failing, which should be plenty of time to at least report the emergency and divert to the nearest airport with emergency services.
The sort of blind trust you seem to have due to "Linux changing at an unprecedented rate" is probably the greatest security threat.
Interest in Linux malware is also increasing at unprecedented rates due to Android. For now, most efforts are focused on Android's JRE and trojanized hacked apps/games but it may only be a matter of time until they start seriously pursuing more difficult targets.
Most computers use digital PWM control for CPU power these days and the reason for that is because the CPU knows how much current and voltage it needs for a given workload and can set its VID to control the PWM directly instead of relying only on slow analog feedback. This allows much faster ramp up/down on load changes because the CPU can tell the PWM about load changes before they happen. You aren't going to see microsecond-scale large transient response with pure-analog like you do with digital since analog feedback bandwidth is limited by the need to scrub noise off the feedback signal, keep the filter's response time fast enough to minimize overshoots yet make it slow enough to retain enough phase margin for stable operation.
As for computers in process controls, they have been everywhere for a long time already. PLCs may be able to handle immediate control but most complex processes require large-scale monitoring, control, coordination, data recording, trend analysis, etc. to detect and correct overall process variations that fall beyond individual PLCs' ability to monitor and correct. For operators, computers are used all the time to organize thousands of parameters in a handful of computer displays that can be easily re-arranged either to the operator's preferences, overview, operating/troubleshooting themes, subsystems, etc. instead of entire walls and consoles of manual controls, easily duplicate controls and displays for multiple operators, remote troubleshooting, etc.
Only if the merchant or whoever you concluded the transaction with agrees to reverse it and even then, the refund is still a separate transaction from the original payment.
A crook can give you a "receipt" and vanish from your life or make excuses to refuse refunds just about as easily with real cash as Bitcoins.
The main differences are that Bitcoin is mostly used in higher-risk transactions and does nor have any legal protections anywhere so if you get screwed, you have little if any legal protection.
Instead of SHAing each entropy source individually, I would simply concatenate all the entropy sources together and SHA that. It saves the hash initialization, finalization and intermediate "folding" steps.
Intel uses a phase noise amplifier to generate a random bit stream, passes that stream through a hash algorithm to cancel hardware bias and fill/refresh an entropy buffer, hashes parts of that buffer to produce the RNG output and that output also gets hashed back in the entropy buffer to provide a high-bandwidth RNG stream.
Basically, it is a low-bandwidth true hardware RNG (something like 1Mbps) continuously seeding a high-bandwidth PRNG to amplify its bandwidth.
If you want a secure PRNG, use a decent seed source with whatever other entropy sources you want and use that to start a recursive hash loop, using the hash's output as your random number. Good hash functions have characteristics pretty close to a true RNG when used this way and many true RNGs use hash as an intermediate step to cancel input bias.
How often have pilots successfully landed large aircrafts on water? AFAIK, the Hudson landing is the only time pilots have managed to pull off a perfect landing where the plane stayed in one piece and everyone survived - they did not call it the "Miracle on the Hudson" for nothing and the only reason they managed to pull that off is because the river was perfectly still at the time. All other water landings I remember seeing footage or reconstructions of had various degrees of severe disintegration either on impact or soon after - hitting water at over 200km/h is almost like hitting a brick wall; anything that sticks out (like engines, wings, instrument tubes, antennas, landing gear and doors if deployed, etc.) gets ripped out and creates more areas where drag will rip even more stuff off. I do not remember any other water landing where the plane still had both wings attached.
BTW, the cabin is only designed to keep 100kPa inside the cabin. Keeping the 100MPa from crashing into a wave outside would require something drastically different.
Another problem with your theory is that it is unlikely the wiring between hypothetical batteries and the satellite radio would have both survived the crash and remained afloat within communications depth assuming the transmitter was and remained water-tight: SLA and NiMH batteries would readily sink while Lithion-based batteries violently react with water if their shell is compromised.
Nearly all the electrical power in a plane goes through the cockpit's breaker panel... even the toilet's pump. As some reports have explained, the ACAMS actually has separate breakers for the monitoring systems and the transceivers and only the monitoring system got shut down presumably because whoever turned that off did not know there were two and the transceivers ended up continuing to transmit empty frames - that second breaker is supposedly in a non-obvious location on the panel.
If a plane is in such a bad shape that it has to rely on battery power instead of its APU or RAT, I doubt it could spare battery power for systems that probably won't help them: if you simultaneously lose power from both engines and cannot start the auxiliary power unit to restore power, you have issues well beyond anything ACAMS can help with. And that battery power would still be going through the cockpit... no cockpit, no power. Cockpits also don't float too well so it would drag the transceivers down to the bottom with it if the wiring survived.
I would be a little surprised if the engine monitoring and satellite link circuitry would be on battery backup since it is unlikely engines and passengers would have much use for satellite link after the plane hits water. For the satellite link to work, the antenna would also need to remain above water since submersion adds horrible attenuation to radio signals. Additionally, cabin electronics aren't water-tight so submersion in ocean water would ruin them in fairly short order.
It probably does just before air breaks down and the arc strikes. Bright flashing lights with loud bangs probably scare animals a whole lot more than a dim purple/violet haze and a soft steady hum.
And light years ahead of Windows 3.0's or OS/2's grid of icons on the desktop... or the grid of icons in graphical DOS-based programs... or the grids of text-based buttons in text-mode programs.
The most puzzling thing is how could those patents ever slip through? With the amount of tablet and touch-screen technology shown in Star Trek: TNG/DS9/Voyager/Enterprise, I'm having a hard time imagining how most of those could have ever gone through - most of the cosmetic ideas precede the first iPod by a decade.
Everyone who drives already has to buy liability insurance.
Some places have multiple different layers of insurances drivers must sign up for. Where I live, basic collective insurance built in the license and plate fees and drivers are required to buy additional vehicle liability insurance for a minimum of 1M$ on top of that. The mandatory collective insurance regime covers the balance of claims that exceed the mandatory minimum private insurance and cases where there is no insurer to file claims against such as hit-and-runners who don't get caught or people who drive illegally without vehicle insurance.
While I agree that taxis do feel a lot like a cartel in many ways, I can think of at least two legitimate reasons to treat them differently: - in places with a mandatory public insurance regime built into license and plate fees, the higher taxi fees are there to cover the higher risk exposure associated with those drivers and vehicles - a licensed taxi is (hopefully) more trust-worthy and reliable than random people - at the very least, you can file complaints against them and if those get taken seriously by the-powers-that-be, too many/severe complaints will get the bad taxi's license reviewed and possibly revoked
Which is more efficient? 1- a GPU architecture that can accept API calls almost straight-through 2- a GPU that requires middleware to re-arrange code and data going through the API
Can you honestly tell me AMD did not coordinate Mantle and GCN design efforts to provide close to the thinnest middleware layer possible between the API and GCN? Can you honestly tell me the middleware for other architectures won't be thicker to match API features GCN handles natively but other GPUs have no native direct equivalent for? Can you honestly tell me a thicker middleware is going to perform equally well?
I'm not saying there won't be any performance benefits for other vendors. Just that the decks are almost certainly stacked in AMD's favor to some potentially non-negligible extent. Unless Nvidia decides to adopt Mantle, we will never find out exactly how much that is.
That article merely says that GCN is not mandatory.
Just because you can beat the API into "working" on something else does not mean it will be as efficient. Mantle was designed around GCN so the API likely has tons of things that map almost exactly 1:1 with GCN hardware but not necessarily quite that neatly on anything else. That's where the extra middleware comes in.
If you read the conclusion of your cited article, they say exactly what I said, albeit in different words: Mantle's roots are likely too close to GCN to be truly portable between vendors (or AMD's own previous and possibly future post-GCN architectures) unless other vendors change their architectures to something more GCN-like.
AFAIK, AMD never answered when asked what will happen to Mantle beyond GCN - apart from saying GCN would be around for the foreseeable future.
Since AMD was very clear that Mantle only works with their GPUs based on GCN architecture, it seems to imply that although the API might be portable to other GPUs, the amount of middleware necessary to bridge the gap between the API and other architectures may not be worth the trouble - at least too much trouble to bother porting it to their own older GPUs. It certainly won't be if DX12 delivers on most of those closer-to-the-metal promises.
Trying to set maximum speeds based on 85th sounds like a futile thing to do: if that causes the speeds to rise, the 85th will likely rise when it gets re-evaluated at some future point until speeds are high enough that people do not dare go any faster and no matter what the maximum speed is, people still need to have the common sense to adjust speed based on driving conditions - people who fail to slow down when driving into fog, wet/snowy/icy roads, etc. is where/when monster pileups tend to start.
There is a road where I used to drive on a regular basis where the speed limit is 70km/h but people often drive through there at over 120km/h. With the number of blind corners and hills on that road, I would be nervous driving at over 90km/h there - I totaled a car on that road once due to a traffic jam backing up all the way to one of those blind hills and I was only going at the 70k limit. I would not want to find out at what speed people would drive through there if the speed limit was raised to 100km/h and prefer not thinking about how much nastier that crash would have been with twice the kinetic energy involved.
Slashdot Mirror
It is not even the satellite data. Merely the variation in carrier frequency between hourly "pings" caused by doppler effect: at first the plane was flying south from the north side of the equator, bringing it closer to geostationary satellites causing a doppler shift to slightly higher observed frequency, then another ping near the equator with no apparent doppler shift followed by lower carrier frequencies as the plane started moving away from the equator.
They could have gotten the same doppler pattern if the plane turned around at the equator and started going north after the equator ping. That's why the Inmarsat staff cannot rule out the northern route with absolute certainty.
If they had logs from two satellites, they would have been able to make 100% certain.
While you can technically call that narrowed, this narrower area is still the broadest search area ever. The Inmarsat pings are only accurate within something like 500km since they are only once per hour events. There is an additional ~10km uncertainty from altitude, probably a few more km due to signal noise since I doubt the Inmarsat satellites recorded the raw RF signal for a real Doppler analysis. They probably deduced the Doppler effect from the carrier lock frequency of individual handshake packets. After that, you have all the unknowns from winds, surface/depth currents and who knows what else.
Once they find something on the surface, they will have 17+ days of ocean currents and storms to back-track and those can displace stuff by 100+km/day.
They knew where the Air France plane crashed yet it took them five days to find the wreck itself and two more years to find the recorders. Here, we're at 17 days and we have no confirmed debris yet; only sightings of potential candidates by satellites and planes that they are having trouble finding again by sea to pick them up for analysis.
Unless they get incredibly lucky, this could take a very long time.
The point he was probably trying to make is that if the government wanted to make things more efficient, they should have converted most of those 30 years of paper backlog to digital form since they probably have to do that to make things fit with current administrative systems anyway.
Doing as-needed data entry spares the trouble of converting documents before they are necessary but has more overhead for hunting down files on a case-by-case basis while bulk data entry spares the trouble of hunting down individual files at the expense of filing some data that might never get called up for. Bulk entry done right would also have the benefit of automated cross-checking to highlight discrepancies and potentially dead files.
In other words, if the government wanted to be efficient about it, they would re-file data electronically for their primary working set and keep paper records for backup/reference purposes in case someone disputes electronic records instead of relying on paper records as their primary source.
Another problem with the fire theory is that it would still take several minutes for the fire to break out of fire-resistant cargo partitions and cause any actual damage to the plane or passengers. With the number of smoke detectors on planes these days, pilots would have gotten the alarm long before systems would start failing, which should be plenty of time to at least report the emergency and divert to the nearest airport with emergency services.
The sort of blind trust you seem to have due to "Linux changing at an unprecedented rate" is probably the greatest security threat.
Interest in Linux malware is also increasing at unprecedented rates due to Android. For now, most efforts are focused on Android's JRE and trojanized hacked apps/games but it may only be a matter of time until they start seriously pursuing more difficult targets.
Most computers use digital PWM control for CPU power these days and the reason for that is because the CPU knows how much current and voltage it needs for a given workload and can set its VID to control the PWM directly instead of relying only on slow analog feedback. This allows much faster ramp up/down on load changes because the CPU can tell the PWM about load changes before they happen. You aren't going to see microsecond-scale large transient response with pure-analog like you do with digital since analog feedback bandwidth is limited by the need to scrub noise off the feedback signal, keep the filter's response time fast enough to minimize overshoots yet make it slow enough to retain enough phase margin for stable operation.
As for computers in process controls, they have been everywhere for a long time already. PLCs may be able to handle immediate control but most complex processes require large-scale monitoring, control, coordination, data recording, trend analysis, etc. to detect and correct overall process variations that fall beyond individual PLCs' ability to monitor and correct. For operators, computers are used all the time to organize thousands of parameters in a handful of computer displays that can be easily re-arranged either to the operator's preferences, overview, operating/troubleshooting themes, subsystems, etc. instead of entire walls and consoles of manual controls, easily duplicate controls and displays for multiple operators, remote troubleshooting, etc.
Only if the merchant or whoever you concluded the transaction with agrees to reverse it and even then, the refund is still a separate transaction from the original payment.
A crook can give you a "receipt" and vanish from your life or make excuses to refuse refunds just about as easily with real cash as Bitcoins.
The main differences are that Bitcoin is mostly used in higher-risk transactions and does nor have any legal protections anywhere so if you get screwed, you have little if any legal protection.
There was that.
Compared to the next most "successful" water landings I know off, I would still call it practically intact :)
Instead of SHAing each entropy source individually, I would simply concatenate all the entropy sources together and SHA that. It saves the hash initialization, finalization and intermediate "folding" steps.
Intel uses a phase noise amplifier to generate a random bit stream, passes that stream through a hash algorithm to cancel hardware bias and fill/refresh an entropy buffer, hashes parts of that buffer to produce the RNG output and that output also gets hashed back in the entropy buffer to provide a high-bandwidth RNG stream.
Basically, it is a low-bandwidth true hardware RNG (something like 1Mbps) continuously seeding a high-bandwidth PRNG to amplify its bandwidth.
If you want a secure PRNG, use a decent seed source with whatever other entropy sources you want and use that to start a recursive hash loop, using the hash's output as your random number. Good hash functions have characteristics pretty close to a true RNG when used this way and many true RNGs use hash as an intermediate step to cancel input bias.
How often have pilots successfully landed large aircrafts on water? AFAIK, the Hudson landing is the only time pilots have managed to pull off a perfect landing where the plane stayed in one piece and everyone survived - they did not call it the "Miracle on the Hudson" for nothing and the only reason they managed to pull that off is because the river was perfectly still at the time. All other water landings I remember seeing footage or reconstructions of had various degrees of severe disintegration either on impact or soon after - hitting water at over 200km/h is almost like hitting a brick wall; anything that sticks out (like engines, wings, instrument tubes, antennas, landing gear and doors if deployed, etc.) gets ripped out and creates more areas where drag will rip even more stuff off. I do not remember any other water landing where the plane still had both wings attached.
BTW, the cabin is only designed to keep 100kPa inside the cabin. Keeping the 100MPa from crashing into a wave outside would require something drastically different.
Another problem with your theory is that it is unlikely the wiring between hypothetical batteries and the satellite radio would have both survived the crash and remained afloat within communications depth assuming the transmitter was and remained water-tight: SLA and NiMH batteries would readily sink while Lithion-based batteries violently react with water if their shell is compromised.
Nearly all the electrical power in a plane goes through the cockpit's breaker panel... even the toilet's pump. As some reports have explained, the ACAMS actually has separate breakers for the monitoring systems and the transceivers and only the monitoring system got shut down presumably because whoever turned that off did not know there were two and the transceivers ended up continuing to transmit empty frames - that second breaker is supposedly in a non-obvious location on the panel.
If a plane is in such a bad shape that it has to rely on battery power instead of its APU or RAT, I doubt it could spare battery power for systems that probably won't help them: if you simultaneously lose power from both engines and cannot start the auxiliary power unit to restore power, you have issues well beyond anything ACAMS can help with. And that battery power would still be going through the cockpit... no cockpit, no power. Cockpits also don't float too well so it would drag the transceivers down to the bottom with it if the wiring survived.
I would be a little surprised if the engine monitoring and satellite link circuitry would be on battery backup since it is unlikely engines and passengers would have much use for satellite link after the plane hits water. For the satellite link to work, the antenna would also need to remain above water since submersion adds horrible attenuation to radio signals. Additionally, cabin electronics aren't water-tight so submersion in ocean water would ruin them in fairly short order.
It probably does just before air breaks down and the arc strikes. Bright flashing lights with loud bangs probably scare animals a whole lot more than a dim purple/violet haze and a soft steady hum.
And light years ahead of Windows 3.0's or OS/2's grid of icons on the desktop... or the grid of icons in graphical DOS-based programs... or the grids of text-based buttons in text-mode programs.
Yeah, re-inventing the grid is so patent-worthy.
There already is protection against "wholesale copying" of a product's look and feel; it is called a trademark.
The stupid USPTO rules are letting companies patent trademark elements, which is beyond dumb.
The most puzzling thing is how could those patents ever slip through? With the amount of tablet and touch-screen technology shown in Star Trek: TNG/DS9/Voyager/Enterprise, I'm having a hard time imagining how most of those could have ever gone through - most of the cosmetic ideas precede the first iPod by a decade.
Yeah, Canada is about 100C too warm.
Everyone who drives already has to buy liability insurance.
Some places have multiple different layers of insurances drivers must sign up for. Where I live, basic collective insurance built in the license and plate fees and drivers are required to buy additional vehicle liability insurance for a minimum of 1M$ on top of that. The mandatory collective insurance regime covers the balance of claims that exceed the mandatory minimum private insurance and cases where there is no insurer to file claims against such as hit-and-runners who don't get caught or people who drive illegally without vehicle insurance.
While I agree that taxis do feel a lot like a cartel in many ways, I can think of at least two legitimate reasons to treat them differently:
- in places with a mandatory public insurance regime built into license and plate fees, the higher taxi fees are there to cover the higher risk exposure associated with those drivers and vehicles
- a licensed taxi is (hopefully) more trust-worthy and reliable than random people - at the very least, you can file complaints against them and if those get taken seriously by the-powers-that-be, too many/severe complaints will get the bad taxi's license reviewed and possibly revoked
Which is more efficient?
1- a GPU architecture that can accept API calls almost straight-through
2- a GPU that requires middleware to re-arrange code and data going through the API
Can you honestly tell me AMD did not coordinate Mantle and GCN design efforts to provide close to the thinnest middleware layer possible between the API and GCN? Can you honestly tell me the middleware for other architectures won't be thicker to match API features GCN handles natively but other GPUs have no native direct equivalent for? Can you honestly tell me a thicker middleware is going to perform equally well?
I'm not saying there won't be any performance benefits for other vendors. Just that the decks are almost certainly stacked in AMD's favor to some potentially non-negligible extent. Unless Nvidia decides to adopt Mantle, we will never find out exactly how much that is.
That article merely says that GCN is not mandatory.
Just because you can beat the API into "working" on something else does not mean it will be as efficient. Mantle was designed around GCN so the API likely has tons of things that map almost exactly 1:1 with GCN hardware but not necessarily quite that neatly on anything else. That's where the extra middleware comes in.
If you read the conclusion of your cited article, they say exactly what I said, albeit in different words: Mantle's roots are likely too close to GCN to be truly portable between vendors (or AMD's own previous and possibly future post-GCN architectures) unless other vendors change their architectures to something more GCN-like.
AFAIK, AMD never answered when asked what will happen to Mantle beyond GCN - apart from saying GCN would be around for the foreseeable future.
Since AMD was very clear that Mantle only works with their GPUs based on GCN architecture, it seems to imply that although the API might be portable to other GPUs, the amount of middleware necessary to bridge the gap between the API and other architectures may not be worth the trouble - at least too much trouble to bother porting it to their own older GPUs. It certainly won't be if DX12 delivers on most of those closer-to-the-metal promises.
Trying to set maximum speeds based on 85th sounds like a futile thing to do: if that causes the speeds to rise, the 85th will likely rise when it gets re-evaluated at some future point until speeds are high enough that people do not dare go any faster and no matter what the maximum speed is, people still need to have the common sense to adjust speed based on driving conditions - people who fail to slow down when driving into fog, wet/snowy/icy roads, etc. is where/when monster pileups tend to start.
There is a road where I used to drive on a regular basis where the speed limit is 70km/h but people often drive through there at over 120km/h. With the number of blind corners and hills on that road, I would be nervous driving at over 90km/h there - I totaled a car on that road once due to a traffic jam backing up all the way to one of those blind hills and I was only going at the 70k limit. I would not want to find out at what speed people would drive through there if the speed limit was raised to 100km/h and prefer not thinking about how much nastier that crash would have been with twice the kinetic energy involved.