What changes were needed in Half-Life? Quake seemed okay enough to modify though it was rushed and getting close to what was possible with the hardware at the time.
Yeah this - I got one of these emails someone sniffing around my GitHub not that long ago and it wasn't immediately obvious that it was a scammy recruiter, so I responded to sound out if they were actually interested in one of my projects. Got the same generic response about let's work together on something so I didn't respond.
I'm largely happy with GitHub though for public GitHub at least, search is now terrible - it doesn't seem to return anything when not logged in and if you are logged in the filtering options are limited (this was the case mid last year anyway - maybe it's improved but I've given up trying to use the web search).
Sounds about right. One of Australia's big four banks had the online banking password requirement of exactly six characters for a long time - for similar reasons I assume.
Right. GitHub started as and still is that "social coding platform" from 2008 inspired by the then-novel growth hacking of that era understood and demonstrated by Facebook—where it wasn't enough to host, say, your user's LiveJournal blog, and their friends might sign up if they wanted, and that was that. No, rather, you host your users' content but put it inside a closed system where you've erected artificial barriers that make it impossible to do certain things unless those friends are actively using the platform, too.
GitHub could have been project hosting and patch submission. It's the natural model for both the style of contributions that you see most on GitHub today and how it's used by Linux. (Pull requests are meant for a small circle of trusted collaborators that you're regularly pulling from and have already paid the one-time cost to set up in your remotes—someone is meant to literally invoke git-pull to get a whole slew of changes that have already been vetted by someone within the circle of frequent collaborators—since it is, after all, already in their tree—and anyone else submits patches.) Allowing simple patch submission poses a problem, though, in that even if Alice chooses to host projects on GitHub, then Bob might decide Gitorious is better and host stuff there even while remaining friendly and sending patches to Alice's GitHub-hosted project. By going with a different, proprietary pull request system and forcing a clunky forking workflow on Alice and Bob, on the other hand, you can enforce where the source of the changes are coming from (i.e. another repo hosted on GitHub). And that's what they did.
I’m speculating here, but I think this is at least a plausible explanation. There is no guarantee that the pull request will be accepted. And the new commit has to live somewhere. When you require a fork, the commit is stored in the submitter’s version. If you don’t require the fork, the commit is stored somewhere in the main project repository. Personally, this is something I’d try to avoid.
I don’t know how the Agit-flow stores the commit, but I assume it would have to be in the main repo, which I’m happy to not be used for random PRs.
Requiring forks makes it more convoluted for simple quick pushes, but I can see why it would be done this way.
I suspect the real answer is that’s the way Linux is developed. Traditionally, the mai developers all kept their own separate branches that would be used track changes. When it was time for a new release, the appropriate commits would then be merged into the main repository. For large scale changes, having separate forks makes sense — there is a lot to track. But, it does make the simple use-case more difficult. Git was designed to make the complex use-cases possible, sometimes at the expense of usability for simpler use cases.
Australia recently locked under 16s out of social media and it seems like the social media companies used heuristics to determine if accounts were owned by under 16s... so I assume Discord will do something similar.
I'm in Australia and have not been prompted to verify my identity for any service (I'm assuming that one of the heuristics is average age of "friends" but I have no idea).
Yep, some stakeholder wants a pen-test or an audit so you do it and address the findings to keep them happy. Going through it now at work - bunch of silly findings because the pen testers know they don't get paid to send back an empty report and tell you everything is fine.
reply