In terms of the memory usage, it’s a reasonable approach these days. It gets hairy when we consider security vulnerabilities. It’s far easier to patch one system-wide shared library than to hunt down every single application still bundling a vulnerable version.

Nix is a bit of a middle ground. Each package has a specific set of dependency version. It calculates the hash of each dependency and compares it to those that you have installed. If it is installed, it uses that, if it isn’t, it installs it. This means that packages can have different versions and dependency hell is impossible, whilst also reusing existing dependencies if they’re the exact same.

If you use any accelerated graphics (GTK4 anyone?), you cannot and must not bundle all your dependencies.

Conceptually, graphics drivers have two parts: The part in the kernel (e.g. amdgpu), and the part loaded as a library from the system into the application (e.g. Mesa).

Mesa - or any other GL/Vulkan implementation - is loaded from the system into the application as a library. Mesa relies on system libc, system LLVM (!!!), a particular libc++, etc.

If you ship libGL (and LLVM etc), you must re-release your software with upgraded deps whenever new graphics cards are released (and should whenever bugs are fixed). Your software is literally incompatible with (some) newer computers.

For the proprietary Nvidia libGL - which, again relies on system glibc - you can’t legally include it.

Flatpak solves this by separating out ‘graphics driver libraries’ as a unique type of runtime, and having a shitload of special rules & custom hacks to check the system libGL, open source or proprietary, maybe substitute a Flatpak provided libGL, with all the deps that libGL needs, and make it compatible with whatever app & whatever app runtime.

Actually correctly solving the libGL debacle is half the value of Flatpak to me.

Well the issue for me is internet speed, yesterday night I had to leave my pc on for two hours to update my flatpaks, I don’t even have that many of them, but the updates were mostly drivers and runtimes.

Windows apps have been doing this for ages with disasterous security results due to the lack of mandatory OS sandboxing. E.g. CVE for admin level RCE via Adobe Flash. This model works with third party apps only when sandboxed. This was done from the get go on Android and now with Snap and Flatpak (I assume). It’s absolutely the way to go once the security framework is in place.

I love it when every basic application is an entire operating system under the hood

If you use Nix the imperative way (nix profile blah), you don’t need to learn the Nix language at all, or write config files. Installing/removing/upgrading packages is just a single command, similar to other package managers.

Eg:

• To search for bat on nixpkgs: nix search nixpkgs bat
• To install bat: nix profile install nixpkgs#bat
• To upgrade all packages: nix profile upgrade '.*'

Ref: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-profile

Stop making a list and start with eg: Nix Pills

You can do rollbacks if you’re using something like home-manager on a foreign distribution. It’s just a bit more janky admittedly.

If you maintain upstream software and do not have an interest in learning and using Nix, please don’t put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that’s not how distros are supposed to work.

Leave it to someone who is interested to package your software in Nixpkgs. Your “job” is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).

If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn’t true, so cross-pollination can be super helpful here.
Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer’s approval stating that it works as they expect, I’d merge immediately.)

If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
As a Nixpkgs committer, I’d much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.

Dont know where you are getting this. Nixpkgs is a breeze to manage compared to apt repo. Also it does not matter if you are on nixos or non-nixos system, the only difference is that nix does not take care of services on its own. What kind of docs do you miss? Nix has its own extensive nix docs page, and for packaging you also have nixpkgs documentation page - also official and not much related to nixos itself. Also nix has quite good man pages.

it’s the way Nix works too

Of the future? They’re a duplicate of what Apple was doing with software as far back as the mid 90s.

Every ounce of performance we squeeze out of our hardware is replaced with pounds of bloat like this.

It’s fine for a utility or something you’ll hardly ever need to use, but running every day software like this is a complete waste.

I can reassure you that it does not encroach on anything the “host” distro package manager does and does not cause conflicts with it.

At runtime, it only ever touches things in `/nix; it’s self-contained.

The only time Nix needs to interact with the host distro in any way is during install where it must place a little glue in your system configuration for things like PATH, bash completions or the nix-daemon to work as expected.

deleted by creator

Nixpkgs can be used without knowing anything about nix. You can install almost anything by just running e.g.:

nix-shell -p cowsay

The requirement for that is the nix package manager but that should be easy to install. But yeah getting into Nixos with flakes and all that stuff can be hard.

Why don’t you just install nix on debian and see

Flatpak still depends on runtimes though, I have a few different runtimes I had to install just because of one or two flatpaks that required them (like for example I have both the gnome and kde flatpak runtimes, despite not running either of those desktop environments)… and they can depend on specific versions of runtimes too! I remember one time flatpak recommended me to uninstall one flatpak program I had because it depended on a deprecated runtime that was no longer supported.

Also, some flatpaks can depend on another flatpak, like how for Godot they are preparing a “parent” flatpak (I don’t remember the terminology) that godot games can depend on in order to reduce redundancies when having multiple godot games installed.

Because of those things, you are still likely to require a flatpak remote configured and an internet connection when you install a flatpak. It’s not really a fully self contained thing.

Appimages are more self contained… but even those might make assumptions on what libraries the system might have, which makes them not as universal as they might seem. That or the file needs to be really big, unnecessarily so. Usually, a combination or compromise between both problems, at the discretion of the dev doing the packaging.

The advantage with Nix is that it’s more efficient with the users space (because it makes sure you don’t get the exact same version of a library installed twice), while making it impossible to have a dependency conflict regardless of how old or new is what you wanna install (which is something the package manager from your typical distro can’t do).

For nixpkgs, whike I’m sure I can get a package from the sounds of the sizes the package covers only the application or the library, meaning I still need the dependencies.

When you download/build a nix package, nix will absolutely also download all necessary dependencies.

So what exactly would make me the user trade my built in tools (apt/pacman/dnf) for nix?

Getting a shell with a specific package as a one off. Want ffmpeg? nix-shell -p ffmpeg opens a shell with ffmpeg in its path, and only that shell has it.

Along with that, that means users can install packages for themselves. Limited use for single-user systems, but nonetheless it’s possible.

Per-project dependencies. Pretty much the same as above, but the dependencies are declared in a file which is part of the project. In many cases that same file can also be used as a nix package itself, like any other in nixpkgs. Very useful if you write software yourself. Here’s an example.

Being a source-based package manager with a cache means that you get all the benefits of prebuilt packages but can easily patch or use other versions of a package, with no difference in use (other than that it will build it locally instead of downloading from the cache).

On a distro with a different main package manager I would probably mainly use it for per-project dependencies though.

Inate complexity that keeps moving as they introduce things like flakes.

Flakes solve the problem of reproducibility for which nixpkgs (or other external input) revision to use (e.g. in a software project). The main thing they bring is a npm-like lock file and a predictable interface. You don’t have to use them if you don’t want that.

Its a declarative configuration management system as package manager.

No it isn’t. That’s NixOS, which is another thing built on top of Nix and nixpkgs. nixpkgs is first and foremost a package collection.

It is a whole ecosystem:

• Nix the package manager
• Nix the functional language used to declare packages and configurations
• NixOS that has the package manager and a system configuration in the functional language
• Home Manager, which provides a configuration on the user level and can be used on NixOS as well as other distros and MacOS

To start out it’s completely fine to just install Nix the package manager on a regular distro or on MacOS and use the nix-env command to install some packages. It will automatically use nixpkgs and use working dependencies for each package, whilst also checking if the depency is already installed to avoid installing the same one twice. This is pretty much the same thing as using Flatpak

Flakes explanation:

The Nix package manager has channels to manage package repos. It works like package managers on other distros where you simply have a list of urls to pull packages from, with Nix it would just be the nixpkgs release either a version number for stable or unstable for the unstable rolling release. Any time you install through the package manager or the config in NixOS, it will get the packages from the channel.

The problem is that the channels aren’t very reproducible. The repos get updates regularly, especially unstable which updates even faster than Arch. Channels don’t provide an easy way to specify a single commit of the repo, except for entering a url with the commit version in it. For stuff like a shell.nix, you’d need to either import nixpkgs from the system’s channel or import the url of nixpkgs with a specific commit ID.

Flakes is a feature that for some reason is still experimental after years, but many are already using it. It works like manifest.json and package.lock in a JavaScript project. You have a directory or git repo with a flake.nix file in which you specify your external dependencies like the nixpkgs release in the “inputs” section and your outputs in the “outputs” section, like a NixOS/Home Manager configuration, a shell or a package. Then when you use an output, Nix pulls the inputs and builds the output, it then generates a flake.lock file that contains all the inputs with their specific commit and hash. Now if you use an output again later with the same flake.lock, it will still use the exact same version as last time and should generate the exact same outputs. You just run nix flake update to generate a new flake.lock with new dependencies. You can’t use flakes with nix-env simply because installing packages imperatively without a config file defeats the point of reproducibility with flakes.

Flake example with Home Manager:

My Flake Repo/
├── flake.nix - nixpkgs input and home manager configuration output
├── flake.lock - generated by nix
└── home.nix - home manager config import from flake.nix

Here the home.nix file contains the config with the list of packages to install as well as configuration options for those programs. The flake.nix contains the nixpkgs input and a homeManagerConfigurations output that import the home.nix. You can run home manager switch --flake ./My Flake Repo to use that config from the flake. To update run nix flake update.