Andrew Nesbitt has a good write [0] up on why using Git as a database is a bad idea

[0] https://nesbitt.io/2025/12/24/package-managers-keep-using-gi...

An example:

"I’ve seen Grab’s hunger. I’ve felt it. I have it. This space is win or die. They will fight to the death, and I am with them. This company, with some 3000 employees I think, is more unified than I’ve seen with most 5-person companies. This is the kind of focused camaraderie, cooperation and discipline that you typically only see in the military, in times of war.

Which should hardly surprise you, because that’s exactly what this is. This is war.

I am giving everything I’ve got to help Grab win. I am all in. You’d be amazed at what you can accomplish when you’re all in."

This is the writing of someone planning to make a capstone career move instead of leaving in 18 months. It's not the worst thing to do (He says he left b/c the time difference to support a team in SE Asia was hard physically, and he's getting older) and I support taking big swings. I'm just saying Yegge's writing has a pattern.

Crypto and what Yegge is doing with $GAS is dangerous because if the token price crashes and people betting their life savings think he didn't deliver on his promises... I like Steve personally which is why I'm saying anything.

Now, Yegge's writing tilts towards the grandoise... see his writing when joining Grab [1] and Sourcegraph [2] respectively versus how things actually played out.

I prefer optimism and I'm not anti AI by any means, but given his observed behavior and how AI can't exacerbate certain pathologies... not great. Adding the recent crypto activities on top and all that entails is the ingredients for a powder keg.

Hope someone is looking out for him.

[0] https://courses.cs.washington.edu/courses/cse452/23wi/papers...

[1] https://steve-yegge.medium.com/why-i-left-google-to-join-gra...

[2] https://sourcegraph.com/blog/introducing-steve-yegge

I actually use txtar with a custom CLI to quickly copy multiple files to my clipboard and paste it into an LLM chat. I try not to get too far from the chat paradigm so I can stay flexible with which LLM provider I use

Comments URL: https://news.ycombinator.com/item?id=35527661

Points: 2

# Comments: 0

Main challenge is the value of the nixpkgs repo is enormous, and that looks tightly tied to Nix the language and its implicit constructs. I think instead of an FDI one would have to provide a true competitor that is more attractive on multiple dimensions like:

- reworking Nix as more a modular architecture (see Tvix: https://tvl.fyi/blog/rewriting-nix)

- Tackling a package repo and Nixos equivalent with day 1 reproducibility (not just repeatability) like https://reproducible-builds.org/

- Better UX experience on the "entrypoints" of Nix like home-manager and dev-shell flakes - I think CUE has some nicer language features for this and does not require figuring out derivation generation, just referencing the existing nixpkgs set

Considering the tight integration between Nix language v. Nixpkgs v. Nix program I mostly see CUE usable to generate data files but would eventually need to be consumed in a .nix config at some point

Comments URL: https://news.ycombinator.com/item?id=23145049

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=23070503

Points: 2

# Comments: 0

[0] https://danwang.co/how-technology-grows/

I am fairly comfortable with Linux as a user for things like understanding processes, ports, key files and utilities, etc. The way I understand how to model abstractions like containers is to know the various OS primitives like cgroups, changing root, network isolation. Once one sees how those pieces come together to create the container abstraction, they can be mapped to the system calls provided by the OS. Usually they also have utilities bundled (like `chroot`) to interface with those primitives as an operator.

[0] https://github.com/bitnami/kubecfg

[1] https://kustomize.io/

Comments URL: https://news.ycombinator.com/item?id=21546053

Points: 4

# Comments: 1