Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
1–10 of 23 posts
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#2301 bytes! The base64 one-liner install is a nice flex. Accepting an infinite loop when energy_full doesn't exist is peak code golf, perfectly reasonable when every byte counts. Is there a writeup on the assembly somewhere?
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#3I have a use for this: A somewhat portable one-liner to go in my waybar/sway/i3 configs!
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#4Love it! It's entirely inapplicable and useless to me but it embodies the spirit of Show HN and what the spirit of programming in the 80s and 90s was.
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#5[dead]
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#6301 bytes! The base64 one-liner install is a nice flex. Accepting an infinite loop when energy_full doesn't exist is peak code golf, perfectly reasonable when every byte counts. Is there a writeup on the assembly somewhere?
The xz step doesn't seem to be doing very much, though. It seems the decoded data is currently 278 bytes versus a 298-byte decompressed result.
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#7Love this kind of tiny, over‑engineered hack—totally impractical, but pure Show HN energy.
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#8301 bytes! The base64 one-liner install is a nice flex. Accepting an infinite loop when energy_full doesn't exist is peak code golf, perfectly reasonable when every byte counts. Is there a writeup on the assembly somewhere?
Haha this is great!
What about adding a Make rule to auto-generate the one-liner install from the binary?
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#9It doesn't even look like particularly optimised Asm (could immediately spot a few savings, despite how horrible GAS syntax is to read...), but is definitely not "compiler slop"[1] either, which shows just how inefficient the majority of programs actually are. Of course even the ELF header takes up a significant amount of space, but this reminds me of how PC magazines would print short listings of utilities like this, often a few dozen up to a few hundred bytes at most --- in DOS .COM format, which is headerless and thus pure machine instructions.
[1] In the late 80s and early 90s, the battle between those writing handwritten Asm and those using compiled HLLs has many similarities to AI-generated vs non-AI code today.
Re: Show HN: A (marginally) useful x86-64 ELF executable in 301 bytes
#10It doesn't even look like particularly optimised Asm (could immediately spot a few savings, despite how horrible GAS syntax is to read...), but is definitely not "compiler slop"[1] either, which shows just how inefficient the majority of programs actually are. Of course even the ELF header takes up a significant amount of space, but this reminds me of how PC magazines would print short listings of utilities like this…
If the savings are about `mov $1, %edi` and `mov $10, %ecx`, those 32-bit immediate values line up with the higher bytes of p_filesz and p_memsz in the program header, which have to be zero [1]. If not, what are the savings? :)
[1]: https://github.com/meribold/btry/commit/8ef5a4ce58ae73c489d2...