> If you compile the same source twice you get the exact same binary. You wish this were true. You really, really wish it were. But it's not always. Reproducib

> If you compile the same source twice you get the exact same binary. You wish this were true. You really, really wish it were. But it's not always. Reproducibility is a really tough problem when you support 25+ Linuxes, each with their own versions of GCC and libc, different compiler flags by default, etc. There's some work being done to make this "better" like GNU ld's build-id hashing binary sections so it's easier to tell if they changed, and projects that stash the compiler's flags in a binary section with -frecord-gcc-switches/-grecord-gcc-switches. But we've still got a long way to go, at least in the wonderfully fragmented landscape of Linux software development. Furthermore, the example in the article is rather specious. Versioning is very often done by macros and string replacement and not some constant somewhere in a .section that's easy to just "lemme tweak this" and push a new release. No, you'd have to go through the entire object file to find any place that version number is used. It's not the exceptional case in real world software with multiple supported releases that you see code like: if (version_number == 2 || version_number == 3) { do this thing; } else if (version_number == 4) { do that thing instead; } or its equivalent with #ifdefs, which the compiler can then fold away in preprocessing or dead code elimination leaving you with the right chunk for the product version. Hex editing the binary won't catch this, leaving you with a broken binary. tl;dr: rebuild the software if you screwed up.