[HN Gopher] Packaging Swift Apps for Alpine Linux
___________________________________________________________________
Packaging Swift Apps for Alpine Linux
Author : todsacerdoti
Score : 76 points
Date : 2024-06-16 15:59 UTC (7 hours ago)
(HTM) web link (mko.re)
(TXT) w3m dump (mko.re)
| yjftsjthsd-h wrote:
| Similar to chroot, I wonder if flatpak is a good option?
| Obviously native is better but I know that that works because
| that's how I've run Steam on Alpine
| xena wrote:
| Flatpak isn't really intended for command-line apps. Maybe this
| is where something like dockerc
| (https://github.com/NilsIrl/dockerc) can shine?
| tadfisher wrote:
| Nix is another option for static builds. There is a
| `pkgsStatic` tree for building static musl-linked binaries,
| which would be a perfect integration point for Swift's static
| Linux target.
| silisili wrote:
| I was curious how large these static binaries would be since the
| last announcement. Being honest, 100MB is quite a bit larger than
| I was expecting. Probably fine for CI business apps and such, but
| kinda rules out a lot of linux util type things.
| repelsteeltje wrote:
| I seem to have missed the part where he explains _why_ he 's
| targeting Alpine Linux for his Swift app. Alpine isn't
| mainstream (the way Ubuntu or rhel are) and stands out mostly
| for being compact and clutter free.
|
| So... indeed... If you somehow end up with 100MB package for
| what is essentially just 250kB, I'd say something did not go
| right. Feels very square peg in round hole.
| yjftsjthsd-h wrote:
| Some of us are just using Alpine as our primary OS, and would
| need a compelling reason to do anything else.
| Tildey wrote:
| If I had to guess, Alpine is a very popular choice for
| building container images in Docker/Kubernetes/whatever the
| new hotness is since I last worked with containers. Mostly
| because the aforementioned small size and low overhead add up
| if you're at any sort of scale (even one instance on top of
| your desktop OS).
|
| If you're wanting to containerise the program, maybe it's
| less resource intensive to add those things to Alpine than to
| run another distro with more support? Obviously only
| speculation
| iudqnolq wrote:
| Doesn't Kubernetes deduplicate layers by hash? I thought
| the key to minimizing overhead was standardizing on a
| limited set of images across everything you'll be running
| on the same host.
|
| Just from reading HN it seems like Alpine had a brief fad a
| few years ago but never got much traction.
| arccy wrote:
| the underlying container runtime (usually containerd)
| will dedupe shared layers, but there's a lot of things
| you don't get to directly control, like third party apps,
| and the bottleneck when spinning up new nodes is real.
| Plus, envs where there isn't that much caching, like CI.
| lolinder wrote:
| The Alpine Linux docker image is 7.8 MiB to Ubuntu's 76 MiB,
| so they get a savings of about 68 MiB in image size by using
| Alpine Linux over Ubuntu.
|
| From the stats in TFA it looks like about 43 MiB of the file
| size is the Swift runtime itself, which would need to be
| installed in any OS. This leaves ~57 MiB extra in their
| static binary approach vs what they'd get out of dynamic
| linking.
|
| 68 MiB (saved by using alpine) - 57 MiB (lost to static
| linking) = 11 MiB (net gains from Alpine), so their Alpine
| Linux solution is actually about 10% smaller than the
| equivalent that uses an Ubuntu image.
|
| Is that worth the extra work they put into it? It probably
| depends on the application.
| dagmx wrote:
| A big chunk (roughly a quarter) of it is the Unicode handling
| library.
|
| I think eventually the stdlib will be split up more so that
| it's not one giant blob, but there's a lot of areas that will
| be reducing in the future.
| arp242 wrote:
| 75M is still huge for this type of thing.
|
| My smallest Go CLI is 1.6M. This is probably about as small
| as you can get in Go and still do something useful. Some of
| my other (larger) Go CLIs range from ~2.5M to ~6.5M. Go is
| not known for producing small binaries.
| neonsunset wrote:
| Hmm, so it includes the entirety of Swift's standard library?
| Isn't there an option to tree shake/trim it? That's what .NET AOT
| compilation does (standard library is always included, sans the
| dependency on glibc or musl, which you can statically link into
| the binary as well should you need that)
| JCWasmx86 wrote:
| The biggest symbol of a statically linked swift binary that I
| have, is icudt_swift65_dat with 27.98MB, so I think that's not
| so easy to remove (nm v3.1.2 --size-sort --radix=d|swift
| demangle) And I think if you strip debuginfo it will be smaller
| (For a statically linked program of mine: 98MB -> 56MB)
|
| But I think for a distribution it makes more sense to link
| swift programs dynamically against the runtime libraries, like
| it's the case for e.g. the C standard library, OpenSSL etc., as
| you can assume they all work with the same version and are ABI-
| compatible.
|
| I tested it with a nearly static build (Still links against
| glibc and friends): 55MB get stripped to 44MB, so not that
| much. 27MB of that is icudt_swift65_dat, so I guess you would
| have to optimise that first
| georgelyon wrote:
| If I'm not mistaken, the embedded swift mode aims to make ICU
| (the 27mb file for Unicode support) optional (and thus easily
| removed where it isn't needed)
| 0xTim wrote:
| With the new Foundation work going on, when you migrate to
| that, if you don't import `FoundationInternationalization`
| then you won't pull in all of ICU and it won't be bundled in
___________________________________________________________________
(page generated 2024-06-16 23:00 UTC)