The ability to quickly try out and verify ideas is valuable. This would have taken immensely more time to get to a stage to reasonable verify or dismiss as an idea otherwise. This saves time for builders.

The author cares; this is not a post-a-quick-project-as-slop-to-get-cred situation.

The Nixpkgs Core team was established in Sept 2025 (https://discourse.nixos.org/t/establishing-the-nixpkgs-core-...), so it is a fairly new concept and idea. They've accomplished some good things as highlighted in the post, but are now stepping down. Yes, we'd prefer for the team to exist, but we've also functioned without one for ~20 years. It may take multiple iterations to bootstrap the concept and to figure out the right structure - or we may find it isn't needed. So no, this is not a critical emergency. It's a return to the status quo of late last year.

That being said, I think it is still a concept worth pursuing.

I agree with the concept but the name is terrible. "Core team" gives one the impression that this is the most important team to the project. It's not! It could be called the "governance facilitator" team or admins or something.

Please name the next iteration something less spicy.

exactly what rust devs realized. they went from "core team" to "leadership council" in the next iteratiion

I don't mean to be dismissive of the work done by the team which just resigned, and hope they get back on their feet.

But also out of those 6y the core team did not exist for ~5y, apparently. How is it a highly ignorant reaction?

The amount of monthly contributions has doubled in the last four years alone, from ~7k to ~14k commits per month. Why did I take six years as a reference? Because 2020 is the year nixpkgs really started to pick up traction, and the growth has been almost linear ever since.

Your argument only holds if I were to say "it grew to its current amount of monthly contributions in 2020 and then stayed constant, without growing any further."

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!

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.

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!

> 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).

Where is --file argument documented? I checked the man page, that doesn't exist.

The manpage for `nix build` & `nix shell` goes to `nix-build` & `nix-shell` the stable, non-experimental command which do not need a file as an arg since they are more developer-friendly. The `nix-command` experimental stuff is documented somewhere else—maybe https://nix.dev/manual/nix/2.35/command-ref/new-cli/nix.html... is good enough for the concept. `man nixos-rebuild`, `man nix profile` have `--file, -F` documented.

> 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?

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.

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).

> 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.

> It only had approximately a third of the package count listed for a particular Ubuntu version than said version had in actuality

Source?

apt-list on said Ubuntu system.

A common pattern is to manage your own "overlay" repo on top of nixpkgs to keep the packages you care about up to date.

> NixOS is dying

I won't believe that until Netcraft confirms it.

Ah, good to see a fellow hot grits enjoyer.

Perhaps give boats some advantage in capacity.

Presumably this would support a big improvement to both SBOM generation as well as various UX features and workflow improvements.

Trading perfect reproducibility for usability: a pragmatic look at Flox's new features

This is exactly how I can rapidly prototype things. Once proficient with this tooling is becomes very easy to quickly spin up services and PoCs. Managing it and iterating is also a breeze.

Random thought. Another commenter worried about the runtime of the program becoming mangled and performing destructive operations on your machine. What if you run the reducer as a source-to-source Nix derivation? Protects against dangerous things, and can be easily distributed to remote builders.

Oh, that’s a neat idea. To reply to the sibling comment: Nix runs commands under a sandbox. It’s not bullet proof, but useful enough that it will prevent obvious commands like deleting local files and accessing the network.

It took some time to get RustPython to run, but it seems to work fine: https://gist.github.com/judofyr/82d2255c92ebb0c6b3a6882ac9fd...

Also, after running it for 5 minutes it was now able of reducing it to a much smaller case:

    class a:
        def b() : c
        def h(d) :
            while d:
                    break
            else:
                return 
            d.b()
    def j(e) :
        f = a()
        if f.h  () :
                g
    i = ""
    j(i)

You generally shouldn’t use absolute paths in your programs. That makes it dangerous for local development, and makes running two copies of the program to compare behaviors difficult.

There’s a Venn diagram of people who don’t care enough to do that (works for me!) and people who would never think to use c-reduce. It’s not a perfect circle, but it’ll be fairly close.

> You generally shouldn’t use absolute paths in your programs.

This is true, but I was enjoying the irony that there is an old sys-sdmin adage that you should only use absolute paths in your program(usually a shell script, in this environment) this is to make sure it is running exactly what you expect it to run.

So always put "/usr/bin/awk" instead of just "awk"

I had a co-worker once who took this as gospel. His scripts were always... interesting... to port to a new environment.

How does this protect against dangerous things?

My understanding is that this would just cause the dangerous things to be repeatable.

It must be that by running any program within the nix build sandbox you don't expose your files unless you discover a privilege escalation attack by chance during the reduction process.

Agreed. Packaging is different than deployment. Devs should return to the art of packaging, such that their software can be then deployed into containers, VMs, micro VMs, whatever. That is what packaging allows, re-use.

This is the sort of behavior Nix encourages (disclaimer: I work at https://flox.dev , using Nix as our baseline tech). Docker as both a packaging and deployment format can carry a bit of weight, but can quickly get out of hand.

This is excellent. Have you considered making a presentation or a write-up of the experience?

Thanks for the input. A couple of folks suggested that recently as well. Once I can clear up some bandwidth, I do intend to follow through on that. It gave me a huge appreciation for Nix as a build system, and I would love to share that if it were helpful to others.

A similar article for bringing Ruby into the Nix ecosystem: https://flox.dev/blog/flox-and-ruby