Yes they need to be ported, in the optimal case it's just specifing the build dependencies and the build command.

It's deprecation addressed so you only store any given dependency & version once, but if you need multiple versions you store each.

It's easy for the storage size to balloon, but also easy to garage collect away stuff you aren't using without worrying about it

You update the library and every thing it depends on

You need to restart the gui application after the upgrade

The download size can be big, I haven't found it much more inconvenient than other distros

Start up time is unremarkable

Nix also defaults new build commands to the equivalent of `./configure && make && make install` so it works out of the box with a lot of packages, as long as you declare the build inputs that it may need.

As for disk size, beyond garbage collection, you can also ask Nix to sweep its store and hardlink identical files together in order to save space if you suspect significant file duplication (and if your FS doesn't already deduplicate blocks).

Note: these points concern Nix, the situation may be different on Guix

> * Do packages need to be 'ported' to Nix or its build / install system? If so, how much effort will it take and on what factors the effort required to port may vary substantially? (eg: Programming Language).

Yes. To make Nix really work it has to be pervasive and this sometimes means porting packages again, however there's a lot of automation around this, see[0] for ones that leverage existing build systems in other languages. Autoconf and cmake packages are already accounted for by the default builder, and usually only the dependencies have to be specified.

> * How is disk space usage? Is there any kind of deduplication?

The Nix store can be intensive on memory, as once a dependency such as glibc is updated, all the reverse dependencies (i.e. the set X such that X depends on glibc directly or transitively) have to be rebuilt as well. There is an option to optimise the store, but I don't know how much it helps in practice, see[1]. Garbage collection can be invoked manually or automatically to free up unused store entries.

> * Other performance characteristics - bandwidth (delta upgrades possible?), startup time (I hope this will be good)..

By startup time you might be referring to NixOS. It's very good on my Late 2013 13-inch MacBook Pro, around 20 seconds to go from cold boot to login screen.

[0] https://github.com/svanderburg/node2nix https://github.com/NixOS/cabal2nix https://github.com/cargo2nix/cargo2nix https://github.com/nix-community/poetry2nix https://github.com/kamilchm/go2nix https://github.com/nix-community/pip2nix

[1] https://nixos.wiki/wiki/Storage_optimization

> By startup time you might be referring to NixOS

I was referring to application startup which is an issue for snap & flatpak. I'd like to know how it (Nix + sandboxing solution like bubblewrap) compares to flatpak.

Nix doesn’t sandbox applications, it is basically only patches the ELF header so that it links to nix store entries instead of /usr/lib when it comes to shared libs.

So While I don’t have benchmarks, it is basically in the same ballpark as Arch programs.