I may be missing something, but this is exactly what I want as a default. I want the session links there. I see PRs from my coworkers with session links.
I still get to control whether other people can see the session, but I don’t lose it.
I don’t get the “unprofessional” argument. This is attribution. Attribution is professional. If you don’t want it, you turn it off or rewrite the commit messages. If you are having Claude write the commit messages FOR YOU and you are NOT READING THEM then that’s what’s unprofessional. I am honestly kind of shocked and disappointed by how upset people are by this.
Which is actually why I DON'T like the session amended. Ultimately it is an ad placed into the Git log, and noise at that. Regardless of if it exists or not, the professional responsibility for what is contained in that PR/commit falls to the feet of the developer contributing it.
Microsoft previously did this with Copilot, which was correctly met with a very negative response. I don't see why an ad by Anthropic is better than an ad from Microsoft.
Agree, that it is an ad. Also, unless the full session (in a resume-able format, along all session artifact such as intermediate research/docs used to produce the final output) is also included in the commit, the session id is useless.
I presume this is Anthropic trying to their "usage" stats before their IPO.
> Anyone who did and could do so turned it off immediately
I know I’m not alone as someone who’s bothered by the postscript, but too lazy to do anything but delete it every time. There’s even an entire (well part of) song about it: https://www.youtube.com/watch?v=EbdeVhPAbms
Out of curiosity, do these Claude commit messages fall into the same category of "it's annoying but not worth the effort to turn it off"? If yes/no, why?
Most people's identities and self worth are tied up in the material things they buy rather than actual self actualization and personal axxomplishments.
Even as a lifelong Apple user and longtime iPhone user, that sig irritated the shit out of me and was instantly disabled whenever I set up a new device.
Also, and this may come as a shock to you and a number of other HN users: I never considered it a "point of pride." I switched because Android was a privacy dumpster fire comparatively and battery life was far better.
I also can't remember a discussion in person with folks where someone seemed "proud" to use an iPhone. If anything, the Android crowd loves to sneer at iPhone users and look down on them as idiots who need a "simpleton" phone.
I'm no simpleton. I ran custom roms and so on. Had F-droid installed, and so on. I do miss the customization, but I also look back and realize I wasted a massive amount of time on installing roms, backups, and the customizations themselves. Probably weeks of my life if not more. My iPhone? I don't. It's a phone. That runs apps. Do I wish I could install whatever I want, particularly given how secure apple's sandboxing is, and thus in theory how safe it should be? sure. but at the end of the day I want to live my life.
Now compare that to why people don’t want Claude in their commit messages or PR descriptions.
Clearly there’s no pride in using agentic coding (if anything, maybe it’s the opposite of pride..). I don’t think most developers want to publicize their use of agentic. But I could be wrong.
I'm not sure i see it as an ad. "Sent from my iPhone" is an ad because the iPhone is not a meaningful part of sending the email. Claude is a meaningful part of the commit though if you're using it, so to me it's more like clarity or transparency than an advertisement.
You don't see how a link to "https://claude.ai/.." in the Git log is an ad for Cluade/Anthropic? It feels exactly like "Sent from an iPhone" to me, and has exactly the same value to people reviewing the Git log later (i.e. none).
Keep in mind that if you run across someone else's spam in the Git logs:
- You need a Claude account.
- You need permission to view the session.
The only people who can just follow that link and look at how Claude was used, is Anthropic themselves. Therefore, they can also use it as an additional mechanism to tie sessions back to other IDs/identities. For everyone else this is "Sent from an iPhone" but longer.
But presumably everyone in your company/team is using Jira, so it's not an "ad" because it's a product already used internally. Claude is appending these links to all commits by default, whether or not others on the team use Claude. Those are very different things.
Good counterpoint. We link to GitHub from JIRA, and the reverse. Linking to the Claude session that generated the code seems reasonable...it's a related artifact.
One thing I'm not sure about: what is the utility of linking to the session? What are folks expected to do with that data?
You're missing the pattern of behavior from Anthropic. They constantly market like this: the session link, the Co-Authored by Claude, the unwillingness to adopt AGENTS.md. Hell, on workflows on 2.1.246 Claude's been ignoring the "attribution" block in settings.json and gone right back to coauthoring every commit.
What's the odds on them fixing that bug anytime soon.
The part after "https://claude.ai/" is a UID, that's useful to have to tie together multiple possibly unrelated commits and changes authored in a given session.
The way I see it, the conversation transcript is the important part. The specific link to claude.ai nor the model itself is important to me. Otherwise we'll all just be linking out to 10 different AI model providers websites to see history. I'd rather it be some open solution.
Models change so much that I don't really see why anybody cares what model was used to generate the code after the fact. It changes every few months and they're non-deterministic so its not like you'll ever "recreate" the same conversation yourself anyways.
UID itself is what is useful, regardless of whether or not you have access to the actual session transcript.
One could argue that "https://claude.ai/<uid>" is slightly more verbose over "CLAUDE_UID=<uid>", but the former is also slightly more convenient for those with access to the transcript, and both have word "claude" in them, because you need to be able to tell which UID in the commit message is for what.
If my tree kept a log of all the activities that led to it being a tree, I wouldn't mind if that log included "Spear and Jackson". To me the closer analogy with software would be if the final web app interface was stamped with "built with Claude".
There has been more than I project where I literally didn’t even look at the code.
I prompted what amounts to verbose “I want X” and then did QA. I’m perfectly happy with an LLM being credited with that code and there being no copyright existing for that code.
For some people that is their life’s work and they want to clutch pearls. Their sole contribution was a half baked idea and they shipped QA out to their “users” but they want to be credited with any rights.
There is definitely a continuum in LLM usage for code, do I agree with an AI blindly stamping every commit, not really.
Do I see LLM generated code as equivalent to me digging a hole with a shovel, it depends. Sometimes there was very little shovelling, other times there was no me involved and you may as well credit the entire hole to the shovel.
Where this will come in is when it comes to copyright and licensing.
If your entire product is LLM generated you sure as hell have no right to place any license on there other than potentially a MIT equivalent license, even that is dubious though but from an organisational standpoint MIT probably will be more widely accepted than saying it is uncopyrightable.
My argument being I would rather know that you didn’t even look at the code, which is what this will achieve, whether I agree with it or not at the very least it will make it easier to sift through the garbage.
This is a problem with copyright in general. There's no longer any requirement to provide information about copyright status, so there's no way for the public to know whether something is copyrighted (no doubt the uncertainty is intentional as an additional way to undermine the public domain). This is just as true for expired copyrights, or material placed in the public domain intentionally.
The solution isn't to add notices to non-copyrighted things; it's to require notice for copyrighted things, including date.
Individually, of course, one should simply assume things are not copyrighted if you have no way to know, and do whatever you want. If the author can't be bothered to tell you, you have no moral responsibility to care.
Yes it’s the same as using a stock drum pattern in a drum machine, it is not copyrightable because no human was involved in any part of it.
If you have an idea and want rights to it then do it the old fashion way and pay a developer to do a commissioned work and you can have your copyright, heres the catch, that will cost a hell of a lot more than 100usd a month
And when that developer copies and pastes useful code snippets from the internet into this product you’ve commissioned them to create? Also not copyrightable?
I agree. But I think I would also like the OS to put a fingerprint (I.e committed on macOSX in /usr/marc/… while he was watching porn on xxx). This way we can get the full context by default and better understand the PRs.
I'm sorry if this is a naive question, but why can't you just edit the commit message however you like?
Or, for preference, write the whole commit message yourself? It confuses me a great deal to see projects where someone put in a lot of effort to write a useful and detailed prompt but absolutely couldn't be bothered to write a few sentences for the commit.
Realistically, what do you actually get from viewing people's sessions? I honestly don't really understand why people care.
The specific model used can't be important because theres a new trending one every couple weeks nowadays. The conversation could be wildly out there and have 10+ different iterations of the same thing in it that led to the final product, etc.
It's not like before AI we were asking people to explain every single iteration they went through in their commit body, or to see their entire internal dialogue.
I don't really understand people's hype around needing to see the conversation they had with their AI. As long as the code itself is self-documented and final decisions are relatively well-documented future agents and humans will pick up on it much faster than reading the entire transcripts anyways.
That's not even bringing into the fact that there are people who use multiple models, multiple sessions, multiple harnesses across the same commits/changesets. How do you reconcile those alongside people who could have made human changes in the end?
There’s always been a school of thought that is in this direction. In the pre AI world people discussed whether to squash commits or to not and I was on the squash side because I think that the development artifact should be optimized for reading and just as one does not read a novel in all of its pre-edited forms to read it, one should not do so for code. The cost to grok using that method is too high.
However with LLMs you can have them analyze prior transcripts to identify bug sources and so on. I could see it being used. But all theorycrafting. And perhaps motivated reasoning. I’ve always committed early and often and used bisect to find bugs. That places me right away in the squash commits camp because of the method I use to write code.
People don’t want their incompetence displayed. The session is probably a series of “continue” prompts with basic understanding demonstrated in the initial ask.
The link to session is a red herring - most people seeing it won't be able to access the transcript.
It's a tag with an UID. It's useful to connect together multiple changes, including possibly several commits across multiple unrelated repositories, as well as other artifacts and actions. It records the causal link, and connects it to telemetry (people do run their own telemetry over agents, especially in team/company setting). Because chances are that, if you have issues with some change made by AI, being able to look up what other changes were made as part of the same session is going to be very helpful.
> That's not even bringing into the fact that there are people who use multiple models, multiple sessions, multiple harnesses across the same commits/changesets. How do you reconcile those alongside people who could have made human changes in the end?
This is exactly how. By tagging changes with session UID, and using it as key to resolve other changes, as well as specific model and harness versions used, if you use telemetry endpoints harnesses tend to offer.
The whole discussion is just people getting tripped over the tag being link-shaped, ie. "https://what.tld/<uid>", instead of "WHAT_ID=<uid>".
I think it’s foreseeable that if you use the LLM to commit work you’ve written, it might cause problems with attribution.
In general I assume that attribution to AI is approximate. People copy-paste things out of chats and those don’t get attributed to the AI. And on the flip side, I’ve had AI write a commit, and then I’ve reverted it and written something different by hand (and it got tagged with an LLM session).
The AI attribution is approximate and informative. The commit message and authorship are the more important parts.
You may be concerned that people will think your commits are LLM-generated. I’m sorry that you have to work in that environment, but I don’t work in an environment like that and I don’t share your concerns.
How would it know for certain it was used for a given commit? What if there was no code? What if the approach was different, but some lines were the same?
I think some folks think that using an LLM is a shameful act and this is somehow shaming it and others believe that it ties back to the conversation. These conversations don't have any guarantee of being accessible over the long haul. If there was value in the conversation, the conversation should be somehow captured as well, not just some URLs.
I'm OK with the attribution, but I just didn't like a session URL appearing on a public repo all of a sudden. I was left wondering "did I just leak my private session?"
I don't understand why it isn't opt-in. Or at least a heads-up somewhere.
At this point it's believable to me that Anthropic might not even be aware of what features get added in a given release. It's hard to tell the difference between "they actively are against documenting all of the defaults they keep changing" and "they genuinely don't even pay enough attention to notice when their vibe-coded changes have changed a default". Functionally they're the same, and both would stem from similar (lack of) values, but I think it does kind of matter because it's essentially the difference between explicitly crafting an experience for users versus defining same things they want and letting the vibes end up driving it towards a bunch of user-facing emergent properties that no one has considered.
"Of course they were intentional in adding in an ad to everyone's git log" honestly night be the less cynical take, because the alternative is assuming that they actually look at git logs ever rather than only having Claude deal with it.
I think a lot of people interpret it as trying to foist additional burden on reviewers. As in "here's my PR, I would like to take credit for this idea, it's now on you to review. If you find a problem with it, I expect you to call out exactly what my incorrect assumptions were, which you are able to do because they're all buried somewhere in this Claude session. Let me know what they are and I'll paste them into a new session and submit again."
I agree that attribution is professional. What I would worry about is people using the link to supply the reasoning behind the change without putting it into the commit message. Then you have the problem of needing to load the session to understand the change, when one would ideally be able to get that context from source control alone.
More like an ad for trillion dollar corporations. Not in the business of giving those out for free.
Attribution also helps people who want to judge others for using AI. Not even slightly interested in enabling any form of prejudice and stigma against myself. Even the markdown files that agents use don't go into my master branches anymore.
I think there's a distinction between attribution and linking to something nobody else can necessarily access. Placing a path to my local build is something I'd avoid because it's irrelevant to everyone else. I think the same applies here.
Same. Over relied on and far less clear than alternatives 99% of the time. Claude is a shitty English writer that is only tolerated for it’s coding ability.
If you know “origin” or “source” and those words suffice, using a word that means the same thing but you don’t know is strictly worse for communication.
So if Claude is writing a novel, maybe provenance is the best word to use at times. If its a codebase README or variable name, its usually not.
hard disagree. I'm not gonna read the session log, and I don't care for it at all.
as for the commit message: if it's the usual verbose Claude style, I'm also not going to read it. to be honest, probably if it's not verbose, I'm still not reading it.
I'll ask my review agent anyway to summarize your code. My review agent will read your commit message.
I read the summary which for me focuses on intent: What's the current state, why it's not good, what is being changed and how, and then look at performance numbers.
Then I read the code but only after it got scrutinized by pr review skills on multiple models and those feedback got marked completed by the author.
Yeah, same here, but I do not pay that much attention to the PR description since it's all written by the same AI, it just narrates its own code. I prefer to skim it then jump to the code.
The problem thesis is already in the ticket, so we could just reference it in the PR without duplication. The current state and how it's being changed are already the code diff itself under the changes tab, right? Reading it straight makes me question the code better since the AI is usually overconfident in its writing, so I don't focus on it unless I face a hard blocker or constraint that should be mentioned there.
I also do this with my swarm of review agents, asking them to review the code without context, that way, they produce more high-quality feedback that is backed by self-sourcing the context from the codebase instead of relying on the AI-provided PR description that might justify a code change that others might disagree with otherwise. it works well especially with code changes that could miss other parts of the codebase during refactoring or implementing features that touch multiple domains.
Sure, but it does spook some people like me where I frequently mention context in session like: "it would be better to fix this on the backend, but that is a separate team that moves VERY slowly", etc. And I don't want that accidentally getting broadcast.
Am I misunderstanding this change? This makes it sound like Claude is attaching the entire session content when I thought it was only a link that is exclusively readable by the author, unless deliberately shared?
ai has been an excuse for people to shove into pr's all kinds of shit that would never be tolerated otherwise; from super long descriptions to annoying emojis in commit messages and overly verbose comments and code that has the mpg of a broken scooter...
I use and love openspec and I'm against this session attribution by default setting.
But I do see the value in seeing the conversation that lead to the spec. I make sure that all product decisions go through me prior to the agent writing the spec and the questions I ask and decisions I make could definitely help understand retroactively why something is the way it is.
I guess with the default openspec schema you wouldn't have that but you could customize it or create your own in which the reasoning is encoded fully.
It feels like an absolute failure of project management if your tooling needs to attach a session identifier in a git commit message for it to understand what’s going on.
Wikis, changelogs, decision records, issue trackers and more are available to provide greater context for you, your team and the agents you deploy.
It is because many "developers" want to pretend that they have read the code and have understood it so they can claim it as their own.
Attribution is indeed professional. If you use an AI to write the code for you and have no idea why you accepted the decisions it made nor can you explain them to another human, that would be clear evidence of acute skill atrophy.
It’s not a question of ISA support. If you call via a function pointer, how do you supply the pointer to the data? (It has to either be in a separate place from the function code, or the same place. One requires an ABI change, the other an executable, writable section of memory.)
> If you call via a function pointer, how do you supply the pointer to the data?
D has the notion of a "delegate", which is a (function pointer) and (context pointer) pair. This is incredibly useful, because delegates can:
1. call nested functions that need a pointer to the stack frame of the nestee function
2. call member functions that need `this` pointer
3. call lambdas
4. call COM member functions
The neato thing about this is the ABI for delegates is all the same, so a function that gets a delegate parameter will work with any of 1..4. It's one of the most used features of D.
This feature would IMO violate the contract that C allows you to specify memory layout of objects, to some level of detail (I am being a little vague about the “level of detail”).
Supporting closures, more or less, requires design decisions that are equivalent to choosing a specific layout for objects in an object-oriented language. C, as it is, makes none of these assumptions and you can translate a lot of different language ABIs into some C code (that may be clumsy). Keeping the abstraction that function pointers = pointers to entry points for functions, well, that’s frustrating for C programmers writing C programs, but extremely useful for interoperability.
At the moment we can not call nested functions or other things from other language from C, which is a pretty big hole in our interoperability story. I do not see why we need to make any design decision to specify object layout, we simply need a code pointer and static chain pair, which would then be sufficient to call arbitrary entities from other languages.
> I do not see why we need to make any design decision to specify object layout
> we simply need a code pointer and static chain pair
The code pointer and chain pair needs an object layout. You would have to pick a specific layout, and it would not be compatible with other languages that have a different layout.
Right now I can do this:
struct a {
void (*fun)(void *ctx);
int data1;
int data2;
};
struct b {
void (*fun)(void *ctx);
void *ctx;
};
And I could call them:
struct a *aptr;
a->fun(aptr);
struct b *bptr;
b->fun(bptr->ctx);
There is only one neutral, maximally compatible option here—which is to have the function pointer separate from the arguments you want to pass in, and pass them in explicitly.
If you add closures to C you are making compatibility worse, not better.
Except doing this manually does not allow me to directly call a C++ lambda, a Go closure, an Ada closure etc which I can not even express in C. So compatibility can not become worse, it is already maximally bad. And even where you can build a compatible solution in C, there are now different choices. Your examples already directly shows this contradicting your claim that here is only one option.
Adding such a type as a vocabulary type would fix all this. You can argue that we fix an object layout for a pointer pair, but this seems an acceptable trade-off to me. This seems far from your previous claim that this "requires design decisions that are equivalent to choosing a specific layout for objects in an object-oriented language." Note also that such a type can always adapt to different calling conventions of other languages by using the address of a static thunk as code pointer so it is very generic.
A C++ lambda (as essentially is the case for a Rust lambda as well) is just an unnameable class object with an overloaded call operator, which makes the closure function body itself just a regular member function ABI-wise. You're not calling these things outside of the language, because they're only really callable via the language-specific static dispatch mechanism of templates. If you need to be able to dynamically call a lambda, you're going to be stuffing them in an object that contains a pointer to the lambda object and a pointer to the function of the actual body, something that looks essentially like what GP's assertion of what a lambda ABI looks like.
You can stuff it into something such as std::function_ref which erases the Voldemort type and then it can be dynamically called without needing templates. And this could be from C or other languages if only there was a common type in C we could use.
C++ lambdas and Go closures are incompatible with each other. If you pick something that lets C call Go closures (which are fat pointers passed around), it is likely to be incompatible with whatever your C++ library is doing.
The point is that it can always be adapted to a common wide pointer type, which C could provide as a standard. C++ already has a solution for this on their ide: std::function(_ref).
Feels like there are a few categories of services from cloud providers,
There’s the basic infrastructure we know and love like S3, EC2, etc.
There’s the higher level but still basic stuff that just makes a lot of sense. I like ECS + Fargate, Lambda, DynamoDB, SQS.
And then there are the tarpits. CloudFormation. Cognito. Step Functions. API Gateway. They do something useful (otherwise why would they exist?) but the main point of their existence seems to be to trap you in AWS, and the fact that they solve a problem seems secondary. Some of them are cheap (CloudFormation is free!) but in general they seem like expensive alternatives to simpler, cheaper solutions.
The further up the stack you go, the worse it gets - but, honestly, Cognito and API Gateway are no worse than mid-tier.
The really nightmarish ones are the likes of CodeStar, AppRunner, Directory Service, CodeCatalyst, and 90% of anything under the Systems Manager heading. Things that tend to be glued together from multiple lower-level services with a sprinkling of vendor lock-in on top.
I found "Systems Manager Session Manager" (terrible name!) useful a few times for getting around network restrictions.
You set up a EC2 VM, which doesn't have to be in a public subnet, then use "session manager" to forward ports to other instances / services using the AWS CLI. It is possible for that stuff to be blocked with IAM but often it's overlooked since IAM is confusing enough as it is.
I take breaks from AI agents and write a percentage of commits purely by hand, partly to keep experiencing the flow state, partly because I think I need the expertise.
Speaking of gear, there are also a lot of people who will go out and spend $440 on a SM-7b, and then use it to record somebody (1) not saying interesting (2) who doesn’t have good speaking skills (3) in a room which doesn’t sound good (4) with a preamp that doesn’t have enough clean gain to record a low-output mic like the SM-7b.
It’s not like gear isn’t important but the SM-7b has become such an object of hate for me because of what it represents for podcasters. The “you will very quickly learn what works and doesn’t” is a much better starting point. (And yes, the SM-7b is great, blah blah blah. $440 is still a lot of money for most people, and it’s not $440 of ‘great’ for somebody who is starting out.)
I started with a couple of $40 Jabra USB headsets + a MacBook. MacOs comes with a built in equalizer that lets you "merge" two inputs into a feed. You can then use Audacity to record one user on the left channel and one on the right.
Again, I didn't know anything about audio processing but with some YouTube videos, Audacity manual + asking an LLM you can really make the audio sound great.
As one extreme, you can literally start a podcast with a phone and whatever audio app is included with the phone.
I likewise used to bring a backpack full of gear, but I think the experience of traveling and taking pictures over and over again with the Big Nice Camera did a lot to hone my skills as a photographer.
I have photos I’m genuinely happy with, years later.
Everything being static inline makes it hostile to these older systems which have limited RAM. Use of float makes it unlikely that you’d run it on the PlayStation, which has no FPU.
> Everything being static inline makes it hostile to these older systems which have limited RAM
If you don't define `PICOPHYSICS_IMPLEMENTATION` then you just get prototypes and a few struct definitions. From what I could tell the static inline functions are just used as helpers by the non-static functions defined in the implementation TU. It's similar to the stb[1] implementation pattern.
Also, inlining improves code size more often than you might think. There is a lot of ceremony in a function call, and the compiler has to make pessimistic assumptions about what is trashed by the call, causing unnecessary spills and fills. Things like the simple vec3 operations here should pretty much always be made available for inlining; whether the compiler actually decides to inline them is a different story.
> Use of float makes it unlikely that you’d run it on the PlayStation, which has no FPU.
I think this sentence just made me realize what made the PSX graphics look so "PSX", I'm guessing all the positions/translations and similar stuff were actually not floating point which they typically are (today at least), hence the classic look of triangles/meshes kind of "jumping"? Huh...
The jumpy polygons are because the PSX's GPU only accepts vertex positions in screen coordinates, meaning that vertices always snap to hard integer values. There is no sub-pixel accuracy. That's not a limitation caused by the PSX's lack of an FPU though. A large part of the render pipeline and standard libraries are built around the use of fixed point math, i.e. using integers to simulate decimal values. The GTE co-processor which handles 3D math makes use of standardized fixed-point types. So the PSX would have been capable of calculating sub-pixel coordinate values, it's just that the communication between CPU and GPU was designed to use only integer screen coordinate values.
It's slightly more complicated than that. The PlayStation's geometry pipeline uses fixed-point coordinates with a decent amount of fractional precision (12 bits), however the GPU lacks support for subpixel rendering and operates entirely in screen space using integer X/Y pixel coordinates; all transformed vertices thus have to be rounded CPU-side before they reach the GPU. The GPU is also a 2D rasterizer only, with no perspective correction nor depth buffering, so transformed Z values are used on the CPU to sort polygons back to front (typically using hardware-assisted linked list bucket sorting) and dropped afterwards [1].
Not just limited RAM, but limited RAM bandwidth, which seems like it would make this particularly painful on the N64 (ironic, given that the in-file README says that this came about specifically to support porting a game to the N64). That said, should be possible to wrap these with some non-inlined functions in a pinch, yeah?
Re: floats, I wonder how well it'd perform if compiled with soft-float support?
> Everything being static inline makes it hostile to these older systems which have limited RAM.
Compilers can un-inline as well. In fact, since every function is defined in the header file, the static inline annotation means very little, it's more of a hint; the functions that were not marked static inline can be inlined just as well by the compiler.
Only one of the consoles listed lacks an FPU, the other two (N64 and DreamCast) both have FPUs. Despite its age, the FPU on the N64 was plenty fast and it was used extensively.
The N64's FPU will usually be faster than doing fixed point on the CPU.
You are actually multiplier/divider bound, and the CPU can multiply about 10 bits per cycle and only divide 1 bit per cycle. Since you aren't multiplying the sign/exponent bits, it's faster to multiply/divide the 24 mantissa bits of a 32-bit float than it is to multiply/divide the 32 bits of an int.
And with fixed point, you then have to throw in the extra shift instruction (which floating point automatically does internally).
Though, this only applies to fixed point on the CPU. The RSP has no FPU, but it does have a 128 bit vector unit with 8 16bit lanes which is pretty good at fixed point stuff. If you can vectorise your algorithm, it will be faster on the RSP.
There was a sweet spot in like 2024 when it seemed like everything was possible with Nix, but now it seems like everything “experimental” is permanently so (like flakes), packages I care about are not as fresh as I want, I have no mental recall for Nix commands…
Meanwhile, my company is using Nix for everything heavily internally. Everyone gets their dependencies via Nix unless you are like using PAM or something.
Reminds me of Bazel, in the way that it gets adopted by companies with developer support teams (because it solves real problems) but feels frustrating for us ordinary folk. Nixpkgs is kind of a critical part of “ordinary folk” and with the core team disbanding, I feel like my personal moves away from Nix (for projects) are proving correct.
I was lead on a Nix adoption effort for a few years that was kind of like that: it solved real problems, unlocked far faster, smaller, and cheaper builds than would have been possible any other way, and let us ship delta updates over crappy wifi connections to Linux computers on robots. Flakes were a perfect fit for our model, and we were just in time for stuff like up to date versions of cuda and tensorflow to be delivered via nixpkgs.
In my mind, Nix was unstoppable, and I particularly loved how empowered I imagined developers would feel. No mystery-meat CI scripts pushing packages to distant infrastructure that no one understands or even has the permissions to interact with, just the entire build system in one repo, trivially cloneable and hackable... add patches or build steps to anything and it's the same build as always, build it locally or send it to Hydra, it doesn't matter.
A devs "got" it and did leverage those things, used PRs to do safe evaluation of bumps to core dependencies, but I think on the whole it was regarded as cool but not tractable, and a few years after leaving, it sounds like plans are being laid to replace it all with something containers or whatever.
Very frustrating, particularly in a world where it should be trivial to identify the 5-10 typical tasks that people want to do with the nix code, and set up Claude skills to handle those. Given how easy and self-contained the build-test loop is, it feels like an almost perfect fit for agent-led development.
We're using it in the same way - running NixOS on robots.
Overall I think it is succeeding, though it definitely doesn't 'just work' out of the box. We've invested a fair bit of effort into things like:
- containerised services[1]
- UI for branch deployment/service management
- delta patching (at the byte level, to save bandwidth)
The main problem was always that nixlang/nixpkgs are arcane and have a steep learning curve. The majority of your colleagues (in any workplace) don't care about build systems and just want things to work. I think that has been more or less solved by LLMs, and it's now more viable than ever to adopt Nix.
Meanwhile I’m over here with my 100 line flake.nix that installs system dependencies with direnv across hundreds of dev users and dozens of repositories wondering why everyone is all up in arms about boring and stable technology that solves a specific problem
In my personal life, I also like Nix for small projects, especially where you're crossing multiple ecosystems so that any one system's tooling/lockfiles aren't really enough to "enclose" the whole thing.
For that work project though, the final closure was thousands of store paths, with hundreds of source repos being brought together across a multiple of languages and build systems. A lot of that was/is essential complexity, just the reality that robotics is hard, the tools aren't as mature as in other domains, and so you have to be able to develop features and bugfixes all over a huge software stack simultaneously. Doing that with conventional tooling basically gets you a rigid world where you have to tag/release intermediate packages all the time just to get changes into testing, or you have to build the world on every push (lol docker).
With input addressing and hermetic building of the intermediate stages, Nix and Bazel are systems that don't make you make that choice.
My gut feeling is that Nix is just not quite the right abstraction level. I can’t quite articulate this. And hell maybe I’m wrong.
I don’t want to configure a global environment. I just want a build system that works reliably in any environment and can cross-compile from any platform to any platform.
Nix does too damn much. All I want is a build system that doesn’t suck. And I want to run it on windows + Mac + Linux as a first class citizen. And I want to arbitrarily target any platform.
What this really comes down to is that Linux C/C++ toolchains are badly designed. Nix is a huge massive convoluted architecture to try and twist itself around that unfortunate reality.
At least that’s my spicy unpopular opinion that is probably wrong but is at least has elements of truth.
Shared Dynamic Libraries. Not to say they aren't useful. Keeping applications small, keeping security updates simple, sub linear ram scaling, yada-yada-yada, big wins cross the board, not debating that.
The pervasive link detection structure of effectively everything on GNU/Linux assumes is (more-or-less) objectively incorrect behavior in any sane security minded context. Binaries should be able to declare the interface/contract they expect (args/types/abi/exceptions/cryptographic signatures/digests). Then the runtime linker "match" against the local system. The current system is basically 2 levels of string equality checking.
Nix goes into the right direction by getting your runtime linker/elf-runtime & package manager "integrated". But this sort of just feels like putting 'lipstick on a pig' and dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer. Nix just manages the environment/symlinks such that `foo.exe` doesn't realize this fact.
> dancing around the core issue that `foo.exe` cannot ever realize `foobar-v1.8` and `foobar-v1.7` are both installed on the same computer
I’m curious if you have an opinion on how you think this should be handled?
At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
I also blame C/C++ toolchains for being very very bad on Linux.
> I’m curious if you have an opinion on how you think this should be handled?
To "totally overcomplicate things" but do it correctly
- Binary states a list of constraints (namespace:name [<|>|>=|<=|!=] semver).
- ldconf/ld.so either integrate into your package manager and/or are easier to update (I'm not writing conf files by hand and/or flakes). I should simply be able to recursively scan.
- Give the runtime linker an SMT constraint solver (when <1000 this is nearly instant)
- Cache known states to avoid solving NP hard problems every time you launch `cat`.
> At this point I’m just on team static linking or Windows DLL black box style. The Linux approach of dynamic libraries which function same as static is just the worst of every world.
Honestly same.
Having the package manager <-> elf runtime <-> shared libraries more-or-less be a blackbox is probably for the best (which is sort of what windows does with the install-shield/install-wizard stuff). But nobody in Linux Land really wants to "improve" userland, other then change to flavor-of-the-month display managers.
> I also blame C/C++ toolchains for being very very bad on Linux.
They honestly aren't, it is more your pacakge manager *is* your library manager. Because of the absolute bullshit of shared libraries.
If you pretend it is the 1970/80s everyone at your company has the architecture, unix version, etc. It is pretty nice. No cross compiling, multiple OSs, everything just sort of works pretty well. But like I said, "pretend".
> They honestly aren't, it is more your pacakge manager is your library manager. Because of the absolute bullshit of shared libraries.
Hrm. It’s trivial for Linux to cross-compile for Windows because Windows is sane. It requires moving mountains for Windows to cross-compile to Linux. Hell, the only way Linux can reasonably compile to target an older version of glibc is to create a full container image containing and using the old glibc. It’s absurd. I suppose this isn’t the root evil. But it feels related to me. Maybe not.
I mean... a big part of that with conventional Linux distros is the idea that you can security-update a low level library and all the stuff linking to it gets the fixes "for free", a dream abandoned both by Nix and also the movement toward distribution via containers/flatpaks/VMs/whatever.
> The truth is like the sun. The light from the sun touches everything, it's bright and it's obvious... yet no one can stare directly at it.
bad analogy. It can be very painful to accept the truth, but doing so is always a good thing. Staring directly into the sun can cause permanent damage to your eyes -- not a good thing.
No this is not true. There is an evolutionary reason why people lie to themselves. Look at the world.
Almost everyone believes in religions. The world lies to themselves on an unprecedented scale. If accepting the truth had an evolutionary benefit then most of the world would not be so delusional. Delusion dominates the population because lying to oneself conveys a survival benefit such that natural selection selects for this trait.
This short infographic illustrates and proves it. But you know what else proves it? Me getting voted down as I throw the truth down in front of everyone’s faces. I’m a target for selection.
Maybe nix will one day be a tool that’s actually good. It has elements of it but complexity and usability hinder adoption. So overall nix is just shit imo. It’s shit wrapped in a dream, a dream of an ideal way to do things. How do we make that dream a reality?
By lying to ourselves. By claiming nix is already there and that other people can’t see the light such that over the years after enough improvements nix becomes an actual good tool because enough delusional people pushed the dream far enough that it actually happened. But in order to do that… people like me must be culled from the herd.
At the time I was there we hadn't made it all the way to NixOS on the targets, so it was an Ubuntu "base" + Nix managing the app workspace as a kind of pseudo container, though able to bring more of its own system configuration with it (https://github.com/numtide/system-manager) than the more typical nuisance setup of container + separate outer config managed by ansible or a deb or whatever.
As a result of that, in "production" we still actually delivered full rootfs images just to be absolutely certain, and the delta upgrades were for smaller test fleets that could updated hourly just via simple push tooling.
If I was building it from scratch though, I'd probably just do NixOS + colmena, and do a push model forever. It's not worth the saved SSH connection to not have those logs and status messages coming back to the central coordinator immediately.
I’ve been running a NixOS based homelab for awhile now with 5 physical hosts and about 30 NixOS containers/VMs in an Incus cluster and I can’t imagine moving away from my central Nix repo and ability to rebuild/upgrade the entire fleet in one command and feel confident that things will work.
While I’m concerned about the disbanding, it would take quite a lot to make me look elsewhere, and there’s enough critical mass that I feel confident others will step up.
YMMV, I don’t run a home lab, I just have a NAS and run a personal website. I definitely don’t have a “fleet”. I have two servers running Debian and I can bring them back up from zero in <30 minutes.
“Rebuild everything in one command and have it work” is not something that I’m chasing after and I am skeptical that it would work anyway. Maybe there is something I’m missing, but when I update the software, the updates come with changes and it’s possible that things break. My goals are to keep reasonably up to date and to be able to fix things quickly if they do break.
Regarding Nix complaints:
Package maintenance is kind of a crapshoot. Maybe your package is in nixpkgs, maybe there is a flake for it, maybe you find something that is actively updated, maybe not. Maybe there is a package but half the features are turned off because the maintainer didn’t bother. Maybe there is a package but half the features are turned off on macOS for unknown reasons. What I want is just to know what level of distro-level maintenance the package has, including its transitive dependencies.
Docs are just kinda bad. Fragmented across different sites. Docs teaching you Nix forwards or backwards, or teaching old Nix, or teaching Nix with flakes, or teaching you Nix for end-users or developers or package maintainers, or Nix on Mac or NixOS. A surprising number of broken links. What I want is one site, with a little drop-down menu to select the version I am using. What I have is hours spent on the NixOS Discord trying to figure out how to do basic stuff.
Yeah. I fixed AI/GPU stack consisting of 6 existing packages to run CLI on Mac. Fixed all comments during several weeks. And then silence. No approve no nothing for few months. Closed PR and will never come back.
> “Rebuild everything in one command and have it work” is not something that I’m chasing after and I am skeptical that it would work anyway.
I'm not using "rebuild" to describe recreating an instance from scratch, but in the "nixos-rebuild" sense, i.e. I can deploy a fleet-wide configuration shared by all hosts, or apply package updates across the fleet, etc.
As for the skepticism, all I can offer is my experience which is that it does indeed work, and I've been running this way for awhile.
> Maybe there is something I’m missing, but when I update the software, the updates come with changes and it’s possible that things break.
The only time I've had breaking changes that required manual intervention was on a major release update. The issue amounted to "You're using abc configuration option but should be using xyz instead". This message was clearly logged, and fixing it was a matter of a few minutes of reading why a particular property name had changed.
Those updates happen twice/year, and in the last ~3 years I think two packages have forced me to make a change. Unless you're running unstable, you won't encounter this for ongoing package updates within a release.
On the topic of rebuilding from scratch, that's not a single command, but it's only a few. VMs/containers mount incus volumes (zfs-backed) for data storage, and a fresh rebuild is a matter of spawning a new instance from my homelab base image (I use OpenTofu to orchestrate this), running a nixos-rebuild targeting the new instance from my workstation, and things are back up and running. But I'm less focused on full rebuilds since I'm already doing Incus backups and can restore on any of the nodes in my Incus cluster.
> My goals are to keep reasonably up to date and to be able to fix things quickly if they do break.
My goals are similar. I can completely understand sticking with Debian for two hosts. I had experimented with NixOS for years but never really went all-in until I started expanding my homelab environment. At that point, NixOS just clicked and I'm far more productive with 30+ hosts than I used to be with 1-2.
> Package maintenance is kind of a crapshoot. Maybe your package is in nixpkgs, maybe there is a flake for it, maybe...
Which channel were you running on? And do you have any examples of specific packages? What you're describing just sounds foreign to me. I currently default to the latest stable release but if there's something that isn't in stable I'll override that specific package to use unstable. Much of the community just runs everything on unstable, but I prefer a slightly slower pace of updates.
Nixpkgs is the largest package repository across distros by volume, and as much as I love Debian, it's far more common to find things missing there.
> Maybe there is a package but half the features are turned off on macOS for unknown reasons
This sounds like you're branching into territory that can no longer be reasonably framed as NixOS vs. Debian (or other distro of choice).
> Docs are just kinda bad.
This is by far the project's greatest weakness. LLMs have been the saving grace. The frontier models are excellent at NixOS and I've switched to mostly having a conversation in my NixOS Claude project when I need info. This is in no way a defense of the docs, but for anyone motivated to use NixOS, there is at least a good option beyond the docs themselves.
I moved my homelab to Kubernetes. I just don’t see the use of single VPS’es. But I use the cluster as a training platform, so if I didn’t need Kubernetes in other parts of my life, I probably would have stuck with my NixOS VPS’es that all share config.
I use kubenix to manage the cluster, of course. ;-)
The two aren't mutually exclusive! I just finished porting my personal kubernetes cluster from running on Debian to running on NixOS. Now whenever I want to update the host OS on my kubernetes nodes, I just build a new bootable ISO from my Nix configs and upload it to my servers, swapping out the whole OS atomically. If anything goes wrong, I can swap back to my previous build. No more anxiety running `sudo apt-get upgrade` and hoping for the best.
But as the host OS I use Talos Linux, which itself is declarative and minimal. For small Kubernetes version upgrades, I upgrade the kubelet with an API command. When that isn't possible, I upload a new Talos image and swap them.
Since the nodes are cloud VMs, I will use a spare VM to add as a new node, and remove an old node. So I never run with fewer nodes. For my on-prem cluster, I will do the same with a spare hypervisor VM. It really helps ensure my nodes are ephemeral.
So NixOS, for now, has become a desktop/laptop operating system for me, and whenever I need an execution environment, e.g. a CI runner or a remote shell, I choose "something Nix-like" which is `nix` in a container without systemd.
> Meanwhile, my company is using Nix for everything heavily internally. Everyone gets their dependencies via Nix unless you are like using PAM or something.
Why doesn't your company fund development of nix and its associated ecosystem?
That's the social contract with open-source software. You are not owed a cent for your work. But they're not owed support either.
On the other hand, building an entire company atop experimental software that might explode or cease to exist tomorrow seems so monumentally stupid that the inevitable business failure is the outcome they don't need, but so badly deserve.
>building an entire company atop experimental software that might explode or cease to exist tomorrow seems so monumentally stupid
All things come to an end. Why not ride the wave of a FOSS project, eg by offering support as a business. As long as you are prepared to pivot or close the business when it's no longer needed, why not?
Is it really that complicated? I personally use direnv with nix to have per-project dependency versions installed automatically, and I’ve never had too much trouble. I know that the flake.nix files can become somewhat complicated, but mine have been pretty simple thus far.
Not OP, I’m not really sure what your specific complaints are based on the original comment. They seemed more like general/nonspecific concerns, which left the comment pretty open to interpretation.
I’m here in the thread and I can answer questions or elaborate on things, so if you want to know what I meant you can just ask me and there’s a good chance I’ll respond.
It gets worse when you are not a solo dev, and there's sufficient variety on people's setups. Oops, someone updated a version, and then built things for just their processor, and now I am stuck in a 20 minute compilation loop because some bad pin. Debugging Nix problems like those makes me think that old Gentoo Linux back in 2005 was easy and user friendly.
Updating causing a rebuild isn't really a Nix or even a build tool problem though, is it? cache.nixos.org can't provide everything for every architecture all the time.
With multiple types of machines involved, you want some sort of binary cache setup, ideally automated with CI. There's niks3 [0], celler [1] (a more active fork of attic [2]), hydra [3].
The way I set it up at my shop was that everything would build on your PR, and so by the time it merged, everything was already cached and no one should see a rebuild... at most a download.
Im thinking through this for my team, any previous writeups on it? Or do you mind brain dumping the high level of how you had it setup from a design perspective : D
The first was the "toolkit" repo that had all the manual maintained dependencies and functions, while the second was a managed repo which would have tags pushed to it by the pipeline.
So basically all the repos had a push hook attached to them that would run this centralized dispatch workflow (on Jenkins, but it could be anything). The dispatch job would sanitize the branch name like joey-b/fancy-feature and attach it to the most recent "released version" + devel timestamp, so you'd end up with like 2.25+20260808-12345+joey-b-fancy-feature, and that would be pushed as a floating tag to the nix-ros repo with all the sources from the hundreds of participating repos either locked to the versions set in the top level 2.25 devel branches or to the specified feature branch, so that a given build could pull together multiple same-named branches from across repos. That would be sent off to Hydra, and nix2container outputs were also built that went to simulator based validation.
But the end UI was pretty nice, basically a nix configuration mapped the names to the those repos so after the build was done you could just pull it and "enter the workspace" environment like:
And if you were hacking on the "base" repo itself, it was very easy to pass flags like --override-input base=ros-base#some-ref or path/to/local for quick iteration.
Anyway, as I say, I'm obviously proud of what was achieved, particularly in a pre-LLM world, and the experience of building this has given me many of pg's blub experiences over the years, where I look at the ways that other build and packaging systems solve these problems and think yes, yes I can see how that works, but also, I have experienced a world where in exchange for some relatively minor strictness tradeoffs, the set of problems that that is solving never had to exist in the first place.
Awesome, thanks for taking the time to put this together, that really is impressive pre-LLM. We wont be at this level for a while but its great to have resources to look at for examples of others have solved things.
That's already the case in determinate-nix. Flakes do have big problems though - try cloning a big data project with GBs of data and see how much you love flakes when it copies it to the store every time you run `nix run .#analysis`.
I don’t have all of the details, sorry, but PAM is a bunch of .so that are dlopen'd and if you mess them up you lose access to your system pretty damn quick. I would tell people to just use the system libc but I don’t know the specific failure modes for using libc via Nix. Using system libc = building your project outside of Nix.
There could be similar issues with NSS but I think more people are ready to bypass NSS altogether.
It has to do with installing packages that use PAM to e.g. validate user passwords (e.g. display managers, screen lockers). So there is a system PAM with its configuration, but making a program packaged with nix respect that system PAM config is not as easy as just linking with libpam from nixpkgs.
Yes, each rom bit can be a transistor or even a diode with a decoder circuit. Simplest Dram cell is capacitor+transistor - and you need a clock, refresh circuit etc.
Someday, I imagine model weights could even be encoded as analog resistors (memristors or similar) for even greater density
I still get to control whether other people can see the session, but I don’t lose it.
I don’t get the “unprofessional” argument. This is attribution. Attribution is professional. If you don’t want it, you turn it off or rewrite the commit messages. If you are having Claude write the commit messages FOR YOU and you are NOT READING THEM then that’s what’s unprofessional. I am honestly kind of shocked and disappointed by how upset people are by this.
reply