Gnome Software is the software center for the Gnome desktop environment (DE), and is a popular option for other DEs that don’t have their own software center, such as Xfce. Gnome Software is especially front-and-center on Fedora Workstation, given the amount of overlap between Fedora and Gnome developers.

In a mailing list post, user tqcharm recently recommended that Gnome Software completely remove support for RPMs, the native format for apps in the Red Hat/Fedora world.

Since the consensus seems to be that RPMs should be at the end of the priority list, what about decoupling (removing) RPMs from GNOME Software completely?

This might seem to be a step back, but it would make GNOME Software more consistent between Workstation and Silverblue, and support Fedora in its goal to make Flatpaks the primary packaging option.

That would leave RPMs to be a choice of the more advanced users, who seem to prefer the powerful dnf over GNOME Software anyway.

With RPMs missing from GNOME Software, prioritizing package sources becomes easier too: be it Fedora Core > Flathub Verified (or Probably Safe) -> Fedora Extended -> Flathub Extended or similar.

Michael Catanzaro, a Red Hat engineer, as well as a prominent Fedora and Gnome developer, replied with the following:

Removing RPM applications is my long term goal, but I’m not sure how quickly we’ll be able to get there.

Flatpaks, as well as Snaps, are a containerized app format that bundles all the necessary dependencies within the app, rather than relying on the underlying system. This is similar to how applications work on macOS, and solve many of the dependency issues that can arise when trying to have the latest software on older, point release distros.

Despite the advantages they offer, Flatpaks still have some disadvantages. For example, Flatpaks are designed primarily with desktop apps in mind, and are not suited for command-line apps. Flatpaks can also take up more space than traditional apps, although this becomes less of a factor as more Flatpaks are installed, since Flatpaks can share dependencies among themselves.

In addition, many Linux users still prefer traditional app package formats, such as RPMs in the Red Hat/Fedora/openSUSE world and DEBs in the Debian/Ubuntu world. There is also the question of how Gnome Software would handle native packages on other Linux distros, such as Debian and Ubuntu-based distros.

Ultimately, Gnome developers have a longstanding reputation for removing functionality the vast majority of users consider important, such as maximize/minimize window buttons, desktop icons, and more. The philosophy has contributed to many users transitioning to KDE Plasma, Cinnamon, or Xfce, all of which maintain the traditional desktop paradigm.

If Gnome developers move forward with this plan, it’s a move that will likely alienate even more users.

Nintendo has a long history of going after open-source emulation projects, threatening legal action to shut down one after another and earning the ire of the gaming community. As Android Authority points out, however, since none of the cases in question have ever seen the inside of a courtroom, there is no definitive status on the legality of emulation.

AA also reports that at the recent Tokyo eSports Festa, Nintendo patent attorney and IP general manager Koji Nishiura agreed that emulators are technically legal.

The outlet goes on to emphasize the tightrope developers have to walk. While emulation itself may be legal, trying to bypass the Nintendo Switch’s anti-piracy measures or circumventing copyright protection is a legal minefield.

Nonetheless, Nishiura’s admission is a major blow to Nintendo’s legal efforts to kill emulation projects.

A Microsoft developer submitted code months ago that was designed to improve performance by changing how CPUs cache executable pages. The code was designed to use large read-only execute (ROX) pages instead of the current method.

Unfortunately, the code interfered with Control Clow Integrity (CFI), an anti-malware feature that is critical to maintaining Linux security.

Intel engineer Peter Zijlstra submitted a commit that that rolled back the code. He acknowledged the Microsoft developer has been working to fix the issue, but felt time had run out in order to finalize work on 6.13.

The whole module_writable_address() nonsense made a giant mess of alternative.c, not to mention it still contains bugs — notable some of the CFI variants crash and burn.

Mike has been working on patches to clean all this up again, but given the current state of things, this stuff just isn’t ready.

Disable for now, lets try again next cycle.

While increased performance is a worthwhile goal, Zijlstra made the right call in rolling back the change. Performance should not come at the expense of security, which is exactly what would have happened if this patch had slipped through.

Deno Land, the maker of a popular JavaScript runtime, has launched an effort to strip Oracle of its JavaScript trademark, which the company acquired when it purchased Sun Microsystems in 2009. Deno is making the case to the US Patent and Trademark Office that Oracle’s trademark is overly broad, too broad to be covered by a trademark.

In a post on Mastodon, Deno says Oracle has informed them that it has no intention of voluntarily giving up its trademark, essentially guaranteeing a legal battle.

FreeJavaScript update: Oracle has informed us they won’t voluntarily withdraw their trademark on “JavaScript”. Next: they’ll file their Answer and we’ll start discovery to show how “JavaScript” is widely recognized as a generic term and not controlled by Oracle.

Allegations of Fraud and Abandoned Trademark

Deno has laid out serious allegations, including that Oracle engaged in fraud to renew JavaScript trademark in 2019. In the documentation Deno provided, Oracle references and shows screen captures of Node.js and its website, even though Oracle does not own and is not involved with Node.js.

Oracle, through its attorney, submitted specimens showing screen captures of the Node.js website, a project created by Ryan Dahl, Petitioner’s Chief Executive Officer. Node.js is not affiliated with Oracle, and the use of screen captures of the “nodejs.org” website as a specimen did not show any use of the mark by Oracle or on behalf of Oracle.

Moreso, as of December 26, 2019, Oracle knew that it had no connection with Node.js and that its use of Node.js’s website to show “use in commerce” of the phrase “JavaScript” by Oracle was not valid.

Oracle’s knowingly fraudulent statements were material to the USPTO’s decision to renew the Registered Mark, reg. no. 2416017.

Deno also claims that if JavaScript is not a generic phrase—and therefore exempt from trademark—as Oracle maintains, then the company has abandoned the trademark by not creating or selling any JavaScript products.

JavaScript is one of the most ubiquitous technologies and programming languages, one that helps power much of the internet and, increasingly, desktop applications. While Oracle has not exercised its trademark, Deno is clearly concerned about the possibility of the company choosing to do so.

Amazon Q Developer is the company’s tool that’s designed to improve programmers’ productivity by handling much of the extraneous tasks programmers are often saddled with, such as code reviews, unit testing, and writing documentation.

In fact, Amazon says these extraneous tasks take so much time that most developers only code an hour a day.

Today, developers report they spend an average of just one hour per day coding. They spend most of their time on tedious, undifferentiated tasks such as learning codebases, writing and reviewing documentation, testing, managing deployments, troubleshooting issues or finding and fixing vulnerabilities. Q Developer is a generative AI-powered assistant for designing, building, testing, deploying, and maintaining software. Its agents for software development have a deep understanding of your entire code repos, so they can accelerate many tasks beyond coding. With this new capability, Q Developer can help you understand your existing code bases faster, or quickly document new features, so you can focus on shipping features for your customers.

Amazon Q Developer was became generally available in April, with the company continuing to improve it and add features in the ensuing months.

Amazon Q Developer has agents that can generate real-time code suggestions based on your comments and existing code, bootstrap new projects from a single prompt (/dev), automate the process of upgrading and transforming legacy Java applications with the Amazon Q Developer transformation capability (/transform), generate customized code recommendations from your private repositories securely, and quickly understand what resources are running in your AWS account with a simple prompt.

As of early December, Amazon Q Developer can now provide enhanced codebase documentation, improved code reviews, and automatic unit tests.

Today, we’re expanding Amazon Q Developer agent capabilities for: 1) enhanced documentation in codebases (/doc), 2) supporting code reviews to detect and resolve security and code quality issues (/review), and 3) generating unit tests automatically and improving test coverage (/test) across the software development lifecycle in your preferred IDE or GitLab Duo with Amazon Q (in preview), which is one of the most popular enterprise DevOps platforms.

Developers can learn more and get started with Amazon Q Developer here.

The latest incident comes courtesy of a Curl bug report. Curl is an important open-source component used for data transfer across networks. A recent, very detailed bug report raised alarming concerns about possible vulnerabilities.

Both Curl_inet_ntop and inet_ntop4 pose significant buffer overflow risks due to a lack of proper size validation and unsafe string operations. The proposed fixes address these issues by enforcing strict buffer size checks and using safer string handling techniques. Comprehensive testing and adherence to these best practices will ensure the functions are secure and robust for both IPv4 and IPv6 address conversions.

Despite the ominous-sounding nature of the bug report, investigation by the developers immediately turned up issues. As developer Jim Fuller point out, the report was not actionable, containing no steps to reproduce the bug, let alone fix it.

Once I got through ‘the wall of text’ which appears comprehensive but does not contain a reproducer or concrete steps to vulnerability – as far as I can tell we have another report with no risk of vulnerability … if the op wants to suggest a code change then I would suggest to raise a PR.

Unfortunately, at this point in the discussion, the user who reported the “vulnerability” started claiming they were being disrespected and treated with a lack of empathy because their report was being ignored and labeled “AI slop.” Curl maintainer Daniel Stenberg responded, condemning AI bug reports.

I’m sorry you feel that way, but you need to realize your own role here. We receive AI slop like this regularly and at volume. You contribute to unnecessary load of curl maintainers and I refuse to take that lightly and I am determined to act swiftly against it. Now and going forward.

You submitted what seems to be an obvious AI slop “report” where you say there is a security problem, probably because an AI tricked you into believing this. You then waste our time by not telling us that an AI did this for you and you then continue the discussion with even more crap responses – seemingly also generated by AI.

By all means, use AI to learn things and to figure out potential problems, but when you just blindly assume that a silly tool is automatically right just because it sounds plausible, then you’re doing us all (the curl project, the world, the open source community) a huge disservice. You should have studied the claim and verified it before you reported it. You should have told us an AI reported this to you. You should have provided an exact source code location or steps-to-reproduce when asked to – because when you failed to, you proved that your “report” had no particular value.

A Larger Problem

The Curl team’s issues with AI bug reports are by no means isolated incidents. First spotted by The Register, Seth Larson, the Python Software Foundation’s security developer-in-residence, penned a blog post lamenting the situation.

I’m on the security report triage team for CPython, pip, urllib3, Requests, and a handful of other open source projects. I’m also in a trusted position such that I get “tagged in” to other open source projects to help others when they need help with security.

Recently I’ve noticed an uptick in extremely low-quality, spammy, and LLM-hallucinated security reports to open source projects. The issue is in the age of LLMs, these reports appear at first-glance to be potentially legitimate and thus require time to refute. Other projects such as curl have reported similar findings.

Larson goes on to say that people need to recognize how much time and money are wasted with spammy, AI-generated bug reports, and that the industry should consider such reports malicious.

Security is already a topic that is not aligned with why many maintainers contribute their time to open source software, instead seeing security as important to help protect their users. It’s critical as reporters to respect this often volunteered time.

Security reports that waste maintainers’ time result in confusion, stress, frustration, and to top it off a sense of isolation due to the secretive nature of security reports. All of these feelings can add to burn-out of likely highly-trusted contributors to open source projects.

In many ways, these low-quality reports should be treated as if they are malicious. Even if this is not their intent, the outcome is maintainers that are burnt out and more averse to legitimate security work.

Conclusion

Open source projects need contributors, including people who are willing to put the time in that it takes to produce detailed, well-researched,and actionable bug reports. Users interested in contributing in this way should put in the time and effort it takes to do it right, instead of taking the easy way of relying on hallucination-prone AI models.

Above all, when called out for lazy behavior, individual’s shouldn’t blame the developer and whine about a lack of empathy, while having no empathy for the developer’s wasted time and energy.

Musk’s xAI has been expanding rapidly, forging its own path in the AI world. The company initially relied on Oracle for its Nvidia H100 systems before building out its own cluster of 100,000 H100s. According to the Memphis Chamber of Commerce, the company is preparing a major expansion of its supercomputer, with plans to grow it to at least one million GPUs.

The expansion, already underway, will incorporate a minimum of one million Graphics Processing Units (GPUs), marking the largest capital investment in the region’s history. Additionally, Fortune 500 tech giants Nvidia, Dell, and Supermicro Computer (SMC) will be establishing operations in Memphis, further solidifying the city’s position as the “Digital Delta” – a moniker coined by FedEx founder Fred Smith and his son, FedEx Executive Richard Smith.

xAI’s Brent Mayo touted the investment as “an unprecedented pace” in AI development.

“In Memphis, we’re pioneering development in the heartland of America,” Mayo declared. “We’re not just leading from the front; we’re accelerating progress at an unprecedented pace while ensuring the stability of the grid utilizing megapack technology.”

For his part, Musk retweeted a headline, while jokingly saying the company planned to implement a billion GPUs.

Spotify’s Web API allows third-party apps to access Spotify and provide an alternative experience for users unhappy with the company’s default apps. Like Reddit before it, Spotify seems to be changing its stance on third-party access, making it harder for developers.

The company announced the changes in a developer blog post on November 27.

Since our last broader update on the Community platform, we continue to see new integrations made through Spotify’s APIs and SDKs. We’re excited about the continued engagement we’re seeing to learn, experiment, innovate, and deliver unique experiences with Spotify.

As we continue to review the experience provided on Spotify for Developers, we’ve decided to roll out a number of measures with the aim of creating a more secure platform.

The company makes clear that the changes impact new Web API use cases, not existing apps.

Effective today, new Web API use cases will no longer be able to access or use the following endpoints and functionality in their third-party applications. Applications with existing extended mode Web API access that were relying on these endpoints remain unaffected by this change.

• Related Artists
• Recommendations
• Audio Features
• Audio Analysis
• Get Featured Playlists
• Get Category’s Playlists
• 30-second preview URLs, in multi-get responses (SimpleTrack object)
• Algorithmic and Spotify-owned editorial playlists

These changes will impact the following Web API applications:

• Existing apps that are still in development mode without a pending extension request
• New apps that are registered on or after today’s date

The company says “third party integrations continue to play an important role in the way users can experience the Spotify experiencing through third party apps.” Regardless of what the company says, however, the API change is not an encouraging indication of where things are going for third-party developers.

Oracle acquired the JavaScript trademark when it purchased Sun Microsystems in 2009. According to Deno, the term “JavaScript” too generic to be protected by trademark.

The term “JavaScript” is the generic term for a general-purpose programming language used globally by millions of developers. It is widely recognized as the generic term for the programming language defined by the ECMA-262 specification, maintained by Ecma International’s TC39, a committee with representatives from major browser vendors and JavaScript developers.

Oracle does not control (and has never controlled) any aspect of the specification or how the phrase “JavaScript” can be used by others.

Today, millions of companies, universities, academics, and programmers, including Petitioner, use “JavaScript” daily without any involvement with Oracle. The phrase “JavaScript” does not belong to one corporation. It belongs to the public. JavaScript is the generic name for one of the bedrock languages of modern programming, and, therefore, the Registered Mark must be canceled.

Allegations of Fraud

In addition to the issues presented by the generic nature of the term, Deno alleges that Oracle has engaged in fraud when it renewed the trademark in 2019. Deno provides documentation showing that Oracle showed screen captures of the Node.js website as evidence of Oracle’s ownership of JavaScript. There’s just one issue…Node.js has nothing to do with Oracle, as Deno points out.

Oracle, through its attorney, submitted specimens showing screen captures of the Node.js website, a project created by Ryan Dahl, Petitioner’s Chief Executive Officer. Node.js is not affiliated with Oracle, and the use of screen captures of the “nodejs.org” website as a specimen did not show any use of the mark by Oracle or on behalf of Oracle.

Moreso, as of December 26, 2019, Oracle knew that it had no connection with Node.js and that its use of Node.js’s website to show “use in commerce” of the phrase “JavaScript” by Oracle was not valid.

Oracle’s knowingly fraudulent statements were material to the USPTO’s decision to renew the Registered Mark, reg. no. 2416017.

Abandoned Trademark

Deno also claims that Oracle has essentially abandoned the JavaScript trademark by not selling any goods or services pertaining to JavaScript since the company acquired Sun and the trademark.

In the alternative, if the phrase “JavaScript” is not generic, then Oracle has abandoned the Registered Mark with no intent (or ability) to resume use for Oracle’s Goods and Services.

In the alternative, Oracle has not sold any goods or rendered any services showing the Registered Mark as a source identifier since acquiring the mark from the Registered Mark’s original owner, Sun Microsystems, Inc., in 2009.

JavaScript is one of the fundamental building blocks of the internet, and increasingly of desktop apps and even operating systems. There certainly appears to be some merit to Deno’s argument that JavaScript is simply too generic and widely used for one single company to “own” it, especially if that company is not actively doing anything to further JavaScript’s development.

JavaScript was the previous king of programming languages, used for everything from websites to applications to desktop environments. Despite its ubiquity, JavaScript’s reign has finally come to an end, with Python taking the top spot.

As GitHub points out, Python’s rise in popularity owes to its use in data science and machine learning.

In 2024, Python overtook JavaScript as the most popular language on GitHub, while Jupyter Notebooks skyrocketed—both of which underscore the surge in data science and machine learning on GitHub. We’re also seeing increased interest in AI agents and smaller models that require less computational power, reflecting a shift across the industry as more people focus on new use cases for AI.

Interestingly, Python’s rise coincides with a general rise in developers.

Our data also shows a lot more people are joining the global developer community. In the past year, more developers joined GitHub and engaged with open source and public projects (in some cases, empowered by AI). And since tools like GitHub Copilot started going mainstream in early 2023, the number of developers on GitHub has rapidly grown with significant gains in the global south. While we see signals that AI is driving interest in software development, we can’t fully explain the surge in global growth our data reflects (but we’ll keep studying it).

GitHub goes on to highlight three major trends in the industry.

• A surge in global generative AI activity. AI is growing and evolving fast, and developers globally are going far beyond code generation with today’s tools and models. While the United States leads in contributions to generative AI projects on GitHub, we see more absolute activity outside the United States. In 2024, there was a 59% surge in the number of contributions to generative AI projects on GitHub and a 98% increase in the number of projects overall—and many of those contributions came from places like India, Germany, Japan, and Singapore.
• A rapidly growing number of developers worldwide—especially in Africa, Latin America, and Asia. Notable growth is occurring in India, which is expected to have the world’s largest developer population on GitHub by 2028, as well as across Africa and Latin America. We also see Brazil’s developer community growing fast. Some of this is attributable to students. The GitHub Education program, for instance, has had more than 7 million verified participants. We’ve also seen 100% year-over-year growth among students, teachers, and open source maintainers adopting GitHub Copilot as part of our complimentary access program. This suggests AI isn’t just helping more people learn to write code or build software faster—it’s also attracting and helping more people become developers. First-time open source contributors continue to show wide-scale interest in AI projects. But we aren’t seeing signs that AI has hurt open source with low-quality contributions.
• Python is now the most used language on GitHub as global open source activity continues to extend beyond traditional software development. We saw Python emerge for the first time as the most used language on GitHub (more on that later). Python is used heavily across machine learning, data science, scientific computing, hobbyist, and home automation fields among others. The rise in Python usage correlates with large communities of people joining the open source community from across the STEM world rather than the traditional community of software developers. This year, we also saw a 92% spike in usage across Jupyter Notebooks. This could indicate people in data science, AI, machine learning, and academia increasingly use GitHub. Systems programming languages, like Rust, are also on the rise, even as Python, JavaScript, TypeScript, and Java remain the most widely used languages on GitHub.

GitHub’s findings are a significant data point in an industry that is in the process of evolving, thanks to AI’s impact. Many developers and industry veterans have been worried that AI would replace programmers, leading to mass firings. Already, companies are relying heavily on AI to help write code.

GitHub’s Findings Echo Statements From Industry Leaders

For example, in a recent quarterly report, Alphabet CEO Sundar Pichai said more than 25% of all Google code has been written by AI. Similarly, Google co-founder Sergey Brin highlighted just how much AI has impacted his development habits.

“I think that AI touches so many different elements of day-to-day life, and sure, search is one of them,” Brin said in an interview with All-In Podcast’s David Friedberg. “But it kind of covers everything. For example, programming itself, the way that I think about it is very different now.

“Writing code from scratch feels really hard, compared to just asking the AI to do it,” Brin added, to laughter from the audience. “I’ve written a little bit of code myself, just for kicks, just for fun. And then sometimes I’ve had the AI write the code for me, which was fun.”

Brin’s experience seems to support GitHub’s findings, that AI is enhancing development and likely leading to a surge in developer engagement.

JetBrains has a long history of creating development tools for a variety of languages. The company also invented the Kotlin programming language, which is replacing Java as the preferred language for creating Android applications.

The company has been making some of its newest IDEs available for free, beginning with RustRover and Aqua earlier this year. The company says it is expanding that to include Rider and WebStorm. Rider is used for .NET development, while WebStore is used for JavaScript and TypeScript.

Earlier this year, we implemented a new licensing model for our recently introduced IDEs, RustRover and Aqua, making them free for non-commercial use. We’re now extending this model to WebStorm and Rider. If you’re using these IDEs for non-commercial purposes, such as learning, open-source project development, content creation, or hobby development, you can now do so for free.

For commercial projects, nothing will change – our existing licensing remains in place. Other JetBrains IDEs are not affected by this update, either. We’ll evaluate the outcomes of this free non-commercial licensing initiative to see if it can be expanded.

JetBrains says it wants to make its tools more approachable and investigated a number of different approaches. Given the monolithic nature of the company’s IDEs, creating an entirely separate community edition was ruled out as an option, as it would have created a subpar experience. Instead, the company chose to offer the IDEs for free for non-commercial use, picking WebStorm and Rider for their specific appeal.

According to various surveys like Stack Overflow, 68% of developers code outside of work as a hobby, and nearly 40% for professional growth or self-paced learning. This share is even higher for game and web development. For example, game developers often begin their careers by creating games as a hobby, using free game engines. This inspired our choice to apply the new licensing model to WebStorm and Rider.

The company does include some restrictions, but they are fairly reasonable for a free product.

As defined in the Toolbox Subscription Agreement for Non-Commercial Use, commercial products are products distributed or made available for a fee or used as part of your business activity. However, there are certain categories excluded explicitly from this definition. Common examples of non-commercial cases include learning and self-education, any form of content creation, open-source code, and hobby development.

It’s important to note that, if you’re using a non-commercial license, you cannot opt out of the collection of anonymous usage statistics. We use this information to improve our products. The data we collect is exclusively that of anonymous feature usages of our IDEs. It is focused on what actions are performed and what types of functionality of the IDE are used. We do not collect any other data. This is similar to our Early Access Program (EAP) and is in compliance with our Privacy Policy.

JetBrains’ latest move is a good one for developers and the company, and will likely help broaden the company’s audience.

Germany’s Sovereign Tech Fund has the goal of promoting and supporting the development of open source projects, especially those developing “foundational open source technologies.” Two years in, the organization says it has invested in 60 such projects, to the tune of €23 million.

Throughout our second year, the Sovereign Tech Fund identified and invested in even more foundational open source technologies. With nearly 500 submissions proposing over €114 million in work since we started accepting applications, the need for support has never been more clear. By financing critical projects like Log4j, we’re commissioning much-needed maintenance, security work, and improvements in the public interest. The work on these components benefits all the companies, organizations, and individuals who depend on the open technologies that comprise our shared digital infrastructure.

Some of the projects that have received investment include FreeBSD, Mamba, Samba, PHP, GNOME, Reproducible Builds, GFortran, systemd, FFmpeg, GStreamer, Log4j, Drupal, Fortran, and many more.

An important element included improving developer tooling, which will in turn benefit many other projects.

Five teams received approximately €860,000 to working on improving developer tooling, securing software production, and documentation in free and open source (FOSS) projects: conda-store, Haskell Cabal, p5.js documentation, and Open Web Docs.

The Sovereign Tech Fund has been so successful that its funding has been increased going into 2025.

The Sovereign Tech Fund was founded two years ago as a special initiative — the first of its kind — to increase the resilience of the open source ecosystem. This signified a new way of thinking about how the public interest, governments, and digital infrastructure are interconnected. Over the last year, we’ve made much progress towards becoming an independent and permanent organization, working closely with SPRIND and our partners at German Ministry for Economic Affairs and Climate Action, which funds us.

Last week, the budget committee of the Bundestag decided to increase the Sovereign Tech Fund’s allocation by €4 million for next year. We’re honored and thankful for the German Parliament’s recognition of the importance of open source technologies, and for their continued trust in our work.

Given the importance of open source software, both within the open source community and to the many corporations that rely on it, it’s good to see efforts made to support some of these critical projects.

Valve is one of the leading game publishers and distributors, and is the main way many gamers access their favorite titles via its Steam platform. The company also makes the Steam Deck, a handheld console that can be docked for traditional console play. The Steam Deck runs SteamOS, which is based on Arch Linux, meaning it can also be used as a full-fledged Linux computer as well.

Catch our chat on Valve and Arch Linux boosting Linux gaming!

Given the role Arch Linux plays in Valve’s product line, it’s not surprising the two entities are collaborating. In an announcement on the Arch mailing list, Levente Polyak said Valve will provide backing for a build service infrastructure, as well as a secure signing enclave.

We are excited to announce that Arch Linux is entering into a direct collaboration with Valve. Valve is generously providing backing for two critical projects that will have a huge impact on our distribution: a build service infrastructure and a secure signing enclave. By supporting work on a freelance basis for these topics, Valve enables us to work on them without being limited solely by the free time of our volunteers.

This opportunity allows us to address some of the biggest outstanding challenges we have been facing for a while. The collaboration will speed-up the progress that would otherwise take much longer for us to achieve, and will ultimately unblock us from finally pursuing some of our planned endeavors. We are incredibly grateful for Valve to make this possible and for their explicit commitment to help and support Arch Linux.

These projects will follow our usual development and consensus-building workflows. [RFCs] will be created for any wide-ranging changes. Discussions on this mailing list as well as issue, milestone and epic planning in our GitLab will provide transparency and insight into the work. We believe this collaboration will greatly benefit Arch Linux, and are looking forward to share further development on this mailing list as work progresses.

Valve has emerged as a major force for good in the Linux community, doing a tremendous amount of work that benefits the community at large. This latest measure is an excellent example of a corporation that depends on Linux for some of its products giving back to the community and helping the foundation its products rely on.

Rust made its way into the Linux kernel with version 6.1, becoming only the second language supported by the kernel, behind the original C. With each release of the kernel, Rust support has continued to grow, but that doesn’t mean it’s been a smooth ride.

Filho, who works as a software engineer at Microsoft, sent an email to the kernel mailing list to explain why he is stepping back from the project.

I am retiring from the project. After almost 4 years, I find myself lacking the energy and enthusiasm I once had to respond to some of the nontechnical nonsense, so it’s best to leave it up to those who still have it in them.

Filho goes on to express how much he enjoyed working with the Rust for Linux team.

To the Rust for Linux team: thank you, you are great. It was a pleasure working with you all; the times we spent discussing technical issues, finding ways to address soundness holes, etc. were something I always enjoyed and looked forward to. I count myself lucky to have collaborated with such a talented and friendly group.

I wish all the success to the project.

Interestingly, the next part of the email subtly addresses the kind of drama Filho evidently was tired of dealing with.

I truly believe the future of kernels is with memory-safe languages. I am no visionary but if Linux doesn’t internalize this, I’m afraid some other kernel will do to it what it did to Unix.

Lastly, I’ll leave a small, 3min 30s, sample for context here: https://youtu.be/WiPp9YEBV0Q?t=1529 — and to reiterate, no one is trying force anyone else to learn Rust nor prevent refactorings of C code.

That last statement is telling, given there has been growing reports that some of the long-time developers working on the Linux kernel resented Rust’s inclusion. In fact, in recent comments, Linux creator Linus Torvalds expressed his own disappointment with the situation.

“I was expecting updates to be faster, but part of the problem is that old-time kernel developers are used to C and don’t know Rust,” Torvalds said, via The Linux Experiment. “They’re not exactly excited about having to learn a new language that is, in some respects, very different. So there’s been some pushback on Rust.”

Torvalds is known to put his foot down and yank developers back in line when they stray too. If the Rust for Linux project keeps losing top maintainers because of unnecessary drama and pushback, it’s a safe bet Torvalds may soon intervene and set things straight.

Mono is the open-source .Net implementation. Similarly, Wine is open-source software that allows Linux and macOS run Windows applications. Unlike emulation, which often takes a significant performance hit, Wine translates Windows API calls to their counterparts on Linux and macOS, providing near-native performance.

Microsoft’s Jeff Schwartz announced the news in a GitHub post, as well as on the Mono Project’s website.

The Mono Project (mono/mono) (‘original mono’) has been an important part of the .NET ecosystem since it was launched in 2001. Microsoft became the steward of the Mono Project when it acquired Xamarin in 2016.

The last major release of the Mono Project was in July 2019, with minor patch releases since that time. The last patch release was February 2024.

We are happy to announce that the WineHQ organization will be taking over as the stewards of the Mono Project upstream at wine-mono / Mono · GitLab (winehq.org). Source code in existing mono/mono and other repos will remain available, although repos may be archived. Binaries will remain available for up to four years.

Microsoft maintains a modern fork of Mono runtime in the dotnet/runtime repo and has been progressively moving workloads to that fork. That work is now complete, and we recommend that active Mono users and maintainers of Mono-based app frameworks migrate to .NET which includes work from this fork.

We want to recognize that the Mono Project was the first .NET implementation on Android, iOS, Linux, and other operating systems. The Mono Project was a trailblazer for the .NET platform across many operating systems. It helped make cross-platform .NET a reality and enabled .NET in many new places and we appreciate the work of those who came before us.

Thank you to all the Mono developers!

Microsoft often takes flak for their past stance on free and open-source software, but the company has increasingly embraced FOSS, including creating and running their own Linux distro. Windows also includes Windows Subsystem for Linux, allowing users to run Linux apps and services within Windows.

Donating Mono to Wine is a good move that will hopefully give the open-source community the ability to continue developing and improving it.

Apple drew sharp criticism when it was revealed that macOS Sequoia would ask weekly, and after each restart, to confirm that various screenshot and screen recording apps had permission to operate. Needless to say, users were not happy with the idea of being continually nagged about software they chose to install and use.

The company appears to be listening to the feedback, at least to some degree, with news that Sequoia will ask users to confirm such apps have permission to operate on a monthly basis, instead of weekly. According to 9to5Mac, Sequoia will no longer ask after each restart.

The outlet reports that the following message is now displayed, as of macOS Sequoia beta 6:

“[App name] is requesting to bypass the system private window picker and directly access your screen and audio. This will allow [app name] to record your screen and system audio, including personal or sensitive information that may be visible or audible.”

Unfortunately, there is still no option to permanently grant permission, with users only able to allow permission for one month at a time.

Some developers, including Craig Hockenberry, who was one of the first to notice the original permission notifications, have pointed to the Persistent Content Capture entitlement as a possible way permanently grant permissions for an app and silence the notifications.

As TidBits points out, however, Apple describes the entitlement as ““a Boolean value that indicates whether a Virtual Network Computing (VNC) app needs persistent access to screen capture,” which would seem to indicate it lacks the flexibility necessary to fill the role developers are hoping for.

While Apple’s focus on security is admirable, and monthly notifications are better than weekly ones, the company’s entire approach to this situation seems like a solution looking for a problem, and will likely alienate far more users than it helps.

GrapheneOS is an open source, security hardened version of Android that offers a level of security that stock standard Android—or even iOS—can’t match. GrapheneOS is the OS of choice for Edward Snowden, as well as journalists, activists, and yours truly.

Despite GrapheneOS offering superior privacy and security as the standard Android, Google is taking steps to keep it and other third-party Android ROMs second-class citizens within the Android ecosystem. In particular, Google is restricting access to Play Integrity API, the security feature that verifies that apps have not been maliciously tampered with. Unfortunately, some apps won’t work without Play Integrity API, including some banking and multi-factor authentication apps.

In a long Mastodon thread, the GrapheneOS devs say Google is unfairly banning the OS from using Play Integrity API, despite GrapheneOS being far more secure than Android vendors that do have access to the API.

Play Integrity API is claimed to be based on devices complying with the Compatibility Test Suite and Compatibility Definition Document. We have irrefutable proof that the majority of certified Android devices do not comply with the CTS/CDD. Play Integrity API is based on lies.

Essentially every non-Pixel device has important CTS failures not caused by CTS bugs. OEMs are cheating to obtain certification. Google claims GrapheneOS can’t be permitted because we don’t have a certification where they freely allow cheating and don’t ban non-compliant devices.

Since Play Integrity doesn’t even have a minimum security patch level, it permits a device with multiple years of missing patches. Hardware attestation was required on all devices launched with Android 8 or later, but they don’t enforce it to permit non-compliant devices.

The devs then make the point that Google allows partners using the stock Android to use Play Integrity API, despite missing years of security patches. Meanwhile, GrapheneOS remains banned using the API.

The reality is that the Play Integrity API permits devices from companies partnered with Google with privileged Google Play integration when they’re running the stock OS. It’s easy to bypass, but they’ll make changes to block it being done at scale long term such as if we did it.

It does not matter if these devices have years of missing security patches. It doesn’t matter if the companies skipped or improperly implemented mandatory security features despite that being required by CDD compliance. Failing even very important CTS tests doesn’t matter either.

GrapheneOS devs says Google can either allow them access to Play Integrity API or face a lawsuit.

Google can either permit GrapheneOS in the Play Integrity API in the near future via the approach documented at https://grapheneos.org/articles/attestation-compatibility-guide or we’ll be taking legal action against them and their partners. We’ve started the process of talking to regulators and they’re interested.

Given Google’s recent loss in court, with the company being designated an illegal monopoly, it’s likely not an idle threat that regulators are interested in complaints from the GrapheneOS devs.

Either way, hopefully Google will provide—or be forced to provide—GrapheneOS and other third-party Android ROMs access to Play Integrity API. Doing so will ensure a more robust Android ecosystem and give people true options when it comes to the choice of their mobile OS.

Canonical’s Brett Grandbois pointed out that Ubuntu and the Linux kernel’s developers follow two different release schedules. As a general rule, the Canonical Kernel Team (CKT) likes to have a month from the time the kernel developers release a new version to when they view it stable enough to incorporate it into Ubuntu.

Given the non-aligned nature of the two release schedules, it is inevitable that there will be instances where both release dates happen to fall on or near the same date. This can be further exacerbated by the nature of the upstream kernel releasing when it is deemed ready, not at some predetermined deadline, which therefore could mean a much later release date than originally anticipated. A general rule of thumb, that the CKT has determined, is that about a month is required between an upstream release and the associated Ubuntu kernel to be considered stable enough for release. That can pose a problem when the upstream release is expected to land either within the 4 weeks before the Ubuntu release or even a few weeks after the Ubuntu release is scheduled.

As Grandbois points out, this can create issues for the CKT when release schedules force the team to either adopto a brand-new kernel that hasn’t been fully tested, or an older one that’s already superseded.

This puts the CKT in a bit of a dilemma. Does Ubuntu release with a 2-3 month old upstream kernel that will likely be superseded on or near the release date? Or should the qualification period be shortened to make the release date, possibly with a lower confidence in stability? Or should the Ubuntu release date be adjusted accordingly, even with prior commitments made?

Moving forward, Grandbois says the CKT will adopt the newest available kernel, even if it’s not the final version.

The intent behind this post is to describe a new policy the CKT is taking in regards to kernel version selection for an upcoming Ubuntu release. To provide users with the absolute latest in features and hardware support, Ubuntu will now ship the absolute latest available version of the upstream Linux kernel at the specified Ubuntu release freeze date, even if upstream is still in Release Candidate (RC) status.

As a result of the change, Grandbois says the CKT will only be able to announce the kernel version for the next upcoming release, rather than being able to announce the planned kernel version for subsequent releases as well.

This is to be the kernel selection policy for all future Ubuntu releases, hence the description of LTS situations as well as the Interim 24.10 release.

With this policy we will be able to be more aggressive about making kernel version commitment announcements for an upcoming release at a much earlier date than previously. However, due to the uncoupled nature of the upstream and Ubuntu releases as described above the CKT will only be able to announce the kernel version for the next upcoming release, not any successive ones.

The new strategy should help users with newer hardware, providing them with the latest kernel and drivers out of the box. In contrast, current users often have to install a kernel that is slightly out-of-date, and then update it if it doesn’t fully support their hardware.

Given Canonical’s commitment to maintaining and supporting the kernel versions it uses, the change shouldn’t result in significant downsides for users.

Rust has been gaining traction in the developer community, thanks to a host of modern features. One of the biggest its its emphasis on memory safety, which greatly improves security since memory issues are one of the leading causes of vulnerabilities. Google has seen significant improvements to Android’s security as a result of incorporating Rust, Microsoft is similarly adding it to the Windows kernel, and the NSA has been encouraging companies to switch to Rust and similar languages.

DARPA’s Translating All C to Rust (TRACTOR) program is designed to help accelerate the transition from legacy C to Rust.

“You can go to any of the LLM websites, start chatting with one of the AI chatbots, and all you need to say is ‘here’s some C code, please translate it to safe idiomatic Rust code,’ cut, paste, and something comes out, and it’s often very good, but not always,” said Dr. Dan Wallach, DARPA program manager for TRACTOR. “The research challenge is to dramatically improve the automated translation from C to Rust, particularly for program constructs with the most relevance.”

“Rust forces the programmer to get things right,” added Wallach. “It can feel constraining to deal with all the rules it forces, but when you acclimate to them, the rules give you freedom. They’re like guardrails; once you realize they’re there to protect you, you’ll become free to focus on more important things.”

Interested developers can learn more here.

CrowdStrike pushed an updated to its cybersecurity update that crippled millions of Windows PCs around the world, bringing multiple industries to their knees. Because CrowdStrike’s software runs at the kernel level, it was nearly impossible to resolve the issue without physical access to the affected machines.

The FSF says the industry needs to learn from the incident, citing a number of issues that led to the outage, including automatic updates:

Let’s be clear: in principle, there is nothing ethically wrong with automatic updates so long as the user has made an informed choice to receive them. For instance, it’s perfectly understandable that a public library might not want to pore over kernel changelogs; they simply want to receive the update and move on with their work. At the same time, software bugs happen. Free software developers know this better than anyone. The Linux(-libre) kernel does not have some mystic immunity to them. What our community does have is a social structure that, most likely, would have rectified the situation swiftly.

The FSF also takes Microsoft to task for blaming CrowdStrike’s access to the Windows kernel as one of the main reasons for the outage:

In a cunning PR spin, it appears that Microsoft has started blaming the incident on third-party firms’ access to kernel source and documentation. Translated out of Redmond-ese, the point they are trying to make amounts to “if only we’d been allowed to be more secretive, this wouldn’t have happened!” Anyone with so much as a basic understanding of software development can see that this argument doesn’t hold water, just as anyone with a basic understanding of rhetoric can appreciate the irony that the same company that develops Copilot is whinging about the need to keep code secret from others. At this very minute, Copilot is ingesting free software on Microsoft’s proprietary platform, GitHub, with little respect for each program’s license.

In our own coverage of CrowdStrike, we pointed out our belief that the situation is slightly more nuanced than the above quote would make it seem. While open-source software does have a good track record with security—thanks to the source being easily inspected and audited—Microsoft being forced to open up kernel access is not an apples to apples comparison.

Windows is closed-source software. Similarly, much of CrowdStrike’s software is closed-source as well. As a result, CrowdStrike’s access to the Windows kernel is combining the worst options, namely marrying two closed-source platforms. Because both platforms are closed-source, they don’t benefit from the same open nature as true open-source software, and lack the transparency and ability to inspect and audit the code.

Nonetheless, the FSF is right that something needs to change:

We also need to see that calling for a diversity of providers of nonfree software that are mere front ends for “cloud” software doesn’t solve the problem. Correcting it fully requires switching to free software that runs on the user’s own computer.

The Free Software Foundation is often accused of being utopian, but we are well aware that moving airlines, libraries, and every other institution affected by the CrowdStrike outage to free software is a tremendous undertaking. Given free software’s distinct ethical advantage, not to mention the embarrassing damage control underway from both Microsoft and CrowdStrike, we think the move is a necessary one. The more public an institution, the more vitally it needs to be running free software.