IIRC Go had to deal with a bunch of issue related to their initial source based package management system. The URL imports remain, but I believe fetches are served through the pkg.go.dev proxy now.
Andrew Nesbitt has a good write [0] up on why using Git as a database is a bad idea
I should be specific. I think the technical analysis is reasonable and I actually enjoy someone staking on a big vision, which is why I saved these pieces.
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.
I'm developing concern for Steve. He's been a well known developer and writer in the industry for years now (See his popular 'Google Platforms Rant' essay from years ago) [0].
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.
One nice thing if you work on the B2B software side - end of year is generally slow in terms of new deals. Definitely a good idea to schedule bug bashes, refactors, and general tech debt payments with greater buy in from the business
Does this use the txtar format created for developing the go language?
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
Yes, derivations are the main primitive to target in an agnostic way
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:
- 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
Dan Wang explores this idea in 'How Technology Grows' [0]. To summarize, he asserts that the main downside of offshoring is the loss of process knowledge (the tacit knowledge that is learned by doing and transmitted through culture).
I enjoyed this blog post. Julia does a great job of distilling an idea down with examples.
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.
Author here. The closest thing to borgcfg in Kubernetes would be kubecfg [0]. It is based on jsonnet, the open source equivalent to GCL. The official blessed solution right now would be kustomize [1] since it is directly integrated into kubectl. I categorize both in the article with my evaluation as solutions.
I agree, a package manager is designed for installing a graph of versioned (effectively immutable) artifacts like a binary or code package. Kubernetes is built to run services, which are not static but continuously running and react to inputs. Services need monitoring and self-healing to ensure they are healthy and operational.
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.
I highly recommend using CUE for the configuration part. I may not have mentioned this, but CUE is a superset of JSON, You can write the config in CUE then compile the config into a final unified JSON file to be fed into another system. You can separate the orchestration and configuration of a system through an actual data transport system.
I consider this new tool being promoted here (Adapt) to be in a similar space to Pulumi (https://www.pulumi.com) which allows for using full featured imperative programming languages for defining infrastructure. The key idea is that the writer can do anything in the code (unless sandboxed) but must return a data structure that will then be passed to the a system to actually orchestrate the cloud provider APIs for you. I can see some potential of using react features for IaC, like leveraging lifecyle hooks for state changes and the React Context API for threading state deep into subtrees of the data structure.
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.
Now that Git Virtual File System (VFS) is coming to GitHub, I think we shall see an uptick in monorepo adoption. Though what I said early about compatible tooling still applies. The repo style affects so much of the tooling, from Continous Integration, deployment, building, versioning, etc.