161 karma · joined December 23, 2013
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...
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
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
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.
In the future I predict we are moving towards a model where we have ways expressively define configuration (CUE) locally which we push to Kubernetes operators [0] which do the heavy lifting to deploy, monitor, and manage/upgrade a defined service that the operator is responsible for.
[0] https://kubernetes.io/docs/concepts/extend-kubernetes/operat...
I was attracted to this style of IaC for awhile as I had my own frustrations with the current 'YAML Engineering' that we have to do. After looking at the space I am bullish on CUE (https://cuelang.org/docs/about/) for IaC. There are some points that these imperative-declarative systems still do not address that are critical for IaC:
- Data validation and constraints. A config should be a structure of fields and what types they should be. If needed they can be further specified into concrete types. In CUE, types are values and multiple field definitions are unified to their most concrete type. For example, if `a: >5` and `a: <10` and `a:7` would unify to`a:7`. `a:11` would not be a valid unfication.
- Deep nested configuration: Configuration are a tree structure that can have values that need to be overridden deep in the structure. Imperative languages rely on functions for abstraction, but that is fragile as you need to basically expose every field as a function parameter at some point. CUE does not have functions but instead relies and templates, constraints, and easy overriding of values deep in the tree to achieve a similar effect.
- External data injection: Most configuration systems need to be able to inject data into the environment to be evaluated at runtime. This usually requires wrapping the tool in another tool in a fragile way. CUE has a scripting layer to allow injecting data into the execution environment without wrapping.
It really is not a small difference.
seize should be cease