Self-healing fuses are common in the industry and cost pennies. There isn't really an excuse for a device that fries simply because it is asked, in error, to deliver too much current. In contrast, there are other ways that a mis-wire could damage equipment that the manufacturer would have a hard time protecting against.
Yes, I think pre-made 3D databases will be an input but far from the only one. Vision and radar have to dominate because there is never proof that the model matches reality, just a caution flag when it does not.
Just check the source next time, please. If you can't read it or it makes claims that are far from practicality, pass it by. I bet the energy is miniscule.
They did a test burn of the first one, which showed some engine damage, maybe debris in it. It will be interesting to see if they get a clean burn this time.
Slashdot is still doing this. Ugh. It's not much better than the typical science-fair story.
How much energy? I can make a free-power radio receiver with not much more than a long wire and a rectifier. It will feed your earbuds but it won't charge your Tesla.
There is also the prospect of dirt getting in the way when things depend on one-molecule-thick layers.
Elon said today in the post-launch press-conference that recovery meant a potential of 1/100 in present operating cost but that fixed cost would not change from recovery. He is trying to reduce fixed cost with additional automation and of course there are economies of scale. 30% is what they can start with and make a profit, which they have to do now. I believe they can achieve a significantly larger reduction over the long term.
SpaceX has stated that about 30% of rockets launched overall will be able to RTLS. That's why the barge is so critical. F9 Heavy will only be able to RTLS depending on the total delta-V demanded for the mission. There is a delta-V cost for RTLS, you can't just do it on the grid fins.
It looked like pretty rough seas, too. The next step is that someone goes on the barge and welds shoes over the landing gear to hold it to the deck. There may also be something that fastens to the "octoweb", the frame that holds the engines at the bottom of the first stage.
Believe it or not, welding something to the steel is fast, and easy to un-do. You just cut it off with the same welding equipment, and use an angle grinder to remove the bead.
Obviously now we have to see the recovery percentage that SpaceX can achieve, especially when they start landing Falcon Heavy on three barges, the one for the center booster being much farther downrange than the others. Seeing three land, two of them simultaneously, is going to be pretty amazing. If they can recover a lot of them, this completely changes the economics of space flight beyond the 30% discount SpaceX is quoting in the short term.
And don't forget that they are getting the Dragon back too, and Dragon 2 with its eventual ground-landing capability is expected to be reusable. Currently Dragon 1 lands in sea water, and the reuse they have so far is only of the pressure vessel, the capsule is stripped down to that and rebuilt.
Recovering the second stage is possible although not currently on the SpaceX roadmap. They would need to fly it with a heat shield.
Now, consider what it would take to land a Dragon on the moon and return. Not inconceivable, given Falcon Heavy and a few launches.
RSC Energia has made press releases about its work on inflatable space station modules since 2013 and has not flown one yet, nor have they announced when they will fly one. There is so far no evidence that they are handling the project with more speed or lower cost than NASA, ESA, or JAXA, or indeed that the project will ever result in flown hardware.
There are two ways a buffer overflow could happen in a memory-safe language:
1) The language could detect an attempted boundary violation using its own boundary-check code, refuse to complete it, and then take a defined action. The defined action would probably be to throw an exception, reset the driver state, unwind the stack out of the driver, and cause an error or exception to the caller. This would not crash the kernel and removes a large number of errors that previously could crash the kernel.
2) Hardware could cause the problem. This would indeed crash the kernel.
The point is what can cause a memory error. A properly-implemented memory-safe language will not overflow buffers as a result of code execution only, whether it's in kernel or user space. Its I/O functions will respect buffer boundaries. It can potentially have various sorts of memory errors as a result of improperly-programmed hardware.
User-space code in a type-safe language that makes memory-mapped access to the graphics card might still dump core as a result of the software/hardware interaction.
Show me a portable, standards-compliant way to phrase a URL so that it uses a specific network interface. As far as I know, there isn't one. To state this cleanly, I would really like to write this:
Unfortunately, your assumptions only apply when memory-mapped hardware is not involved. In other words, when the code in question isn't a device driver. Once it is, you have the potential to bus-fault when you mis-program the hardware and it fails to respond to your mapped reference, wild DMAs to any address can happen due to incorrect programming, etc.
One of the big mistakes being made is that filesystem and communication services need not come from the local operating system. Process and memory management and just enough networking to open the filesystem/communication server connection needs to come from the local OS.
My Supermicro C7x99-oce-f doesn't support ECC, does support non-Xeon CPUs, the sound interface is from RealTek, and the Aspeed IPMI integrates a low-end display chip and its firmware doesn't handle having another display card in the system well.
It's sort of everything people in this thread say Supermicro isn't.
Slashdot Mirror
Self-healing fuses are common in the industry and cost pennies. There isn't really an excuse for a device that fries simply because it is asked, in error, to deliver too much current. In contrast, there are other ways that a mis-wire could damage equipment that the manufacturer would have a hard time protecting against.
Sure, it can happen. We also have 50-car pile-ups in the fog where human drivers have the same problem and fail to stop.
People are really bad drivers, because they're not monomaniacal about it. Computers are, and are ultimately going to be better drivers than us.
Actually, I would be perfectly happy to have an autonomous vehicle that required human take-over 10% of the time. Just not very suddenly.
Yes, I think pre-made 3D databases will be an input but far from the only one. Vision and radar have to dominate because there is never proof that the model matches reality, just a caution flag when it does not.
Probably. But I would not hold out for 10 years.
Just check the source next time, please. If you can't read it or it makes claims that are far from practicality, pass it by. I bet the energy is miniscule.
It is there, just color-encrypted so that 8% of US males can't see it.
No sympathy for us color blind folks...
Right. Where's the link?
Don't confuse autonomous driving with lane assist. Real autonomous driving has much more input data than visibility of white lines.
They did a test burn of the first one, which showed some engine damage, maybe debris in it. It will be interesting to see if they get a clean burn this time.
Slashdot is still doing this. Ugh. It's not much better than the typical science-fair story.
How much energy? I can make a free-power radio receiver with not much more than a long wire and a rectifier. It will feed your earbuds but it won't charge your Tesla.
There is also the prospect of dirt getting in the way when things depend on one-molecule-thick layers.
Elon said today in the post-launch press-conference that recovery meant a potential of 1/100 in present operating cost but that fixed cost would not change from recovery. He is trying to reduce fixed cost with additional automation and of course there are economies of scale. 30% is what they can start with and make a profit, which they have to do now. I believe they can achieve a significantly larger reduction over the long term.
SpaceX has stated that about 30% of rockets launched overall will be able to RTLS. That's why the barge is so critical. F9 Heavy will only be able to RTLS depending on the total delta-V demanded for the mission. There is a delta-V cost for RTLS, you can't just do it on the grid fins.
It looked like pretty rough seas, too. The next step is that someone goes on the barge and welds shoes over the landing gear to hold it to the deck. There may also be something that fastens to the "octoweb", the frame that holds the engines at the bottom of the first stage.
Believe it or not, welding something to the steel is fast, and easy to un-do. You just cut it off with the same welding equipment, and use an angle grinder to remove the bead.
Obviously now we have to see the recovery percentage that SpaceX can achieve, especially when they start landing Falcon Heavy on three barges, the one for the center booster being much farther downrange than the others. Seeing three land, two of them simultaneously, is going to be pretty amazing. If they can recover a lot of them, this completely changes the economics of space flight beyond the 30% discount SpaceX is quoting in the short term.
And don't forget that they are getting the Dragon back too, and Dragon 2 with its eventual ground-landing capability is expected to be reusable. Currently Dragon 1 lands in sea water, and the reuse they have so far is only of the pressure vessel, the capsule is stripped down to that and rebuilt.
Recovering the second stage is possible although not currently on the SpaceX roadmap. They would need to fly it with a heat shield.
Now, consider what it would take to land a Dragon on the moon and return. Not inconceivable, given Falcon Heavy and a few launches.
RSC Energia has made press releases about its work on inflatable space station modules since 2013 and has not flown one yet, nor have they announced when they will fly one. There is so far no evidence that they are handling the project with more speed or lower cost than NASA, ESA, or JAXA, or indeed that the project will ever result in flown hardware.
There are two ways a buffer overflow could happen in a memory-safe language:
1) The language could detect an attempted boundary violation using its own boundary-check code, refuse to complete it, and then take a defined action. The defined action would probably be to throw an exception, reset the driver state, unwind the stack out of the driver, and cause an error or exception to the caller. This would not crash the kernel and removes a large number of errors that previously could crash the kernel.
2) Hardware could cause the problem. This would indeed crash the kernel.
Say share-and-share-alike. "viral" is pejorative and it's not in our interest to continue its usage.
The point is what can cause a memory error. A properly-implemented memory-safe language will not overflow buffers as a result of code execution only, whether it's in kernel or user space. Its I/O functions will respect buffer boundaries. It can potentially have various sorts of memory errors as a result of improperly-programmed hardware.
User-space code in a type-safe language that makes memory-mapped access to the graphics card might still dump core as a result of the software/hardware interaction.
They made big and terrible mistakes, and cried all the way to the bank :-)
I liked the iAPX 432. Except that back then it was insufferably slow. Today we could do it right.
Show me a portable, standards-compliant way to phrase a URL so that it uses a specific network interface. As far as I know, there isn't one. To state this cleanly, I would really like to write this:
For example:
and
Unfortunately, your assumptions only apply when memory-mapped hardware is not involved. In other words, when the code in question isn't a device driver. Once it is, you have the potential to bus-fault when you mis-program the hardware and it fails to respond to your mapped reference, wild DMAs to any address can happen due to incorrect programming, etc.
You mean this?
One of the big mistakes being made is that filesystem and communication services need not come from the local operating system. Process and memory management and just enough networking to open the filesystem/communication server connection needs to come from the local OS.
My Supermicro C7x99-oce-f doesn't support ECC, does support non-Xeon CPUs, the sound interface is from RealTek, and the Aspeed IPMI integrates a low-end display chip and its firmware doesn't handle having another display card in the system well.
It's sort of everything people in this thread say Supermicro isn't.