Developer-driven software distribution is a bad idea, which is why I dislike things like Flatpak.
Having distro maintainers involved in the process and installing your software from a free software distribution like Debian or FreeBSD is a much better distribution of power. The packages can be tuned to suit their environment without the developer having to repackage it for every distro, and the distro maintainers can keep out anti-features like telemetry and advertising.
The middleman may seem annoying to developers, but embrace the model and it'll work for you. Landing packages in your favorite distro isn't actually that hard, and the rest of the distros will follow. If you're an end-user who wants to see some software available for your distro, look into packaging and volunteer - it's easy.
@sir One of the major features of Flatpak is using container technology to make sure no matter the distro, the package is running in the same environment as the developer's machine, so there is no need to "tune for the environment."
For the anti-feature point, if you have problems with the source, you should fork it, not pretend you are distributing the app while in reality you are distributing something else.
@grainloom I know it has been a long time but I didn't have a chance to look to Nix/Guix documentation until today. I wrote something with my limited understanding of Nix/Guix (and actually Flatpak too) that may be useful to compare:
@grainloom Also https://wiki.gnome.org/Projects/OSTree/NixOSComparison claims "In OSTree, the checksums are of object *content* (including extended attributes). This means that any data that's identical is transparently, automatically shared on disk. It's possible to ask the Nix store to deduplicate, (via hard links and immutable bit), but this is significantly less efficient than the OSTree approach. The Nix use of the ext immutable bit is racy, since it has to be briefly removed to make a hard link."
@cagatayy not sure how that works in guix, but it deduplicates a lot of data automatically.
the content based hashing could be solved by the intensional store and there is definitely ongoing work on the Nix side for that.
OSTree seems interesting tho, it might be useful for the stateful parts of Guix System.
@cagatayy it can, but it doesn't need to 99% of the time
the `guix environment` subcommand natively supports containers and the `guix system` subcommand can also work with various VM and container tech
it can also create self-contained redistributable packages with `guix pack`
@grainloom Oh, I should have been more clear, I meant things like limiting access to filesystem, network, X11, etc. The app manifest declares which permissions are given by default and it can also be overriden by the user. Flathub checks the permissions in the manifests for submitted apps. Some of this could also be done with Docker but since Flatpak is focused on desktop apps, it is simplified. There is also work to expose permissions in settings apps so the user can control in an easier way.
@cagatayy this whole sandboxing thing shouldn't need this much support machinery tbh. permissions systems shouldn't depend on package management.
some of those features would be nice to have in Guix, but the main reason app stores need permission systems is because you can't esily audit closed source crap.
@cagatayy i doubt they are equal in reproducability, guix can give you a full graph of the inputs for any package, all the way to the bootstrap binaries.
for tooling, i also have my doubts. declarative system configs are very cool. right now i'm debugging a wacom udev confif issue and i can do it in a vm by just running `guix system vm` on the config file i used to install the system. it barely takes up any space.
and i could then send this file to someone and they could test the exact same system config.
AFAIK this is not a goal of Flatpak & co.
Server run by the main developers of the project It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!