It’s a multi-decade tradition that goes back to Project Athena, a collaboration between MIT, DEC, and IBM. X11’s reference implementation has been the main flag-bearer of the license, propagating it forward to many freedesktop.org projects.
And here we see the self-Godwin in the wild. Masterful play, sir.
Neither the CFO nor CEO are saying that Google ought to be not broken up. They are saying that Mozilla existentially depends on Google. This is actually more of a central point in the lawsuit than you think; in the original complaint, part 6 of the background is about revenue-sharing agreements (RSAs) between Google and various other companies who would normally compete in search, browsers, and other venues. That is, nobody is disputing that:
Today, Google has RSAs with nearly every significant non-Google browser (other than those distributed by Microsoft) including Mozilla’s Firefox, Opera, and UCWeb. These agreements generally require the browsers to make Google the preset default general search engine for each search access point on both their Web and mobile versions.
If Mozilla did want to petition the court, then they are welcome to file as amici, but they haven’t! Nor have any court filings included a reference to the CFO’s testimony so far, although to be fair the testimony isn’t yet available to read. There is no evidence that Mozilla will stand in the way of whatever the court decides to do with Google. Rather, in their post, the CEO is asking lawmakers to figure out some way to ensure that the browser market remains competitive:
Mozilla calls on regulators and policymakers to recognize the vital role of independent browsers and take action to nurture competition, innovation, and protect the public interest in the evolving digital landscape.
Courts aren’t regulators or policymakers. The complaint before the court is not the same as the underlying principles of antitrust which motivated the complaint. A request to improve the future is not the same as a request to forestall the present.
“For the record, I still don’t like this particular face-eating incident.” As if you aren’t a leopard enthusiast. Who cares whether you like something?
You literally attach a license to every comment you post. The rules which make that license effective are the same rules which make Free Software and open-source licenses effective, too. Show some solidarity; you’re part of the community too, and you should feel comfortable making the same demands as the rest of us. When you say that “open source defenders” are distinct from “developers” you are contributing to a schism for the sake of aggrandizing employment and exploitation.
The original workflow, which is still in use today, is git-blame followed by git-show: look up candidate commits, then examine their history individually. This can be accelerated with a GUI; e.g. GitHub and GitLab support blame-style views.
I agree that the UX of existing git commands is not great. They evolved in a particular insular environment – Linux kernel development with heavy mailing-list usage and large multi-headed merges, with occasional pull requests and manual integration testing.
Check out my top-level comment for a link to git’s data model. A data-first approach with blob, tree, commit, and tag can be enlightening. The on-disk format tries to balance integrity, easy manipulation, disk space, and incremental updates; it’s also weakly monoidal, enabling distributed development. Look up the history of Bitkeeper and git; this is “a version control system [designed] from the ground up with documented architecture from the start”! And there are many non-C implementations as a result, like pure-Python dulwich.
A PDF is available here, and analysis from Colyer 2016 is good.
This paper is fascinating in terms of ethnography. Consider: the paper mentions “branch” or “branches” dozens of times, but only says “tree” four times, and every instance is in the phrase “working tree”. The paper never mentions “blob” or “blobs”, “DAG” or “graph” or “poset”. The authors either chose to omit git’s data model, or they don’t know about it. The implication is that the UX and UI don’t reflect the data model, I suppose, but it is a very curious omission.
Now, contrast this with Git’s documentation. When sysadmins teach git, we focus on the data first. git is a kind of database which stores four different flavors of object, and the git UI is merely a collection of commands for programmatically manipulating the database. All of the various UX is purpose-built, on a per-command basis, for development workflows. New commands can be implemented as plain UINX-style executable scripts in any language.
In summary, this paper looks at git as a version-control product, while its developers and users look at git as a version-control framework.
There was a followup paper from a few years later, also with Colyer 2016 analysis; this paper has too many glaring defects to discuss here.
On a personal note, I saw this and am happy to note that science has marched along:
We plan to extend our notation to make it more expressive in the future, but are cognizant of the fact that diagrammatic syntaxes for first order logic have a long and troubled history.
Not long after this paper, ontology logs were figured out, which can be made as expressive as needed for the case of relations; see Patterson 2017.
I mirror some specific repositories of mine to GH specifically so that they will be included in Copilot’s training data. It amuses me when chatbots think that they know Lojban or Metamath, can’t distinguish RPython from Python 2.7, or think that Monte is Mathematica. Some languages, particularly Zaddy, are likely so confusing and have such small corpora that chatbots will never be able to generate them; their inclusion in training data is possibly unhelpful.
No, I don’t keep everything there. In particular Cammy is only publically available via the notoriously unreliable OSDN mirror because I don’t trust folks to understand purity, functions, and category theory.