Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Packaging Swift Apps for Alpine Linux

mko.re

Post reply on HN
Print view View original

11–20 of 45 posts

Re: Packaging Swift Apps for Alpine Linux

#11

Post by repelsteeltje »

silisili wrote: post #3

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.

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.

Re: Packaging Swift Apps for Alpine Linux

#12

Post by yjftsjthsd-h »

repelsteeltje wrote: post #11
silisili wrote: post #3

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.

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.

Some of us are just using Alpine as our primary OS, and would need a compelling reason to do anything else.

Re: Packaging Swift Apps for Alpine Linux

#13

Post by [deleted] »

neonsunset wrote: post #5

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)

[deleted]

Re: Packaging Swift Apps for Alpine Linux

#14

Post by Tildey »

repelsteeltje wrote: post #11
silisili wrote: post #3

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.

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.

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

Re: Packaging Swift Apps for Alpine Linux

#15

Post by [deleted] »

repelsteeltje wrote: post #11
silisili wrote: post #3

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.

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.

[deleted]

Re: Packaging Swift Apps for Alpine Linux

#16

Post by lolinder »

repelsteeltje wrote: post #11
silisili wrote: post #3

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.

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.

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.

Re: Packaging Swift Apps for Alpine Linux

#17

Post by tadfisher »

xena wrote: post #10
yjftsjthsd-h wrote: post #2

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

Flatpak isn't really intended for command-line apps. Maybe this is where something like dockerc ( https://github.com/NilsIrl/dockerc ) can shine?

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.

Re: Packaging Swift Apps for Alpine Linux

#18

Post by iudqnolq »

Tildey wrote: post #14
repelsteeltje wrote: post #11

Earlier quoted context omitted.

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.

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 A…

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.

Re: Packaging Swift Apps for Alpine Linux

#19

Post by dagmx »

silisili wrote: post #3

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.

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.

Re: Packaging Swift Apps for Alpine Linux

#20

Post by arccy »

iudqnolq wrote: post #18
Tildey wrote: post #14

Earlier quoted context omitted.

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 A…

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.

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.
Post reply on HN