From the looks of it, many of the (potential) bugs in OpenSSL are caused by the use of a custom memory allocation scheme instead of a standard C allocator. Removing the custom memory management in favor of standard memory management alone implies dozens if not hundreds of relatively trivial code changes to all the places where the custom (de-)allocator get used. In the process of tracking down all of these, they come across stuff that does not look right and fix it while they are already in there.
As for why so many bugs, "so many eyes" only works if you still have tons of people actively participating in the project's development. At a glance, it seems like the OpenBSD guys are saying the OpenSSL project was getting stale. Stale projects do not have anywhere near as many eyes going through their code nor as many people actively looking for potential bugs to fix before they get reported in the wild.
In short: OpenSSL was long overdue for a make-over.
What makes ethanol act as a fuel anti-freeze is by mixing with moisture to lower the freezing point of water and help keep it blended with the fuel so it does not pool up as much... it is not the fuel that freezes; it is its moisture load and water condensation inside the tank. If you lower the ethanol content too much, ice crystals may clog or jam the pump, fuel filter, injectors or any other component where flow restrictions and water accumulation may occur.
If you live in an area of where temperatures drop a fair bit below freezing for a fair chunk of the year, you would end up adding ethanol as a fuel anti-freeze. It is also a weak solvent for compounds that are not soluble in gasoline, absorbs moisture, reduces the likelihood of engine knocking and a handful of other benefits.
Ethanol does have lower energy density than gasoline but it has enough benefits for some amount of it still being generally desirable - if you removed all ethanol from gasoline, gas companies would likely replace it with a more complex additive cocktail that might not perform quite as good.
> The vast majority of crashes is due to pilot error because the vast majority of possible crashes due to equipment failures are prevented by the pilots.
Before automation, the vast majority of crashes were caused by pilot errors or pilots failing to respond properly to emergencies due to being too tired from flying the plane. Automation lets pilots save most of their energy for when it counts instead of tiring themselves out with routine flight procedures like keeping their hands on the control column for hours at a time, just trying to stay in the middle of their flight level.
Imagine if we removed autopilot and all other automation from 777s and A380s overnight so pilots had to be hands-on from taxiing out of the parking at their origin all the way to taxiing into their parking space at their destination. I bet the number of crashes would increase considerably. If you really are a pilot, you should be able to imagine how micro-managing every aspect of modern planes from start to finish while attempting to maintain a rock-steady flight path and altitude could give you a splitting headache in no time flat... modern planes are simply not designed to be humanly manageable for extended periods.
As for all those automation failures you mentioned, many of those would not happen if automation was not designed with the assumption of attentive and well-trained pilots on-board: pilot-less flights would have extra sensors and extra ground, air and space based infrastructure to help them perform sanity check when on-board sensors start to disagree before the malfunction has a chance to escalate into a full-blown emergency. Current automation simply disengages when something weird happens and lets the pilots deal with it, which often makes things worse when pilots are not paying close enough attention to notice the impending emergency before the autopilot dumps it on their lap.
There already is a lot of automation in fly-by-wire planes where the software is designed to detect faults and automatically compensate for many common failures. Some aircraft manufacturers are even contemplating emulating stabilizer fins by software tweaks to the wings' control surfaces, which sounds a bit scary IMO: so much control on so few actuators/sensors; this would require redefining absolute confidence.
At the end of the day, all programming languages are about abstracting things. If you are testing the intrinsic security of a programming language, you are in essence testing how successful the language's built-in data types, built-in functions, APIs, standard libraries, etc. are at mitigating risk factors, which is all about abstraction.
A language's intrinsic security is only as good as its abstractions.
The best solution for the court's display system would be to hard-wire it so they would not have to worry about WiFi.
Putting up routers with temporary internet access won't help them if reporters and whoever else is in the room continue using their own hotspot or ad-hoc network - people in the room might not like the idea of going through the public WiFi or having to re-configure all their own wireless stuff.
It may be "only one tool" but it is representative of the rapidly escalating cost and effort that goes with pushing fundamental physics to the next level.
The point was not about precluding discoveries elsewhere but how proving new theories and refining existing ones is thousands, if not millions of times more expensive than it used to be.
100 years ago, researchers could make fundamental physics discoveries in their garage. Today, further advancements in fundamental physics require things like the LHC. Fundamental science moved pretty far up on the cost and effort curve - much faster than any budget can keep up with.
You would likely still want to retain fuel transfer capabilities in order to rescue carriers if their on-board fuel generators go offline for whatever reason until they can be repaired or swapped out and supply other ships along the way anyway.
Windows is more convenient than DOS when I need to access something on a network share or just need to take/read notes or do other copy-pasting on the side.
As for Linux, the CDT430 only has 16MB RAM. Most remotely recent Linux distributions will not even install with less than 256MB RAM.
You also have the extremely high current arcs between the rails and the projectile super-heating air around it, sputtering material from both the rails and slug, oxidizing in air when it exits the plasma cloud.
Since when is fuel transfer costly or complicated? Even if your reduce or eliminate fuel transfer to the carrier, you still need fuel transfer to everything else.
Even if carriers did not need fuel, they would still require food resupply, equipment resupply, spare parts resupply, munitions resupply, crew swaps, etc. so carriers and other ships would still need to meet with supply ships every other week even if you take fuel out of the equation.
Except gas stations need to also be usable by handicaped people too.
The electrical cable may be roughly the same size as the fuel hose but the volumetric mass of gasoline is much lower than copper and a low-pressure hose is still far more flexible than a thick copper cable. That electrical cable also needs fool-proof cable insulation and some form of equally fool-proof and well-insulated charging paddle with fairly beefy copper/brass slugs which may add a fair amount of weight too unless they crank voltages much higher... but that would require thicker, tougher and more resilient insulation to prevent electrocutions.
Extremely fast charge times look nice in theory but I have a hard time imagining it working out in practice. Most people use their cars to go to work (20-50km trip) or go to other places where they are away from their cars for 60+ minutes at a time so in most cases, ultra-fast charging is not really necessary if ubiquitous parking charging is available: you go to work and spend 3-4 hours in the office before going out to lunch then 3-4 more hours in the office before going home with the car parked overnight; that's ~18h/day the car can be on slow-charge not counting possible additional charge time on the shopping mall, restaurant and wherever else's parking lot.
Aside from long road trips where you have no intention to stop any longer than absolutely necessary, ultra-fast recharge has somewhat limited real uses.
There are tons of documentation for Linux. The problem is it is scattered all over the place, written by thousands of volunteers in nearly as many different styles, non-uniform structures, various degrees of success and thoroughness at cross-referencing other relevant documentation, etc. which makes getting things done under Linux a lot more frustrating for the uninitiated than it should be when compared against VisualStudio and MSDN.
Microsoft's APIs might not be the prettiest or cleanest but they are quite well documented in a very uniform and coherent manner, which makes them relatively pleasant to work with.
In either case though, most people end up writing wrappers to take care of the redundant, tedious and unintuitive bits so they only need to worry about them once so it is not too much of an issue either way much beyond the first time.
While a fire MIGHT explain some of it, I have a hard time with that theory: this is a fly-by-wire plane so if control wiring gets damaged by a fire, I would not expect it to continue flying very long unless said fire only affected communications between the cockpit and electronics bay but if the fire only affected that, pilots would have quickly realized they were losing control over the plane much faster than anything covered in their flight manual can explain, leaving them little choice but to phone home and request assistance from Boeing engineers to recover control.
Also, as soon as pilots know they have a fire on-board that they cannot put out with 100% certainty, landing the plane reaches the top of their priority list pretty quickly and requesting diversion to the nearest airport preferably with full emergency services due to a fire emergency would be near the top of that procedure so pilots can focus on flying/landing and ground crews can get ready.
With the number of smoke detectors in planes, pilots should have known about the (hypothetical) fire long before instruments and controls started failing and I have a hard time how an event severe enough to take out all external communications practically all at once would have left the plane flight-worthy for hours.
With cloud-based stuff, you never know how soon plugs are going to get pulled.
On the plus side, people may become more aware and wary of what may happen when depending on online services so we may hopefully have more offline options in the future.
This sort of system would be good for driving in secondary streets (stop signs instead of lights) and where right turns on red lights are allowed where drivers often do not need to stop any longer than necessary to verify it is safe to cross. With the flywheel, you can do both quick stops and quick starts without worrying so much about fuel efficiency. On main streets where lights are timed for a specific speed, accelerating too slowly may cause you to either be too late for the next green light or cause many drivers behind you to miss it, which is sometimes considered dangerously low speed.
In an automatic transmission, a slow acceleration has higher losses in the torque converter until it spins fast enough to lock and slow braking wears brakes down more quickly.
Your definition of SUCCESSFUL landing includes planes breaking apart?
The Hudson plane landed in one piece and floated long enough for everyone to safely evacuate and rescuers to get on-site with only five serious injuries out of 150+ people aboard while the Lion flight's fuselage broke into two pieces with four serious injuries out of ~110 people aboard and could have easily been much worse.
BTW, does landing in water so shallow it barely reaches wings-high (bottom of fuselage, presumably with collapsed landing gears from the photos I have seen) really qualify as a water landing? The plane crashed into pretty solid stuff just below the surface and obviously won't sink if it is already resting on the bottom; the Lion 904 looks more like a beached whale than a plane that landed in water. Things would have likely been much nastier if 904 had been a true water landing without land just below the surface preventing it from nose-diving in the water, sending the plane in a cartwheel or whatever other random direction it may have taken without ground to constrain it.
Now, the message I was originally replying to was about MH370 landing on water intact enough to remain afloat. The Hudson plane had perfect water landing conditions but still lost one engine, damaged a cargo door and ripped a bit of fuselage on impact, which is all relatively minor damage but significant for how quickly the plane is going to take on water. The southern Indian ocean has 30-50km/h winds and 1-2m waves even on a good day; nowhere near ideal for replicating the Hudson miracle... and in MH370's case, we are talking about a 777 which would be even more difficult to land in one piece on water since stresses across the airframe would be considerably higher.
The Hudson miracle is not a miracle only because everyone survived. It is a miracle because the plane itself was also nearly intact.
Landing a large plane on water is nearly impossible even under the best circumstances: the moment wings hit the water, they usually get ripped apart, sending the rest of the plane in a tumble that rips the rest of it apart. Hitting water at 200+km/h is like hitting a concrete block.
AFAIK, the only such successful landing in history is the Hudson miracle and that was only possible because the river waters were almost perfectly still and the pilots managed perfect execution - the impact still ripped one of the engines off. It would not be possible in oceanic waters with crosswinds, bad weather, waves and unknown water currents.
Slashdot Mirror
From the looks of it, many of the (potential) bugs in OpenSSL are caused by the use of a custom memory allocation scheme instead of a standard C allocator. Removing the custom memory management in favor of standard memory management alone implies dozens if not hundreds of relatively trivial code changes to all the places where the custom (de-)allocator get used. In the process of tracking down all of these, they come across stuff that does not look right and fix it while they are already in there.
As for why so many bugs, "so many eyes" only works if you still have tons of people actively participating in the project's development. At a glance, it seems like the OpenBSD guys are saying the OpenSSL project was getting stale. Stale projects do not have anywhere near as many eyes going through their code nor as many people actively looking for potential bugs to fix before they get reported in the wild.
In short: OpenSSL was long overdue for a make-over.
What makes ethanol act as a fuel anti-freeze is by mixing with moisture to lower the freezing point of water and help keep it blended with the fuel so it does not pool up as much... it is not the fuel that freezes; it is its moisture load and water condensation inside the tank. If you lower the ethanol content too much, ice crystals may clog or jam the pump, fuel filter, injectors or any other component where flow restrictions and water accumulation may occur.
If you live in an area of where temperatures drop a fair bit below freezing for a fair chunk of the year, you would end up adding ethanol as a fuel anti-freeze. It is also a weak solvent for compounds that are not soluble in gasoline, absorbs moisture, reduces the likelihood of engine knocking and a handful of other benefits.
Ethanol does have lower energy density than gasoline but it has enough benefits for some amount of it still being generally desirable - if you removed all ethanol from gasoline, gas companies would likely replace it with a more complex additive cocktail that might not perform quite as good.
> The vast majority of crashes is due to pilot error because the vast majority of possible crashes due to equipment failures are prevented by the pilots.
Before automation, the vast majority of crashes were caused by pilot errors or pilots failing to respond properly to emergencies due to being too tired from flying the plane. Automation lets pilots save most of their energy for when it counts instead of tiring themselves out with routine flight procedures like keeping their hands on the control column for hours at a time, just trying to stay in the middle of their flight level.
Imagine if we removed autopilot and all other automation from 777s and A380s overnight so pilots had to be hands-on from taxiing out of the parking at their origin all the way to taxiing into their parking space at their destination. I bet the number of crashes would increase considerably. If you really are a pilot, you should be able to imagine how micro-managing every aspect of modern planes from start to finish while attempting to maintain a rock-steady flight path and altitude could give you a splitting headache in no time flat... modern planes are simply not designed to be humanly manageable for extended periods.
As for all those automation failures you mentioned, many of those would not happen if automation was not designed with the assumption of attentive and well-trained pilots on-board: pilot-less flights would have extra sensors and extra ground, air and space based infrastructure to help them perform sanity check when on-board sensors start to disagree before the malfunction has a chance to escalate into a full-blown emergency. Current automation simply disengages when something weird happens and lets the pilots deal with it, which often makes things worse when pilots are not paying close enough attention to notice the impending emergency before the autopilot dumps it on their lap.
There already is a lot of automation in fly-by-wire planes where the software is designed to detect faults and automatically compensate for many common failures. Some aircraft manufacturers are even contemplating emulating stabilizer fins by software tweaks to the wings' control surfaces, which sounds a bit scary IMO: so much control on so few actuators/sensors; this would require redefining absolute confidence.
At the end of the day, all programming languages are about abstracting things. If you are testing the intrinsic security of a programming language, you are in essence testing how successful the language's built-in data types, built-in functions, APIs, standard libraries, etc. are at mitigating risk factors, which is all about abstraction.
A language's intrinsic security is only as good as its abstractions.
My 486 used SIPP memory... same thing as a SIMM but with leads soldered on them to plug in a header instead of a card-edge memory slot.
The best solution for the court's display system would be to hard-wire it so they would not have to worry about WiFi.
Putting up routers with temporary internet access won't help them if reporters and whoever else is in the room continue using their own hotspot or ad-hoc network - people in the room might not like the idea of going through the public WiFi or having to re-configure all their own wireless stuff.
It may be "only one tool" but it is representative of the rapidly escalating cost and effort that goes with pushing fundamental physics to the next level.
The point was not about precluding discoveries elsewhere but how proving new theories and refining existing ones is thousands, if not millions of times more expensive than it used to be.
100 years ago, researchers could make fundamental physics discoveries in their garage. Today, further advancements in fundamental physics require things like the LHC. Fundamental science moved pretty far up on the cost and effort curve - much faster than any budget can keep up with.
You would likely still want to retain fuel transfer capabilities in order to rescue carriers if their on-board fuel generators go offline for whatever reason until they can be repaired or swapped out and supply other ships along the way anyway.
And that was exactly what I said.
If you use the carrier as the fuel supply ship, the carrier still needs full fuel transfer facilities and crew.
Windows is more convenient than DOS when I need to access something on a network share or just need to take/read notes or do other copy-pasting on the side.
As for Linux, the CDT430 only has 16MB RAM. Most remotely recent Linux distributions will not even install with less than 256MB RAM.
You also have the extremely high current arcs between the rails and the projectile super-heating air around it, sputtering material from both the rails and slug, oxidizing in air when it exits the plasma cloud.
Since when is fuel transfer costly or complicated? Even if your reduce or eliminate fuel transfer to the carrier, you still need fuel transfer to everything else.
Even if carriers did not need fuel, they would still require food resupply, equipment resupply, spare parts resupply, munitions resupply, crew swaps, etc. so carriers and other ships would still need to meet with supply ships every other week even if you take fuel out of the equation.
I have an old Toshiba CDT430 running Win95-OSR2. I use it mainly as a portable serial console.
Except gas stations need to also be usable by handicaped people too.
The electrical cable may be roughly the same size as the fuel hose but the volumetric mass of gasoline is much lower than copper and a low-pressure hose is still far more flexible than a thick copper cable. That electrical cable also needs fool-proof cable insulation and some form of equally fool-proof and well-insulated charging paddle with fairly beefy copper/brass slugs which may add a fair amount of weight too unless they crank voltages much higher... but that would require thicker, tougher and more resilient insulation to prevent electrocutions.
Extremely fast charge times look nice in theory but I have a hard time imagining it working out in practice. Most people use their cars to go to work (20-50km trip) or go to other places where they are away from their cars for 60+ minutes at a time so in most cases, ultra-fast charging is not really necessary if ubiquitous parking charging is available: you go to work and spend 3-4 hours in the office before going out to lunch then 3-4 more hours in the office before going home with the car parked overnight; that's ~18h/day the car can be on slow-charge not counting possible additional charge time on the shopping mall, restaurant and wherever else's parking lot.
Aside from long road trips where you have no intention to stop any longer than absolutely necessary, ultra-fast recharge has somewhat limited real uses.
There are tons of documentation for Linux. The problem is it is scattered all over the place, written by thousands of volunteers in nearly as many different styles, non-uniform structures, various degrees of success and thoroughness at cross-referencing other relevant documentation, etc. which makes getting things done under Linux a lot more frustrating for the uninitiated than it should be when compared against VisualStudio and MSDN.
Microsoft's APIs might not be the prettiest or cleanest but they are quite well documented in a very uniform and coherent manner, which makes them relatively pleasant to work with.
In either case though, most people end up writing wrappers to take care of the redundant, tedious and unintuitive bits so they only need to worry about them once so it is not too much of an issue either way much beyond the first time.
While a fire MIGHT explain some of it, I have a hard time with that theory: this is a fly-by-wire plane so if control wiring gets damaged by a fire, I would not expect it to continue flying very long unless said fire only affected communications between the cockpit and electronics bay but if the fire only affected that, pilots would have quickly realized they were losing control over the plane much faster than anything covered in their flight manual can explain, leaving them little choice but to phone home and request assistance from Boeing engineers to recover control.
Also, as soon as pilots know they have a fire on-board that they cannot put out with 100% certainty, landing the plane reaches the top of their priority list pretty quickly and requesting diversion to the nearest airport preferably with full emergency services due to a fire emergency would be near the top of that procedure so pilots can focus on flying/landing and ground crews can get ready.
With the number of smoke detectors in planes, pilots should have known about the (hypothetical) fire long before instruments and controls started failing and I have a hard time how an event severe enough to take out all external communications practically all at once would have left the plane flight-worthy for hours.
With cloud-based stuff, you never know how soon plugs are going to get pulled.
On the plus side, people may become more aware and wary of what may happen when depending on online services so we may hopefully have more offline options in the future.
This sort of system would be good for driving in secondary streets (stop signs instead of lights) and where right turns on red lights are allowed where drivers often do not need to stop any longer than necessary to verify it is safe to cross. With the flywheel, you can do both quick stops and quick starts without worrying so much about fuel efficiency. On main streets where lights are timed for a specific speed, accelerating too slowly may cause you to either be too late for the next green light or cause many drivers behind you to miss it, which is sometimes considered dangerously low speed.
In an automatic transmission, a slow acceleration has higher losses in the torque converter until it spins fast enough to lock and slow braking wears brakes down more quickly.
Your definition of SUCCESSFUL landing includes planes breaking apart?
The Hudson plane landed in one piece and floated long enough for everyone to safely evacuate and rescuers to get on-site with only five serious injuries out of 150+ people aboard while the Lion flight's fuselage broke into two pieces with four serious injuries out of ~110 people aboard and could have easily been much worse.
BTW, does landing in water so shallow it barely reaches wings-high (bottom of fuselage, presumably with collapsed landing gears from the photos I have seen) really qualify as a water landing? The plane crashed into pretty solid stuff just below the surface and obviously won't sink if it is already resting on the bottom; the Lion 904 looks more like a beached whale than a plane that landed in water. Things would have likely been much nastier if 904 had been a true water landing without land just below the surface preventing it from nose-diving in the water, sending the plane in a cartwheel or whatever other random direction it may have taken without ground to constrain it.
Now, the message I was originally replying to was about MH370 landing on water intact enough to remain afloat. The Hudson plane had perfect water landing conditions but still lost one engine, damaged a cargo door and ripped a bit of fuselage on impact, which is all relatively minor damage but significant for how quickly the plane is going to take on water. The southern Indian ocean has 30-50km/h winds and 1-2m waves even on a good day; nowhere near ideal for replicating the Hudson miracle... and in MH370's case, we are talking about a 777 which would be even more difficult to land in one piece on water since stresses across the airframe would be considerably higher.
The Hudson miracle is not a miracle only because everyone survived. It is a miracle because the plane itself was also nearly intact.
Landing a large plane on water is nearly impossible even under the best circumstances: the moment wings hit the water, they usually get ripped apart, sending the rest of the plane in a tumble that rips the rest of it apart. Hitting water at 200+km/h is like hitting a concrete block.
AFAIK, the only such successful landing in history is the Hudson miracle and that was only possible because the river waters were almost perfectly still and the pilots managed perfect execution - the impact still ripped one of the engines off. It would not be possible in oceanic waters with crosswinds, bad weather, waves and unknown water currents.