6 ms·

Packages were handled way before 2025 already, so it is strange that you insinuate they'd all only burn out within a year, and before that it was all cake and t

Packages were handled way before 2025 already, so it is strange that you insinuate they'd all only burn out within a year, and before that it was all cake and tea. NixOS is dying, everyone sees this right now. > but we've also functioned without one for ~20 years. Then this is also a PR problem because why need a team when the 20 years before were allegedly so perfect?

deleted 1mo ago
[deleted]
embedding-shape 1mo ago
> NixOS is dying, everyone sees this right now. Huh? Based on what? The packages I use keep getting updated, so clearly nixpkgs is alive. The OS I use keep getting updated, so clearly NixOS is alive to. Who exactly is dying, and what makes you believe that?
- Pay08 1mo ago
  Isn't nixpkgs still a pretty bad state? I know there used to be a lot of "abandoned" packages that went years without updating to the new versions provided by upstream, that a lot of packages were copying binaries around instead of building open source software from the source, etc.
  - toshinoriyagi 1mo ago
    Nixpkgs is one of, if not the largest, package managers by # of packages. I think naturally that will result in more abandoned packages than others. What is the % of abandoned packages relative to total I can't say. Nix tends to have updates almost as quickly as Arch does, I run a lot of bleeding edge software and have no issues, and the breadth of packages is immense. Nix just has a different style. With the AUR, you can adopt an abandoned package more easily. That has pros and cons (the AUR has recently suffered multiple supply-chain attacks due to packages being adopted and infected).
    - Pay08 1mo ago
      > Nixpkgs is one of, if not the largest, package managers by # of packages. I'm fairly certain that the graph you're thinking of is complete bullshit. It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality.
      - abacate 1mo ago
        > It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality Source?
        Pay08 1mo ago
        apt-list on said Ubuntu system.
  - nickdichev 1mo ago
    A common pattern is to manage your own "overlay" repo on top of nixpkgs to keep the packages you care about up to date.
bityard 1mo ago
> NixOS is dying I won't believe that until Netcraft confirms it.
- bombcar 1mo ago
  Ah, good to see a fellow hot grits enjoyer.
black_knight 1mo ago
I know nothing about the organisation of NixOS, but I know that NixOS is in a unique position now that LLMs have arrived. It offers the unique experience where you can fearlessly let the LLM loose on your system config to setup any convenience you want. I am not alone to have made this observation, so I am hopeful that Nix and NixOS will gain even more momentum in the future!
- toastal 1mo ago
  While rollback takes away some fears, “fearless” is a stretch. LLMs are relatively quite bad at Nix choosing tightly-coupled, non-modular, non-scalable patterns with unnecessary dependencies/experimental features, while also choosing to reimplement pkgs.lib functions without good reason. Generating more code, pulling in more deps to get out of the mess isn’t the solution either & is usually what I have been seeing more now.
  - black_knight 1mo ago
    You are most certainly correct about this! And at the same time, I kind of cherish my ignorance on the proper ways of Nix. I have so many aspects of life where I practice perfectionism, and if Nix becomes another one of them, I shall have no spare time! On the other hand, I just checked, and the domain ratemyflake.com is available. I think we should set it up, so that we can rate each other's nixings!
    - toastal 1mo ago
      > tightly-coupled, non-modular, non-scalable pattern, experimental This is a massive part of the problem to be advocating for & adopting flakes. My config is much simpler: nixos-rebuild switch --file host/$HOSTNAME. This doesn’t require a properly evaluating, not-quite-Nix manifest file to just to build a system. If more folks understood the standard package format & overlays, they too would come to the conclusion that pointing to a file is simpler/uncoupled. packages are just derivations, as are apps, as are checks so there’s little value in separating them. Overlays, modules, configurations, these are all better as their own files too—instead of what I see more often which is coupling them to the flake so they can’t be consumed by stable nix. I have seen big corpos get totally boned by transitive dependency resolution exploding the lockfile too as input.follows does not offer the same power as overlays. The straw breaking camels’ backs to me is how restricted the input pinning options are to things being shipped by the C++ binary & the maintenance burden upstream now takes on trying to shove too many things into the binary instead of sticking to a few primitives. You don’t need perfectionism—my config is a mess of some of my most beginner code—but the foundation folks are building on is not good & it ends up leaving very sour tastes in folks’ mouths and/or trying to build abstractions on abstractions to hide the underlying design (things built on ‘dendredic’ patterns, which itself is a questionable patterns, built on flake-parts which is questionable, all to hide limitations of flakes which is the core misstep which is hard to work with causing folks to want to overabstract).

deleted 1mo ago

[deleted]

embedding-shape 1mo ago

> NixOS is dying, everyone sees this right now. Huh? Based on what? The packages I use keep getting updated, so clearly nixpkgs is alive. The OS I use keep getting updated, so clearly NixOS is alive to. Who exactly is dying, and what makes you believe that?

Pay08 1mo ago
Isn't nixpkgs still a pretty bad state? I know there used to be a lot of "abandoned" packages that went years without updating to the new versions provided by upstream, that a lot of packages were copying binaries around instead of building open source software from the source, etc.
- toshinoriyagi 1mo ago
  Nixpkgs is one of, if not the largest, package managers by # of packages. I think naturally that will result in more abandoned packages than others. What is the % of abandoned packages relative to total I can't say. Nix tends to have updates almost as quickly as Arch does, I run a lot of bleeding edge software and have no issues, and the breadth of packages is immense. Nix just has a different style. With the AUR, you can adopt an abandoned package more easily. That has pros and cons (the AUR has recently suffered multiple supply-chain attacks due to packages being adopted and infected).
  - Pay08 1mo ago
    > Nixpkgs is one of, if not the largest, package managers by # of packages. I'm fairly certain that the graph you're thinking of is complete bullshit. It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality.
    - abacate 1mo ago
      > It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality Source?
      - Pay08 1mo ago
        apt-list on said Ubuntu system.
- nickdichev 1mo ago
  A common pattern is to manage your own "overlay" repo on top of nixpkgs to keep the packages you care about up to date.

bityard 1mo ago

> NixOS is dying I won't believe that until Netcraft confirms it.

bombcar 1mo ago
Ah, good to see a fellow hot grits enjoyer.

black_knight 1mo ago

I know nothing about the organisation of NixOS, but I know that NixOS is in a unique position now that LLMs have arrived. It offers the unique experience where you can fearlessly let the LLM loose on your system config to setup any convenience you want. I am not alone to have made this observation, so I am hopeful that Nix and NixOS will gain even more momentum in the future!

toastal 1mo ago
While rollback takes away some fears, “fearless” is a stretch. LLMs are relatively quite bad at Nix choosing tightly-coupled, non-modular, non-scalable patterns with unnecessary dependencies/experimental features, while also choosing to reimplement pkgs.lib functions without good reason. Generating more code, pulling in more deps to get out of the mess isn’t the solution either & is usually what I have been seeing more now.
- black_knight 1mo ago
  You are most certainly correct about this! And at the same time, I kind of cherish my ignorance on the proper ways of Nix. I have so many aspects of life where I practice perfectionism, and if Nix becomes another one of them, I shall have no spare time! On the other hand, I just checked, and the domain ratemyflake.com is available. I think we should set it up, so that we can rate each other's nixings!
  - toastal 1mo ago
    > tightly-coupled, non-modular, non-scalable pattern, experimental This is a massive part of the problem to be advocating for & adopting flakes. My config is much simpler: nixos-rebuild switch --file host/$HOSTNAME. This doesn’t require a properly evaluating, not-quite-Nix manifest file to just to build a system. If more folks understood the standard package format & overlays, they too would come to the conclusion that pointing to a file is simpler/uncoupled. packages are just derivations, as are apps, as are checks so there’s little value in separating them. Overlays, modules, configurations, these are all better as their own files too—instead of what I see more often which is coupling them to the flake so they can’t be consumed by stable nix. I have seen big corpos get totally boned by transitive dependency resolution exploding the lockfile too as input.follows does not offer the same power as overlays. The straw breaking camels’ backs to me is how restricted the input pinning options are to things being shipped by the C++ binary & the maintenance burden upstream now takes on trying to shove too many things into the binary instead of sticking to a few primitives. You don’t need perfectionism—my config is a mess of some of my most beginner code—but the foundation folks are building on is not good & it ends up leaving very sour tastes in folks’ mouths and/or trying to build abstractions on abstractions to hide the underlying design (things built on ‘dendredic’ patterns, which itself is a questionable patterns, built on flake-parts which is questionable, all to hide limitations of flakes which is the core misstep which is hard to work with causing folks to want to overabstract).