News for hackers. Stuff that matters.
Re:GNU Guix 1.2.0 by viraptor on Monday November 23, 2020 @04:38PM (#25192246)
One thing that flatpak has over nix is the set of common bases. If I was going to distribute something shifted from nix, I'd essentially need to move every single dependency (which needs to be compiled/configured right). It's not a huge problem for a cli tool in golang, but something that requires qt, GL, input method support, etc.? I'm glad there's a flatpak base for those that not only "just works", and it's going to be maintained/distributed even of the app isn't.
Re:GNU Guix 1.2.0 by mbakke on Monday November 23, 2020 @05:13PM (#25192564)
I'm not sure I understand this argument. The main difference when compiling is that you use --prefix=$output instead of --prefix=/usr (which is nicely abstracted away by build systems).

You can 'guix pack -RR ibus qutebrowser', copy the resulting binaries to any GNU/Linux system, and still expect them to work.

Re:GNU Guix 1.2.0 by viraptor on Monday November 23, 2020 @05:37PM (#25192788)
Yes you can, but you have to compile and distribute them all. And again distribute every single update for them. You end up with "nothing changed in my app, but there's the whole package again with a fixed deep dependency of foo". (Or more likely, no update)
Re:GNU Guix 1.2.0 by mbakke on Monday November 23, 2020 @06:05PM (#25192990)
Right. Referring to exact versions of dependencies is a feature of the functional package management model. How else can you guarantee that the program will behave exactly the same every time you run it?

Guix (unlike Nix) supports "grafts", so you can change something deep in the graph without having to compile every dependent package again. But grafts also produce different store items of course, so no big difference for "guix pack".

Re:GNU Guix 1.2.0 by viraptor on Monday November 23, 2020 @10:26PM (#25194965)
And it depends on your use case - whether you want to guarantee exactly the same behaviour and ship all the dependency updates yourself; or do you want to have less maintenance burden and trust the base layer to not change behaviour.

In a tightly controlled environment inside a company where the update mechanisms are preconfigured / enforced, I'd go with nix model. When distributing an app to people on the internet, I'd choose flatpak model.

Re:GNU Guix 1.2.0 by kaba0 on Tuesday November 24, 2020 @04:02AM (#25196628)
But you simply don’t have to worry about it. You test it on the next LTS release of nixpkgs and that’s it. Your user may download a bit more data, but I found that nix is lightyears faster then fedora’s build tool, and on par with arch, while not polluting the whole filesystem with random files. I don’t see where would you need more maintainance.
Re:GNU Guix 1.2.0 by georgyo on Monday November 23, 2020 @07:03PM (#25193529)
Re:GNU Guix 1.2.0 by mbakke on Monday November 23, 2020 @07:32PM (#25193760)
Oh, cool. I don't see it being used anywhere though, apart from being available as a system activation function?

In Guix grafts are used rather extensively, mainly for security updates, but also command-line transformations such as "--with-debug-info".

Re:GNU Guix 1.2.0 by civodul on Tuesday November 24, 2020 @03:01AM (#25196299)
It wouldn't be a nice interface for packagers to use.

More importantly, it's not enough to implement grafts because it's not recursive, as discussed at https://guix.gnu.org/en/blog/2016/timely-delivery-of-securit... .

Re:GNU Guix 1.2.0 by soraminazuki on Monday November 23, 2020 @08:09PM (#25194048)
Nixpkgs already packages all of the things you've mentioned (qt, GL, input method support). So to package your own software with Nix, all you have to do is specify them as dependencies. There's no need to "move every single dependency" at all.
Re:GNU Guix 1.2.0 by viraptor on Monday November 23, 2020 @10:23PM (#25194944)
"packages all of the things" == "move every single dependency". We're talking about the same thing.