4 ms·

>"I don't want to care" Update once per year. > brew, distrobox, flatpak You can have that stuff on Nix if you need it. Nix is bad because the language is v

>"I don't want to care" Update once per year. > brew, distrobox, flatpak You can have that stuff on Nix if you need it. Nix is bad because the language is very limited and extremely hard to debug and the module system is fragile and obscure (just try to write a recursion-safe mkMerge and prove it won't magically drop some parts of your config because the values in the module system are always magic attrsets, not values), but, unfortunately, there is nothing better around.

SOLAR_FIELDS 1y ago
Even updating once per year is still a battle. It avoids the constant breakages from using unstable, but the problem is even the mainline “stable” nixpkgs will break because there really isn’t a good integration story for all of these components. Case in point: I just spent an hour this week pointlessly updating my home manager config because home manager just decided that a breaking api change would go in. The nix people have designed the ecosystem in such a way that everyone’s bespoke configuration can break at any given point and there is not an easy way to integration test even every common scenario. In other words, the old adage still rings true. The beauty of Nix is that you can do anything. The ugliness of nix is that you can do anything
- inahga 1y ago
  What's been driving me batshit is when nixos-rebuild decides it wants to build from source. I just burned an hour the other day trying to update, and getting stuck because Nix decided my little old laptop needed to compile node.js from source. Had to trial-and-error remove packages to figure out which one was transitively pulling in node.js. It turned out to be ansible... which is a pure python tool. Beats me. There's also some cases where it wants to build Android Studio from source. I've just removed it and now run it in a VM. I'm sure I'm doing it wrong, and I'm sure nixos-rebuild has a reason to build things from source, and maybe I'm not RTFMing hard enough. But good god, I just need my system to update.
  - SOLAR_FIELDS 1y ago
    Less than a week ago I complained about nearly the exact same issue and received the typical “nixy” response “that’s what the cache is for”. Well, that’s excellent news, when the cache actually works as expected. I see this a lot with my flake.nix per repo configurations too. The flake.nix never changes, yet it inexplicably rebuilds packages sometimes
    - sshine 1y ago
      I've been wondering about that too. I guess our system's nixpkgs moves forward while the nixpkgs in our project flake.nix stays the same. So eventually the nixpkgs of the project is garbage collected, because it isn't pinned by the system, and it needs to redownload and rebuild? I don't know. I try to `nix flake update` my system configuration every 2-3 months. Arguably, running Arch and not updating frequently is a pain, too.
      - pshirshov 1y ago
        > eventually the nixpkgs of the project is garbage collected You should manually create a garbage collection root (that pesky 'result' symlink, --out-link)
        sshine 1y ago
        Are you saying that the presence of a result/ symlink means the sources are kept, and if I remove the result/ symlink, it gets gc’ed?
        pshirshov 1y ago
        Yes, gc root links are accounted at the moment they are written by nix and they retain the graph while they are continue to exist.
  - pshirshov 1y ago
    > Had to trial-and-error remove packages There are introspection tools for that. > Build from source That's not an issue unless you stay on master or use config flags (there is just a handful of them, but they are imortant, eg cudaSupport=true can easily give you 5-6 hours of build time, rocmSupport can easily give you a couple of days)
- pshirshov 1y ago
  > a battle Everything is a battle and nix battle is bit less hopeless than the imperative distro battle, but again, nix is bad but noone wants to build a better thingy. I've seen countless attempts and I'm trying to make my own build system (not targeting linux distros though). The problem is extremely hard. Essentially you have to build a general purpose PL which is better (more introspectable/debuggable/extensible) than other GPPLs.
ayrtondesozzla 1y ago
If you've spent time with Nix, I assume you heard about Guix at some stage. And if you've heard about Guix and still make the above comment, I assume you have some reason(s) to think the Scheme programming language doesn't solve some/all those problems you mention. Nonetheless, in case those assumptions are off - GNU Guix exists, and is written in and extended in (Guile) Scheme. Guile is general purpose, has the excellent Andy Wingo powering a lot of improvements to the language the last years, and some people are very fond of it. Perhaps you'd be interested in investigating, if Nix's DSL wasn't to your liking.
- pshirshov 1y ago
  > the Scheme programming language doesn't solve some/all those problems you mention Yes, the Scheme programming language doesn't solve any those problems I mention. > improvements to the language Despite of the language, if we speak about Linux distros, I need all those pesky blobs to get my desktop running. And, by the way, is there anything alike to flakes, so I can have an actually reproducible build, not a mess of channels?
  - ayrtondesozzla 1y ago
    If misquoting someone intentionally seems like normal behaviour to you, I'll leave the discussion there, thanks
    - pshirshov 1y ago
      Such a waste of a throwaway account. I can explain what's wrong with Guix and Scheme in detail but who cares.
      - ayrtondesozzla 1y ago
        First you misquote me in an oddly obvious and low-effort way, now another inane comment - how can the nature of this account have any relevance? You wrote a comment implying what's wrong with Nix is the language, and stating that there's unfortunately "nothing better" out there. It is true in this universe that there is a software project called GNU Guix, which is 13 years old, whose literal origin idea is - what if we take the general idea behind Nix, but write it all afresh in a fully featured programming language, and make it extensible and configurable with that language. There are a host of reasons you might not want to get into that personally, as I stated - but it really does exist, regardless of your personal feelings?
yjftsjthsd-h 1y ago
>> brew, distrobox, flatpak > You can have that stuff on Nix if you need it. In fact, I'd openly recommend such a solution: NixOS base, most applications via flatpak, and dev work in distrobox. Gives you 80% of the benefits for 20% of the work. (Although I will also happily agree that Fedora's Silverblue or OpenSUSE MicroOS as the base is also pretty good; I think that's just a trade if you need to actually tweak the base layer)

SOLAR_FIELDS 1y ago

Even updating once per year is still a battle. It avoids the constant breakages from using unstable, but the problem is even the mainline “stable” nixpkgs will break because there really isn’t a good integration story for all of these components. Case in point: I just spent an hour this week pointlessly updating my home manager config because home manager just decided that a breaking api change would go in. The nix people have designed the ecosystem in such a way that everyone’s bespoke configuration can break at any given point and there is not an easy way to integration test even every common scenario. In other words, the old adage still rings true. The beauty of Nix is that you can do anything. The ugliness of nix is that you can do anything

inahga 1y ago
What's been driving me batshit is when nixos-rebuild decides it wants to build from source. I just burned an hour the other day trying to update, and getting stuck because Nix decided my little old laptop needed to compile node.js from source. Had to trial-and-error remove packages to figure out which one was transitively pulling in node.js. It turned out to be ansible... which is a pure python tool. Beats me. There's also some cases where it wants to build Android Studio from source. I've just removed it and now run it in a VM. I'm sure I'm doing it wrong, and I'm sure nixos-rebuild has a reason to build things from source, and maybe I'm not RTFMing hard enough. But good god, I just need my system to update.
- SOLAR_FIELDS 1y ago
  Less than a week ago I complained about nearly the exact same issue and received the typical “nixy” response “that’s what the cache is for”. Well, that’s excellent news, when the cache actually works as expected. I see this a lot with my flake.nix per repo configurations too. The flake.nix never changes, yet it inexplicably rebuilds packages sometimes
  - sshine 1y ago
    I've been wondering about that too. I guess our system's nixpkgs moves forward while the nixpkgs in our project flake.nix stays the same. So eventually the nixpkgs of the project is garbage collected, because it isn't pinned by the system, and it needs to redownload and rebuild? I don't know. I try to `nix flake update` my system configuration every 2-3 months. Arguably, running Arch and not updating frequently is a pain, too.
    - pshirshov 1y ago
      > eventually the nixpkgs of the project is garbage collected You should manually create a garbage collection root (that pesky 'result' symlink, --out-link)
      - sshine 1y ago
        Are you saying that the presence of a result/ symlink means the sources are kept, and if I remove the result/ symlink, it gets gc’ed?
        pshirshov 1y ago
        Yes, gc root links are accounted at the moment they are written by nix and they retain the graph while they are continue to exist.
- pshirshov 1y ago
  > Had to trial-and-error remove packages There are introspection tools for that. > Build from source That's not an issue unless you stay on master or use config flags (there is just a handful of them, but they are imortant, eg cudaSupport=true can easily give you 5-6 hours of build time, rocmSupport can easily give you a couple of days)
pshirshov 1y ago
> a battle Everything is a battle and nix battle is bit less hopeless than the imperative distro battle, but again, nix is bad but noone wants to build a better thingy. I've seen countless attempts and I'm trying to make my own build system (not targeting linux distros though). The problem is extremely hard. Essentially you have to build a general purpose PL which is better (more introspectable/debuggable/extensible) than other GPPLs.

ayrtondesozzla 1y ago

If you've spent time with Nix, I assume you heard about Guix at some stage. And if you've heard about Guix and still make the above comment, I assume you have some reason(s) to think the Scheme programming language doesn't solve some/all those problems you mention. Nonetheless, in case those assumptions are off - GNU Guix exists, and is written in and extended in (Guile) Scheme. Guile is general purpose, has the excellent Andy Wingo powering a lot of improvements to the language the last years, and some people are very fond of it. Perhaps you'd be interested in investigating, if Nix's DSL wasn't to your liking.

pshirshov 1y ago
> the Scheme programming language doesn't solve some/all those problems you mention Yes, the Scheme programming language doesn't solve any those problems I mention. > improvements to the language Despite of the language, if we speak about Linux distros, I need all those pesky blobs to get my desktop running. And, by the way, is there anything alike to flakes, so I can have an actually reproducible build, not a mess of channels?
- ayrtondesozzla 1y ago
  If misquoting someone intentionally seems like normal behaviour to you, I'll leave the discussion there, thanks
  - pshirshov 1y ago
    Such a waste of a throwaway account. I can explain what's wrong with Guix and Scheme in detail but who cares.
    - ayrtondesozzla 1y ago
      First you misquote me in an oddly obvious and low-effort way, now another inane comment - how can the nature of this account have any relevance? You wrote a comment implying what's wrong with Nix is the language, and stating that there's unfortunately "nothing better" out there. It is true in this universe that there is a software project called GNU Guix, which is 13 years old, whose literal origin idea is - what if we take the general idea behind Nix, but write it all afresh in a fully featured programming language, and make it extensible and configurable with that language. There are a host of reasons you might not want to get into that personally, as I stated - but it really does exist, regardless of your personal feelings?

yjftsjthsd-h 1y ago

>> brew, distrobox, flatpak > You can have that stuff on Nix if you need it. In fact, I'd openly recommend such a solution: NixOS base, most applications via flatpak, and dev work in distrobox. Gives you 80% of the benefits for 20% of the work. (Although I will also happily agree that Fedora's Silverblue or OpenSUSE MicroOS as the base is also pretty good; I think that's just a trade if you need to actually tweak the base layer)