GitLab Moves on from Master/Slave Terminology – InApps is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn GitLab Moves on from Master/Slave Terminology – InApps in today’s post !
Read more about GitLab Moves on from Master/Slave Terminology – InApps at Wikipedia
You can find content about GitLab Moves on from Master/Slave Terminology – InApps from the Wikipedia website
If the last year of spending far too much time online has taught me nothing else, I’ve learned that time reading the comments of anonymous internet strangers is the biggest possible waste of time, and this particular topic is an outstanding example of that. If you’re having a good day and feel like ruining it, just head on over to GitLab’s tweet announcing it would be changing the default branch terminology from “master” to “main” and click through all of the responses.
The indignant outrage and insistence upon using the “master/slave” dichotomy is real, my friends.
Me just laughing my ass off at all the people whining and crying because @gitlab has changed it’s default branch for *NEW* branches from master to main.. and all those that cried about when @github did it and said they’d move to Gitlab because of it #github #gitlab
— Robert McKenzie (@m1xzg) March 11, 2021
GitLab is just the latest to join the ongoing trend of getting rid of these old terms, with Atlassian’s BitBucket making the move last June, and GitHub following suit a few months later. The git project’s efforts at doing the same, meanwhile, are ongoing. As GitLab outlines in its blog post on the change, the terminology comes directly from Bitkeeper, a distributed source management system that preceded git by about five years, although it also follows an even earlier naming tradition among various systems, from hard drives to databases to automotive braking systems. The move away from this tradition has been ongoing, not only in source control systems, but also among other technology solutions, such as the Python programming language.
In computer argot, “master/slave” represents two entities, in which a “slave” takes all its commands from another entity, “the master.” Like a lot of computer terminology, these terms were probably chosen arbitrarily, because they are metaphorically descriptive. But they recall the abhorrent act of slavery, in which one human could “own” another.
In an Internet Engineering Task Force discussion document, Niels ten Oever and MalloryKnodel put it best when they asserted that “Master-slave is an offensive metaphor that will and should never become fully detached from history. ”
If you’d like a bit more reading on the general topic, then look no further than our own pages from just last year, when Jennifer Riggins argued that words, in fact, matter. A brief excerpt:
“When looking to make a difference, words can leave an impact. Because words do matter. Entire social media are born out of an obsession with semantics. Language is what defines us as human beings.
So when a language sees a change, it’s a sign of something more. Because, whether it’s books or code, words leave a legacy. Word choice online is akin to statues on-site — they are often chosen by only a few and become outdated and rusty if not reconsidered regularly.”
As Riggins notes in her piece, tech has a bit of a diversity problem, and that problem is beyond evident when looking at the aforementioned Twitter comment thread.
And as for the details of GitLab’s move away from the terminology in question, the default branch name changes will be coming to GitLab.com and self-managed instances, starting with GitLab 13.11 which arrives on April 22, 2021. At first, the change will ship under a feature flag, though this will be removed a month later, and new projects will use the default name of “main” moving forward. The GitLab project itself will change its own repository branch names as well at this time.
Happy to help solve problems with CI configs. For sharing them, please join https://t.co/g5eD97xUqj 🙂
Your current projects with a committed .gitlab-ci.yml will stay as is.
— Michael Friedrich, a taste of austria (@dnsmichi) March 11, 2021
This Week in Programming
- Gophers Sure Do Love Them Some Go: The results of the 2020 Go developer survey are out and, surprise surprise, an overwhelming majority of respondents — 92% of the 9,648 responses — said that their overall satisfaction with the language was high. Similarly, 81% said they felt productive in Go in less than three months, with nearly as many (76%) saying they use the language at work. As for use cases, the survey finds that Go continues to be heavily used for APIs, CLIs, web, DevOps and data processing. If you’re wondering where Go is lacking, it seems that, on a community level, underrepresented groups tend to feel less welcome in the community. On a technical level, just 26% said they felt Go was lacking the language features they needed, with 88% of those respondents citing, you guessed it, the soon-to-be-added generics as a critical missing piece.
- GitHub Discussions Go Private: GitHub Discussions, the collaborative communication forum for GitHub repositories and communities, is now available for private repositories. Announced in December 2020, the feature was initially offered in public beta for public repositories and after what the company said was rapid growth “with tens of thousands of open source communities and discussions created,” the feature is now going public beta for private repositories. Already, GitHub said the feature is being used for boot camps and classrooms, and at Stripe to build a developer network. Getting started using the feature is as easy as enabling Discussions under “Features” in the repository settings.
tech: “this is a golden age of automation, machine learning, developer productivity and great user experiences.”
also tech: “you’re on mute”.
— RedMonk (@redmonk) March 1, 2021
- GitHub Actions Gets a Visual Studio Revamp: There are some new GitHub Actions tooling in Visual Studio to try out, following the addition of Actions in Visual Studio last September and the ensuing feedback. After the initial release, the Visual Studio team worked with the community and found there was some confusing UI and an insufficient summary page, and says that “as a result, we’ve made some changes to the experience to bring it more in line with this feedback and also with our vision of even more potential integration in the future.” With this latest update, you can expect a redesigned summary page, a new status section that makes clear the likely next steps, and the ability to commit and push the workflow with a single click. On this last point, that single click will commit the workflow file locally, push the workflow to remote, create the necessary GitHub secrets required by the workflow to execute successfully, and finally establish a link between the GitHub repo and the Azure instance used for deployment. If you have other updates you think need addressing, the team requests feedback via the Developer Community.
- Rooting out Rootkits with Azure Trusted Launch: Microsoft has announced a preview of Azure Trusted Launch for virtual machines, a feature that it says can help Azure customers prevent bootkit and rootkit infections, which are malware types that run with kernel-mode privileges and can be “extremely difficult to detect and almost impossible to remove.” With Azure Trusted Launch for virtual machines, administrators can “deploy virtual machines with verified and signed bootloaders, OS kernels, and a boot policy that leverages the Trusted Launch Virtual Trusted Platform Module (vTPM) to measure and attest to whether the boot was compromised,” and everything can be seen and enabled in Azure Security Center. Currently, Trusted Launch is in preview within selected Azure regions on the most commonly used operating systems images, with more coming soon. For more information, check out the docs.
Ok I will say this one: 90 percent of buildpacks and Dockerfiles are trying to be as good as ‘git push heroku’ was in 2014. https://t.co/Ij6CGuD4vN
— Dan Lorenc (@lorenc_dan) March 9, 2021
- Google Summer of Code Opens Up With 200+ Mentor Orgs: With spring just around the corner (at least here in the hemisphere that Google calls home), the Google Summer of Code is just around the corner, with student applications opening up on March 29, and they have announced the 2021 mentoring organizations, 31 of them new this year. Among the more than 200 organizations there are a few notable cloud native projects, including the Cloud Native Computing Foundation, the Continuous Delivery Foundation, and Ceph, as well as many others, such as Ruby, Git, ReactOS, GitLab, the Linux Foundation, the Python Software Foundation, and more. If you haven’t heard of Google’s Summer of Code, check out the FAQ or their video describing exactly what is GSoC. It might be perfect for that young aspiring coder in your life.
the modern tech industry is basically folks just endlessly remaking remakes of heroku
— Always Miso (@monkchips) March 8, 2021
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.