I'm not sure what is meant by that. Not fast enough to decode in real time? There is/was no need to do that. The transmissions would have gone to tape in any case.
Here is a link describing how to decode such a tape: https://destevez.net/2021/09/decoding-voyager-1/
That recording was made in 2015 on a modern radio telescope, it is not from a tape.
The GP has the details wrong though: when the Voyager design was finalized in the early 70s with the Viterbi encoder, there wasn’t enough computational power to decode the signal. By the time it launched in ‘77, there was enough and it launched with the Viterbi encoder enabled.
Who knows how many of the details I misinterpreted or am misremembering, or that he was. Where did he hear it originally? Maybe a grizzled old professor who worked directly on the project? Maybe a TA who made up the whole thing?
Whether true or not, it inspired me then as it does now to strive to be a better engineer, to think outside the box, to attempt hard things.
I continue sharing it hoping that one day Cunningham's Law will take effect and someone will share the correct details. But there's also a part of me that hopes that never happens.
Though even faster will be doing part of the computation now and then switching to new hardware later, so it's a false dichotomy.
Not necessairly. This still costs:
• Programmer/development time to implement save/restore/transfer
• Time on new hardware, bottlenecked by old hardware, restoring a partial computation from old disks or networks
You're not going to waste time restoring partial calculations for anything from an Amiga cluster for time saving purpouses. Additionally, this scheme ties up hardware that then can't be used for "cost effective to finish on current hardware" calculations.
Though this does assume that X is a constant, or at least bounded below by a constant. If hardware performance improved up to an asymptote, then there would still be nonzero improvement, but it might not be enough for waiting to ever be worth it.
If your disagreement is that a constant is not appropriate here, consider the interpretation in this comparison of running a program on a slower computer A and then a faster computer B. There would be a constant difference in performance between these two computers, assuming they are in working order. So, taking the model with a single constant is appropriate for this example.
If you are saying the performance improvement is bounded below by a constant, I would ask you, what is the domain of this function? Time? So we would be talking about continuously moving a computation between different computers? The only line here is a best fit line, emergent data, so I don't understand how this could be a preferred way to talk about the situation (the alternate to an assumption), because this is suggesting the emergent structure with nice continuity features is a preferred fundamental understanding of the situation, but it's not.
Then, where you are talking about hardware performance improving up to a (assuming horizontal) asymptote. I guess this means "If hardware performance increase becomes marginal[1], there is a nonzero improvement." Or in other words, "If hardware performance increase is marginal, there is a marginal [performance] increase". Performance and improvement are both rates of change, so this is tautological.
Finally, you state that waiting for such a marginal near-zero performance increase isn't worth it. I think most people would agree this is obvious if said in simpler terms. However, this is still not disagreeing with me, because I never suggested waiting was worth it.
So, what's the disagreement?
[1] which is well-established not to be the case, so I don't think this is a relevant case to the interesting factoid about waiting to start computation
Similarly my encrypted internet traffic might be private today but if it’s being logged then it’s only a matter of time before it will be completely visible to the authorities. I probably average ~10Mbps of traffic which is ~50TB/year, or $100 of storage. You could cut that price by 10% if you blacklisted the Netflix traffic, and drop it to 1% if you whitelisted only the email and IM traffic.
Either way, one day they’ll know everything.
Turns out the next generation has their own life to worry about, and doesn't care much for their ancestors' stuff (unless it's money... they love money...).
I guess in our day and age we could write extensive meta data about where and when a picture was taken and who is in the picture, but I don't care to look through my own pictures, why would anyone else?
> Anecdotes about lives of elderly people are nice when you are sitting an evening with a glass of wine and plate of cheese. Otherwise who cares?
I remember some book I read where the child was constantly hearing about his family's history. Dune, maybe? Maybe a Philip Dick book? Asimov? I'm getting old.
People who can profit. And the idea of profit might be different in future.
That attic might contain a priceless vintage synthesizer, that encrypted drive might contain a priceless set of vintage unpublished club penguin screenshots that would make its AI approximation 0.03% more accurate. Etc.
After the death of one of my great uncles who died childless I picked up his photo and music collection. And I discovered the grandfather of a friend of mine in one of his holiday pictures, turns out they used to be friends and we had no idea.
I guess I may be ignoring all those documents that weren’t interesting enough to be remembered, but I imagine it’s hard to predict what will be interesting in the future. The fact that 99% of our lives are stored in computers vs paper would still vastly reduce the number of _interesting_ documents.
Digital assets are a lot more perishable that physical ones. Cloud accounts will expire and be purged before anyone has the chance to retrieve them. Nobody will do "storage wars" with your pictures. Your local storage will fail or become incompatible with future tech before anyone has a chance to care about it.
We generate information at an ever increasing rate so whatever digital collections we have now will probably never be "dug up" by our descendants for a deeper look.
I'm trying to leave a "curated" collection with a few memories in such a way that it's immediately available to my family after I'm no longer around. Some moments in time that were important to my life, and had an influence on theirs.
Lets hope our kids and theirs keep our digital archives long enough for the great grandkid's to enjoy.
I do snap bills and white boards to remember but not with the eager enthusiasm of the long since grown up child.
All the energy released by converting all mass in the solar system into energy apparently gives a hard physical limit just above 2^225 elementary computations before you run out of gas so brute forcing a 256-bit symmetric key seems entirely unfeasible even if all of humanities resources were dedicated to the problem. The calculation is presented here https://security.stackexchange.com/questions/6141/amount-of-... . Waaay out of my field though so this calculation could be off or I could be misunderstanding somehow.
Have a look at this post, which illustrates this reality being true for hash functions (where similar principles as symmetric and asymmetric encryption apply). https://valerieaurora.org/hash.html
Notice Valerie specifically calls out, “Long semi-mathematical posts comparing the complexity of the attack to the number of protons in the universe”.
I think you're making a bit of confusion. hash functions are part of symmetric key cryptography, while asymmetric cryptography is public key cryptography that is very different from hash functions.
In any case, the overall point remains. Short of the one time pad you can’t build a provably flawless scheme.
Big if.
We already knew how to design good and strong symmetric ciphers way back in the 1970s. One of the standard blocking blocks of modern symmetric cipher is called the Feistel network, which was used to create DES. Despite that it's the first widely used encryption standard, even today there's essentially no known flaw in its basic design. It was broken only because the key was artificially weakened to 56 bits. In the 1980s, cryptographers already knew 128 bit really should be the minimum security standard in spite of what NSA officially claimed. In the 1990s, when faster computers meant more overhead was acceptable, people agreed that symmetric ciphers should have an extra 256-bit option to protect them from any possible future breakthrough.
There are only two possible ways to break them, perhaps people will eventually find a flaw in Feistel network ciphers to enable classical attacks against all security levels, but it would require a groundbreaking mathematical breakthrough unimaginable today, so it's possible but unlikely. Another route is quantum computing. If it's possible to build a large quantum computer, all 128-bit ciphers will eventually be brute-forced by Glover's algorithm. On the other hand, 256-bit ciphers will still be immune (and people already put this defense in place long before post-quantum cryptography became a serious research topic).
Thus, if you want a future archeologist from the 23rd century to decrypt your data, only use 128-bit symmetric ciphers.
Namely I’d ask when not if. My opinion is that short of the one time pad, we won’t come up with provably unbreakable schemes.
The big assumption of cryptography is that, there exists some problems that are not provably unsolvable but difficult enough for almost any practical purposes. To engineers, no assumption can be more reasonable than that. Given unlimited time, it's a provable fact that any (brand new) processor with asynchronous input signal will malfunction due to metastability in digital circuits, it's also a provable fact that metastability is a fundamental flaw in all digital electronics - but computers still work because the MTBF can be made as large as necessary, longer than the lifetime of the Solar system if you really want to.
So the only problem here is, how long is the MTBF of today's building blocks of symmetric ciphers? If it's on the scale of 100 years or so, sure, everything is breakable if you're patient. If it's on the scale of 1000 years, well, breaking it is "only" a matter of time. But if it's on the scale of 10000 years, I don't believe it's relevant to the human civilization (as we know it) anymore - your standard may vary.
The problem is that computerized cryptography is a young subject, the best data we have so far is symmetric ciphers tend to be more secure than asymmetric ones. We know that Feistel networks have an excellent safety record and remain unbroken after 50 years. We also know that we can break almost all widely used asymmetric ciphers today with large quantum computers if we can build one, but we can't do the same to symmetric ones - even the ancient DES is unbreakable if it's redesigned to use 256-bit keys. So while nobody knows for sure, but most rational agents will certainly assign higher and higher confidence every year - until a breakthrough occurs.
> My opinion is that short of the one time pad, we won’t come up with provably unbreakable schemes.
Many mathematicians and some physicists may prefer a higher standard of security than "lowly" practical engineers. This is the main motivation behind quantum cryptography - rather than placing security on empirical observations, its slogan is that the security is placed on the laws of physics. Many have pointed that the this slogan is misleading: any practical form of quantum cryptography must exist in the engineering sense, and there will certainly be some forms of security flaws such as sensor imperfection or at least side channels... That being said, I certainly understand why it looks so attractive to many people if you're the kind of person who really worry about provability.
Agreed. My overall / initial point was that I can’t say the time to crack = the time to brute force and start talking about the age of the universe. Even if we had to wait 10,000 years for cryptanalysis to break AES, it’s a blink of an eye in sideral timescale.
> quantum cryptography
Quantum cryptography is helpful in detecting eavesdropping (due to the no clone theorem). Ie quantum cryptography is helpful in avoiding asymmetric encryption for key exchange when communicating with symmetric encryption. Eg BB84. And given asymmetric encryption is most vulnerable to quantum attacks (compared to symmetric), quantum cryptography improves today’s state of the art. BUT, I insist that none of this gives provably uncrackable schemes.
AND it might be that we never build such a scheme. After all we have Godel’s incompleteness theorem lying around.
https://www.nsa.gov/Press-Room/Press-Releases-Statements/Pre...
https://tvtropes.org/pmwiki/pmwiki.php/Main/LightspeedLeapfr...
Now to the speed differences. To read, the laser needs only to see a reflection (or not) at a specific point, while to write, the laser needs time to heat up that same point. It’s like the difference between seeing a laser reflect off a balloon, versus the time required for that same laser to pop it. This heating is how CDs are written, quite literally by heating up points on the disc until they are no longer reflective. That’s why it is called “burning”. While more power might speed up the process, there is still time required. Meanwhile, all that is needed to read faster is an increase in the speed to observe, or the frequency to “read”, the light reflection.
With more powerful lasers operating at a faster frequency and with more precision, we can have a laser “see” these differences at 48 times the normal speed, but can only burn at 8 times the normal speed before the reliability of the process suffers.
Bonus: for a rewritable disc, it works slightly different. Instead of destructively burning the CD, you can think of it as being a material that becomes non-reflective at one temperature, and reflective again at another. This allows data to be “erased”. Also, when you “close” a disc to prevent rewriting, you aren’t actually preventing it from being rewritten. It is more like using a sharpie to put a name on the disc, with the words “do not overwrite” that all drive software/firmware respects.
Strange hill to die on, I'm aware.
No idea exactly what you're referring to taking several times longer, perhaps software was misconfigured. However what is more likely: The market was flooded with terrible quality media, combined with touting write speeds that were more for marketing than any concern for integrity, it was easy to burn discs just at the edge of readability, with marginal signal and numerous errors. This would cause effective read speed to be terrible, but this was more an indication that the discs were poor quality and/or poorly written then any inherent limitations in the process or how drives worked.
There are 48X "max" CD burners. But that maximum is no different than the maximum for reading. It's MAX because that speed is only attainable at the extreme outside of the disc. These higher speed drives operate with constant angular velocity (essentially a fixed RPM). In order to attain 52X at the inside of the disc would require a speed of around 30k RPM and no CD drive gets anywhere near that (though this was a common misconception). The top RPM for half height drives is around 10k - or about 50x the linear velocity of a CD at the outside.
Currently I usually use an Lite-On iHAS124 DVD/CD burner made in the last 6 years. It will write at up-to 48X and this speed is the maximum. The average burn speed for an entire disc when using "48x" is about 25x, or just about 3 minutes for the disc. For supported media it runs at a constant angular velocity around 10k RPM.
Exact Audio Copy / Red Book CD audio ripping is an entirely different subject. It can take longer due to cache busting and other issues that have nothing to do with the physical capabilities of the drive and more to do with the difficulty of directly streaming Red Book Audio, and issues with specific drives and their firmware. You can read at top speed though with a properly configured setup, I do it all the time.
> difficulty of directly streaming Red Book Audio
Actually, it's what I was alluding to this whole time. Sorry for not saying so out of the gate. Red Book audio was my life for a while. I recall writing cue sheets [0] for CDRWIN by hand! Ripping groups would brag that a given release was created with EAC at no more than 2.4x or something like that...
I believe data CDs (whichever color book that was) had more robust error correction (given that computer files can't just have glitches interpolated like audio can to some extent) which is why if you completely filled a CD with Red Book audio (74/80 minutes), ripped it to an uncompressed format like WAV/AIFF, and tried to put all of it on a data format CD as files, it wouldn't fit; it was a decent amount larger than 640/700MB and not just due to metadata.
Decoding also can be table-driven, but then takes 2^m × n bits, and that’s larger.
For example, encoding each byte in 16 bits (picking an example that leads to simple math), the encoding table would be 256 × 16 bits = 512 bytes and the decoding one 65,536 × 8 bits = 64kB.
Problem for Voyager was that 2^n × m already was large for the time.
It was never faster to write than it was to read.
Video codecs like h264 or VP9 are the opposite: Decoding is just following an algorithm, but an encoder can save bits by spending more effort searching for patterns in the data.
This is a more general point about the duality of compact encoding (compressing data to the lowest number of bits e.g. for storage) and redundant encoding (expanding data to allow error detection when transmitted across a noisy medium.)
Since the signal strength degrades with distance to Earth, error correction naturally becomes much more of an issue later in the mission. I guess that the probes may have switched between different levels of redundancy through the mission, as the transmission error rate rises. But there was never a point where the convolutional code wasn't useful, it just became slightly more useful with a better decoder.
Higher than others at the time, or higher than turbo codes or low-density parity checks?
This doesn't mean that it is universally the best way of doing error correction, other ways of generating redundancy may provide a better set of tradeoffs.
Also, convolutional code is a system that can be configured in many ways, the complexity of the code generation feeds back into the decoding, so a simple convolutional code would be Viterbi decodable at the time, but a more complex system would overall provide better error correction, even though choosing such a system meant that Viterbi would be computationally infeasible.
What I don’t understand (possibly because I didn’t read them fully) is why they didn’t use the better one from the start and taped its data. Maybe they didn’t trust the Voyager to work yet? (One of those PDFs says this was an experimental system) or didn’t Voyager produce enough data to use its full bandwidth (further away, its signal got weaker, so it needed better error correction and/or better receivers on earth) when it still was relatively close to earth?