People who compress their go binaries (or any other binaries, really) - please be aware that thus doing, you stop the OS from being able to page out your executable (rarely a big loss), and also to be unable to share executable pages (not a huge loss for a 2MB executable, a huge loss for a 100MB executable).<p>If there's only one copy of a program running, it won't matter - but if you are running hundreds of copies (even docerized and stuff), you are likely better off NOT upxing.
Surprised this <i>still</i> exists.<p>A little walk down memory lane:
I once ran the exe mailing list for exe packers and protection tools. There was a whole scene of people in the 90s writing such tools and writing unpackers and removal tools for such things. UPX was one of the later ones that still existed when most of this scene vanished.
I used it to compress a Lazarus (open source Delphi clone) executable. The results were great (executable size reduced by more than 50%, iirc from 2 mb to around 800 kB).<p>Offering a sub MB executable in the era of 100 MB electron apps is totally pioneer :)
UPX was also good to protect the code, not only for compacting:<p>1. I used UPX to compact my Delphi EXE file.<p>2. Then I openned up any HEXA editor<p>3. looked for "UPX" string and changed to "222x"<p>Doing this, the UPX unpack tool didn't work and crackers could not easily see or edit my source code with Assembly (as UPX mess with everything!)<p>Thanks UPX :-)
Warning: although UPX is awesome, be wary of using it to distribute software to a wide audience as it seems to trigger false positives in some antivirus software.
PortableApps.com used UPX for most open source releases up until a couple years ago. We stopped due to antivirus false positives combined with the fact that most folks have more space for their apps. We still make available the tool we use called PortableApps.com AppCompactor. It provides a simple GUI to use UPX on a whole directory and sub-directories. Plus it can optionally recompress JAR and ZIP files using 7-Zip. If it's useful to you, you can grab it here: <a href="https://portableapps.com/apps/utilities/portableapps.com_appcompactor" rel="nofollow">https://portableapps.com/apps/utilities/portableapps.com_app...</a>
mpress is an even better, more modern alternative: <a href="http://www.matcode.com/mpress.htm" rel="nofollow">http://www.matcode.com/mpress.htm</a><p>We used to compress all our binaries (desktop software developers), but fighting false positives from antivirus vendors became an endless nightmare. We just gave up and stopped using binary compressors entirely.
Funny to see this here, it's been ages since I've seen UPX mentioned. In the early 2000's I had written some software whose executable was around a megabytes or maybe several megabytes in size coming out of VB6. On one of mid 90's test laptops we used at the time to ensure it would run on even the crummiest of machines it launched NOTICEABLY faster when packed with UPX. The hard disk in that machine was so incredibly slow loading less off the disk and decompressing the executable in RAM was easily an order of magnitude faster.
I do most of my web-dev in Nim these days. Meaning my ELFs are ultimately produced by GCC og Clang. Everyting statically linked - and I mean <i>everything</i>: For clib I use Musl. And then I UPX the bejesus out of them.<p>It's simply <i>nice</i> to ship a fully working app, with SQLite* and everything, which will basically run anywhere with a Linux kernel, in a single executable far below 2 MB.<p>*) Yes, the vast majority of the world's websites need nothing fancier than SQLite to keep them happy. And manageable.
The one time I came across upx, it was used on some malware. It was on a programme named gnome-pty-helper in a user's .config directory that was installed in cron and set to phone home to some locations that were stored in clear once upx had been used to unpack it.<p>Years back I used gzexe and also some pkzip based thing on DOS. On a modern system, you're better of enabling filesystem level compression which also won't break OS paging if the executable is run more than once.
UPX still works great when used with Go executables.<p>We use it heavily to compress some of our Docker image executables [1].<p>[1] <a href="https://github.com/znly/docker-protobuf/blob/master/Dockerfile#L113" rel="nofollow">https://github.com/znly/docker-protobuf/blob/master/Dockerfi...</a>
I used to use this a lot, back in the bad old days, when drive space was at a premium.<p>These days I struggle to fill my hard drives no matter how wasteful I am with downloading videos and not bothering to clean up afterwards... and the amount of hard drive space you can buy per dollar keeps growing faster than I can fill my disks.<p>Much trickier issues to tackle are speed (unless you go with SSD's, but then you run in to space issues again, and reliability issues), backups, and data integrity. All of these issues are made much harder by the sheer amounts of data we're storing these days. Executables usually account for only a relatively small fraction of that space.
also <a href="http://www.farbrausch.de/~fg/kkrunchy/" rel="nofollow">http://www.farbrausch.de/~fg/kkrunchy/</a><p>and related <a href="https://news.ycombinator.com/item?id=7739599" rel="nofollow">https://news.ycombinator.com/item?id=7739599</a>
Note that upx can also cause compatibility problems. For example when macOS Sierra was releases many older apps that used upx needed to be uncompressed and recompressed with a newer upx version in order to get them working again.
Just to chip in on my experience on this matter. I use UPX as one of the RE defense method on a couple of Delphi based software we build which our customer runs regularly on their servers. One of the challenge is some A/V throws a false positive upon checking the result files. Somehow this became no longer an issue after applying code-signing to the UPX output executables.