The wording in the declaration may be a bit romanticized. But the points are valid:
Is an 80 year old unsolved problem maybe unsolved because it was never prioritized? Some problems stay unsolved because few people consider them worth working on.
Who is going to validate the results? Or do we skip that, with the risk of flooding the literature and collective understanding with unverified proofs?
Also interesting to think about: could a single system be generally intelligent, or is a certain bias actually a power. Can we have billions of models, each with their own "experience"
I think both the views have their merits. In my mind the hardware vs software analogy for weights vs context holds better because in most modern computing systems, the hardware is fixed and the software changes. What the system can do efficiently, in practice, is a function of both the limitations/capabilities of the hardware and the software their respective capability ceilings.
The brain theory also kind of says the same thing, but it's hard to say what stays fixed vs changes with experience in the brain ig.
Thought experiment: strip a forge down to what plain Git can't do: identity (who?), attestations (signed claims about a ref or actor), and policy (do these claims allow this ref update?).
With just those primitives, CI is a service that emits "ci/tested." Review emits "review/approved." A merge controller watches for sufficient attestations and requests a ref update. The forge kernel only evaluates whether claims satisfy policy.
Vouch shifts this even further left: attestations about people, not just code. "This person is trusted" is structurally the same kind of signed claim as "this commit passed CI." It gates participation itself, not just mergeability.
All this should ideally be part of a repo, not inside a closed platform like github. I like it and am curious to see where this stands in 5 years.
Inside the repo as metadata that can be consumed by a provider, like GHA config in .github/. Standardized, at least as an extension like git lfs so it's provider independent. Could work! I've long thought effective reputational models are a major missing piece of internet infrastructure, this could be the beginning of their existence given the new asymmetric threat of LLM output, combined with mitchellh's productivity and recognition.
Sure, but I don't see that as a big deal. It comes down to the fact that git does (interactive) rebases and some merges in the working tree and not in memory. If it is able to do it in memory, then you also don't need to squash, but it needs a point where it could checkout conflicts, without altering data. If you like it to be automatic, you can always set rebase.autoStash or merge.autoStash.
As for effect on the workflow, you can just continue to work and commit and then call autosquash in two weeks, when your about to merge. This also has the benefit, that Git (by default) only alters commits nobody has used yet.
It's not a trade-off of clarity just to save developers some extra typing. It's actually improving the clarity by bringing the thing you care about to the foreground: the getting started page having a table of contents with specific items.
I wouldn't dare say XML is better in this regard, but a good reason to be conservative with the use of annotations is exactly that cmd+clicking them doesn't easily lead to where the behavior is implemented.
