Flatpak and the likes are similar enough to Apple's "bundle" concept where you put all the versions, dedicated libraries and frameworks inside the bundle for your 'thing' that you want to distribute. It has been proven to work well (or well enough). I suppose the additional technology behind overlays/bindmounts etc. is different since a Darwin bundle is practically just a directory with some predetermined layout but the experience is the same.

Once it doesn't depend on (yet again) a daemon, registry, and other system-level components but is understood by the shell (or DE) instead, you get a user experience that something like Nix cannot deliver (or at least, not without cutting down on the whole "learn this language to then learn those features to then get work down" thing).

The bundle concept applies more to AppImages than to Flatpak. Flatpak downloads common runtime libraries and packages and uses them to run all GUI packages in a sandboxed environment using bubblewrap. OStree is also involved.

I dislike Flatpak because it encourages package maintainer obsolescence. I heard a guy from OpenSUSE saying in a MicroOS presentation that why create, manage, and use RPMs when we can just use Flatpak. I also don't want to touch Flatpak anymore because people from GNOME are involved in it.

I have to admit that Flatpak's runtime deduplication is impressively good, despite preferring the Nix approach.

It's a shame to hear that kind of talk coming from the openSUSE world when Zypper did so much to raise the bar for high-level Linux distro package management tools. :(

openSUSE does an awesome job getting a hell of a lot of mileage out of RPM, from the vendor-based repo management to BTRFS snapshots to the huge and powerful (cross-distro!) automated build service.

> It's a shame to hear that kind of talk coming from the openSUSE world when Zypper did so much to raise the bar for high-level Linux distro package management tools. :(

Yeah, I don't think it'll last in the foreseeable future judging by how these distros are jumping on the Flatpak/Snap bandwagon. For these distros, package management might as well be dead.

I expect a few distros, such as Alpine Linux and Arch Linux, to remain relatively free from the influence of Flatpak and that's what I'll continue to use on my personal machines.

right now NixOS is for a small subset of geeks(who are ok with using custom functional language for pretty much all configuration) but it's entirely possible to make a GUI based like a SUSE configurator based on nix, and with mature enough nix ecosystem it will work flawlessly an be powerful and simple to use for the end user

> it's entirely possible to make a GUI based like a SUSE configurator based on nix

There is such a project already: https://github.com/nix-gui/nix-gui

For the end user it doesn't matter if a GUI is using some nix-thing in the background. It could just was well run dpkg/rpm behind the scenes and as long as the result is the same it really doesn't matter.

This is also why Nix and NixOS painted itself in a corner; the presented value is only relevant if you are hacking away at it. When you have a smooth GUI experience it really no longer matters what the technical goodness underneath is.

I think the point is that Nix makes it a lot easier (in some ways) to build a more reliable system GUI, rather than other package managers because of declarativity being a first-class feature.

Users shouldn’t have to care what their GUI uses underneath, but it could be the difference between building your own pseudo-declarative layer (which you now have to maintain in perpetuity and handle all the small edge cases), or getting something that is already declarative as the backend and simply generating a config file from the GUI (https://github.com/nix-gui/nix-gui).

EDIT: Also composition. Users could, if they wanted to, augment the GUI generated configuration using the built-in Nix features for composition with config files, which is a lot easier than trying to do the same with traditional system managers.

I doubt a user wants or cares about any of that. User story:

As a User I want to select an application to run so that I can use the application.

This applies to practically everything, if you want to play a game, you don't want to dick around with installers, managers, layers, configurations etc. Just point and click, that's all it should need.

My main point was in the first paragraph. Users care about reliability and I was justifying why I think Nix has the potential to be a more reliable base for a GUI than other options.

I also do think certain users will care about e.g. extensibility/composabilty, as soon as they have to do anything outside of the officially blessed path. Having the ability to compose things nicely is pretty useful. It’s the difference between having to recreate the entire GUI configuration manually and just being able to dip into the config for the (likely small) non-standard part of the system.

While I agree with that, operating systems like macOS and Windows have shown that ease of use still beats other features when a user simply wants to 'do' something.

As good (or as bad) as the technical underpinnings can be, as long as the user gets what they want most of the time they are fine with it.

Nix is one big advantage of course and that is that is isn't a commercial endeavour beholden to markets and income. So it doesn't really matter what general users might want or think (at least not at this stage). We also still have the same problem that is always present and that is content availability. If a user wants to install a Netflix client but none is available, it doesn't matter how good the tools are. Even the best UX can't help when the desired content isn't available.