HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
intoli
exodus
Python2018–2026
intoli / exodus

exodus

Painless relocation of Linux binaries–and all of their dependencies–without containers.

15Distinct people
19Mentions
0Explicit recommenders
3KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Painless relocation of Linux binaries–and all of their dependencies–without containers.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year19 dated mentions

Observed mentions: 2018-02-01 13:31:01 UTC to 2026-01-26 22:32:06 UTC.

02468102018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 10 mentions; 2 submissions, 8 comments20182019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC1028
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC101
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC312
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC000
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC202
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC110
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC101

What Hacker News says

19 sources
Not the OP but what sometimes works is as easy as: ``` ldd your-binary ``` on the old host and then copy all the thing that is referenced, put into ./foo and then start like so on new host: `LD_LIBRARY_PATH=./foo ./your-binary`. (may include typos, from memory) A great tool for this used to be https://github.com/intoli/exodus - not sure if it still works. Disclaimer: Also please don't do this with network-facing services, security applies, etc.pp. but it's a good trick to know.
In The tragedy of running an old Node project
COPY --from=ugit-ops /usr/lib/libpcre* /usr/lib/ COPY --from=ugit-ops /usr/lib/libreadline* /usr/lib/ COPY --from=ugit-ops /lib/libc.musl-* /lib/ COPY --from=ugit-ops /lib/ld-musl-* /lib/ No, what I'm saying is you're blanket copying fully different versions of common library files into operating system lib folders as shown above, possibly breaking OS lib symlinks and/or wholly overwriting OS lib files themselves in the process for _current_ versions used in Alpine OS if they exist now or in the future, potentially destroying OS lib dependencies, and also overwriting the ones possibly included in the future by Alpine OS itself to get your statically copied versions of the various CLI tools your shell script needs to work. The same goes for copying bash, tr, git, and other binaries to OS bin folders. No No NO! That is _insanely_ shortsight
Read the rest
ed. There's a safe way to do that and then there is the way you did it. If you want to learn to do it right and are deadset against static binary versions of those tools for the sake of file size, look at how Exodus does it so that they don't destroy OS bin folders and library dependency files in the process of making a binary able to be moved from one OS to another. Exodus: https://github.com/intoli/exodus This is why I'm saying your resulting docker image is incredibly fragile and something I would never depend on long-term as it's almost guaranteed to crash and burn as Alpine OS upgrades OS bins and lib dependency files in the future. That it works now in this version is an aberration at best and in reality, there probably are things that are broken in Alpine OS that you aren't even aware of because you may not be using the functionality you broke yet. OS package managers handle dependencies for a reason.
In A lesson in dockerizing shell scripts
Jokes aside, this is a actually a pretty common scenario for some people, and I wrote a tool called Exodus to solve it [1]. Exodus makes it trivial to relocate Linux binaries like jq from your local machine [1]. You can simply run exodus jq | ssh my-server locally, and then immediately have access to jq on the server. I personally find it very useful when working with servers or containers that have limited package repositories or where I don't have root access. [1] - https://github.com/intoli/exodus
In Jqjq: Jq Implementation of Jq
I am not sure how this would work. rsh/ssh may be involved. I wouldn't even know how to express: ssh carthoris ls /mnt/media/Movies | grep Spider (this is just an example). Note that in this example, we have two processes running on two different machines. Indeed, the OSs and systems on these machines may be, um... different. Indeed, I routinely include "cloud" machines in pipelines. Indeed, with ssh, the -Y (or -X) option can introduce a GUI to a part of the command. I have wished that shar was part of SUS. Also, I find that "exodus" is useful (across Linux anyway -- the systems have to be "reasonably" homogenous). https://github.com/intoli/exodus
In CLI: Improved
I can definitely understand you cringing about the re-encoding, but I just wanted to point out that the reason that we took this approach was simply to give a semi-plausible real-world example of how tools like aws-serverless-express [1] and Exodus [2] can be used to build useful APIs with AWS Lambda [3] and AWS Gateway [4]. These articles are primarily meant to be educational tutorials that people can use as a reference when writing and deploying their own APIs. The whole "converting to MP3" thing is just an easily understandable premise which lays out a clear goal for the tutorials to build upon. [1] - https://github.com/awslabs/aws-serverless-express [2] - https://github.com/intoli/exodus [3] - https://aws.amazon.com/lambda/ [4] - https://aws.amazon.com/api-gateway/
In Building a YouTube MP3 Downloader with Exodus, FFmpeg, and AWS Lambda

Showing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.