pxc

I get what you're saying but I think what you're describing is more of a temperament more than anything else. Some people, inside and outside academia, have a kind of "root causes" or "first principles" temperament. Others are more inclined to build incrementally on existing knowledge, and less inclined to revisit the foundations.

I think you're right that lots of people with tons of training, expertise, or experience are (sometimes very disappointingly) disinclined to engage in first-principles thinking. But I would expect most academicians to at least know what it is.

I thought viruses weren't considered to be microbes. Was I mistaken? Is there a broader category that includes things like bacteria and also viruses?

Knowing what first principles reasoning is isn't the same thing as being willing to re-teach a discipline from the ground up for a stranger rather than first pointing to the existing literature that, perfectly or imperfectly, already addresses a topic.

That's quite a generous decision. Thanks a lot for doing your work in public and in multiple languages.

> Sadly people from the academia [...] equate [first principles thinking] with exam based memorization or delegation to authority.

In what departments and at what universities? The term "first principles" comes from academia. I think you'd be hard pressed to find a faculty member in any philosophy department doesn't understand what reasoning from first principles is. I'd be surprised if any working mathematician thinks of "memorization" or delegating to authority rather than axiomatization. What experiences led you to say this?

> I'm really struggling to see how to make architectural decisions with an agent. It's great when you're at a total loss for ideas

I feel the opposite, like if I go to an agent without first knowing what I want to build, I'll never figure out what I'm doing or why and it'll run away from me.

I pretty much always go back and forth and have the agent write out a plan to a file and review it myself in my text editor. I still sometimes end up with surprises I disagree with, but I don't really find it to be true that the LLM ends up trying to "drive all of the thinking".

When I'm thinking through an architecture, I not only instruct it to refrain from writing any code, I don't even necessarily tell the agent what I'm trying to build.

In centuries gone past, members of the bourgeoisie would be directed by their doctors to summer homes and country estates so they could "convalesce in the countryside". It seems there was something to it, or at least there is now. (Even back then, it was explicitly about "fresh air".)

When I used to go to parties in college, I was known within my friend group for participating in multiple conversations at once, flitting from one group to another. One of my friends later told me he thought it was impressive, but in fact I just couldn't help but hear all of the conversations at once, and if multiple groups were talking about interesting things, I would find myself torn between them, and end up bouncing back and forth.

> We must be living in a completely different world then.

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!

> Firstly, NixOS is hype

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.

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.

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.

Who has?

Nixpkgs has. :)

Nowadays the only search like this I need to run is

  nix-locate -r 'bin/foo$'

It would be nice to have a CLI alternative to Repology, though.

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

Be careful what you wish for.

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

What is going on???

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

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

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.

There aren't true 1:1 clones, but there's ripgrep (inspired by GNU grep) and fd (inspired by GNU find). Those two I like, though. I think they're thoughtfully designed and in ripgrep's case at least (I just haven't read posts/comments by fd's author), it was developed with some close study of other grep implementations. I still use GNU grep and GNU find as well, but rg and fd are often nice for me.

I thought it was a learning exercise, and maybe some corporations also like it because it has more permissive licensing.

What are those strengths? I've worked with projects hosted on GitHub, GitLab, and Azure DevOps at my current job, and was generally not impressed with AzDO (mostly looking at CI stuff).

As someone whose employer uses both: nope, not yet

> This is a very HN take.

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.

Huh? The usual pattern is that experiments belong to a user and then they graduate to having their own org iff they grow enough maintainers for that to make sense. How is that toxic or self-centered? It's just like "here's a place to do low-stakes experiments in public view". It's not particularly about ego or selfishness or whatever.

The original has the best ergonomics of any controller in my sizeable collection. I'm curious to see how this thing holds up.

> * Someone allowed sudo access or set the SUID bit on a GTFOBin. Using these tricks, you may be able to read or write sensitive files or execute privileged commands in a way the person configuring sudo did not know about.

Some enterprise security software that is designed to "mediate privilege elevation" includes an allowlist configured by the administrators. My experience seeing this rolled out at one company was that software on the allowlist no longer required a password to run with `sudo`. The allowlist initially included, of course, all kinds of broadly useful software that made its way onto this list (e.g., vim, bash).

I worked from home at this company, and I remember thinking it was a good thing, because this software deployed to "secure" my computer made it drastically weaker to someone walking up to it and trying to run something if I stepped away from the keyboard for a moment and forgot to lock it.

> Read that again. The agent itself enumerates the safety rules it was given and admits to violating every one. This is not me speculating about agent failure modes. This is the agent on the record, in writing.

> The "system rules" the agent is referring to are consistent with Cursor's documented system-prompt language and our project rules for this codebase. Both safeguards failed simultaneously.

It seems like human brains aren't built for the experiences we get with AI agents, where "you can just tell them to do something, and they do it!"... until you can't. It's not a junior dev, it's demented. It's not a magical assistant, it's a demonic assistant, possessed by strange forces that act unexpectedly. All possible metaphors are bad.

I've been reading articles and listening to interviews by a prominent AI booster lately (Yegge), and he talks about a kind of curve of engagement with LLM agents in which "trust goes up", and you delegate more and more work to the LLM as you progress along this curve.

One of the things that always struck me (and struck me as wrong) about his characterization is that running agents in YOLO mode arrives super, super early. It's either the second step or implicit in the first "stage". Why don't people see external sandboxing (or, like the article suggests "auditing token scopes") as a prerequisite to running these agents in environments that have access to production (let alone YOLO modes)? How can the standard answer from AI boosters just be "you WILL lose data. it's a brave new world!"? It's possible to use them without being totally careless. Why not try that?