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?
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.
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 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].
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.
GNU coreutils and the broader GNU operating system is an extreme exercise in bloated and overengineered software. It's the antithesis of everything I like Alpine for. Give me a POSIX coreutils and I'm happy. Actually using any of GNU's extensions is an antipattern.
I don't really care about anti-patterns, I care about usability. They're usable, full of features I use and have nice, standardized long form flags, especially good for scripts.
No, they're especially awful for scripts. The only place where extensions are maybe appropriate is ad-hoc at your shell. Your scripts are non-portable. Suck it up and learn the POSIX flags, they're not difficult. If you can't, then you aren't really in Alpine's target audience anyway.
That's a great philosophical standpoint, but unfortunately in the real world BusyBox/musl is just incompatible with some software.
I recently had issues getting Node running with nvm (see [this issue][0] and [this one][1]). Sure, there are workarounds, but GNU coreutils is the standard user land toolset for Linux, and it's no surprise alternative tools are less supported overall.
I hope this will improve over time, because Alpine is an awesome distro.
Then nvm downloads binaries compiled for glibc, not Linux. This is a bug in nvm - not Alpine, not Busybox, not musl, but a bug in nvm. Using tools like nvm is the wrong approach anyway, you should be installing from distro packages - and Alpine supports installing specific versions of a package if you really need that.
>GNU coreutils is the standard user land toolset for Linux
> This is a bug in nvm - not Alpine, not Busybox, not musl, but a bug in _nvm_.
Why the defensive tone? I never claimed one or the other, but as a user, I would just like to see it fixed.
> Using tools like nvm is the wrong approach anyway, you should be installing from distro packages
Please don't tell me what I should be installing. I _like_ nvm and similar tools for other languages, and would like to keep using them without my operating system (or anyone else for that matter) dictating what software to use and why.
Of what, exactly? Of some Unix interoperability ideal? Sure, it has its place. But I'd argue that improving the user experience is even more important, and when user land tools break because of a choice of OS/toolchain, something is wrong there.
Seconded. It's really important that we get out of this "works on my machine" philosophy so endemic to current software dev.
Learn standards. Read about the history of the platforms you're developing for. Get to know their communities. Don't just drop a code bomb on them and say, "well it works for me".
Let's be fair, coreutils are awful for scripting regardless. It is 2017, why are we having to parse and reformat text to pass it between tools? Powershell, which pipes tables of typed objects, is a much better implementation of the same concept.
So let me get this straight. You're saying to take the output of some coreutils tool, pipe it's output text through something that parses text into json, manipulate it with another program, pipe that out through a program converting json to formatted text, and finally pipe that to some other tool.
And that's simpler than just having the tools input and output tables of typed object data directly (can be represented in json for all I care) how?
I'm not really talking about coreutils at all at this point, and neither are you. You're talking about shell features. And I can't speculate on how using jq is generally applicable, but I can give you an example of how to use it in a particular situation.
Except you specifically stated that the coreutils way of doing things was objectively simpler than the Powershell way. If what you're saying about json wasn't applicable to coreutils than it wasn't applicable to your assertion either.
I was never picking nits. The UNIX way is to have simple tools that do one thing well and that can be chained together easily to perform complex tasks.
Guess how Powershell works. And it does it without a bunch of error prone text parsing. And it's a much saner scripting language than Bourne shell variants. And it has the entire CLR at it's disposal (including the C interface).
And you're seriously trying to tell me that the 70s era implementation of the UNIX philosophy is better?
It's clear that PowerShell implements a more modern design, but that doesn't instantly make it better or more powerful. It's just different.
Unix still works fine; we know its quirks, and we work around them. We try to improve it in some areas, but back track in others. We might even tackle object passing some day, and some development has been done in that[0] area[1].
But that's the good thing: Unix (certain variants more than others) is open to change and anything (mostly) goes, and it's not produced by a single corporation. One that is embracing open source more recently[2], sure, but a corporation none the less.
Oh I agree that trusting Microsoft is not a wise move, I'm just disappointed in the way the open source community clings to such archaic tools and methodologies when there is a demonstrably superior approach. Maybe you're all "that's just, like, your opinion man", but I think if you actually used both Powershell and the UNIX toolset day to day, you'd find that it is objective fact.
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.
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:
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.
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).
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.
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 :)
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?).
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
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.
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.
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.
76 comments
[ 3.6 ms ] story [ 133 ms ] thread- 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
on the other hand, debian, openwrt etc are built for multi-arch all the time.
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 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].
https://postmarketos.org
Musl is a promising glibc replacement.
http://www.etalabs.net/compare_libcs.html
I believe it better overall.
I recently had issues getting Node running with nvm (see [this issue][0] and [this one][1]). Sure, there are workarounds, but GNU coreutils is the standard user land toolset for Linux, and it's no surprise alternative tools are less supported overall.
I hope this will improve over time, because Alpine is an awesome distro.
[0]: https://github.com/creationix/nvm/issues/1102
[1]: https://github.com/creationix/nvm/issues/1250
>GNU coreutils is the standard user land toolset for Linux
Bullshit. This is the standard: http://pubs.opengroup.org/onlinepubs/9699919799/
Why the defensive tone? I never claimed one or the other, but as a user, I would just like to see it fixed.
> Using tools like nvm is the wrong approach anyway, you should be installing from distro packages
Please don't tell me what I should be installing. I _like_ nvm and similar tools for other languages, and would like to keep using them without my operating system (or anyone else for that matter) dictating what software to use and why.
> Bullshit.
https://news.ycombinator.com/newsguidelines.html
> This is the standard: http://pubs.opengroup.org/onlinepubs/9699919799/
Of what, exactly? Of some Unix interoperability ideal? Sure, it has its place. But I'd argue that improving the user experience is even more important, and when user land tools break because of a choice of OS/toolchain, something is wrong there.
Learn standards. Read about the history of the platforms you're developing for. Get to know their communities. Don't just drop a code bomb on them and say, "well it works for me".
Coreutils still works, true, but it does not work great.
And that's simpler than just having the tools input and output tables of typed object data directly (can be represented in json for all I care) how?
Guess how Powershell works. And it does it without a bunch of error prone text parsing. And it's a much saner scripting language than Bourne shell variants. And it has the entire CLR at it's disposal (including the C interface).
And you're seriously trying to tell me that the 70s era implementation of the UNIX philosophy is better?
Unix still works fine; we know its quirks, and we work around them. We try to improve it in some areas, but back track in others. We might even tackle object passing some day, and some development has been done in that[0] area[1].
But that's the good thing: Unix (certain variants more than others) is open to change and anything (mostly) goes, and it's not produced by a single corporation. One that is embracing open source more recently[2], sure, but a corporation none the less.
[0]: https://plumbum.readthedocs.io/
[1]: http://xonsh.org/
[2]: https://azure.microsoft.com/en-us/blog/powershell-is-open-so...
Nevertheless, I agree with the statement wholeheartedly.
It is an opinion. And no "substantive proof" is required to support an opinion. Only experience is required.
Everyone is free to form their own opinion. How?
Maybe something like
1. Try GNU coreutils.
2. Try an alternative such as a BSD project or Plan9.
3. Think.
4. Form opinion.
Thus one cannot dismiss alternatives to GNU coreutils without trying them first.
Running Arch at the moment but I am looking at Alpine or maybe one of the BSD's as an alternative.
https://www.theverge.com/2017/11/28/16709190/microsoft-windo...
Edit: why downvote, I like it that way, leaner OpenRC is great
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.
Only negative thing I can think of is that that their support forums¹ are full of spam. [1] https://forum.alpinelinux.org/forum/4
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?
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.
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 :)
See this: https://github.com/gliderlabs/docker-alpine/blob/master/docs...
edit - so far no results, must need some other change to turn it on...
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.
My apk list looks something like
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
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.
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.
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.
b) I think dnsmasq is a better answer. My DNS is already load balanced in k8s, but that is getting hit pretty hard.