"Russian software developers are reporting that their GitHub accounts are being suspended without warning if they work for or previously worked for companies under U.S. sanctions, writes Bleeping Computer: According to Russian media outlets, the ban wave began on April 13 and didn't discriminate between companies and individuals. For example, the GitHub accounts of Sberbank Technology, Sberbank AI Lab, and the Alfa Bank Laboratory had their code repositories initially disabled and are now removed from the platform.... Personal accounts suspended on GitHub have their content wiped while all repositories become immediately out of reach, and the same applies to issues and pull requests.

Habr.com [a Russian collaborative blog about IT] reports that some Russian developers contacted GitHub about the suspension and received an email titled 'GitHub and Trade Controls' that explained their account was disabled due to US sanctions. This email contains a link to a GitHub page explaining the company's policies regarding sanctions and trade controls, which explains how a user can appeal their suspension. This appeal form requires the individual to certify that they do not use their GitHub account on behalf of a sanctioned entity. A developer posted to Twitter saying that he could remove the suspension after filling out the form and that it was due to his previous employer being sanctioned.
A GitHub blog post in March had promised to ensure the availability of open source services "to all, including developers in Russia." So Bleeping Computer contacted a GitHub spokesperson, who explained this weekend that while GitHub may be required to restrict some users to comply with U.S. laws, "We examine government sanctions thoroughly to be certain that users and customers are not impacted beyond what is required by law." According to this, the suspended private accounts are either affiliated, collaborating, or working with/for sanctioned entities. However, even those who previously worked for a sanctioned company appear to be suspended by mistake.

This means that Russian users, in general, can suddenly find their projects wiped and accounts suspended, even if those projects have nothing to do with the sanctioned entities.

Last week 69-year-old Richard Stallman gave a 92-minute presentation on the state of the free software movement. Stallman covered numerous topics, but also added as an aside at one point: Ubuntu of course is a non-free distro, and I wouldn't recommend that anyone use it. Some important packages are now distributed only through their non-freedom-respecting package system, and not as Debian packages. So it's even harder than before to get any freedom out of an Ubuntu installation.
But Stallman also sees a larger issue: Another area where we have problems is there are several languages which come with a package library -- basically people post packages in them. And that might be fine if they had a good criterion for the licensing of the libraries people upload into those sites -- but they're not developed by free software activists, and they don't have such a criterion. There are non-free packages in those libraries too.

Now, some of them make it possible to find out whether a library is free. Some of them, it's difficult. Sometimes -- yeah, you could probably look at the source code and see what licenses are in it, and then you could look up those licenses in GNU.org/licenses/license-list.html and see if all those licenses are free... The problem is, they don't help you. At the very least they should make it easy to say, "Show me only the free packages." And then, "Show me only the GPL-compatible packages, because I'm writing a GPL-covered program, and I can't use the libraries that are not GPL compatible. And I certainly won't ever think of using a non-free library."

They're not interested in helping people move forward in freedom. And so we need people to write front-ends for those package archives, which will show only the freely-licensed packages, and which can be asked to show which ones are GPL-compatible, or show only those. This way they will be usable easily by the free software community. If you like one of the languages that has this problem, please show your appreciation for that language by reconciling its use with maintaining freedom.
And this leads Stallman to a related setback for the free software movement: the containers themselves that are packaging some programs with the libraries they need: The old way of doing this was you would make sure that your program said which versions of libraries it was compiled to work with, and in the source code you'd use something like Autoconf so that it could work with the various library versions. And this way you could build the program for a wide variety of free operating systems and versions of them.

Well, that's some work, so some developers, they release a free program -- not all of them release free programs, but some of them do release free programs -- using containers. And the container has one set of libraries in it. And how do you really know what's in there? It's not straightforward to verify that all the libraries in the container are free, and a lot of people won't realize that they should even think about it. So the use of containers, as they are implemented nowadays by people who are not free software activists and are not particularly concerned with this question, is an obstacle to verifying that you're installing free software.

Well, maybe some of these container systems could be improved, or maybe another one could be designed to solve these problems. If a container packaging system were designed by people who care about freedom, they might find good ways to satisfy this goal, as well as others. So it's something you could possibly work on.

Richard Stallman celebrated his 69th birthday last month. And Wednesday, he gave a 92-minute presentation called "The State of the Free Software Movement."

Stallman began by thanking everyone who's contributed to free software, and encouraged others who want to help to visit gnu.org/help. "The Free Software movement is universal, and morally should not exclude anyone. Because even though there are crimes that should be punished, cutting off someone from contributing to free software punishes the world. Not that person."

And then he began by noting some things that have gotten better in the free software movement, including big improvements in projects like GNU Emacs when displaying external packages. (And in addition, "GNU Health now has a hospital management facility, which should make it applicable to a lot more medical organizations so they can switch to free software. And [Skype alternative] GNU Jami got a big upgrade.")

What's getting worse? Well, the libre-booted machines that we have are getting older and scarcer. Finding a way to support something new is difficult, because Intel and AMD are both designing their hardware to subjugate people. If they were basically haters of the public, it would be hard for them to do it much worse than they're doing.

And Macintoshes are moving towards being jails, like the iMonsters. It's getting harder for users to install even their own programs to run them. And this of course should be illegal. It should be illegal to sell a computer that doesn't let users install software of their own from source code. And probably shouldn't allow the computer to stop you from installing binaries that you get from others either, even though it's true in cases like that, you're doing it at your own risk. But tying people down, strapping them into their chairs so that they can't do anything that hurts themselves -- makes things worse, not better. There are other systems where you can find ways to trust people, that don't depend on being under the power of a giant company.

We've seen problems sometimes where supported old hardware gets de-supported because somebody doesn't think it's important any more — it's so old, how could that matter? But there are reasons...why old hardware sometimes remains very important, and people who aren't thinking about this issue might not realize that...

Stallman also had some advice for students required by their schools to use non-free software like Zoom for their remote learning. "If you have to use a non-free program, there's one last thing... which is to say in each class session, 'I am bitterly ashamed of the fact that I'm using Zoom for this class.' Just that. It's a few seconds. But say it each time.... And over time, the fact that this is really important to you will sink in."

And then halfway through, Stallman began taking questions from the audience...

Read on for Slashdot's report on Stallman's remarks, or jump ahead to...

• How far should copyright law go?
• That NPM package that deleted files in Russia
• Does the free software world need more videogames?
• Stallman's upcoming manual for 'GNU C'
• Free Software's role in protecting our planet's environment

An anonymous reader quotes a report from Yahoo Finance: A single mom who signed up for a $30,000 income-share agreement at a for-profit coding bootcamp has filed a lawsuit in California, alleging she entered the agreement under "false pretenses." Redmond, Washington-based Emily Bruner is suing Bloom Institute of Technology, formerly known as Lambda School, and its head Austen Allred, alleging they misrepresented job placement rates, operated without a license during her course of study, and hid the "true nature" of the school's financial interest in students' success. "I feel like Lambda misled me at every turn -- about their job placement rates and about how they would prepare us for jobs in the field. I was even more shocked when I found out they were operating illegally," Bruner said in a press release. "I took time away from my young son and other career opportunities to participate in a program based on lies," added Bruner, who's seeking a refund from the school as well as monetary damages. "While I'm thankful I opted out of arbitration so I can have my day in court, I wish my classmates who were also misled could be here with me."

Income-share agreements, known as ISAs, are an alternative type of student loan financing where a borrower receives a loan, then pays a percentage of their income after graduation. The terms of an ISA depends on various factors, such as their major topic of study and projected future earnings. [...] Bruner, the plaintiff, signed her ISA on June 29, 2019 when she was living in New Mexico because she could not pay the full tuition amount to attend Lambda full-time, according to the lawsuit. She says she moved back home to North Carolina to live with her parents, who would help her take care of her baby. She took out $30,000 for its six- and 12-month computer science programs offered by San Francisco-based Lambda, according to the complaint. Bruner started school in September 2019 and finished the following August. Students at Lambda agree to pay 17% of their post-Lambda salary for 24 months once they make more than $50,000 a year, according to the lawsuit.

After graduating, she couldn't find a job as a web developer or a software engineer, and was, according to the lawsuit, told by employers that "she did not have the technical skills for the job, and that her education had not prepared her to be a web developer." Bruner ended up going back to program management, a field she was working in prior to attending Lambda. In the lawsuit, she alleged that Lambda misrepresented the fact that it did not have necessary approval from the state regulator, the California Bureau for Postsecondary Education. She also alleged that the school falsified and misrepresented the school's job placement rates. Finally she also alleged that the school hid the true nature of its financial interest in students' success -- specifically by "falsely representing" that Lambda only was compensated when students found jobs and earned income.

Developer burnout is helping to drive an exodus of software developer talent from organizations, as part of a larger trend known as the Great Resignation, according to a report released on April 13 by MuleSoft, which is a division of Salesforce. From a report: The MuleSoft report was based on research conducted by Vanson Bourne in February 2022 across the U.S., U.K., France, Germany, and Australia. Eighty-six percent of respondents indicated that in the last two years it has become increasingly difficult to recruit software developers. One of the reasons why is the larger macroeconomic trend of the Great Resignation, where employees are leaving their employers en masse during the COVID-19 pandemic as they seek a better work-life balance.

Burnout is also a large challenge for developers, according to the report. The top causes of developer burnout are increasing workloads and the challenges of learning new skills to adapt to emerging technologies. "The pandemic was a massive accelerator for the need of digital tools," Matt McLarty, global field CTO and vice president of the Digital Transformation Office (DTO) at MuleSoft, told ITPro Today. "Non-technology companies were ultimately forced to become technology companies overnight, and we saw nearly every organization require developers to help them achieve these new goals on high-pressure deadlines, all at once."

Long-time Slashdot reader theodp writes: Tech-backed Code.org reports that as part of efforts to provide scaled human-centered education, the Stanford AI Lab analyzed 711,274 solutions to interactive block-based Code.org programming assignments submitted by 3rd and 4th grade students to develop AI-based solutions for automatically grading student homework. The research project received funding from LinkedIn founder and VC Reid Hoffman, who is coincidentally a $1+ million supporter of Code.org, which provided the student data.

Autograding systems are increasingly being deployed at all levels of education to meet the challenge of teaching programming at scale. So, will AI make Computer Science grader and undergraduate teaching assistant jobs obsolete?

"Enabling developer productivity has become a key vector in every organization's success," writes Matt Asay at InfoWorld — not a nice-to-have feature but a must-have.

"Which is why, perhaps ironically, the best way to set your developers free may actually be to fetter their freedom." The more developers mattered, the more everyone wanted to cater to their needs with new software tools, new open source projects, new cloud services, etc. This meant lots of new developer choice and associated freedom, but that wasn't necessarily an unalloyed good. As RedMonk analyst Steven O'Grady noted in 2017, "The good news is that this developer-driven fragmentation has yielded an incredible array of open source software. The bad news is that, even for developers, managing this fragmentation is challenging."

Can one have too much choice? Yep.

It's long been known in consumer retail, for example, that when there is too much choice, "consumers are less likely to buy anything at all, and if they do buy, they are less satisfied with their selection." Turns out this isn't just a matter of breakfast cereals or clothing. It also applies to developers building enterprise software. InfoWorld's Scott Carey writes that "complexity is killing software developers." He's right. But what can be done?

In a conversation with Weaveworks CEO Alexis Richardson, he related how self-service development platforms are reemerging to help developers make sense of all that open source and cloud choice. By giving developers "a standard, pre-approved environment in which the effort to create an app from an idea is minimal," he explained, it allows them to "focus on innovation not plumbing."
"Done right, a little bit of constraint goes a long way..." Asay argues, touting the benefits of PaaS (platform as a service) self-service development platforms. ("Enterprises that want to give their developers the freedom the cloud affords can couple it with just enough constraint to make that freedom useful....")

Asay argues that "However you approach it, the point is to stop thinking about freedom and control as impossibly opposed. Smart enterprises are figuring out ways to enable their developers using self-service platforms. Maybe you should, too."

The C programming language has many problems. But now the Registers notes that "Aria Beingessner, a member of the teams that implemented both Rust and Swift, has an interesting take... That C isn't a programming language anymore...."

"And it hasn't been for a long time," Beingessner writes in an online essay: This isn't about the fact that C is actually horribly ill-defined due to a billion implementations or its completely failed integer hierarchy. That stuff sucks, but on its own that wouldn't be my problem.

My problem is that C was elevated to a role of prestige and power, its reign so absolute and eternal that it has completely distorted the way we speak to each other. Rust and Swift cannot simply speak their native and comfortable tongues — they must instead wrap themselves in a grotesque simulacra of C's skin and make their flesh undulate in the same ways it does....

Everyone had to learn to speak C to talk to the major operating systems, and then when it came time to talk to eachother we suddenly all already spoke C so... why not talk to eachother in terms of C too?

Oops! Now C is the lingua franca of programming.

Oops! Now C isn't just a programming language, it's a protocol.
The Register picks up the argument: it's fair (if wildly controversial) to say, as this 2018 Association for Computing Machinery paper puts it, that C is not a low-level programming language. As its subtitle says: "Your computer is not a fast PDP-11."

This is not a relative assessment: that is, it's not saying that there are other programming languages that are lower-level than C. It's an absolute one: C is often praised for being "close to the metal," for being a "portable assembly language." It was, once, but it hasn't been since the 1970s; the underlying computational models of modern computers are nothing like the one that C represents, which was designed for a 1970s 16-bit minicomputer.
The Register summarizes what happens when a language has to interface with an operating system — and thus, that operating system's C code. [I]t has to call C APIs. This is done via Foreign Function Interfaces (FFIs).... In other words, even if you never write any code in C, you have to handle C variables, match C data structures and layouts, link to C functions by name with their symbols....

The real problem is that C was never designed or intended to be an Interface Definition Language, and it isn't very good at it.

About one-third of U.S. subscribers to Netflix share their login credentials with others, according to new data from Leichtman Research Group. From the report: The research firm's online survey of 4,400 consumers confirms the company's own conclusions in recent years. While 64% of respondents said they pay for and use Netflix only in their own household, 33% indicate some form of sharing. (The remaining 3% are households whose Netflix comes packaged via other subscriptions.) Netflix has about 74 million subscribers in the U.S. and Canada and has penetrated nearly 70% of U.S. broadband homes. With subscription growth flattening in the region of late, Netflix has recently phased in rate increases in order to continue funding its $18 billion in annual programming spending. Earlier this month, Netflix announced a test of monthly fees for password-sharing in three territories outside of the U.S. The rise of password sharing between households, a blog post explained, is âoeimpacting our ability to invest in great new TV and films for our members.â

"Pong on a Commodore 64 is one thing... but Pong in a single C64 sprite? That's uncharted territory," writes Slashdot reader segaboy81.

Neowin reports: The Commodore 64 is an iconic machine. For many of us boomers, it was our introduction to programming... Josip Retro Bits is a YouTube channel that specializes in fun challenges on old hardware like the Commodore 64. In an older video, Josip creates a game of Pong using Basic. On the surface, this doesn't sound very interesting, but it's a real challenge because Basic is very limited when compared to writing machine code. Basically, the C64 is perfectly capable of a game like Pong, but not really in Basic. Spoiler alert: he does it. However, a commenter on that video had a novel idea. How about creating an entire game of Pong in a single spite?
That's a 24 x 21 pixels object. ("It can be seen as a bigger programmable character that can be moved on hardware on steps of one pixel," explains one tech blog.) And another spoiler alert: he does it again.

Here's the repository for the "Tiny Pong" code. It's written in C, with functions like drawScreen() and batSound().

And about 18 minutes into the video, he not only plays a game of Pong inside the sprite — he simultaneously makes that sprite move around the screen like the ball in a game of Pong.

GitHub has introduced a new feed into the dashboard of users and it doesn't appear to have gone down well with the code shack's regulars. The Register reports: As soon as the new feed arrived, replete with all kinds of exciting suggestions for developers to look at, the complaints began rolling in as users worried the recommendations were turning GitHub into something distressingly like a social media platform. "I do not need to see recommendations, nor activity of people I don't follow," said one user. "Don't fix what's not broken." Others were blunter, stating: "I don't want algorithmic feed" and requesting a feed on stuff that actually mattered â" issues, releases, PRs and so on. GitHub pushed out a new beta version of its Home Feed earlier this week, with the avowed intention of developers reaching a wider audience and building communities. The plan is to make discovery easier and help users "find new repositories or users to follow based on your interests."

As if to demonstrate the levels of discontent around GitHub's new feature, a Chrome extension quickly showed up to disable the social feed by removing the "For You" section on the GitHub dashboard. Not all users were upset by the appearance of the new feed, and GitHub staff popped up to promise that there would be an option to make one's profile private and opt out of pretty much everything via a single setting. It will, however, take until late April before this option is likely to appear, they said. Which prompted the obvious question: "Why is this opt-out instead of opt-in?"

An anonymous reader shares an opinion piece: Protest is an important element of free speech that should be protected. Openness and inclusivity are cornerstones of the culture of open source, and the tools of open source communities are designed for global access and participation. Collectively, the very culture and tooling of open source -- issue tracking, messaging systems, repositories -- offer a unique signaling channel that may route around censorship imposed by tyrants to hold their power.

Instead of malware, a better approach to free expression would be to use messages in commit logs to send anti-propaganda messages and to issue trackers to share accurate news inside Russia of what is really happening in Ukraine at the hands of the Russian military, to cite two obvious possibilities. There are so many outlets for open source communities to be creative without harming everyone who happens to load the update.

We encourage community members to use both the freedoms and tools of open source innovatively and wisely to inform Russian citizens about the reality of the harm imposed on Ukrainian citizens and to support humanitarian and relief efforts in and supportive of Ukraine. Longer term, it's likely these weaponizations are like spitting into the wind: The downsides of vandalizing open source projects far outweigh any possible benefit, and the blowback will ultimately damage the projects and contributors responsible. By extension, all of open source is harmed. Use your power, yes -- but use it wisely.

Stephen Wilhite, one of the lead inventors of the GIF, died last week from COVID at the age of 74, according to his wife, Kathaleen, who spoke to The Verge. From the report: Stephen Wilhite worked on GIF, or Graphics Interchange Format, which is now used for reactions, messages, and jokes, while employed at CompuServe in the 1980s. He retired around the early 2000s and spent his time traveling, camping, and building model trains in his basement.

Although GIFs are synonymous with animated internet memes these days, that wasn't the reason Wilhite created the format. CompuServe introduced them in the late 1980s as a way to distribute "high-quality, high-resolution graphics" in color at a time when internet speeds were glacial compared to what they are today. "He invented GIF all by himself -- he actually did that at home and brought it into work after he perfected it," Kathaleen said. "He would figure out everything privately in his head and then go to town programming it on the computer."

If you want to go more in-depth into the history of the GIF, the Daily Dot has a good explainer of how the format became an internet phenomenon. In 2013, Wilhite weighed in on the long-standing debate about the correct pronunciation of the image format. He told The New York Times, "The Oxford English Dictionary accepts both pronunciations. They are wrong. It is a soft 'G,' pronounced 'jif.' End of story."

After much speculation, Nvidia today at its March 2022 GTC event announced the Hopper GPU architecture, a line of graphics cards that the company says will accelerate the types of algorithms commonly used in data science. Named for Grace Hopper, the pioneering U.S. computer scientist, the new architecture succeeds Nvidia's Ampere architecture, with launched roughly two years ago. From a report: The first card in the Hopper lineup is the H100, containing 80 billion transistors and a component called the Transformer Engine that's designed to speed up specific categories of AI models. Another architectural highlight includes Nvidia's MIG technology, which allows an H100 to be partitioned into seven smaller, isolated instances to handle different types of jobs. "Datacenters are becoming AI factories -- processing and refining mountains of data to produce intelligence," Nvidia founder and CEO Jensen Huang said in a press release. "Nvidia H100 is the engine of the world's AI infrastructure that enterprises use to accelerate their AI-driven businesses."

The H100 is the first Nvidia GPU to feature dynamic programming instructions (DPX), "instructions" in this context referring to segments of code containing steps that need to be executed. Developed in the 1950s, dynamic programming is an approach to solving problems using two key techniques: recursion and memoization. Recursion in dynamic programming involves breaking a problem down into sub-problems, ideally saving time and computational effort. In memoization, the answers to these sub-problems are stored so that the sub-problems don't need to be recomputed when they're needed later on in the main problem. Dynamic programming is used to find optimal routes for moving machines (e.g., robots), streamline operations on sets of databases, align unique DNA sequences, and more.

"Supporting generics has been Go's most often requested feature, and we're proud to deliver the generic support that the majority of users need today," the Go blog announced this week. *

It's part of what Go's development team is calling the "biggest change ever to the language".

SiliconANGLE writes that "Right out of the gate, Go 1.18 is getting a CPU speed performance boost of up to 20% for Apple M1, ARM64 and PowerPC64 chips. This is all from an expansion of Go 1.17's calling conventions for the application binary interface on these processor architectures."

And Go 1.18 also introduces native support for fuzz testing — the first major programming language to do so, writes ZDNet: As Google explains, fuzz testing or 'fuzzing' is a means of testing the vulnerability of a piece of software by throwing arbitrary or invalid data at it to expose bugs and unknown errors. This adds an additional layer of security to Go's code that will keep it protected as its functionality evolves — crucial as attacks on software continue to escalate both in frequency and complexity. "At Google we are committed to securing the online infrastructure and applications the world depends upon," said Eric Brewer, VIP infrastructure at Google....

While other languages support fuzzing, Go is the first major programming language to incorporate it into its core toolchain, meaning — unlike other languages — third-party support integrations aren't required.
Google is emphasizing Go's security features — and its widespread adoption. ZDNet writes: Google created Go in 2007 and was designed specifically to help software engineers build secure, open-source enterprise applications for modern, multi-core computing systems. More than three-quarters of Cloud Native Computing Foundation projects, including Kubernetes and Istio, are written in Go, says Google. [Also Docker and Etc.] According to data from Stack Overflow, some 10% of developers are writing in Go worldwide, and there are signs that more recruiters are seeking out Go coders in their search for tech talent..... "Although we have a dedicated Go team at Google, we welcome a significant amount of contributions from our community. It's a shared effort, and with their updates we're helping our community achieve Go's long-term vision.
Or, as the Go blog says: We want to thank every Go user who filed a bug, sent in a change, wrote a tutorial, or helped in any way to make Go 1.18 a reality. We couldn't do it without you. Thank you.

Enjoy Go 1.18!
* Supporting generics "includes major — but fully backward-compatible — changes to the language," explains the release notes. Although it adds a few cautionary notes: These new language changes required a large amount of new code that has not had significant testing in production settings. That will only happen as more people write and use generic code. We believe that this feature is well implemented and high quality. However, unlike most aspects of Go, we can't back up that belief with real world experience. Therefore, while we encourage the use of generics where it makes sense, please use appropriate caution when deploying generic code in production.

While we believe that the new language features are well designed and clearly specified, it is possible that we have made mistakes.... it is possible that there will be code using generics that will work with the 1.18 release but break in later releases. We do not plan or expect to make any such change. However, breaking 1.18 programs in future releases may become necessary for reasons that we cannot today foresee. We will minimize any such breakage as much as possible, but we can't guarantee that the breakage will be zero.

Russia's invasion of Ukraine turns up in Mike Melanson's column "This Week in Programming": While the Open Source Initiative's (OSI) definition of open source software is quite clear on the matter — there must be "no discrimination against persons or groups" and "no discrimination against fields of endeavor" — the issue of who should be allowed to use open source software, according to ethical considerations, has long been debated.

Over the last month, this topic has again become a focus of debate as Russia's invasion of Ukraine has led to developers calling for blanket bans by companies like GitHub and GitLab; and to some developers even taking action. Earlier this month, we wrote about how open source gateway Scarf began limiting access to open source packages for the Russian government and military entities, via its gateway.

As we noted at the time, there was a primary distinction made when Scarf took this action: distribution of open source software is separate from the licensing of it. Those points of the OSI definition pertain to the licensing, not to some entity actively providing the software to others.

Since then, discussions around these ideas have continued, and this week an essay by Bradley M. Kuhn, a policy fellow and hacker-in-residence at the Software Freedom Conservancy, argues that copyleft won't solve all problems, just some of them.

The essay specifically takes to task the idea that open source software can effectively affect change by way of licensing limitations. He spent nearly 3,000 words on the topic, before pointedly addressing the issue of Russia — with a similar conclusion to the one reached by Scarf earlier this month. Kuhn argues that "FOSS licenses are not an effective tool to advance social justice causes other than software freedom" and that, instead, developers have a moral obligation to take stances by way of other methods.

"For example, FOSS developers should refuse to work specifically on bug reports from companies who don't pay their workers a living wage," Kuhn offers in an example.

Regarding Russia specifically, Kuhn again points to distribution as an avenue of protest, while still remaining in line with the principles of free and open source software.

"Every FOSS license in existence permits capricious distribution; software freedom guarantees the right to refuse to distribute new versions of the software. (i.e., Copyleft does not require that you publish all your software on the Internet for everyone, or that you give equal access to everyone — rather, it merely requires that those whom you chose to give legitimate access to the software also receive CCS). FOSS projects should thus avoid providing Putin easy access to updates to their FOSS," writes Kuhn.

Pamela Burdman, the executive director of Just Equations, a policy institute focused on the role of math in education equity, writes in an op-ed for Scientific American: All routes to STEM (science, technology, engineering and mathematics) degrees run through calculus classes. Each year, hundreds of thousands of college students take introductory calculus. But only a fraction ultimately complete a STEM degree, and research about why students abandon such degrees suggests that traditional calculus courses are one of the reasons. With scientific understanding and innovation increasingly central to solving 21st-century problems, this loss of talent is something society can ill afford. Math departments alone are unlikely to solve this dilemma. Several of the promising calculus reforms highlighted in our report Charting a New Course: Investigating Barriers on the Calculus Pathway to STEM , published with the California Education Learning Lab, were spearheaded by professors outside of math departments. It's time for STEM faculty to prioritize collaboration across disciplines to transform math classes from weed-out mechanisms to fertile terrain for cultivating a diverse generation of STEM researchers and professionals. This is not uncharted territory.

In 2013, life sciences faculty at the University of California, Los Angeles, developed a two-course sequence that covers classic calculus topics such as the derivative and the integral, but emphasizes their application in a biological context. The professors used modeling of complex systems such as biological and physiological processes as a framework for teaching linear algebra and a starting point for teaching the basics of computer programming to support students' use of systems of differential equations. Creating this course, Mathematics for Life Scientists, wasn't easy. The life sciences faculty involved, none of whom had a joint appointment with the math department, said they resorted to designing the course themselves after math faculty rebuffed their overture. The math faculty feared creating a "watered-down" course with no textbook (though after the course was developed, one math instructor taught some sections of the class).

Besides math, the life sciences faculty said they experienced "significant pushback" from the chemistry and physics departments over concerns that the course wouldn't adequately prepare students for required courses in those disciplines. But the UCLA course seems to be successful, and a textbook based on it now exists. According to recently published research led by UCLA education researchers, students in the new classes ended up with "significantly higher grades" in subsequent physics, chemistry and life sciences courses than students in the traditional calculus course, even when controlling for factors such as demographics, prior preparation and math grades. Students' interest in the subject doubled, according to surveys.

Sophos threat researcher Nick Gregory discovered a hole in Linux's netfilter firewall program that's "exploitable to achieve kernel code execution (via ROP [return-oriented programming]), giving full local privilege escalation, container escape, whatever you want." ZDNet reports: Behind almost all Linux firewalls tools such as iptables; its newer version, nftables; firewalld; and ufw, is netfilter, which controls access to and from Linux's network stack. It's an essential Linux security program, so when a security hole is found in it, it's a big deal. [...] This problem exists because netfilter doesn't handle its hardware offload feature correctly. A local, unprivileged attacker can use this to cause a denial-of-service (DoS), execute arbitrary code, and cause general mayhem. Adding insult to injury, this works even if the hardware being attacked doesn't have offload functionality! That's because, as Gregory wrote to a security list, "Despite being in code dealing with hardware offload, this is reachable when targeting network devices that don't have offload functionality (e.g. lo) as the bug is triggered before the rule creation fails."

This vulnerability is present in the Linux kernel versions 5.4 through 5.6.10. It's listed as Common Vulnerabilities and Exposures (CVE-2022-25636), and with a Common Vulnerability Scoring System (CVSS) score of 7.8), this is a real badie. How bad? In its advisory, Red Hat said, "This flaw allows a local attacker with a user account on the system to gain access to out-of-bounds memory, leading to a system crash or a privilege escalation threat." So, yes, this is bad. Worse still, it affects recent major distribution releases such as Red Hat Enterprise Linux (RHEL) 8.x; Debian Bullseye; Ubuntu Linux, and SUSE Linux Enterprise 15.3. While the Linux kernel netfilter patch has been made, the patch isn't available yet in all distribution releases.

South Africa's Competition Commission says it had referred Facebook and WhatsApp owner Meta Platforms to a tribunal for allegedly abusing its dominant position in the market. From a report: But a spokesperson for WhatsApp said the regulator was objecting to actions meant to protect the platform's users from abuses of WhatsApp's terms. In a statement, the regulator accused Meta of "abusing its dominance by engaging in exclusionary conduct geared at preventing competitors or potential competitors from entering into, participating, and expanding in a market". The commission said Meta had decided to "offboard" GovChat (a start-up that connects government and citizens) and its subsidiary #LetsTalk from its WhatsApp Business Application Programming Interface. It also said the company had "imposed and/or selectively enforced exclusionary terms and conditions regulating access to the WhatsApp Business API, mainly restrictions on the use of data".

This week Silicon Valley's Computer History Museum posted a PDF transcript (and video excerpts) from an interview with 81-year-old Margaret Hamilton, the programmer/systems designer who in the 1960s became director of the Software Engineering Division at the MIT Instrumentation Laboratory which developed the on-board flight software for NASA's Apollo program. Prior to that Hamilton had worked on software to detect an airplane's radar signature, but thought, "You know, 'I guess I should delay graduate school again because I'd like to work on this program that puts all these men on the Moon....'"

"There was always one thing that stood out in my mind, being in the onboard flight software, was that it was 'man rated,' meaning if it didn't work a person's life was at stake if not over. That was always uppermost in my mind and probably many others as well."

Interestingly, Hamilton had originally received two job offers from the Apollo Space Program, and had told them to flip a coin to settle it. ("The other job had to do with support systems. It was software, but it wasn't the onboard flight software.") But what's fascinating is the interview's glimpses at some of the earliest days of the programming profession: There was all these engineers, okay? Hardware engineers, aeronautical engineers and all this, a lot of them out of MIT... But the whole idea of software and programming...? Dick Battin, Dr. Battin, when they told him that they were going to be responsible for the software...he went home to his wife and said he was going to be in charge of software and he thought it was some soft clothing...
Hamilton also remembers in college taking a summer job as a student actuary at Travelers Insurance in the mid-1950s, and "all of a sudden one day word was going around Travelers that there were these new things out there called computers that were going to take away all of their jobs... Pretty soon they wouldn't have jobs. And so everybody was talking about it. They were scared they wouldn't have a way to make a living.

"But, of course, it ended up being more jobs were created with the computers than there were...."

Hamilton's story about Apollo 8 is amazing...