> Those people/use-cases don't care about the GIL.
This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.
Perhaps you missed the "What's in it" section while skimming the readme? :)
>Because of folly's fairly flat structure, the best way to see what's in it is to look at the headers in top level folly/ directory. You can also check the docs folder for documentation, starting with the overview.
That doesn't seem very fair. They link a docs folder and an overview document, neither of which require that the user read code to get a good idea of the library's contents.
EternalTerminal[1] was mentioned in a comment below. It supports port forwarding, and other goodies like native scrollback, at the cost of latency on laggy connections (because it doesn't do full terminal emulation). If that tradeoff sounds good to you, try it!
Aside from its merits as a database, SQLite is also a great example of good documentation[0], thorough testing[1], and focused development. It's something that all library maintainers should study and try to learn from.
I don't know if it's correct to characterize Github's model as a power grab. The design of Github definitely pushes things in a more centralized direction, but I think that approach is superior in many cases and it's not purely for profit.
For many projects, having a single "canonical" version is the best experience for both users of the project and developers. Linux is large and important enough that it may make sense to have many different distros running a slightly different set of patches and accept the overhead of managing multiple sources of truth. For smaller projects with more narrow contributor bases, it would be noisy and confusing.
Plus, there's absolutely nothing stopping anyone from taking their Git repos and putting them on another Git host. Or hosting their own. Or using multiple hosts.
Sure, they're doing things to further their own popularity... But it doesn't appear to be at the expense of anyone else.
> I don't know if it's correct to characterize Github's model as a power grab.
The important question would be if Github forks and pull requests are an open protocol or attached to the platform. I’m not aware if I can make a pull request from - say - bitbucket to github. Can I ? Then it’s not a power grab. If not then redefinition of fork/pull request is an extend and extinguish move.
Edit: okay, extinguish is too harsh. GitHub doesn’t want to extinguish git.
I don't really see forks or pull requests as being part of the git protocol. They are part of a workflow- no different than, say "git flow" is a workflow, not part of the protocol of how, why and when branching happens.
Further, github isn't looking to "extinguish" git in any way. Sure, old workflows (emailing patches?) might not be supported, but again, that's something entirely external to git itself.
As these things are all external to git, it makes sense that they're not portable between vendors- they are the vendor's, not git's, features. You're not using them from within git, you're using the vendor's features to interact with git. That's the primary difference between, say, M$FT's EEE of Java or AOL's instant messenger, HTML and other examples.
Extinguish doesn't mean to end, it means to end the open standard. Github would be happy if all git use were Github use, and every user locked in to their service brings that day closer.
In a similar way you could argue that git doesn’t change diff and patch. It just adds a a convenient way to handle patch files. So why open source it? It turns out it’s very useful to have it in software.
The same is true for tracking forks and managing pull requests.
> The important question would be if Github forks and pull requests are an open protocol or attached to the platform.
Attached to the platform, but open. You could do all the work on your feature branch somewhere else, say, your company's gitlab installation, then when it's done, push the branch into your github "fork" and and create a pull request there. I really don't know on which side of an openness line that would fall, you can easily define the line around it either way.
It’s all git, so you can totally do all the development in gitlab, and only touch github when you are ready to make a pull request.
You’d have to run half a dozen commands, including adding new remote and running “hub fork”, but it would likely still be faster than sending an email.
Forks and PRs are UI sugar on top of Git operations, so it's technically open. That said, merging in a PR is an operation that touches 2 repos, with different user privileges, so I feel it would be hard (though not impossible) to make the UI work with multiple services, without adding extra cross-service auth headache.
The best explanation is coincidence, I think. I have direct knowledge of two of the incidents in the past few weeks, and they have completely unrelated causes.
That’s certainly possible. We’re probably still too early to tell, but the innate conspiracy theorist slash pattern-matching part of my brain wants to find a probable connection.
This is not true. The primary funding and motivation for the GIL removal work comes from the numerical computing community. The PEP (https://peps.python.org/pep-0703/) contains direct quotes from folks working on numpy, scipy, PyTorch, scikit-learn, etc. and also practitioners from places like Meta, DeepMind and so on, describing the practical constraints that the GIL places on many workloads.