Those packages themselves depend on xz. Pretty much all of them.

What you’re suggesting would only make the xz executable not be backdoored anymore but any other application using liblzma would still be as vulnerable as before. That’s actually the only currently known attack vector; inject malicious code into SSHD via liblzma.

That works for leaf packages but not for core node packages. Every package depends on xz in some way; it’s in the stdenv aswell as bootstrap.

That’s a nice idea in theory but not possible in practice as the last Nixpkgs revision without a tainted version of xz is many months old. You’d trade one CVE for dozens of others.

That’s not what flakes are important for at all.

Though unless you already know what flakes could do for you, I agree, you don’t need to even think about flakes. They only concern one specific aspect of Nix and aren’t even the only solution to that problem.

Hmm, that shouldn’t be the case could you open an issue on that?

Does firefox appear in your previous closure? nix-store --query --tree /run/current-system/ | grep firefox

I don’t have a link handy but I’ve seen it done before.

It really depends on what it is you’re trying to share between machines.

I don’t use syncthing but something that fulfils a similar function (git-annex). My Documents repo is set up in such a way that all instances of the repo try to have a copy of everything because documents are very important data and don’t take much space. Other (larger) repos only try to have two or three independant copies; depending on how large and important their data is.

I would not “share” it synchronously as @gratux@lemmy.blahaj.zone recommended because in that case the data is only stored on one device and almost always accessed remotely. If the internet connection is gone, you’d no longer have access to the data and if the VPS dies, your data would be gone on all other machines too.

If you want to use Nextcloud anyways, that would be an option.

If all you want to do is have a shared synchronised state between multiple machines though, Syncthing would be a much lighter weight purpose-built alternative.

Note that it’ll still be a while until Nixpkgs will be bulk-formatted; this RFC “only” decides on the style and how to proceed.

Nix’ stack size is quite limited for a functional language. You cannot have infinite lists either. IIRC it does not do any tail call optimisation; it’s a simple recursive evaluation.

Note that Nix is not a general purpose programming language that is designed to solve general purpose problems such as this one.

You have three options:

1. Take a close look at the stack trace, it should contain the dependant’s definition file somewhere. They’re hard to read, it’s a known issue that isn’t easy to fix.
2. Roll back your Nixpkgs and figure out which package’s runtime closure depends on the package that is broken in the newer Nixpkgs using why-depends
3. Trace through the source code yourself (i.e. grep for the broken dep’s name in your explicitly declared deps)

Excellently written, thank you @samwho@hachyderm.io!

furry anime girl

Welcome to the Nix community I guess :D

Not physical unfortunately but I know of https://leanpub.com/nixos-in-production by @GabriellaG439@tech.lgbt.

Zen/liquorix kernels are packaged.

I use xanmod to get some more experimental things earlier but I don’t think it does all that much.

FYI: nixos-rebuild test.

Uncomment that and nixos-rebuild build. Does it still happen?

Are you using home-manager in your NixOS config?