Alpine Linux 3.5.0 released(alpinelinux.org) |
Alpine Linux 3.5.0 released(alpinelinux.org) |
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.
Mostly for these reasons I prefer a (slightly modified) Alpine base. I do at times run into musl compatibility issues, in those cases I most often fall back to Ubuntu.
I attempted Alpine for my router, but at the time there was no UEFI support (grub2-efi was in the unstable tree). That made me turn to Void Linux, which is totally worth checking out. I use it on my current x86 based router:
http://penguindreams.org/blog/building-a-thin-itx-router/
edit: sorry didn't read you comment entirely; init system doesn't make a difference for a docker base :-P
Which security updates? Generally these are pretty quick, and the processes are improving.
If you're purely running your own application/service (or non-repo software, e.g. rwasa) then Alpine seems perfect.
Is there any reason/discussion for this change?
Once you get rustc, rustup should be fine.
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?
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.
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.
What we're missing is rustc-on-musl and with that rustup-on-musl.
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.
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!