71–80 of 150 posts
Very cool. My version of base64 wants -d, not -D, though.
Linux vs BSD (ie Mac OS X). Sorry about that. Also, you shouldn’t paste weird looking things from the internet in your console :P
Earlier quoted context omitted.
No it isn't. In TRON you leave a trail behind. In Snake, you grow as you eat and drag your body along the path you crawled. TRON's trail is static, Snakes body is dynamic.
I said effectively. > TRON's trail is static, Snakes body is dynamic. And that difference only exists to support the single player vs multiplayer dynamic. If Snake left a Tron tail then it would be a very short, unfun experience. If Tron didn't leave a permanent trail then matches would last too long.
Maybe the single player vs multiplayer difference only exists to support the different tail mechanics.
This reminds me of Steve Gibson's SpinRite, which (from what I recall) is a fully functional disk recovery utility written entirely in assembly. https://www.grc.com/spinrite.htm. Say what you want about the man, but this is something that's saved me on at least one occasion, and is smaller than things I produce that do a lot lot less.
I was confused as to how you could represent a bootable CD image in printable characters. It turns out that you can't. This is a tweet of a perl script which creates a cd.iso file that you can then boot from. The perl script significantly decompresses the data in the tweet. That said, this is a playable game in around 60 bytes of actual data which is impressive.
This reminds me a bit of the science of nanoinformatics as described in one of the Expanse novellas (The Vital Abyss): " A thought experiment from my first course in the program: Take a bar of metal and put a single notch in it. The two lengths thus defined have a relationship that can be expressed as the ratio between them. In theory, therefore, any rational number can be expressed with a single mark on a bar of met…
With Planck's length being roughly 10^-35m, I'd say you'd hit the limit trying to store more than 15 bytes.
As someone that develops almost exclusively in high-level languages on top of may levels of abstraction, it's nice to see what can be accomplished close to the metal. This reminds me of Steve Gibson's SpinRite, which (from what I recall) is a fully functional disk recovery utility written entirely in assembly. https://www.grc.com/spinrite.htm . Say what you want about the man, but this is something that's saved me on…
But I have also had some success with it.
Everything that he releases is amazingly tiny. It just shows how much bloat modern software tends to have.
I was confused as to how you could represent a bootable CD image in printable characters. It turns out that you can't. This is a tweet of a perl script which creates a cd.iso file that you can then boot from. The perl script significantly decompresses the data in the tweet. That said, this is a playable game in around 60 bytes of actual data which is impressive.
I was confused as to how you could represent a bootable CD image in printable characters. It turns out that you can't. This is a tweet of a perl script which creates a cd.iso file that you can then boot from. The perl script significantly decompresses the data in the tweet. That said, this is a playable game in around 60 bytes of actual data which is impressive.
Earlier quoted context omitted.
The same has been said about Pi (3.14). If you can compute, store and search enough the digits of Pi, you can reference anything by just providing the 'start' and 'finish' locations. Unfortunately, with enough digits of Pi, the 'start' and 'finish' numbers can get quite long themselves.
Years ago I tried this and basically ended up proving that if Pi is random and you are "compressing" random data, on average the start and finish numbers together are at least as long as the numbers you are trying to "compress."
Earlier quoted context omitted.
The same has been said about Pi (3.14). If you can compute, store and search enough the digits of Pi, you can reference anything by just providing the 'start' and 'finish' locations. Unfortunately, with enough digits of Pi, the 'start' and 'finish' numbers can get quite long themselves.
Years ago I tried this and basically ended up proving that if Pi is random and you are "compressing" random data, on average the start and finish numbers together are at least as long as the numbers you are trying to "compress."