Alpine Linux 3.7.0 Released | Hacker News Reader

Alpine Linux 3.7.0 Released

alpinelinux.org

115 pointsnikolay73 comments

Alpine is really good. I've been slowly migrating my boxen to it. Just deployed 3 dedis recently running it, a handful of VMs, and I'm installing it on my laptop before I go for holiday travel. I still have a couple of gripes but they've done a damn good job. Note: I use the vanilla kernel distribution.

Isn't the first thing you do to install GNU coreutils? Busybox is neat, but unusable for day to day usage, IMO.

Does that mean the AG Unix is on hold (or dead?). Btw, not sure if it's related to Alpine or not, but your servers are unreachable for me at the moment ;-)

agunix is dead, I killed the server the other day. I never quite accomplished the goals I set out with and had to make too many compromises. I might eventually try again with a different approach or just contribute to Alpine until I run out of gripes.

Ah, well, understandable. After reading about what it took to just bootstrap, it looks like a colossal amount of work to do a distro.

Running Arch at the moment but I am looking at Alpine or maybe one of the BSD's as an alternative.

Well, I got that far, I had a fully bootstrapped distro and was building a whole lot of packages. I just had to compromise on too many of my goals and I felt the distro eventually was no longer distinguished enough from its peers to be worth continuing.

Aren't you the creator of Sway? I recognize the username. Great work! I have a feeling you'll be the next big WM for Linux Desktop. Nothing compares to i3/Sway with a mechanical keyboard. Even Windows is moving applications to tabbed interfaces:

https://www.theverge.com/2017/11/28/16709190/microsoft-windo...

Thanks! I'm glad you like it.

Notable because it uses musl and does some hardening, such as building everything as PIE.

Musl is a promising glibc replacement.

PIE is default in a lot of distributions now.(https://bugs.archlinux.org/task/49791)

Unfortunately, Musl is a bit slower in things like memory allocation, etc.

Sure, it's slower than glibc at some things. And faster at others.

http://www.etalabs.net/compare_libcs.html

I believe it better overall.

As I've seen the above comparison already, glibc is the one better overall when size doesn't really matter.

New Features and Noteworthy New Packages

- Support for EFI;

- Support in the installer for the GRUB bootloader

Significant Updates

- GCC 6.4

- LLVM 5.0

- Go 1.9 - Node.js 8.9 (LTS)

- Perl 5.26

- PostgreSQL 10

- Rust 1.22

What does EFI support mean? I remember booting Alpine on an UEFI system a few months before this update so it can't be support for that. Is it maybe related to efistub?

So I am using Alpine and generally like it.

One question that perhaps someone on this thread will know... why does it cache DNS differently from Ubuntu, and is there a way to fix it?

My app has a domain name for the database sever that I pass to Psycopg2.. say foobar.something.google-cloud.internal. It resolves to the private IP of my PostgreSQL sever.

The problem, is EVERY SINGLE database query is querying the DNS. I can sometimes push 10,000 DNS queries per second. 9,990 of those are for the same stupid database server. Kubernetes runs it's own DNS server which takes the load, but sometimes they get overwhelmed a bit. I am obviously doing something wrong, but not sure the path to explore down.

If I can fix this, then alpine is working pretty amazing for me :)

You can fix this by installing and running a local dns server like dnsmasq to cache for you: apk install dnsmasq

See this: https://github.com/gliderlabs/docker-alpine/blob/master/docs...

Fantastic will try this

edit - so far no results, must need some other change to turn it on...

If you're still in search for a solution: dnsmasq acts as a caching dns server listening on your loopback device, so you probably need to change the dns server of your lan/wifi to 127.0.0.1 (or whatever address dnsmasq is configured to listen at), and also set what external dns servers should be used by dnsmasq. Those are usually not setup properly by default.

tbrock gave the work-around, but as for the "why", it's probably because Debian uses glibc for its libc, while Alpine uses musl. musl aims to be a much more compliant libc than glibc, so when you tell it to look up a name, it probably always does so. Like tbrock said, installing a local dns cache should help (or, failing that, an /etc/hosts entry?).

Its probably just nscd that is caching dns requests on debian not glibc. Though I thought nscd dns ttl caching was broken there. I could be wrong.

Musl libc's dns strategy should actually be faster than glibc when its used.

https://wiki.musl-libc.org/functional-differences-from-glibc...

That said a local cache would be ideal.

Ah ok..

My apk list looks something like

            gcc \
            make \
            libc-dev \
            musl-dev \
            linux-headers \
            pcre-dev \
            postgresql-dev \
            zlib-dev \
            jpeg-dev \
            libxslt-dev \
            libxml2-dev \
            git \

so I see musl but glibc in there....

I do not think I want to do the /etc/hosts thing, as the IP can change for some things.. I would rather just cache it locally for ? 1 minute or something

If your app is opening a new connection for every query, that might be your problem. I would look into having a pool of connections.

Alpine uses musl instead of glibc. Maybe you can find a way to run nscd on it but it doesn't seem very idiomatic for a container platform.

This and a couple of other comments mention nscd, however, unless it's different on other distributions, nscd works via a unix socket. To make it work in containers, you need to explicitly mount it in from the host or run the nscd daemon inside the container. I'd be surprised if @brianwawok was doing that with their non-alpine containers and didn't realize it since it's so explicit

That said, I believe Alpine does have a glibc package which only adds a few MB. So @brianwawok can at least still run Alpine for the image size benefits if musl is unimportant to them.

These are persistent connections, it's not that.

That's weird. I would fire up strace and check what's really happening. musl/glibc shouldn't have visibility into the queries you're making. My suspicion is that something at the app level is doing something that it shouldn't, not musl.

Thanks @gtirloni! I'm new to SQL and was working on a small internal tool. This change, an obvious one in hindsight, sped up my tool by ~2-3x. So for anyone else, check this!

A) If you are opening 10000 new db connections per second you are doing something very wrong. Use connection pooling! Psycopg2 actually has one built in. (http://initd.org/psycopg/docs/pool.html)

B) If DNS actually becomes a legitimate bottleneck, you can just manually resolve the domain name and cache it. If the db sits behind a load balancer or does DNS round robing you can keep the cache time low and re-resolve on connection failures.

a) No they are persistent. I set the timeout to be something like 600 seconds. They are wanting to do a DNS query every time they are used for ???reasons????.

b) I think dnsmasq is a better answer. My DNS is already load balanced in k8s, but that is getting hit pretty hard.

I know Alpine is a great fit for any container env but I'm wondering, is it used elsewhere?

I know a few people who actually use it as their main OS

Indeed. Just this week, someone in my hackerspace approached me who had just switched to Alpine on his notebook, and he convinced me to quickly add support for Alpine to the minimalistic configuration management tool that I'm maintaining.

I'm guessing this is the CM tool he was talking about: http://holocm.org/

I _think_ it's used by Synology as the basis of their DSM storage OS. At least you can install apk packages so that is my assumption.

not sure about this as Alpine is kind of x86 only. yes it has some armhf and ppc64 versions however it seems x86 is the main target to be run on.

on the other hand, debian, openwrt etc are built for multi-arch all the time.

No, arm, arm64 are well supported for physical install. I think ppc64le and s390x are mainly targeting container installs, but probably work for physical installs too.

I used Alpine as the guest OS in VirtualBox VMs. It was useful when I was learning about Docker. It helped me compare containers to virtual machines.

I use Alpine for the VM at the heart of my GPL WordPress tool InstantWP (https://www.instantwp.com).

I spent six months reviewing all the smaller distributions of Linux until I found one that would boot fast enough to be usable with QEMU. It works like a charm and i rock solid. I highly recommend it.

I think it's great on the Raspberry Pi [0]. It boots quickly, has a low footprint and runs in diskless mode by default [1].

I most recently used Alpine and a RPi to make an appliance of sorts, that would wait for the SSID of my Olympus WiFi-enabled camera (it acts as an AP) to show up and then sync all new photos automatically [2].

  [0]: https://wiki.alpinelinux.org/wiki/Raspberry_Pi
  [1]: https://wiki.alpinelinux.org/wiki/Installation#Installation_Handbook
  [2]: https://github.com/gvalkov/olympus-photosync-server

Great project based on Alpine:

https://postmarketos.org

Glad to see updated packages. I wonder if they should be favored over those offered by official Docker images when used in Docker?

For example, what are the pros and cons between using official Docker go image vs creating a custom image from an alpine image with apk add go?

I think I read somewhere that Alpine will update packages only when there are security fixes. I can't find a link to share, sorry.

If you're on Alpine Linux 3.6, you get access to Node.js 6.10.3 (or 7.10.1 in the nodejs-current package)

If you depend on targeting very specific versions of your runtime stack and also want to use Alpine, check if your stack offers official images based off of Alpine. For instance, node:8-alpine, python:3-alpine, etc.

It seems most projects will offer Alpine-based Docker images these days. They should update faster and more frequently, but that depends on each project.

There is an official Docker go/alpine image and their Dockerfiles are public, so if you wanted to create your own you could and it'd be exactly the same.

Many of the official Docker images have Alpine variants. Check the tags of the image you're using.

In theory I’ve liked the container sizes. The problem is the moment you need to do something useful with it ( I can stall python’s Requests library) the image size balloons up and becomes just another container.

Use something like https://github.com/box-builder/box?

Love alpine and it seeming less bloated than most other alternatives :)

Alpine is a nice if you're looking for a really small os with an large number of ported packages. I use it as a rescue system for my main linux os.

Only negative thing I can think of is that that their support forums¹ are full of spam. [1] https://forum.alpinelinux.org/forum/4

Really hoping that Alpine will come through with an official Amazon AMI, or with instructions that actually work on how to make your own.

Love that Alpine Linux uses OpenRC, and has no plans to switch to systemd. https://forum.alpinelinux.org/forum/general-discussion/alpin...

Edit: why downvote, I like it that way, leaner OpenRC is great

Yes, I'm also a fan of OpenRC. I have always found it intuitive.

Alpine aims to have a lean footprint and be highly configurable. I can't imagine using systemd for small-footprint systems, especially since systemd somewhat limits options for system organization.

As to the downvote, just consider it someone saying: "Your opinion is inconsistent with my agenda, and therefore invalid." It's meaningless.

Systemd is not orthogonal to lean and small-footprint systems. This is a good presentation on its use in embedded environments[0].

  [0]: https://www.youtube.com/watch?v=ERS1OSOTGpg

I've written many init scripts for SysV, upstart, OpenRC and FreeBSD's rc, but I've found that systemd's service units to be by far the cleanest and quickest way to muster up an init script (with FreeBSD's rc in second place).

Reply on news.ycombinator.com