I love seeing these projects make use of the wide-open namespace/references that git provides (outside of the basic `refs/heads` for git branches and `refs/tags` for tags). It looks like they store the data in the `bugs` namespace [1] (so refs/bugs/foo).
Other projects also make use of alternate namespaces. The oft-forgotten built-in "git notes" puts stuff in the `refs/notes/` namespace (specifically in `refs/notes/commits`). Gerrit uses the virtual `refs/for/` namespace for receiving commits for review, stores project config in `refs/meta/config`, and stores User data in `refs/users/` in a special repo [2]. I'm sure others do interesting things.
Alternate uses of git's DAG model are fascinating.
Yes, this really meant to be some sort of framework for storing entities in git, handle the conflicts, and let you buld easily your own tool (or add more features to git-bug).
Technically you could solve collisions through single indirection convention ie 'refs/manifest' which describes refs used with their "schema", "version" etc. If you want to decorate your repo with something, you'd register it there. This way you wouldn't have to keep global convention registry for different projects not to step on each other.
Could you expand on how you see that working? combining these extensions is what I’m guessing but I’d be super interested in hearing how it might work.
If all information for an asynchronous development process could be stored into git and distributed by it, this would be a very good idea for many projects.
The same way, one could add support for code review (aka PRs), todo list, custom entities that your workflow need (say, tracking documentation or custom requirement) ... It can also be entirely outside of the development process.
This would allow for really native linking between a tracked issue and corresponding commits/branches/tags, for modeling dependencies between issues as part of the git DAG,...
I want to add another one to the author's list, which I think is even more relevant:
Writing.
Story goes, the Celtic druids relied on oral tradition and rejected writing, because they figured relying on writing was a crutch that made them weaker. They're gone now and, because of that choice, most of their culture with them.
Like Assembly to C to Python, as the author points out, LLMs allow us to move up the ladder of abstraction. There are obvious downsides to this, but I expect the evolution is inevitable.
The complaints about that evolution are also inevitable. We lose control, and expertise is less valued. We experts stand to lose a lot, especially if we clutch to the old ways. We're in the midst of a sea-change, we know what we're losing, but we're not sure what we're gaining.
> Story goes, the Celtic druids relied on oral tradition and rejected writing, because they figured relying on writing was a crutch that made them weaker. They're gone now and, because of that choice, most of their culture with them.
Can you help me complete this analogy? By failing to rely on "writing" (read: LLMs), what will fail to be recorded and therefore remembered? Is the idea that if knowledge isn't encompassed by an LLM, in the future it will be inaccessible to anyone?
Sure! I am not the OP, but it seems like the analogy is how being a Luddite and refusing to integrate modern tools leads to being left behind and becoming irrelevant. Another more contemporary example: when intravascular techniques were first being developed, many CT surgeons felt as though those procedures were beneath them and gladly let cardiologists take point for those while they continued to do open procedures. Because of this, they lost a lot of ground in billable procedures, and it negatively affected compensation and demand for CT surgeons. Now, cardiologists can do some minimally invasive valve repairs and ASD closures, which will continue to take business away from CT surgeons. If you refuse to adapt to new technologies, you will be left behind.
when I was a kid, I was frustrated by the difficult choices of colony placement: "here, I get ore, but one tile over there's bonus food!" and wished I could create a "perfect" map.
This was possible in the Civ IV: Colonization version! However, it appears that the more productive you are, the bigger the Royal army is. I wish I understood the precise mechanism of that.
I think in normal colonization the king just funded the army from the taxes you paid. So, the more goods you sold him the bigger the army. If you traded with the natives instead it wouldn't grow as fast.
Is there actually any hard data out there comparing the NPU on the Google Tensor G4 vs the Apple A18? I wasn't able to quickly find anything concrete.
I mean Apple has been shipping mobile NPUs for longer than Google (Apple: since A11 in 2017, Google: since 2021), and are built on (ostensibly) a smaller silicon node that Google's (G4: Samsung SF4P vs A18: TSMC N3E). However, the G4 appears to have more RAM bandwidth (68.26 GB/s vs 60 GB/s on A18).
Google has been shipping custom NPUs since the Pixel 4 in 2019. Prior to that, Google phones just used off the shelf SOCs from Qualcomm, with 2018's Pixel 3 using the NPU in the Snapdragon 845. Android first shipped NNAPI in Android 8.1 in 2017, with acceleration on various mobile GPUs and DSPs, including the Pixel Visual Core on the Pixel 2. Google has shipped more on-device models so far, but neither company has a moat for on-device inference.
Also, I loved this interview/discussion between Kay & Joe Armstrong, inventor of Erlang, where the topic comes up again (because Erlang is also a lot about messaging between agents)
Tangentially, there remains a test electric car gathering {r,d}ust in one of Google's parking lots, from the early years, that I believed "belonged" to Sergey. IIRC it's at 37.417743, -122.082186
I wonder if they'll ever move it out, put it in a museum or something.
Apparently still there, but mostly hidden under a tree (as seen by Google Maps). In a spectacular irony, Google has no street view of their own parking lot.
I suppose one could periodically check for the presence of this artifact, and if it were to suddenly vanish, that would suggest that Google has decided to build another electric car. It is, after all, legacy IP, best hidden away.
Other projects also make use of alternate namespaces. The oft-forgotten built-in "git notes" puts stuff in the `refs/notes/` namespace (specifically in `refs/notes/commits`). Gerrit uses the virtual `refs/for/` namespace for receiving commits for review, stores project config in `refs/meta/config`, and stores User data in `refs/users/` in a special repo [2]. I'm sure others do interesting things.
Alternate uses of git's DAG model are fascinating.
[1] https://github.com/git-bug/git-bug/blob/bd936650ccf44ca33cf9...
[2] https://gerrit-review.googlesource.com/Documentation/config-...
reply