[HN Gopher] Alpine Linux 3.15
___________________________________________________________________
Alpine Linux 3.15
Author : protecto
Score : 134 points
Date : 2021-11-24 14:42 UTC (8 hours ago)
(HTM) web link (alpinelinux.org)
(TXT) w3m dump (alpinelinux.org)
| mt42or wrote:
| Did they break all things again ? (3.14 breaks lots of things for
| containers.)
| petercooper wrote:
| I'm familiar with Alpine in container scenarios, but is there any
| mileage to using it as a day-to-day desktop distro?
| rahen wrote:
| I use Alpine as my server OS, with Alpine, Ubuntu and CentOS
| containers running on it. It works great this way too.
| pionar wrote:
| Not really. It's not designed for that. It's designed to be as
| lightweight as possible.
|
| also, instead of Glibc, it uses musl, which although is
| supposed to be binary-compatible, does have some gotchas, so
| the larger the system, with more apps and libraries running on
| it expecting glibc, will have issues.
| lonjil wrote:
| It is designed for desktop use, actually. Many of Alpine's
| developers use it as their primary PC distro :)
| qwertox wrote:
| musl really becomes a pain if you work a lot with Python. You
| can't use wheels, which means you will have to compile
| everything yourself, which sometimes takes ages, and you're
| not guaranteed that it won't have unnoticeable errors.
|
| My biggest issue was with the 3.12 -> 3.13 transition, when
| musl got upgraded to 1.2 and with it "musl 1.2 uses new
| time64-compatible system calls". This broke so many things
| for me without me knowing, like nginx having as the datetime
| in the logs the unix epoch. All continued to work, but
| everything related to timestamps was completely messed up, on
| 32 bit OS due to running on Raspberry Pis.
|
| This was the moment where I decided to stick to debian-slim,
| and only very specific containers will continue running on
| Alpine. Before that it was my default container OS.
|
| Also there is no reliability in packages getting updated,
| sometimes they just disappear in the next version. But these
| things are rare occurrences, which only are then nerve
| wracking when you are confronted with them. For 90% of the
| cases Alpine is one of the most awesome container OSs.
| rcarmo wrote:
| Actually, you can run most wheels just fine if you do this:
| https://github.com/insightfulsystems/alpine-
| python/blob/5a34...
|
| You just need to know how :)
| scandinavian wrote:
| > You can't use wheels
|
| musl wheel support was added some time ago:
|
| https://github.com/pypa/packaging/releases/tag/21.0
|
| No idea how many packages actually build musl wheels
| though. From a quick glance at least cryptography and lxml
| has musl wheels.
| rcarmo wrote:
| This still works for me:
|
| https://github.com/insightfulsystems/alpine-
| python/blob/5a34...
|
| But I haven't tested today's version yet.
| senknvd wrote:
| Unfortunately, Alpine patched their version of Python in
| a way that is incompatible with musllinux wheels so we
| are back to where we started until Alpine Linux 3.16 in
| 2022[1].
|
| EDIT: I spoke too soon. Apparently, they have decided to
| amend the patch in a way that is both backwards-
| compatible and compatible with musllinux wheels[2].
| Hopefully, it will roll out soon.
|
| [1]: https://gitlab.alpinelinux.org/alpine/aports/-/issue
| s/13227 [2]: https://bugs.python.org/msg406939
| yieldgap wrote:
| thanks, I had been scouring the internet for something on
| this. Didn't expect to come across it on HN
| _ikke_ wrote:
| This will be addressed though
| wahern wrote:
| OpenBSD went through a similar transition, except they
| didn't even try to maintain ABI compatibility. See
| https://www.openbsd.org/55.html and
| https://www.openbsd.org/faq/upgrade55.html, the latter
| describing the rare "flag day" event. Long term this was
| good for OpenBSD as it saved a ton of unnecessary cruft and
| complexity that would have haunted OpenBSD for years if not
| decades, endlessly taxing developers' time, especially of
| core developers. And it was an inducement for all
| developers, those working on OpenBSD (core and ports teams)
| as well as those targeting OpenBSD, to carefully review
| code for 64-bit time_t safety. But it necessarily required
| that the broader community shoulder a large part of the
| transition burden.
|
| Sometimes it's better to power through with a massive labor
| effort than to try to use fancy hacks to shield people from
| latent problems. All things considered, it doesn't sound
| like the Alpine transition was that bad. But it's the type
| of thing that most Linux users and developers are not
| accustomed to, at least those who don't remember the very
| early years. Ironically, musl libc might not exist if glibc
| hadn't accumulated so much complexity trying to maintain
| strong ABI compatibility.
|
| IMO, small prices to pay for free software and Free
| Software.
| fmajid wrote:
| There is a lot of affinity between Alpine and OpenBSD.
| That's a good thing in my book.
|
| I build my entire development stack from source and don't
| rely on OS packages for it, and I absolutely refuse to
| use binary compiled Python wheels, so Alpine's lack of
| them is actually a feature as far as I am concerned. I
| dealt with the musl quirks.
| puzzlingcaptcha wrote:
| I use it on a headless thin client serving as a NAS/ printer
| server / media box etc. Works very well. Keep in mind that
| Alpine actually predates containers by many years. It
| originally started as a light-weight distro targeted at
| embedded stuff. And the roots are still there.
| https://heap.ovh/alpine-linux-on-fujitsu-futro-s520s720.html
| jagger27 wrote:
| I use it as a bare metal OS on my blog server and it's great in
| that scenario too. I've personally found the libc stuff makes
| it really inconvenient to use as a desktop OS, unfortunately.
| You have to jump through hoops to get something like VSCode to
| "just work".
| turminal wrote:
| Software like VS code is in direct conflict with the way
| alpine does things. Alpine on the desktop is certainly not
| for everyone, but for some use cases it works great.
| spystath wrote:
| Powers my router, running on an APU2. The run-from-ram-with-
| overlays configuration makes upgrades relatively painless.
| alexwennerberg wrote:
| I use it as my primary OS. You have to do more setup work,
| there's much less documentation/help online than more popular
| distros, and running proprietary software (which usually links
| to glibc) is probably not worth the effort. This is mostly fine
| for me, as I don't do much on my computer aside from code and
| use a web browser -- the only difficulty is most streaming
| video unfortunately requires Widevine. Given those limitations,
| I'm very happy with it: it's very simple and I have a much
| better understanding of what is installed/running and why.
| petercooper wrote:
| Yeah, coding (in terminal windows only) and Web browser is
| what I'm thinking of using it for. I might just have to
| plunge in and give it a go, thanks! :)
| yjftsjthsd-h wrote:
| I use it on my desktop:) It's a nice experience after a slight
| learning curve; I'm particularly fond of it supporting ZFS well
| without being Ubuntu. Musl libc _is_ a potential pain point; I
| get most software from official repos or build from source, but
| ex. to run Steam I resorted to flatpak (which just shoves glibc
| in the container with the application).
| xxpor wrote:
| For an average user, I'd guess they'd hit more issues with
| busybox than musl.
| spyremeown wrote:
| I hate how many incredibly useful and sane options and most
| of the time missing from busybox binutils... drivers me
| crazy.
| yjftsjthsd-h wrote:
| If you care, just install the `coreutils` package and it'll
| overwrite the default symlinks and you'll get GNU coreutils
| by default.
| xxpor wrote:
| Oh thanks, that's good to know they're available.
| yjftsjthsd-h wrote:
| Yep:) If you found that useful, I'd suggest looking over
| all of https://wiki.alpinelinux.org/wiki/How_to_get_regul
| ar_stuff_w...
| mikece wrote:
| Are there any (lightweight?) desktop distros built atop
| Alpine as a base?
| patrakov wrote:
| postmarketOS is based on it. I tried it on my PinePhone, it
| works, but in the end I went with Arch Linux ARM.
| El_RIDO wrote:
| I can't recommend it for desktop use, but it is possible to use
| it as such.
|
| IMHO it really shines on dedicated, small VMs or for headless
| SBC use cases.
|
| There's only 5 daemons running after the installation (provider
| in brackets, the installer asks which one for ssh and ntp): -
| init (OpenRC) - ssh (dropbear or OpenSSH) - ntp (chrony or
| busybox) - crond (busybox) - syslog (busybox)
|
| The diskless mode it offers is ideal for SBC's or other use
| cases with SD-cards or such.
|
| So it's niche seems to be with very lightweight or hardened
| servers.
| wchar_t wrote:
| I use it as a daily driver on my Raspberry Pi. Since the
| community is small the package repositories are a bit small as
| well, and I occasionally have to build stuff by hand (painful
| on the Pi). Add musl to the ARM platform and most binaries in
| the wild won't run. However, musl and apk means the Alpine is a
| lot faster than, say, Raspbian or Arch.
| seemaze wrote:
| I love Alpine on the Raspberry Pi Zero family. Not only does
| this create a durable and speedy ramdisk appliance, but
| experience configuring and minimizing the build size
| translates to containers as well.
| spurgu wrote:
| I haven't used it as a desktop, but as a minimal VM for bastion
| SSH servers.
| lonjil wrote:
| As long as you're OK with the limitations imposed by using
| musl, I think it's great on the desktop. I recently switched
| from Void Linux (glibc variant) and it's working very well. I
| run proprietary applications like Spotify, Steam, and Discord
| in Flatpak, and most of the rest from Alpine's repos.
|
| One thing that surprised me is that KDE's software center gives
| package update notifications for Alpine packages OOTB, and the
| GUI Just Works(tm) for installing and upgrading.
| blueflow wrote:
| I am using it as desktop, it does not do things i did not ask
| for, which i really appreciate. I get away with it easily
| because i only use xterm and Firefox for the graphical part.
| fmajid wrote:
| Not as a desktop but I use it on bare metal as my primary
| server. The main advantage is the absence of bloat, e.g.
| components like DBus or systemd that increase the attack
| surface. The use of musl vs. glibc does make some things more
| complicated, however.
| lonjil wrote:
| > The main advantage is the absence of bloat, e.g. components
| like DBus
|
| ? Like most distros that start you off but nothing but a
| minimal base, you can choose whether to install DBus or not.
| Almost everyone using Alpine as a daily driver on their PC
| probably has DBus installed and enabled.
| vmoore wrote:
| Does anyone know where there are screenshots of this on the
| website? I like to see how a desktop looks before I try a new
| distro. Seems absent on the site
| miggol wrote:
| Alpine is more of a command-line distro. It's compact design
| and lack of many dependencies make it ideal for virtual servers
| and containers. Personally I've been eyeing it for an install
| on a small ARM board as a music streaming server, which it
| seems quite suitable for. In this case I would still connect to
| it over the network, still with no GUI or desktop.
| bluedays wrote:
| You can install any Desktop Environment you want.
| yjftsjthsd-h wrote:
| Alpine is a bare bones / DIY distro (like Arch); it'll look
| like whatever DE you install.
| dougbarrett wrote:
| From what I understand of alpine, it's commonly used for Docker
| images to provide a lightweight distro for your apps vs using
| something like ubuntu or debian which may include more than
| what's required.
|
| I don't believe it's intended to be used in a desktop
| environment, but I could be wrong.
| Seirdy wrote:
| This is false; you can install a variety of DEs from the
| repos.
| samgranieri wrote:
| Yes, it's defintely used for Dockerizing apps. I've
| Dockerized several Ruby, Node and Elixir apps using Alpine at
| work.
| smitty1e wrote:
| Is Python totally DIY? Can't find it in the package search.
| lmns wrote:
| Try 'python3' or 'python2'.
| El_RIDO wrote:
| The packages are either python3 or python2 for the language,
| and prefixed py2- or py3- for any of the packaged modules.
| https://pkgs.alpinelinux.org/ does support wildcards so you
| should find the packages using "python?" or "py?-*".
| nick238 wrote:
| There is a pretty good set of maintainers/packagers that
| compile Python libs for Alpine, but if you stumble across one
| that doesn't have a binary built, you're going to have to
| install the whole build toolchain and get all the headers
| yourself. The pre-compiled manylinux* binary packages on PyPI
| aren't compatible with Alpine.
| rcarmo wrote:
| Try this:
|
| https://github.com/insightfulsystems/alpine-
| python/blob/5a34...
| smitty1e wrote:
| Ah, so. Python2 is past the "pining for the fjords" stage, I
| should think.
| nanis wrote:
| apk add python3
| jiripospisil wrote:
| I've just upgraded from 3.14 and everything seems to be running
| well. I'm always amazed how incredibly fast the package manager
| is (apk). If you think Arch's pacman is fast, this is still on
| another level.
| efxhoy wrote:
| Cool that they switched to `doas` from `sudo`. Another great
| OpenBSD tool gaining more adoption.
| xxpor wrote:
| What's the 2 minute summary of why doas is better?
| kingofclams wrote:
| Smaller, less features, ideally less vulnerabilities.
| throwaway984393 wrote:
| On the one hand, I get that not everybody needs all the
| features of sudo, but on the other.... Sudo is _way_ more
| useful than doas. If you really go through all its
| functionality, you start using it in ways you didn 't think
| to before.
|
| You can have a custom AuthZ solution and automatically
| inherit sudo permissions based on groups. It supports a
| configurable askpass. You can background jobs, change
| working directory, selectively pass or set environment
| variables, set $HOME, use a login shell, preserve origin
| groups, use a chroot, read a password from STDIN, override
| the shell, set a timeout. And of course the sudoedit
| features.
|
| I know we all like programs that "do one thing well", but
| sometimes the best way to support all the use cases we want
| is a big honking program.
| masklinn wrote:
| Although it is annoyingly and quite critically missing a
| replacement for `sudo -e` / sudoedit (or was last time I
| checked).
| dotancohen wrote:
| What is wrong with `sudo vim /etc/foo`? I feel that it's
| better than `sudo -e`, but would love to see an example
| where `sudo -e` is better.
| josepmdc wrote:
| `sudo vim` will not load your user's vimrc, sudoedit will
| dotancohen wrote:
| Which is arguable an attack vector. Depending on how
| careless the user is, there is far more likely a chance
| that malicious code is found in .vimrc than is found in
| the VIM executable.
| fragmede wrote:
| _sudoedit_ runs your editor as you, not root, so unless I
| 'm misunderstanding you, no such attack surface exists.
| masklinn wrote:
| They're probably referring to the attack surfaces of the
| extensions you have loaded in your normal configuration,
| as opposed to the probably empty environment of root.
| masklinn wrote:
| It will also run your entire editor as root, which may
| not be something you want.
| masklinn wrote:
| > What is wrong with `sudo vim /etc/foo`?
|
| Aside from forcing vim onto innocent users?
|
| > I feel that it's better than `sudo -e`, but would love
| to see an example where `sudo -e` is better.
|
| It is way worse than `sudo -e`, because it runs the
| entire editor as root, whereas `sudo -e` runs a few file
| copies / move as root. So `sudo -e` has a significantly
| lower amount of stuff in the "secure zone", and thus,
| much in the same way `doas` is more secure than `sudo`,
| `sudo -e` is a lot more secure than running the entire
| editor.
|
| It also works with anything you can set as $EDITOR.
|
| Some editors (like vscode) will outright refuse to run as
| root by default.
| dotancohen wrote:
| > Aside from forcing vim onto innocent users?
|
| Actually, `sudo -e` forces VIM onto innocent users. You
| are free to `sudo nano` if that's your preference.
| > `sudo -e` runs a few file copies / move as root.
|
| Interesting, thank you, I did not know that the editor is
| not run as root with -e. So presumably that means that it
| will have my environment, e.g. will run my .vimrc? Though
| that could be an attack vector too.
| masklinn wrote:
| > Actually, `sudo -e` forces VIM onto innocent users
|
| No, it does not. It runs whatever EDITOR is set to
| (technically the first set of SUDO_EDITOR, VISUAL, and
| EDITOR).
|
| > So presumably that means that it will have my
| environment, e.g. will run my .vimrc?
|
| That is correct.
|
| > Though that could be an attack vector too.
|
| Only on the specific file, which would usually be a lot
| more noticeable unless the attack specifically manages to
| recognise and target sudoedited files while closing the
| buffer.
| dotancohen wrote:
| > Only on the specific file, which would usually be a lot
| more > noticeable unless the attack specifically
| manages to recognise > and target sudoedited files
| while closing the buffer.
|
| I've seen far more sophisticated attacks than that.
| Though vimscript itself is kind of a barrier to entry ))
| mixmastamyk wrote:
| alias suedit='doas ...'
| masklinn wrote:
| That is not at all what sudoedit does.
| mixmastamyk wrote:
| Not at all? Might wanna brush up on the manpage. The temp
| file is a feature but not essential to getting work done.
| masklinn wrote:
| > The temp file is a feature but not essential to getting
| work done.
|
| The entire point of sudoedit is to reduce the attack
| surface, without that it's absolutely useless since you
| can just `sudo` whatever editor you prefer.
| mixmastamyk wrote:
| Exactly. And could be trivially implemented.
| anthk wrote:
| >cat /etc/doas.conf permit persist :wheel
|
| Now all the users belonging to wheel can run stuff as root.
| Done.
| rubyist5eva wrote:
| Sure this is a nice and concise (yet somewhat trite)
| example, but this can be done easily with 1 line in sudoers
| as well (and is usually configured like this by default
| anyway).
|
| Not that doas isn't great, but this particular reason isn't
| that compelling (to me).
| yjftsjthsd-h wrote:
| That's the _entire_ configuration. It does not need
| documentation that starts with a quick introduction to
| EBNF, the whole thing it 's about as simple as you could
| possibly make it. Granted, if you're just doing small
| edits to existing sudo config it might not matter too
| much, but I find it appealing to be able to read and
| understand the entire configuration file and add new
| configuration easily.
| joshklein wrote:
| Configuring sudo is such a footgun that it was deemed
| necessary to fork a text editor purpose-built for only
| modifying sudo configurations (visudo).
|
| So, that's why _not_ sudo. As for why doas, see:
|
| * https://flak.tedunangst.com/post/doas
|
| * https://flak.tedunangst.com/post/doas-mastery
| supergarfield wrote:
| visudo isn't a fork, it just locks the sudoers file against
| concurrent edits, runs whatever standard editor you want,
| waits for it to finish, and validate the new file before
| committing it to the real location.
|
| I can agree that process is too complex, but they're not
| maintaining a fork of vi for that purpose.
___________________________________________________________________
(page generated 2021-11-24 23:02 UTC)