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.

· · Web · 2 · 0 · 2

@cagatayy spoken like a dev who's annoyed that distros hold them accountable

@sir spoken like a person who does not have a real answer
Seriously, I don't maintain any apps. Even if your reply was in good faith, it is incorrect.
Second, it was clear in my first reply: just fork it. It will "hold me accountable." Who is not accountable is the maintainer who changes the code while not changing the brand. The one who should be accountable for the resulting errors is the maintainer but often the user does not know because the downstream is using the upstream's brand.

@cagatayy @sir Hate to bang the Guix/Nix pan all the time (no i don't) but what you want is reproducable packages/environments, not containers.

@grainloom @cagatayy nix people are like the homeless guy on the street corner ranting about the clinton administration in 2019

@sir @cagatayy Well, it's a much more usable rolling release distro than any other I've tried. Guix, that is. Nix's tools could be better.
And its developers aren't elitists who joke about mentally ill homeless people.
Call me when another distro gets an equivalent of `guix environment`.

@grainloom @cagatayy oh, shove off, it was a joke. NixOS is for FP elitists, that's why I don't like it. It's way too complicated for way too little gain. I'll take 90% the stability for 10% the complexity any day of the week.

@sir @cagatayy NixOS maybe, but Guix is not that complicated, nor are its developers or users FP elitists. But even Nix solved some very real problems that establishes package managers of the time failed to address.

@grainloom @cagatayy only true if you accept the "problems" it solves as such

@sir @cagatayy As someone who had pacman fuck up their bootloader due to a power outage, I welcomed anything that makes updates atomic. And being able to have conflicting versions of packages is also nice.

@sir @cagatayy It also makes parametric packages easy to work with. And the functional purity means you can provide binary caches for package variants. Undeclared dependencies not affecting build output is quite useful.

@grainloom @cagatayy I am familiar with these package managers, and I stand by considering these things antifeatures

@grainloom @cagatayy on the contrary, the average person doesn't give two shits about these things. To most people, Linux == Ubuntu

@sir @grainloom @cagatayy I'm very much a Guix advocate. We're developing an upstream distribution, based on this (still young), but in my opinion, fantastic package manager. That being said, I have to agree with Drew. For the majority, Linux = Ubuntu. Most people don't care about the technical details, or reproducible environments - nobody would be using Windows, or MacOS if that was the case. People want beautiful, no-brainer software, that helps them accomplish stuff without reading a manual.

@franz @sir @cagatayy I kinda agree with this but if someone's doing web development and have already installed a language specific package manager, then using Guix or Nix shouldn't be that hard for them and if they wanna distribute things with Flatpak and absolutely refuse to write a proper package instead, then I'd prefer guix pack instead of a blob that who knows what generated.

@grainloom @cagatayy @sir @franz The major difference between language-specific package managers and guix/nix is that the former generally:

- Work out of the box on Windows
- Are installable by non-root in an arbitrary location

I believe that at least one of buck/pants/bazel do this to some extent already today for some languages.

I hope we can one day have a guix-lite that while giving up on some features of full guix can fulfill the above two requirements and make cross-language deps normal rather than fringe, and stop new languages from inventing the 847th wheel.

And, of course, it should fit well with guix-full so that a real guix can benefit from the packaging work done for devs.
@grainloom @cagatayy @sir @franz Cool! So both Nix and Guix support PRoot. It's a bit awkward, but it checks the box.

Still need to cover all those Python devs on Windows. But maybe all of them will be on Linux on Windows sooner or later.

@clacke @cagatayy @sir @franz @grainloom RPM is working on rootless support, and there's a port of RPM with DNF to Windows in progress by the Midipix folks. I'm working on bringing it to macOS myself.

@Conan_Kudo dnf on Windows using minipix? Now I've heard everything. 😀

I hope Windows doesn't become a usable development platform before most of the devs have moved to Linux already.
Show more
Show more


Strictly speaking, the average person doesn't even know about Ubuntu. I would guess more people have heard about Android running on something called Linux (even if it isn't 100% true)

@grainloom @sir @cagatayy

> As someone who had pacman fuck up their bootloader due to a power outage, I welcomed anything that makes updates atomic.

I had (almost) the same thing happen to me, and it also dramatically increased my interest in #GuixSD, though I haven't made the time to try it out.

("Almost" because it wasn't a power outage, it was a WM crash. Which led me to switch to a more stable/simple windows manager (away from #stumpwm to #bspwm))

@grainloom @sir @cagatayy for this point, RPM-OSTree can be a good compromise here. It gives atomicity of image based installs while supporting package installs in a safe way.

@sir @grainloom @cagatayy

> I'll take 90% the stability for 10% the complexity any day of the week.

Yeah, me too if it's reducing complexity by 90% in return for reducing stability by 10%.

Out of curiosity, how much increased complexity (if any) would you accept for 10% more stability?

(Not that I have any idea how to measure either in practice…)

@codesections @grainloom @cagatayy once a system reaches a practical threshold of stability, I will not take anything but slight increases in complexity to push the number further up. In the bootloader case, it's hardly difficult to boot up from your recovery disk and fix it the once in a blue moon it happens

@grainloom @cagatayy @sir And if you actually want a container basically you just `--container`. 😀

@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:

@cagatayy hmmm, it doesn't look like it adds anything that Guix can't do, at least for libre/open packages.
conflicting versions are already taken care of in Guix, and you also get reproducable builds and a lot of tooling.

@grainloom Can Guix do sandboxing? If not, I think that would be an important advantage.
For conflicting versions, reproducable builds and tooling (if you mean the environment part) I think they are equal.

@grainloom Also 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.

@cagatayy Good comparison article, thanks! Didn't know about OSTree before, and that this is what the new immutable Fedora thing uses, that's pretty cool.

Flatpak and OSTree vs Nix/Guix seem similar enough that you could probably implement the one with the other, but I think Nix/Guix are more fine-grained and like @grainloom I suspect Guix/Nix are more intent on Sourcing All The Sources. Not 100% certain though. Would have to look closer at the flatpak package data to find out more.
@grainloom Nix/Guix enthusiast here, banging the Nix/Guix pan with you.

I definitely find that sometimes people happily try to solve problems which have been solved in Nix/Guix since some time already. This means that the pan must be banged even harder.

I sporadically work on various FLOSS projects, but mostly teach and write research papers, and I find that NixOS fits my needs perfectly. The language may often be somewhat obscure, so I started reading up on Guix, which looks much cleaner in many aspects. Unfortunately, I still need to use a couple nonfree tools from time to time, so I am a little bit apprehensive (but I am thinking about a VM solution).

@scolobb There are channels for a lot of nonfree stuff, I use one for my wifi drivers.

A cool thing Guix also lets me do is have two configs installed side by side, one with fully free software, and one with some proprietary stuff.

There are also some nonfree applications packaged in channels, but I haven't needed those so far.

@grainloom I've seen some docs about those channels indeed, but thanks a lot for confirming! I'll definitely try GuixSD on my next machine: even though I like Haskell, I find Nix's syntax waay more obscure than Guile's, and the infrastructure of Guix seems cleaner as well.
Sign in to participate in the conversation

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!