Oinks

That is basically what the EUPL is.

In the sense that allowing a malicious application to steal your SSH keys is "fixing", yes.

This is interesting, but I wouldn't consider this to be at all comparable to Flatpak. From what I can see the only purpose of using bubblewrap here is the dependency isolation (without having to recompile the world ala Nix), which does have some value but it feels misleading to even call it a sandbox.

It mounts /home and /run into the ~~sandbox~~ chroot, which means that "sandboxed" applications can do things like reading your SSH keys, dumping your keyring or escaping the sandbox via write to .bashrc (so most of the attacks you'd want to prevent). This is presumably done because without /home access you wouldn't be able to write to the filesystem and without /run access you can't even display a graphical window, which would make the packages quite useless.

XDG Desktop Portal solves this by allowing filtered dbus access controlled by package metadata (/.flatpak-info), and then having sandboxed applications use portals to access files, secrets and other resources. The metadata is a major flaw in Flatpaks design (note that a lot of the most popular Flatpaks want full $HOME access), but it's also what allows Flatpak to be useful. In this project, there's no metadata since the packages just come from Alpine repositories.

I haven't heard of Coldbrew before, it looks very interesting.

The unfortunate thing about snap is that of all options, it is the most capable. You get GUI, CLI, server, full filesystem access if needed (aka classic snaps). But Canonical really drags the project down and handicaps it with poor decisions.

That's also how I feel about it. I've heard many good things about it technically, but Canonical really killed its adoption outside of Ubuntu.

Then you look into it a bit more and the story changes to "oh actually you need to enable this experimental feature to get better reproducibility".

This unfortunately gets misunderstood a lot, mostly because of the stupid flake hype. You do not need flakes for reproducibility, Nix comes with a fetchTarball builtin function which allows you to pin a specific Nixpkgs commit and output hash.

You're right though, I agree on basically every point (including the part about flakes).

I've used NixOS, wasn't that big of a fan. I certainly love the idea, but not the execution.

Would you mind elaborating on that? I do have some suspicions but I would love to hear what bothered you about it.

There's probably a combination of magic command line flags that allows podman/distrobox to work, but we honestly shouldn't need containers for this at all.

It's frustrating how we have all the pieces to make this work, but they just don't come together properly:

• Brew isn't sandboxed and pollutes the environment
• Nix isn't sandboxed and can't prefix install (also the DX with Nix really sucks)
• Guix is like Nix but without the packages
• Flatpak doesn't have the packages
• Snap is proprietary garbage

Maybe this is a hint that I should write my own package manager, ~~with blackjack and hookers~~ that works like Nix, but doesn't hardcode /nix/store, runs everything in bubblewrap and works with SELinux?

This was already posted three hours ago.

The only strong holdout is glibc (musl is no match, and doesn't pretend to be anyway).

Chimera Linux patches musl to use mimalloc and that allegedly mostly closes the performance gap. With notable glibc stronghold systemd supporting musl in recent versions I wouldn't be too surprised if it catches on eventually, like clang arguably already has.

I appreciate the work ahead of time, and the law is the law. @svartkanin raised this PR internally within staff channels, and the feedback is that we'll wait until there's an overall stance from Arch Linux on this before merging this, and preferably involve legal representatives on this matter on what the best way forward is for us.

But from a personal reflection it's clear that there's a disconnect between law makers intent and how things like this will be implemented in reality, and once a law is in place - we might have to implement inconvenient things..

So I'll leave this open for now, but I'll also lock the conversation because experience from the mailing lists on this topic has told us this thread will get out of hand quickly.

@dylanmtaylor: this stance does not mean that we won't merge this. And despite locking this thread, I think you, me and other contributors and maintainers can still comment (which is fine, and good).

Sounds reasonable to me

You also see Common Lisp on occasion, like in the browser Nyxt or the editor Lem.

Discover itself doesn't guarantee anything. Flathub (the Flatpak repository you are presumably using) requires a human review for new applications but not updates (and the human review doesn't include a full audit of the app). I'm not aware of malware being distributed via Flathub in the past, but that doesn't mean it can't happen.