1. There should be an easy-to-use API, CLI, library, and data (sqlite db or whatever) to query package metadata efficiently.

2. The mythological purity of rolling releases building against edge versions without dependency constraints or maintaining stable versioning causes problems in the real world(tm). There are many cases where past versions are needed. Example: ffmpeg is buggy as hell and has to be managed very carefully. Another example: binutils, gcc, mpfr, mpc, and toolchain friends have to be built together with compatible versions. Further example: don't compile anything with Clang/LLVM 14+ unless you want all of your code to break because some genius decided to break the world out of ideological perfectionism. macports, Homebrew, nix, and Arch are just some who are guilty of this sin.

Didn't Pypi just remove signing too?

More information on that here: https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI...

There was a lot of talk about why this didn't go the other way; keeping signing, but making the practice meaningful. I forget the details about that.

https://www.techtarget.com/whatis/feature/SolarWinds-hack-ex...

https://dan.drydog.com/rpm-signing-howto.html

https://www.cryptnet.net/fdp/crypto/strong_distro.html

With truly reproducible builds, it's possible to introduce distributed caching of artifacts and selective probabilistic rebuilds from source to attest/verify integrity in a distributed manner.

> To make this new Linux variant, Lorenc said, "We hired a bunch of the original Alpine team. But, Alpine was never designed for containers. It was originally designed for routers, firmware, and that kind of thing. What made it attractive for containers was its size and security." Wolfi takes that minimal approach to an extreme for the sake of security.

Of course it's probably not the license he'd prefer but you can still appreciate something for what it is despite the license.

If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.

>Or more frequently on edge, which I run on my workstation and laptops

https://news.ycombinator.com/item?id=36407275

(tl;dr Alpine Edge is stable in some situations and unstable in others. User discretion is advised.)

It doesn’t make the news cause it’s a hobby os that was made important when we decided the size of the container mattered most.

Not using the same thing everyone uses forces developers to care about standards rather than to assume compatibility just because it is how the favorite implementation works. Same reason why it is a good thing that a popular browser that is not Chromium-based exists.

Also every headache I've had with musl libc is because glibc is insane, not because there is a problem with musl. It should be trivial to swap out your standard library, as that is the entire point of dynamic loading. Yet you cannot actually swap out the dynamic library that nearly every program on your system will need, because it's not actually a library.

I’d be more likely to use CoreOS as at least I can claim peer pressure, and potential layer savings.

Also some programming languages, you can’t really populate the app’s dependencies without a bunch of its dependencies. And the only way to split the difference means you have to memorize every file that gets created during the build/install process to be sure you don’t miss anything airlifting them from one container to another.

All of which amounts to me becoming the package manager. Which gets much less fun the more containers you have running in prod.

I generally respect the curation that alpine does. Not too old, not too bleeding edge.

You can attach a debugging container with your tools temporarily: https://kubernetes.io/docs/concepts/workloads/pods/ephemeral...

https://docs.docker.com/build/guide/multi-stage/

On a related topic, I don't use Ubuntu, Debian, Alpine, Arch, Gentoo, Rocky, Alma, Fedora, or {Free,Open,Net}BSD. I use CentOS 9 stream for most things: it's basically RHEL's kernel and it powers 100M's-1 B machines.

I'm no expert in the subject matter, [but support seems to be coming soon?](https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_2...)

Looks like the patch isn't very long either, so hopefully it'll be fairly solid:

https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb9778...

Glibc is also such a mess that it still does not compile with Clang, after _decades_, due to all the crazy GCC extensions they rely on. An attempt is cyclically started and the aborted when some new crazy nonsense is found. For instance, last time I checked they not only used the completely insane folly that GCC nested functions are, but they also relied on GCC attributes so nasty that LLVM never bothered implemented them (like renaming functions at code generation). Using these extensions are not really necessary, and I've a strong suspicious it was more of an attempt by the GNU authors to prevent distributions to ever consider not using GCC as their main compiler.

Also how name resolution is implemented in Glibc means you can't really statically link with it. If you've ever noticed, most "statically linked executables" are not in fact statically linked, but require ld.so just for libc. There are good reasons to disallow statically linking libc, but this is not one of them. Especially since the only stable API on Linux is the kernel interface, so the only way to not have to worry about future Glibc breakage is to either link with Musl or live with the risk.

I work in Python; pretty much no extension packages have a pre-compiled Musl version so you end up spending a ton of time compiling things!

>Using Alpine can make Python Docker builds 50× slower

Musl is a dire mistake.

glibc shouldn’t be statically compiled in because it’s lgpl and so immediately infects your code if you do.

The zig linker is quite nice here because it lets you pick what glibc you want to be compatible with.

Do you know if that's mainly due to the inefficient malloc, or if there are other important performance bottlenecks?

glibc has been more wildly tested, and fixed what was not working, while musl choices were mostly ideological

Only the truly insane would be lashing out at Alpine just because of its use of musl.

The path of least resistance is merely the path of least resistance, not necessarily the best, especially in the long term.

At one point glibc was the weird incompatible limited headache, and the only reason you can enjoy it today instead of paying $1200 to SCO or someone, is because other people did not take the path of least resistance.

In repl IIRC:

    :build pkgs.hello
    :build pkgs.pkgsCross.musl.hello

This one characteristic has made me a hero, over and over, and I'm honestly tired of it.

I'd think twice before using it. What you hope to gain and how else they may be achieved. Registry caches are easy to deploy and don't get enough love.

Any sufficiently complex service will find oddities, and you might need some graybeard wizard to sort it out.

With glibc this normally falls to nsswitch. Sadly I can't remember much about musl - I'm too tired and I've been focused elsewhere lately.

It's notably different in terms of preferred order between files/DNS, also with 'conflicting' repeats (aka lazy round robin).

Beyond that, my point is more about awareness. The developers involved were not aware of what you've provided... or what's not mentioned

We're not particularly interested in NixOS or Guix but we really really want to find a glibc-based distribution that works this way, because Alpine's musl is terrible for desktop use, but the package management is just so amazingly simple and beautiful on a daily driver.

-Emily (see HN profile for details)

It is a different desktop paradigm for sure (for one, you won't be using a standard package manager) and you do feel its rough edges sometimes, but it is my favorite Linux experience so far, where the OS doesn't stay on my way unless I want it to be in the way: I turn my PC on, use it as usual, desktop apps are updated on background with GNOME Software/flatpak and if there is a new image available, as soon as I reboot/shutdown, next time it is up, everything has been cleanly applied. Flatpak'd apps also won't spread files across the system, so everything is as self-contained as it can be.

[1] https://fedoraproject.org/silverblue/ [2] https://ostree.readthedocs.io/en/stable/manual/introduction/

So I made a little kit so anyone can do this on any linux so you can try all the cool stuff in there without the downsides of running a less popular configuration on the bare metal.

And since it's Alpine it's always a fast download vs. a heavier container.

https://github.com/ublue-os/boxkit

Why not? Isn't it a competing solution?

I'd argue Nix merely surfaces the inherently complex nightmare we've all been hiding from though.

From that view it's likely I'd view alpine as pretending to be simple while shuffling complexity elsewhere.

I'm not confident enough to say that is the case with alpine though.

We don't particularly care if, say, `lbu` is a 10,000 line bash script, if it works. Actually, we've tinkered around with KISS Linux before, where a single bash script is responsible for being the entire package manager and rebuilding the entire operating system live. We were unable to get Nvidia working on it even before the motherboard swap though :)

I stick to using Ubuntu minimal container images. They’re 30MB (compressed) in size so it’s never a problem around container bloat.

Those tasks then became Debian based within a couple days.

*cue to angry linux mob attacking me

Although I do have to say that almost all downsides of alpine are not really relevant in the context of containers

Alpine runs great on older hardware. Things that bugged me over the years are the lack of armv5 support (understandably an architecture that is dying) and that their native firewall awall is somewhat limited. Despite being a pleasure to use awall with iptables, it is not capable of nftables exclusive features (eg cake) as far as I understand, yet.

The lack of obscure packages in Alpines repositories is not really an issue in my scenario. Or compiling against musl. Neither is the mentioned DNS over TCP issue.

Using wlroots and sway is a breeze on Alpine and having moved from gentoo > arch > alpine over the years, I am glad Alpine exists. Second choice for me is Void Linux musl and their optional armv5 support via xbps-src.

I hope Alpine will stick around and is not only known to be slim in docker containers.

I too use Alpine on just about everything. I'm happy with it. I do wish it would keep one old kernel around after upgrades but I worked around that.

[1] - https://www.theregister.com/2023/05/16/alpine_linux_318/