4 ms·

Alpine Linux 3.5.0 released

87 points by laamalif 10y ago

throwaway161220 10y ago
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 10y ago
  Have you tried https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rust https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rus... ?
  - justincormack 10y ago
    Yes I hadnt realised this was out until a few weeks back and it works really well.
  - throwaway161220 10y ago
    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 10y ago
      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 10y ago
        > 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 10y ago
        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 10y ago
        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.
- justincormack 10y ago
  Most of the build fixes are offered upstream, not every upstream is interested in supporting non glibc Linux platforms alas. But gradually things are getting upstreamed.
  - throwaway161220 10y ago
    Unfortunately, yes. Looking through llvm, rust, ocaml APKBUILDs for investigative purposes lists some diffs that seem upstream worthy.
    - justincormack 10y ago
      Some of them may have made it into master, but not a release, I thought the rust patches had, and the OCaml ones, but not 100% sure.
ohstopitu 10y ago
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 10y ago
Full ZFS root support, lovely stuff
joshpadnick 10y ago
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/
- jonathonf 10y ago
  If you're serving using repo software (and rebuilding often to pick up the security updates) then Ubuntu (or Debian) starts to make sense. If you're purely running your own application/service (or non-repo software, e.g. rwasa) then Alpine seems perfect.
- justincormack 10y ago
  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 10y ago
    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
- Ruphin 10y ago
Watabou 10y ago
* Switch from OpenSSL to LibreSSL Is there any reason/discussion for this change?
- justincormack 10y ago
  Far fewer security issues, as much code has been removed.

87 points by laamalif 10y ago

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 10y ago
Have you tried https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rust https://pkgs.alpinelinux.org/package/edge/testing/x86_64/rus... ?
- justincormack 10y ago
  Yes I hadnt realised this was out until a few weeks back and it works really well.
- throwaway161220 10y ago
  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 10y ago
    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 10y ago
      > 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 10y ago
        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 10y ago
        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.
justincormack 10y ago
Most of the build fixes are offered upstream, not every upstream is interested in supporting non glibc Linux platforms alas. But gradually things are getting upstreamed.
- throwaway161220 10y ago
  Unfortunately, yes. Looking through llvm, rust, ocaml APKBUILDs for investigative purposes lists some diffs that seem upstream worthy.
  - justincormack 10y ago
    Some of them may have made it into master, but not a release, I thought the rust patches had, and the OCaml ones, but not 100% sure.

ohstopitu 10y ago

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 10y ago

Full ZFS root support, lovely stuff

joshpadnick 10y ago

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/

jonathonf 10y ago
If you're serving using repo software (and rebuilding often to pick up the security updates) then Ubuntu (or Debian) starts to make sense. If you're purely running your own application/service (or non-repo software, e.g. rwasa) then Alpine seems perfect.
justincormack 10y ago
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 10y ago
  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
Ruphin 10y ago

Watabou 10y ago

* Switch from OpenSSL to LibreSSL Is there any reason/discussion for this change?

justincormack 10y ago
Far fewer security issues, as much code has been removed.