My two favorite non-fiction sections of the bookstore are dead and dying. The computer section, if it still exists, is just things like _Excel for Dummies_, and the philosophy books have all been pushed out by self help and dime-store "metaphysics".
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.
"Green card" literally refers to US permanent residency cards; it's called that because the physical cards issued by the US are/were green. "Other contexts" are riffing on actual green cards as a metaphor, and if speakers in other contexts want to talk about legal specificities, they should use an accurate term...
You have to be either a committer in general or a maintainer of a specific package to merge PRs into Nixpkgs. Contributors' PR approvals in Nixpkgs are just an informal signal for maintainers and committers to consider. And maintainers can only merge changes related to the packages they maintain, not other random changes.
But a maintainer could merge their own PR created by a pseudonym, and signing is not required, so in effect, they can ship any changes to their own packages they wish. This is a major supply chain security risk.
Flox is a more comprehensive platform, it's proprietary, and it's designed to replace/hide Nix to some extent. Devenv is open-source and basically standalone, and uses the same kind of Nix configuration interface Nix users are used to from NixOS, Home Manager, Nix-Darwin, etc.
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.
Another great tool, built on top of nix-locate, is comma. So for any program foo, if you have foo installed, you can run it like this:
foo
And if you don't have it installed, you can run it (without installing!) like this:
, foo
And if multiple different packages provide a program named bin/foo then comma lets you interactively choose the one you want, and remembers your choice so you don't have to specify again unless you choose to via the -d flag.
> virtualenv isn't relocatable out of the box, so how else would you deploy a python project?
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.
The experience of using LLMs as digital assistants so far is not great. Gemini on Android sucks so bad it's hard to describe. It can't tell what its own capabilities are, it can't inspect the states of the apps it manipulates, it hallucinates constantly, and it needs more handholding than the crappy old decision tree to do the right thing. I much more often have to pull over to make sure Google Maps is doing the right thing than I ever used to before, because trusting the LLM to be "smarter" so often fails for me.
> It's not just common, it's almost universal to run `pip install` on production machines as a means of deploying a Python program.
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.
"Almost universal" is a bit of a stretch, most of the time these days Python apps are deployed as Docker containers, and if you're using k8s this becomes effectively mandatory.
However a lot of the time especially for older codebases the docker build will just run pip install from public pypi without a proper lockfile.
So at least install code isn't being executed on your production machine, but still significant surface area for supply chain attacks
Well, the install code can leave some code behind that will be executed on the production machine... It doesn't really help being in a container. While a separate problem from Python ecosystem, people really put a lot more faith in isolation offered by containers than they should. Also, it's often very tempting to poke holes in that isolation because it's difficult and up to impossible sometimes to get things done otherwise.
> Hooks (although there's no clean way to enforce they be "installed" on a clone), GHA Workflows (or their equivalents on other forges).
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).
At the end of the day, LLM slop PR spammers are essentially adversarial actors. Git hooks are ultimately a tool for good faith developers within a given community (your team, your company, your regular contributors) in maintaining good hygiene and avoiding lapses into preventable mistakes. That's true for all CI, too.
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. :-\
The most important real use case of devices like this is as accessibility tech. Blind people everywhere are talking about devices like this.
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.
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.
reply