Description
The current bitcoind and lnd images we use are alpine-based, and we have not run into any issues...
...yet.
Be careful using Alpine, I wouldn't recommend it for mission critical stuff like Bitcoin
It's uses musl instead of glibc, so lots of software requires patching to compile properly, so then you're using non-standard untested software. Even if software compiles without patching, you can't be sure subtle libc differences won't have significant effects on runtime behaviour.Maybe the next block hits some strange edge case that triggers a libc bug or one of your patches which effects consensus and you end up on a fork, maybe not an issue if you're just using it for testing but is a big issue if it's used in Umbrel and all Umbrel users get forked off.
The ~100MB you save is not worth the potential headaches it can cause, especially when the core of your system is a 300GB database lol.
Also consider theres a vuln in some 3rd party package, who do you thinks gonna patch it and update their repositories first, a huge project like Debian or a relatively much smaller project like Alpine.
musl is superior to glibc in theory, but in practise until most software is developed and tested against musl you're just asking for issues.
The fact that most distros ship glibc means people generally only develop/test for glibc which means compiling that code against musl could result in unpredictable behaviour.
- As penned down by @lukechilds in the team chat
Going forward, let's look into switching to ubuntu or debian-based bitcoind and lnd images, and also do a performance benchmark test comparing bitcoin sync performance on an alpine container vs an ubuntu/debian container.
Activity