
Alpine Linux 3.5.0 released - laamalif
https://alpinelinux.org/posts/Alpine-3.5.0-released.html
======
joshpadnick
Now that the official Ubuntu containers have gotten down to around 50MB for an
image [1], can the case still be made for using Alpine?

Admittedly, Alpine images are just 2MB [2], but I kept running into so many
edge cases with musl, apk didn't always have the packages I wanted and often
lagged behind critical security updates, and documentation/community was much
smaller than I'd like. It's a genuine question. I'm wondering if the case can
be made to prefer Alpine as your default Docker base image.

[1]
[https://hub.docker.com/r/library/ubuntu/tags/](https://hub.docker.com/r/library/ubuntu/tags/)

[2]
[https://hub.docker.com/r/library/alpine/tags/](https://hub.docker.com/r/library/alpine/tags/)

~~~
justincormack
Well 48MB is a lot. Also Musl Libc has advantages, eg it has an emphasis on
correctness, it is easy to understand (read the code, it is great, Glibc is
very hard to understand). Plus if you want to make statically linked binaries
you pretty much need to use Musl, as Glibc has many cases that do not work.

Which security updates? Generally these are pretty quick, and the processes
are improving.

~~~
jzelinskie
I hope the processes keep improving. They recently introduced Alpine SecDB[0],
which is their database (YAML files) of CVEs. I've been told from one of their
developers that it may not be actively maintained. I hope they stick with it
since now we can use that in Clair[1] to improve the transparency of
containers.

[0]: [http://git.alpinelinux.org/cgit/alpine-
secdb/](http://git.alpinelinux.org/cgit/alpine-secdb/)

[1]: [https://github.com/coreos/clair](https://github.com/coreos/clair)

------
throwaway161220
Alpine Linux is great and I wish they would do more to upstream their build
fixes so that stuff works out of the box with musl. I also wish Rust and then
rustup will work out of the box on Alpine soon, as this will make it very easy
to use generally and in docker images for ci specifically. No complaints, just
a small wish list for a distro that's already very useful. Huge thanks to all
alpine devs!

~~~
steveklabnik
Have you tried
[https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rus...](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rust)
?

~~~
throwaway161220
Sadly it's outdated, only a single version, and missing all the other
important rustup features. Ultimately rustup's Linux binaries would benefit
from either optionally or exclusively being available in a version that's
linked dynamically - or more practically - statically against musl. These
would work in default docker images, Ubuntu, Red Hat, Alpine, Void Linux,
anywhere that has Linux 2.6 ABI. Stack has started doing this for their GHC
builds. Of course, a prerequisite is upstream support for hosting rust in a
musl (no glibc) environment. Since Rust has a musl target for static
compilation, it's natural to be hosted as well.

~~~
steveklabnik
Well, hosted is trickier due to compiler plugins, but yes. It's workable. In
general, please submit bugs upstream or comment on any open issues; this
package was created by someone who was working on exactly that!

Once you get rustc, rustup should be fine.

~~~
throwaway161220
> Well, hosted is trickier due to compiler plugins, but yes.

This has been discussed multiple times in tickets and it's pending. Hopefully
soon :).

> please submit bugs upstream or comment on any open issues

Of course but there's nothing I can add to already existing and open issues
that hasn't already been discussed. There's a need for rustc dev focus on this
just like msvc support in the past.

> Once you get rustc, rustup should be fine.

What do you mean? Being able to build rustup doesn't give you access to rustup
toolchains/targets that run on Alpine, if that's what you mean. Or?

~~~
steveklabnik
I meant that in most distros (I know more about Debian than Alpine), the first
step is packaging rustc + cargo, then applications built with it. So I
imagined it'd go the same way. rustc and cargo are much harder to package, so
after that's done, other applications in Rust tend to be easier.

~~~
throwaway161220
For bootstrapping it in and for a distro that's the right thing, but if we
want to have access to the rustup toolchains and targets, then those require
musl-hosting support upstream in order for rustup binaries to be made
available which, like on Windows or FreeBSD, are downloaded and used by
rustup.

Building rust right now takes enough time that it's hard to recommend a
hypothetical from-source mode for rustup that works similar to OCaml's `opam
switch compiler-vsn`. If building rustc becomes similarly fast, this can be a
good alternative. And in that case having a rustc version in the distro is
very useful, as long as it's not older than two releases.

~~~
steveklabnik
Right. But std with musl is already available from the project; this is mostly
about rustc.

~~~
mitchty
Since I follow alpine linux dev a bit, I thought this:
[https://github.com/alpinelinux/aports/blob/master/testing/ru...](https://github.com/alpinelinux/aports/blob/master/testing/rust/APKBUILD)

Is the port of rustc to run natively on AL? Bit outdated now but it seemed to
work the last time I tried it.

You'd have to enable the testing repo to use it however.

~~~
steveklabnik
Yes, throwaway (in my understanding) seems to want this from the project
itself, not the distro.

~~~
throwaway161220
Is there another way to get access to the continuously updated toolchains and
targets available via rustup?

~~~
steveklabnik
Well, if you had a "built-with-musl" rustup, then you could just use it. But
if not, you can curl the s3 bucket and grab them; rustup is ultimately a
convenience, not a requirement. I guess that's why I see it as "mostly about
rustc", since once you have that, you can compile rustup, and once you can do
that, you can get it easily.

Just to be clear: I would like to see better support for all of this,
personally. I'm not trying to argue that things are perfect today, just figure
out exactly where in the process of getting there all this is, since I use
Debian, not Alpine.

~~~
throwaway161220
I feel like we're talking past each other :). Building rustup with and for
musl isn't the problem. Needing glibc for the binaries downloaded by rustup
is. So this is more about toolchain and target binaries for linux being libc-
agnostic which is easiest to achieve by musl-static-linking them which
requires upstream support. As a first step a second set of musl-dynlink,
parallel to glibc-dynlink, binaries would suffice.

Speaking of Debian, one has to be careful in how stuff is built for the result
to run on Debian, Fedora, Arch, Suse, which is another reason to simplify
things with musl since it already bundles third party C code anyway. So far
rustup doesn't suffer from that, but if it ever were to dynlink ncurses or
another core Linux lib, it would have the same issue as GHC's bindists. It
doesn't and that's great!

~~~
steveklabnik
I think so too. It happens. :)

~~~
throwaway161220
Hehe. Was I able to express the thoughts clearly enough that you're able to
follow (now)?

~~~
steveklabnik
I believe so. :)

------
ohstopitu
Alpine Linux is the easiest/quickest way to create containers that have a
manageable size (which is pretty important if you are hosting your own
registery that charges you for space instead of containers)

------
_joel
Full ZFS root support, lovely stuff

------
Watabou
* Switch from OpenSSL to LibreSSL

Is there any reason/discussion for this change?

~~~
justincormack
Far fewer security issues, as much code has been removed.

