I'm not even a real Nix old-timer, but I've been using NixOS on the job for roles in IT operations and software development for more than 10 years now.

And for a few years before that, I used Nix on a personal basis as a college student.

I'm aware of the rapid growth in user interest, of course; I was there for it!

NixOS is more than 20 years old, and virtually all of the things that make it compelling were already present a decade ago. If it's not for you, you'll know after you give it a try. But for those for whom it clicks, it's desirable because it just provides a more enjoyable computing experience. It's not more complicated than that.

> Secondly, "AI ... can .... safely modify my infrastructure", OP is either being a troll or haven't seem how the whole IT world is upside down because of those very same statements.

I do lots of Terraform work and some Nix work with LLM agents at my job. Is it worth it to rewrite a huge amount of whatever infrastructure-as-code your LLM agent generates? Hell yes; they generate way too much code and they make lots of mistakes. Are LLM agents still useful for experimentation via infrastructure-as-code? Also yes.

> Thirdly, "my entire infrastructure is defined in text files", you clearly never heard of Ansible.

I've used Ansible and Puppet at previous jobs. They don't manage state in a comparable way to NixOS. It just ain't the vibe. Domen Kozar wrote a decent blog post about the technical differences a decade ago: https://www.domenkozar.com/2014/03/11/why-puppet-chef-ansibl...

But the real reason is that those technical differences add up to a more pleasant experience for NixOS.

In my earlier days as a NixOS user, I used to get really excited with its design and how cool it is, and the neat technical properties that fall out of that (atomic upgrades! rollbacks! (and no filesystem snapshotting needed!)). I still think those things are awesome. But at the risk of feeding into your impression that "NixOS is hype", I've learned since then that the better pitch is about the subjectivity of using it: it feels good to use because experimentation is extremely cheap, reversible, transparent, and... fun. If you know, you know.

But I've started reading programming books again recently, on my e-reader and on my laptop. People are still writing them, and they're still good. We should all go buy some!

For my own usage, I don't see chatbots as supplanting textbooks. If anything, they pair well; reading a book from cover to cover gives me the breadth and depth I want, but LLMs are there for tangents and questions that come up along the way. I was reading a book and chatting with Claude like tihs just yesterday, for a few hours.

I like devenv a lot and use it on my team at work and for personal projects. Nobody on my team is that "into Nix" other than me, but they don't have much trouble setting up new projects with it. LLM agents are pretty good at working with it as well.

Nixpkgs has. :)

Nowadays the only search like this I need to run is

  nix-locate -r 'bin/foo$'

My team has a handful of Python projects. Here's how they work:

devenv.nix provides a Python runtime and all native dependencies, git hooks for linters and things like this. It integrates with direnv and the Python package manager (currently Poetry 1.x for older projects and uv for newer ones) so that when you cd in you get a virtualenv with everything you need, scripts in the project (or stubs for them) magically appear on your PATH so you don't need to use `uv run` or whatever it is for anything.

flake.nix provides a publishable artifact for projects that we run on workstations or servers. It autogenerates a Nix package from pyproject.toml and friends. You can reproducibly build it across platforms without virtualization, you can push it up to a binary cache and avoid source builds, whatever. It's great.

For projects that we run in cloud-native containers (for us AWS Fargate and AWS Lambda), we don't currently ship our own container images. We just publish zip files that we generate with a Poetry plugin that runs builds inside containers that have the same images as are used by AWS in its default runtime environments and push them up with the AWS CLI. The exact steps are stored as a Devenv script so the CI can be a one liner and you can run everything locally just like you would in CI.

> the python community did nothing

Python sucks.

But you can still represent your Python project as a proper Python package and get reproducible-ish build artifacts that are local-first and embrace Python-native tooling and ship it up to prod in a portable format with or without Docker. It only takes one engineer spending a day or two to work it out once for the whole team or maybe the whole company. You just need someone to be willing to RTFM on a package manager or two. The Python community seems to be largely lacking such people but your team doesn't have to be.

Be careful what you wish for.

Maybe a Python culture problem; maybe a hallmark of Python's status as an "easy to hire for", manager-friendly, least common denominator blub language; maybe a risk that stems from the conveniences of interpreter languages... but this is such a shame in this day and age.

It's seriously not difficult to do better. And if this is what you're doing, you're also missing out on reproducible environments both in dev and in prod. At least autogenerate a Nix package! You still don't need to publish any artifacts, but you can at least have the thing build in a sandbox or yeet the whole closure over SSH.

It's also not that hard to get a Docker image out of a Python project.

You only need one platform-minded person on the whole development team to make this happen.

What is going on???

And the truth is, too, that it's super easy for an LLM agent to run a build and tests. Good faith contributors using LLMs will never open PRs that don't build not because they're willing to "go the extra mile" and do manual work, but because they give the slightest fuck and have any respect or consideration for the humans they're working with.

LLM spam presents a different problem than any of that stuff was meant to solve. It's a malicious act, and you're right that tooling that burns the defender's compute can't be a solution. :-\

Git supports pre-receive hooks. But big multitenant forges like GitHub.com don't allow you to configure them because they're difficult to secure well. (Some of their commercial features are likely based on them, though.)

If you self-host a forge, though, you can configure arbitrary pre-receive hooks for it in order to do things like prevent pushes from succeeding if they contain verifiably working secrets, for example. You could extend that to do whatever you want (at your own risk).

It's the same with phones. I know blind people who have been harassed for holding their phones up to things as though they are taking pictures, but in fact they're using the camera on their phone to render signage legible to them, or having their phone (or a person on the other end) read it.

Banning this in a way that doesn't in practice cause problems for visually impaired people would be difficult. It might also be difficult to do in a way that doesn't harm, for instance, accountability for cops who are acting in public.

The impulse to "ban" is sometimes a bit naive imo.

It's something that Microsoft leadership themselves certainly seems to have believed at times. From "developers, developers, developers, developers!" to courting Linux-targeting webdevs with WSL to VSCode, they've done lots to court developers, sometimes explicitly professing it as a central part of their strategy.

I can't disagree with any of the rest, though. Microsoft's (anti-)competitive strategy has never been about excellence so much as positioning worse stuff to win in virtue of network effects and integrations.