6 comments

  • userbinator 23 minutes ago
    It 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.

  • vparseval 2 hours ago
    Love 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.
  • Eric_Xua 1 hour ago
    Love this kind of tiny, over‑engineered hack—totally impractical, but pure Show HN energy.
  • emanuele-em 2 days ago
    301 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?
    • sjdv1982 1 hour ago
      Haha this is great!

      What about adding a Make rule to auto-generate the one-liner install from the binary?

    • zahlman 2 hours ago
      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.
  • captn3m0 2 hours ago
    I have a use for this: A somewhat portable one-liner to go in my waybar/sway/i3 configs!
  • darioterror 2 hours ago
    [dead]