Hacker News Reader

Comment by fotcorn | Hacker News Reader

I did a short comparision between this and alpine by installing nginx inside the image (I used nginx-light inside ubuntu):

  CONTAINER ID    IMAGE           SIZE
  493450e7bc12    alpine          1.37MB (virtual 5.52MB)
  62b1db90500c    ubuntu:bionic   6MB (virtual 87MB)

I deleted the cache files from apt after installing (/var/lib/apt/lists*)

Looks quite nice, but it seems Ubuntu packages are much bigger than Alpine package, e.g. Postgres is 159 MB in Ubuntu Bionic and only 32 MB in Alpine (including dependencies). Do the Ubuntu packages have more feature than the equivalent Alpine packages?

View on HN

> Do the Ubuntu packages have more feature than the equivalent Alpine packages?

The ubuntu package comes with more stuff. e.g. It includes all the 'in tree' PG extensions and their dependencies where as alpine keeps them in a separate package, postgresql-contrib.

Perhaps because Alpine Linux uses busybox and musl instead of LSB and glibc?

typo: libc -> glibc

Speaking of musl, I ran Void Linux with musl for a few weeks on my laptop but found that a lot of the software packages were prone to crash and many of them wouldn't even run correctly at all. What has the experience of using Alpine with musl on servers been like for those of you that do?

That's very interesting. I would love for someone to dig deeper into this.

What happens if you do a multistage build (to get rid of the build tools once you don't need them) and compile Postgres from source on Alpine and Bionic?

Consider how dope it'd be to ~"tree-shake" packages based on config files, if doing immutable infrastructure. Basically, only compile / include the features of the services you run based on what's required by the config files. I'm sure that this is a complex problem, but it shouldn't be impossible to mostly / fully automate.

This is brilliant. You'd need to basically define every single compile-time param and then have your build process emit a customized binary (and retinue of supporting stuffs) that does just that and nothing else.

Probably makes your total build time significantly longer; you'd need aggressive caching based on the feature flag set.

This is mostly how gentoo works. You define global settings, like "gui" or "pulseaudio", and you also have per package features to enable or disable. After setting these up, when you install a package, it is installed using only the features you enabled, so you have a lot of control over what and how you make your system work.

So Gentoo? I think E-Trade may still use it in production.

Alpine is compiled against musl libc, so the binaries are much smaller. Id addition to tgat, it uses Busybox.

I can't imagine that to be one of the more significant factors in this case. It's much more likely that the ubuntu version includes a lot more functionality. Just looking at the configure flags: Alpine: --with-ldap --with-libedit-preferred --with-libxml--with-openssl --with-perl --with-python --with-tcl --with-uuid=e2fs Debian: --with-icu --with-tcl --with-perl --with-python --with-pam --with-openssl --with-libxml --with-libxslt --enable-nls --enable-integer-datetimes --enable-thread-safety --enable-tap-tests --enable-debug --disable-rpath --with-uuid=e2fs --with-gssapi --with-ldap --with-selinux

Specifically the differences in enabling ICU (portable collations) and nls (i.e. translations) alone are probably going to be the majority of difference in installed size.

But musl is linked statically, therefore the image must contain multiple instances of the library. Very impressive that the Alpine image still comes out smaller

Reply on news.ycombinator.com