"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 metal. Using a simple alphabetic code, a mark that calculated to a ratio of.12152205 could be read as 12-15-22-05, or “l-o-v-e.” The complete plays of Shakespeare could be written in a single mark, if it were possible to measure accurately enough. Or the machine language expression of the most advanced expert systems, though by then the notch might be small enough that Planck’s constant got in the way. How massive amounts of information could be expressed in and retrieved from infinitesimal objects was the driving concern of my college years."
Pure fiction at this point, but it would be an interesting experiment to encode data into objects that could be expressed using the mathematical ratio of their shapes or sizes.
With Planck's length being roughly 10^-35m, I'd say you'd hit the limit trying to store more than 15 bytes.
The limitations mentioned in the above comment relate to the fact that to know you'd arrived at the number designed into the Notch and the Rod, you'd have to have agreed to beforehand the tolerance limits on measurement of this 'device' so that the uncertainty in measurement can be ignored and the ratio derived.
To maybe get the right number you would have to expand your possible number of ratios (at a certain measurement sensitivity you would have a certain number of lengths you could use, and thus certain number of ratios would be available to you) and to get just the right number to describe your whole "machine language expression of the most advanced expert systems" you would have to delve into tolerances of the Plank length.
Or adjust the size of your rod length and notch, make them bigger, to get that sweet number with a 'poorer' level of sensitivity.
.. Or find a number with enough usable number sequences to serve the purpose and program in the numbers surrounding gibberish as markers/jump points to the next sequence of usable numbers. I suppose you could find enough usable sequences in the full expression of pi (as it's rational expression is without end) to write a program that can decode the full linux kernel out of it.
My 11 digit phone number occurs around the 115 millionth digit, a grand saving of two digits.
https://github.com/philipl/pifs
Discussed here previously (2014):
As if this were a practical means of storing data.
That said, this is a playable game in around 60 bytes of actual data which is impressive.
https://upload.wikimedia.org/wikipedia/commons/9/96/Munition...
[0]: http://cypherpunks.venona.com/archive/1995/10/msg00317.html
http://www.cs.cmu.edu/~tom7/abc/paper.txt (view in monospace font, 160 character lines)
.. and way smaller than your comment .
https://en.wikipedia.org/wiki/Run-length_encoding
https://perldoc.perl.org/perlop.html#Multiplicative-Operator...
AAA converts the result of the addition of two valid unpacked BCD digits to a valid 2-digit BCD number.
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.
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.
The other argument is that the various things SR tries to "manage" (sector interleave, getting various timing parameters "perfect", etc) were only relevant with ST-506 (!!) and similar disks from the 80s/very early 90s, and that anything remotely modern (even IDE, virtually 100% of SATA) generally doesn't provide enough low-level control surface that trying to micro-manage the disk's behavior will do anything particularly special.
Of course, I'm sure each manufacturer has their own tools and widgets that can use undocumented proprietary SATA/SCSI commands to control the drive's behavior at a very low level, but those kinds of tools are a) rare as hens' teeth and b) probably very easy to break disks with due to poor UI design and lack of documentation. Chances are the most expensive data recovery centers probably have some of these tools, and more importantly the training to know how not to kill HDDs with them :P
TL;DR: Yes, SR works, but probably just as well as dd3rescue; as always, if you think a disk is this side of dead and you think you have a chance without specialized tools, just imaging it is probably the best first step, because SR and all other tools will of course stress it.
With all of this said, I really, really like SR's startup animation :3 and I agree that it's refreshingly small.
/s (Just kidding this is actually super cool.)
https://www.ticalc.org/archives/files/fileinfo/227/22747.htm...
In a time when most software is filled with superfluous waste and endless layers of abstraction and libraries, it’s nice to see that the art of writing minimal software is not completely lost.
The certification on the other hand is a bit more costly though. My estimation of the certification cost for a ~20 people company if you do it as frugally as possible ended up at $18000 for the first year investment, and $6200 recurring the following years.
Perhaps someone can fit two games in a single multibyte tweet?
Anyhow, two games... cool, but to be perfectly honest, I thought the game was going to be more like the real snake than just drawing a non-overlapping line on screen. A more impressive game might be more impressive than two games.
Then again, two games is also pretty darn cool.
Meaning languages like Chinese and Japanese are still at the old limit.
This is a fantastic way to get into low level programming with a fun,tangible and approachable result.
back in "the day (TM)", we used to do this with ..achem ..viruses on floppies :) Putting it in a tweet is just brilliant.
anyone remember the one where it would say "smoke more weed dude"? (or something of the sort) :)
https://gist.github.com/mathiasverraes/9046427
https://philsturgeon.uk/php/2009/12/15/Twiny-Framework-the-f...
x86 processors still boot into real mode…
"UEFI firmware performs those same steps, but also prepares a protected mode environment with flat segmentation and for x86-64 CPUs, a long mode environment with identity-mapped paging. The A20 gate is enabled as well."
btw my base64 util needed lower case -d
For some reason, emulators (at least the ones I tried) wait 4x what real machines wait when you use BIOS int 15b 86h. You can tweak the code if you want to play at a faster speed.
There’s probably a sound explanation for this discrepancy...
inc cl
nop
inc dx
bf86 fec1
bf86 9042