Alpha Particles.. Lol... This author did not do his homework.. I piece of paper can stop an Alpha Particle... No way is an Alpha going to penetrate all the matter surrounding the memory silicon..
No, the AC fails his homework. The alpha particles that caused problems in the past came from inside the chip packaging itself. DRAM manufacturers now go to great lengths to exclude any isotopes that could undergo alpha decay in their chips.
- among digitally transferred currencies.... *without* central control is in fact a necessity towards progress away from immoral war, murder, theft via taxation... and toward self enablement and charity for all human beings
- electricity consumption by cryptocurrency *absolutely unequivocally FAILS* to even come close the that consumed by all the systems supporting the worlds Fiats.... their politicians salaries healt retirement, their buildings construction maintenanace heating cooling, all their cars and fuel and environmental impacts etc.
Cryptocurrency takes only highly optimized, narrow silos of - Silicon sand - Electricity of any source - Internet (sand + electricity)
You forgot the fourth, fat, silo: -Kool-Aid
You'll need plenty more of that, given your current levels of consumption.
That's one reason for what I stated. You can still transfer value without central control, the same way it has always been done. Adding this particular "digital" way doesn't justify the huge consumption of energy resources that it involves.
Bitcoin has utility. It is the only way of digitally transferring value that is not centrally controlled and not a copycat.
You know, human civilization somehow made it through its first 5,000 years without any means to "digitally transfer value without central control". That doesn't seem to be a problem that's been holding back human achievement in any significant way, and certainly not to the extent that it needs to have a big chunk of the world's electricity output thrown at it.
You spit out a whole bunch of technical minutia, all of which is completely irrelevant to actual people.
Since you're too focused on the details to figure it out, here's a hint about he key difference between the two systems: The user interface on the phone network is almost invariably hooked to a fucking ringer which interrupts people and demands a real-time response. The internet is not.
"But the phone goes over the internet N layers down in the protocol!!!" Shut up.
"But the phone company doesn't know anything about the caller ID they invented!!" They'll make sure they know real quick if they're made financially liable.
Under just what law and in what jurisdiction do you have standing to sue over "property damage" in outer space? After all, you left your property far outside the boundaries of this nation altogether.
What kind of a deterrent do you think these lawsuits would be anyway? Clearly, some jackass could destroy hundreds of billions of dollars worth of hardware with just a few million dollars invested in launching space debris. Would any of these people actually get remuneration? Of course not.
It makes far more sense for the government to simply forbid launching space debris, just like it forbids you from murdering people. Luckily, feeble-minded hard-core libertarians who can't comprehend this fact consistently comprise about 1% of the electorate, so we don't really have to worry about such scenarios.
Someone else on this discussion pointed out that somehow, the FCC does seem to be in charge of regulating satellite orbits. Somebody has to do it, regardless of you ill-formed opinions.
But more importantly, In you libertarian paradise, what happens to the happiness of the Free Citizens who paid billions of dollars for the existing satellites that will get wiped out by all this sand and gravel? Are they now supposed to exercise their 2nd Amendment rights, stand their ground and shoot these gravel lofters in retaliation for destroying their property?
1. The compilers were incompatible in that they didn't even accept the same definition of what "C++" was, causing many developers to devote much effort in finding some common subset that would compile on different platforms, or writing a bunch of confusing #ifdefs. This resulted in less time to look for actual bugs.
2. On a different topic not involving mutual compatibility, each of the compilers would often create new bugs out of whole cloth by spitting out bad machine code that did not conform to even what the crappy C++ specs of the time hinted should happen.
That's right: any attempt to regulate the radio spectrum is FASCIST!!!1!!!
The only way to manage radio transmissions that without enslaving Free Citizens is a free-for-all. Let the man with the biggest amplifier and the biggest dish win; any attempt to keep him down is tyranny.
When I RFTA I was floored by the statement "When I first learned C++ in college, it was expected that sometimes your program would crash." - the author implies that it just happens but that's never been true and I would really be hesitant about hiring a programmer that accepted that his programs sometimes crash.
I was there in the late 80s ad early 90s, and I can assure you that almost without exception, nontrivial C++ programs written in that era crashed regularly, regardless of who wrote them. The compilers were total crap and incompatible between vendors, the specifications were poor, aids like STL didn't exist or were too buggy to use, "best practices" had not yet been identified, and there were few modern software quality tools to help.
Heartbleed was a buffer overflow in an already allocated pool. Memory safety wouldn't have mitigated it.
In many memory-safe languages, the Heartbleed bug would have been highly unlikely to actually happen in real-world usage.
The problem was that they allocated a large buffer based on a "payload size" field in the request, but the request actually had a small payload, so the message sent included the random system data between those sizes. The programmers using manual buffer management confused the principles of buffer capacity and data length.
If they had written the program in Go, for example, they would most likely have used "slices" to hold buffers like this. Slices automatically keep track of the capacity and length for you. They probably would have allocated a slice with a capacity defined by the payload size field, but then used the append() function (or similar operation) to actually move the payload data to the slice, which keeps track of the actual length of valid data. They would then send the data from the slice in the response, and this would not include any extra data beyond the valid length.
Further protection would be provided by the fact that the Go runtime zeros out memory when first allocated. Unless the slice gets reused, there would be no sensitive data to send anyway. If the slice were reused, it would probably contain only previous message data, which is a much smaller range of information than random data from the heap.
Slashdot Mirror
Alpha Particles.. Lol... This author did not do his homework.. I piece of paper can stop an Alpha Particle... No way is an Alpha going to penetrate all the matter surrounding the memory silicon..
No, the AC fails his homework. The alpha particles that caused problems in the past came from inside the chip packaging itself. DRAM manufacturers now go to great lengths to exclude any isotopes that could undergo alpha decay in their chips.
"*I* didn't run over that little kid in the crosswalk.
The car I was driving did!"
Once again, the so-called tech visionaries have been proven wrong:
Five cameras ought to be enough for anybody.
--Bill Gates, 1992
Except that
- among digitally transferred currencies.... *without* central control is in fact a necessity towards progress away from immoral war, murder, theft via taxation... and toward self enablement and charity for all human beings
- electricity consumption by cryptocurrency *absolutely unequivocally FAILS* to even come close the that consumed by all the systems supporting the worlds Fiats.... their politicians salaries healt retirement, their buildings construction maintenanace heating cooling, all their cars and fuel and environmental impacts etc.
Cryptocurrency takes only highly optimized, narrow silos of
- Silicon sand
- Electricity of any source
- Internet (sand + electricity)
You forgot the fourth, fat, silo:
-Kool-Aid
You'll need plenty more of that, given your current levels of consumption.
That's one reason for what I stated. You can still transfer value without central control, the same way it has always been done. Adding this particular "digital" way doesn't justify the huge consumption of energy resources that it involves.
Bitcoin has utility. It is the only way of digitally transferring value that is not centrally controlled and not a copycat.
You know, human civilization somehow made it through its first 5,000 years without any means to "digitally transfer value without central control". That doesn't seem to be a problem that's been holding back human achievement in any significant way, and certainly not to the extent that it needs to have a big chunk of the world's electricity output thrown at it.
Everybody's an expert, except the people who actually design/build them.
You appear to be attempting sarcasm, but in the case of NASA, that's literally been true ever since the mid 70s.
It appears that somebody made an inopportune announcement before verifying all the facts.
So you're happy with retreating. Most people aren't.
A phone without a ringer would be next to useless.
The solution is not to make people retreat from using phones the way they always have. Instead, it's to eliminate bot scammers.
Guess you missed the memo that the Deep State refactored the Constitution. The replacement is called 'mercantilism'.
It's odd then that the Deep State is allegedly opposed to the current mercantilist U.S. President.
Blah, blah, blah...
You spit out a whole bunch of technical minutia, all of which is completely irrelevant to actual people.
Since you're too focused on the details to figure it out, here's a hint about he key difference between the two systems: The user interface on the phone network is almost invariably hooked to a fucking ringer which interrupts people and demands a real-time response. The internet is not.
"But the phone goes over the internet N layers down in the protocol!!!"
Shut up.
"But the phone company doesn't know anything about the caller ID they invented!!"
They'll make sure they know real quick if they're made financially liable.
Under just what law and in what jurisdiction do you have standing to sue over "property damage" in outer space? After all, you left your property far outside the boundaries of this nation altogether.
What kind of a deterrent do you think these lawsuits would be anyway? Clearly, some jackass could destroy hundreds of billions of dollars worth of hardware with just a few million dollars invested in launching space debris. Would any of these people actually get remuneration? Of course not.
It makes far more sense for the government to simply forbid launching space debris, just like it forbids you from murdering people. Luckily, feeble-minded hard-core libertarians who can't comprehend this fact consistently comprise about 1% of the electorate, so we don't really have to worry about such scenarios.
. In C they could also probably just have checked the length of the payload.
But they DIDN'T.
The Go runtime does check, every time without fail.
They can sue the dispenser of the gravel for damages, duh...
On what basis? Who controls right-of-way in outer space? The FCC?
Who is going to enforce any judgements? Could it be the very same jackbooted fascist government that you spoke of?
Someone else on this discussion pointed out that somehow, the FCC does seem to be in charge of regulating satellite orbits. Somebody has to do it, regardless of you ill-formed opinions.
But more importantly, In you libertarian paradise, what happens to the happiness of the Free Citizens who paid billions of dollars for the existing satellites that will get wiped out by all this sand and gravel? Are they now supposed to exercise their 2nd Amendment rights, stand their ground and shoot these gravel lofters in retaliation for destroying their property?
I was pointing out two different things:
1. The compilers were incompatible in that they didn't even accept the same definition of what "C++" was, causing many developers to devote much effort in finding some common subset that would compile on different platforms, or writing a bunch of confusing #ifdefs. This resulted in less time to look for actual bugs.
2. On a different topic not involving mutual compatibility, each of the compilers would often create new bugs out of whole cloth by spitting out bad machine code that did not conform to even what the crappy C++ specs of the time hinted should happen.
Right: SpaceX ought to be able to disperse truckloads of sand and gravel in long-lived orbits if paying customers ask them to.
That is irrelevant
That is not irrelevant if the compiler spit out bug-ridden opcodes, which they often did.
That's right: any attempt to regulate the radio spectrum is FASCIST!!!1!!!
The only way to manage radio transmissions that without enslaving Free Citizens is a free-for-all. Let the man with the biggest amplifier and the biggest dish win; any attempt to keep him down is tyranny.
When I RFTA I was floored by the statement "When I first learned C++ in college, it was expected that sometimes your program would crash." - the author implies that it just happens but that's never been true and I would really be hesitant about hiring a programmer that accepted that his programs sometimes crash.
I was there in the late 80s ad early 90s, and I can assure you that almost without exception, nontrivial C++ programs written in that era crashed regularly, regardless of who wrote them. The compilers were total crap and incompatible between vendors, the specifications were poor, aids like STL didn't exist or were too buggy to use, "best practices" had not yet been identified, and there were few modern software quality tools to help.
Heartbleed was a buffer overflow in an already allocated pool. Memory safety wouldn't have mitigated it.
In many memory-safe languages, the Heartbleed bug would have been highly unlikely to actually happen in real-world usage.
The problem was that they allocated a large buffer based on a "payload size" field in the request, but the request actually had a small payload, so the message sent included the random system data between those sizes. The programmers using manual buffer management confused the principles of buffer capacity and data length.
If they had written the program in Go, for example, they would most likely have used "slices" to hold buffers like this. Slices automatically keep track of the capacity and length for you. They probably would have allocated a slice with a capacity defined by the payload size field, but then used the append() function (or similar operation) to actually move the payload data to the slice, which keeps track of the actual length of valid data. They would then send the data from the slice in the response, and this would not include any extra data beyond the valid length.
Further protection would be provided by the fact that the Go runtime zeros out memory when first allocated. Unless the slice gets reused, there would be no sensitive data to send anyway. If the slice were reused, it would probably contain only previous message data, which is a much smaller range of information than random data from the heap.
You, sir, are no Farenheit:
Of course there are microscopic life forms living in our brains. Without them, how would people be able to harness the power of The Force?
The allegation is that Swiss copyright laws are like their cheese?