# Additional Linux Distributions **URL:** \ **Category:** Development\ **Created:** [May 5, 2020, 8:19pm UTC](https://forums.swift.org/t/additional-linux-distributions/36188 "2020-05-05T20:19:43Z")\ **Posts on this page:** 1\ **Showing post:** 69
**Author:** ![Max\_Desiatov](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/max_desiatov/32/20654_2.png) [@Max\_Desiatov](https://forums.swift.org/u/Max_Desiatov)\ **Post date:** [June 8, 2020, 12:27pm UTC](https://forums.swift.org/t/additional-linux-distributions/36188/69 "2020-06-08T12:27:50Z")
I've attempted to get this working, but it looks like upstream LLVM and Clang don't support musl and Alpine Linux without certain patches that are currenly applied by Alpine maintainers. I personally think that these patches should be merged upstream and then propagated to the Apple's Swift LLVM branches, which would simplify a lot of porting efforts. After that, there's a question whether we need to create a separate `Musl` Swift module in addition to the available `Glibc` module to indicate the difference in behavior of those libraries. In that case, this will require Swift developers to replace (or make conditional) `import Glibc` with `import Musl` if those are present in their source code. We also need to make sure that the Swift compiler, runtime, ICU and Foundation work well with musl by setting up CI with relevant test suites enabled. All of that is a substantial amount of effort, and I don't think I'll be able to pull it off myself anytime soon, given the amount of other projects I'm currently working on. > [@tomerd](#): > > In addition to the `slim` images mentioned above which we publish for ubuntu (CentOS and Amazon Linux 2 dont need anything on top of the distro for _running_ swift programs), another option that folks could find interesting is Google's [distroless](https://github.com/GoogleContainerTools/distroless). I did a small experiment today: @Tof if you're concerned with size, this distroless option described above is something you should try. If your Docker images aren't small enough with `distroless`, they are unlikely to become much smaller with Alpine. If you're concerned with the amount of space that Swift binaries and libraries that you link with take, you should also consider static linking and then applying WMO/LTO on top of that. There may still be some unused code in the resulting binary, but there's ongoing work on making LTO more effective with the latest update on that avialable here: "[[GSoC] LTO support progress report](https://forums.swift.org/t/gsoc-lto-support-progress-report/37149)". I personally would focus my efforts on getting improved LTO into Swift, since that would benefit all platforms in terms of resulting binary size, not just Linux. Only after all those efforts combined with `distroless` don't lead to good results, I'd continue the work on making LLVM/Clang/Swift work well with musl/Alpine. --- _[View the full topic](https://forums.swift.org/t/additional-linux-distributions/36188)._