Mark Zuckerberg explicitly called out the airpod pairing being closed as unfair in a semi recent interview, maybe he can throw some dollars that way and get it all working nicely in some meta products.
Readit Newsandrewchambers commented on AirPods libreated from Apple's ecosystem github.com/kavishdevar/li... · Posted by u/moonleay
andrewchambers commented on You can't build tcc from Nixpkgs if you are in the UK github.com/NixOS/nixpkgs/... · Posted by u/RGBCube
Was playing around with the idea of p2p source hosting in package trees like nix and did a little weekend package prototype here of my own here:
https://github.com/magnet-linux/magnet-linux
Not really ready for prime time, but I think I have some interesting ideas there at least.
My point isn't really about what is correct or incorrect in this case.
My point is about making it so that you have to actively risk money to push the truth needle in the wrong direction.
I've seen a large number of comments online saying the shooter was a trump supporter - I don't really understand where that information comes from.
I feel like this is the sort of thing a prediction market might be able sort out.
andrewchambers commented on Reichstag Fire Decree (1933) encyclopedia.ushmm.org/co... · Posted by u/KnuthIsGod
Hoping for a polymarket bet so this can be resolved.
Kind of surprised by this take - I use openpilot often and also use claude code.
I kind of consider them the same thing. Openpilot can drive really well on highways for hours on end when nothing interesting is happening. Claude code can do straight forward refactors, write boilerplate, do scaffolding, do automated git bisects with no input from me.
Neither one is a substitute for the 'driver'. Claude code is like the level 2 self driving of programming.
andrewchambers commented on Zlib-rs is faster than C trifectatech.org/blog/zli... · Posted by u/dochtman
Isn't it the case that once you use unsafe even a single time, you lose all of Rust's nice guarantees? As far as I'm aware, inside the unsafe block you can do whatever you want which means all of the nice memory-safety properties of the language go away.
It's like letting a wet dog (who'd just been swimming in a nearby swamp) run loose inside your hermetically sealed cleanroom.
It's more like letting a wet dog who you are watching closely quickly pass from your front door to the shower.
andrewchambers commented on Schemesh: Fusion between Unix shell and Lisp REPL github.com/cosmos72/schem... · Posted by u/cosmos0072
For Janet fans, there's janetsh (https://github.com/andrewchambers/janetsh). Seems very elegant indeed.
Author here - thanks for linking - Unfortunately I didn't have time to continue on this for a long while. I am certainly happy if people get inspiration from any ideas and continue on with it.
andrewchambers commented on Recent results show that LLMs struggle with compositional tasks quantamagazine.org/chatbo... · Posted by u/thm
Oh, we have new letter-number combinations now. That is amazing. I stand corrected.
If you haven't tried using them then I am not sure your opinion on them is any good.
andrewchambers commented on Test-driven development with an LLM for fun and profit blog.yfzhou.fyi/posts/tdd... · Posted by u/crazylogger
One trend I've noticed, framed as a logical deduction:
1. Coding assistants based on o1 and Sonnet are pretty great at coding with <50k context, but degrade rapidly beyond that.
2. Coding agents do massively better when they have a test-driven reward signal.
3. If a problem can be framed in a way that a coding agent can solve, that speeds up development at least 10x from the base case of human + assistant.
4. From (1)-(3), if you can get all the necessary context into 50k tokens and measure progress via tests, you can speed up development by 10x.
5. Therefore all new development should be microservices written from scratch and interacting via cleanly defined APIs.
Sure enough, I see HN projects evolving in that direction.
You don't need microservices for that, just factor your code into libraries that can fit into the context window. Also write functions that have clear inputs and outputs and don't need to know the full state of the software.
This has always been good practice anyway.