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.

Apple has been improving Maps for years, building it into a legitimate rival to Google Maps. Conspicuously absent, however, was a web-based option. The company is now rectifying that, offering a beta of an all-new web-based version of Apple Maps.

Unfortunately, as of right now, access is extremely limited. Mac and iPad, as well as Windows, are the only platforms supported, with Linux and Android both blocked. Similarly, Safari, Edge, and Chrome are the only web browsers supported, with Firefox and Brave unsupported.

Hopefully, by the time Apple releases the final product it will support all platforms and all major web browsers.

Google Maps has lacked incident reporting since its inception, making it one of the most requested features among users. While Google is now introducing it, it is only doing so in a single country.

In its India blog post, Google announced the new feature:

Easily report incidents to help your community

One of the things that makes Google Maps so special is our passionate community of local contributors. India boasts the largest such community in the world, with over 60 million people sharing millions of reviews, photos, business edits, and road updates every day. This wealth of authentic, real-world information is a helpful resource for people navigating their everyday lives. We’re always looking for ways to make it easier for users to share valuable information to help the community.

We’ve simplified how you can report road incidents. Whether there’s ongoing construction or a traffic mishap on your route, you can now report it with just a few taps, making it easy and less distracting. You can even confirm others’ reports with a single tap which helps increase confidence in these user reported incidents. This update is available in India on Google Maps across all platforms – Android, iOS, Android Auto, and Apple CarPlay.

While Apple CarPlay has had the feature for some time, it looks like Google Maps users outside of India will have to wait to be able to access the feature.

Fedora’s maintainers originally proposed including opt-out telemetry in Fedora 40 Workstation, a proposition that drew widespread criticism and condemnation since it would be enabled by default. While the proposal emphasized that all telemetry would be anatomized, critics remained unconvinced. As a general rule, Linux users tend to value their privacy much more than Windows or Mac users, making opt-out telemetry a non-starter.

The maintainers took the criticism to heart and revamped the proposal, this time around opt-in telemetry, meaning users have to explicitly enable it. The revised proposal passed with a 6-0 vote.

The proposal includes the follow details:

The goal of this change proposal is to provide the Fedora community with accurate, representative data about the real world use of Fedora Workstation. By doing this, we believe that we can accelerate the development of Fedora Workstation, and ensure that it improves in line with our users’ needs and requirements.

Protecting user privacy is of utmost importance for this initiative. To this end, the service will only collect generic, standardized data, and will never collect anything that is personally identifying. It will also, of course, be fully open source. On the server side, the data will be stored in a way that prevents user identification.

Another important aspect of the initiative is that it will be run in a transparent manner, and will be governed as part of the Fedora project. Although this change is proposed by Red Hat, a new SIG will be responsible for the service and will be open to community participation. It will publish analyses of the data which has been collected, provide documentation about how the service operates, share samples of the database data, and respond to requests from the community.

Finally, we intend to ensure that metrics reporting is fully under the control of end users. Metrics collection will default to off, and will only be enabled through a clear on/off prompt in initial setup. Users will be able to view the data that has been collected locally, and will be able to remove the client software from their systems, should they choose to do so.

It’s good to see the Fedora maintainers listen to the community and change course. A number of open source projects—including KDE—use opt-in telemetry, demonstrating its viability as an option for privacy-conscious user bases.

Markdown is markup language that allows users to easily format plain text. The format is popular among writers, researchers, developers, content creators, and more, thanks to a variety of benefits. The Markdown Guide highlights some of the most popular reasons users opt for Markdown:

• Markdown is portable. Files containing Markdown-formatted text can be opened using virtually any application. If you decide you don’t like the Markdown application you’re currently using, you can import your Markdown files into another Markdown application. That’s in stark contrast to word processing applications like Microsoft Word that lock your content into a proprietary file format.
• Markdown is platform independent. You can create Markdown-formatted text on any device running any operating system.
• Markdown is future proof. Even if the application you’re using stops working at some point in the future, you’ll still be able to read your Markdown-formatted text using a text editing application. This is an important consideration when it comes to books, university theses, and other milestone documents that need to be preserved indefinitely.

Google says it is significantly improving Docs’ Markdown support:

In 2022, we introduced expanded support for composing with Markdown in Google Docs on web. Today, we’re introducing highly-requested features that enhance Docs’ interoperability with other Markdown supporting tools. These include the ability to:

• Convert Markdown to Docs content on paste
• Copy Docs content as Markdown
• Export a Doc as Markdown (from File > Download)
• Import Markdown as a Doc (from File > Open or “Open with Google Docs” from Drive)

This update is particularly useful for technical content writers as they can now convert Docs content to/from Markdown. For example, developers can collaborate on software documentation in Docs and then export it as Markdown for use in other Markdown supporting tools.

Google says the import/export options are enabled by default, while the “Copy as Markdown” and “Paste from Markdown” are off by default and will need to be enabled.

According to Reuters, GitLab is working with investment bankers to explore a possible sale, with cloud monitoring firm Datadog already expressing interest.

GitLab currently is valued at $8 billion, meaning any deal would be a substantial one at a time when regulators are growing increasingly critical of consolidation in the tech industry. As Reuters points out, GitLab has been facing growing challenges competing with GitHub, which was purchased by Microsoft and benefits from its parent company’s deep pockets.

Sid Sijbrandij, GitLab co-founder and CEO, is currently undergoing is second round of treatment for osteosarcoma. Although he has said he is working on a full recovery and will continue as CEO, it’s not outside the realm of possibility that his health could force him to reduce his role in the company.

It is also unclear what role Alphabet could play in a possible sale/acquisition, given the company controls 22.2% of GitLab’s voting shares.

Ultimately, it is too early in the process to know for sure if a deal will be reached.

Million was brought on in October 2023 to help the GNOME Foundation with its fundraising efforts. At the time, the foundation touted Million’s “three decades of invaluable experience in nonprofit management” as one of leading reasons behind hiring her.

Now, nine months later, Million is resigning to pursue a PhD in Psychology and to focus on her own private practice.

“I’m very proud of what I have accomplished in my time with GNOME,” Million said, “and I am dedicated to working with Richard through a transition to ensure that everything I have been working on is handed off smoothly. I will be pursuing a PhD in Psychology and dedicating myself to my own private practice. I want to thank all the wonderful people I have had the pleasure of connecting with here at GNOME, including the staff, board, advisors, founders, and volunteers. You have created something of real value in the world, and I look forward to seeing what you do next.”

The foundation touted the work Million has done in her short tenure:

On behalf of the whole GNOME community, the Board of Directors would like to give our utmost thanks to Holly for her achievements during the past 10 months, including drafting a bold five-year strategic plan for the Foundation, securing two important fiscal sponsorship agreements with GIMP and Black Python Devs, writing our first funding proposal that will now enable the Foundation to apply for more grants, vastly improving our financial operations, and implementing a break-even budget to preserve our financial reserves.

Richard Littauer has joined the foundation as Interim Executive Director while the search for a permanent replacement begins.

The Foundation’s Interim Executive Director, Richard Littauer, brings years of open source leadership as part of his work as an organizer of SustainOSS and CURIOSS, as a sustainability coordinator at the Open Source Initiative, and as a community development manager at Open Source Collective, and through open source contributions to many projects, such as Node.js and IPFS. The Board appointed Richard in June and is confident in his ability to guide the Foundation during this transitional period.

Docker images play an important role in software deployment, giving organizations a way to deploy and application with all the necessary dependencies. This make it easier to deploy, and has a number of security advantages, as Canonical explains.

The distroless container design paradigm describes containers that include only the files specifically required to run a single application. The goal is a container that is smaller and more difficult to exploit when vulnerabilities are discovered, because there are no surplus utilities or additional content inside the container that can aid an attacker.

Canonical will design Docker images for customers, incorporating all the necessary components and dependencies so the Docker image can be deployed on a number of platforms.

Canonical’s move to offer ‘Everything LTS’ expands Ubuntu Pro with thousands of new open source upstream components, including today’s latest AI/ML dependencies and tools for machine learning, training and inference, which are maintained as source alongside Ubuntu instead of as ‘deb’ packages. The CVE security maintenance commitment Canonical makes to these open source components facilitates compliance with regulatory baselines like FIPS, FedRAMP, EU Cyber Resilience Act (CRA), FCC U.S. Cyber Trust Mark and DISA-STIG.

Customers engage Canonical to design a Docker image of an open source application, or a base image that includes all of the open source dependencies to host their proprietary app. They get hardened distroless container images with a minimal attack surface and 12+ years CVE maintenance. The Docker image – an Open Container Initiative (OCI) standard container image format – runs natively on Ubuntu as well as Red Hat Enterprise Linux (RHEL), VMware Kubernetes or public cloud K8s. Canonical will support these custom-built images on all of those platforms.

“Everything LTS means CVE maintenance for your entire open source dependency tree, including open source that is not already packaged as a deb in Ubuntu” said Mark Shuttleworth, CEO of Canonical. “We deliver distroless or Ubuntu-based Docker images to your spec, which we will support on RHEL, VMware, Ubuntu or major public cloud K8s. Our enterprise and ISV customers can now count on Canonical to meet regulatory maintenance requirements with any open source stack, no matter how large or complex, wherever they want to deploy it.”

“Ensuring compliance with FedRAMP or HIPAA is very challenging for CISOs. This is the simplest and most cost effective way to run a large-scale, compliant container estate in hybrid or public clouds” said Alex Gallagher, Head of Public Cloud Alliances at Canonical. “We work closely with certified public clouds to optimise the security and performance of Kubernetes, and integrate Ubuntu Pro to provide seamless, frictionless access to LTS containers.”

Traditionally, apps downloaded from the App Store required double the amount of space as the downloaded app. For example, if a downloaded app takes 100 MB of space on disk, macOS would not allow a user to download the app unless there was 200 MB of free space.

In the release notes for macOS Sequoia 15 Beta 2, Apple says the issue now been addressed.

Starting in macOS 15, the App Store no longer needs twice the space free for an initial app download and install. The free space requirement will now be the final install size of the app, plus a small buffer. Developers should consider this change in any messaging they might have around size requirements.

The change is a welcome one. Although it won’t significantly impact most users, it will help out those who are struggling with limited disk space.

Major Nelson was at Microsoft for more than 22 years, serving as Senior Director Corporate Communications for the last 11. In that role, Major Nelson was often seen as the public face of Xbox. The executive announced in an X post that he was joining Unity, after leaving Microsoft nearly a year ago.

I am thrilled to announce that I’m joining the Community team at @unity! Building on my long history as a developer advocate at @Xbox, I’m excited to collaborate again with developers, harnessing our collective creativity to shape the future of real-time gaming and experiences. Let’s make magic happen!

Larry Hryb, Gamer Emeritus (@majornelson) | June 17, 2024

Major Nelson provided more information in a LinkedIn post, saying how excited he is about Unity’s future potential.

At Unity, I see a horizon brimming with potential. Unity’s mission of empowering creative and business success of creators around the world across games, apps, and experiences aligns with my lifelong passion for innovation and community building. I am eager to collaborate with the talented developers and creators who use Unity’s tools to bring their visions to life. Together, we’ll continue to transform the way stories are told and experiences are shared. I step into this new role with a heart full of memories and a spirit charged by the possibilities ahead.

Unity has had a rough year following a disastrous price change that led to widespread backlash from the developer community. While the company ultimately rolled back many of the changes, CEO John Riccitiello and CTO Marc Whitten both resigned in the aftermath.

Given Major Nelson’s status within the gaming community, he is a natural choice to head up community relations for a company that desperately needs to repair its relationships with its developer community.

The blue screen of death first debuted on Microsoft Windows where it gained notoriety for being painfully unhelpful. Despite that dubious past—or perhaps specifically to make fun of it—Linux devs have decided to co-opt the idea to alert the user when a kernel panic occurs.

Javier Martinez Canillas, a Red Hat and Fedora Linux dev, announced that the change has made its way to Linux (note “DRM panic” refers to “Direct Rendering Manager,” not “Digital Rights Management”).

A “Blue Screen Of Death” on the #BeaglePlay board, using the new DRM panic infrastructure contributed by my awesome colleague Jocelyn Falempe.

— Javier Martinez C. (@javierm@fosstodon.org) | June 15, 2024

The Linux blue screen of death code has been added as of Linux kernel 6.10.

C++ began its life as an extension of C, adding high-level and object-oriented features, something C traditionally lacked. Despite its advantages, C++ has played second fiddle to C, with the latter being preferred by many organizations for its performance and low-level power.

According to TIOBE, C++ has finally overtaken C as of June 2024.

“C++ is the new number 2 in the TIOBE index,” said Paul Jansen CEO TIOBE Software. “Originally, dubbed as the better and object-oriented version of C, it took C++ 39 years after its inception to beat C’s popularity. C++ has never been that high in the TIOBE index, whereas C has never been that low. C++ started a new life as of 2011 with its consistent 3 yearly updates. Although most compilers and most engineers can’t take up with this pace, it is considered a success to see the language evolve. The main strenghts of C++ are its performance and scalability. Its downside is its many ways to get things done, i.e. its rich idiom of features, which is caused by its long history and aim for backward compatibility. C++ is heavily used in embedded systems, game development and financial trading software, just to name a few domains.”

It remains to be seen if the rankings change is a permanent one, or merely a temporary statistical blip.

The Rust programming language has been growing in popularity thanks to a combination of factors, such as speed, security, memory safety, and more. As a result, it is increasingly being used in safety-critical software—such as in transportation, energy, and life sciences—and is one of the languages the NSA recommends.

The Foundation is launch is launching the Consortium in partnership with AdaCore, Arm, Ferrous Systems, HighTec EDV-Systeme GmbH, Lynx Software Technologies, OxidOS, TECHFUND, TrustInSoft, Veecle, and Woven by Toyota. The announcement says Consortium membership is open to Foundation members.

Work under the consortium will begin with the creation of a public charter and goals, and meeting minutes will be published on an ongoing basis. The Safety-Critical Rust Consortium will liaise with the Rust Project through Rust Foundation Project Directors and members of Rust Project teams. The Consortium’s scope, which will be fully delineated in the charter, may include the development of guidelines, linters, libraries, static analysis tools, formal methods and language subsets to meet industrial and legal requirements. The Consortium’s deliverables will be developed and licensed in a manner compatible with other Rust Project endeavors.

A number of critical Rust personnel voiced their support and endorsement:

“This is exciting! I am truly pleased to see the Rust Foundation and anyone in the safety-critical space coming together on this topic,” said Graydon Hoare, creator of the Rust programming language.

“Safety is our foremost priority in vehicle software development. Traditionally, achieving the highest levels of safety has been a complex and lengthy endeavor, requiring the use of specialized tools and processes beyond the programming language. We are therefore pleased to collaborate with leading experts in the safety industry to integrate new tools such as Rust into our safety-critical systems,” said JF Bastien, Distinguished Engineer at Woven by Toyota.

“Rust has already established itself as a safe and secure programming language with developers in open source, industry and governments. Now is the time to use that momentum towards bringing Rust as a mainstream language in safety-critical areas, providing processes and specifications that allow Rust to be certified in this space,” said Joel Marcey, Director of Technology at the Rust Foundation.

The Foundation says the creation of the Consortium will help fill a gap in well-established processes and collective industry knowledge.

Rust offers particular advantages in terms of developer ergonomics, productivity and software quality; however, it lacks a deep and established well of safety-processes and collective industry knowledge of safety-critical systems.

Without closing this gap, a developer must primarily rely on best practices and normative precautions, which can limit innovation. Rust developers who stray from the well-trod path can find themselves facing an inquiry were an accident to occur. In these circumstances, anything that seems unusual will be investigated for fault. This risk creates a disincentive to widespread Rust adoption, leaving developers unable to reap all its advantages while potentially facing financial, reputational and moral costs.

The announcement is good news for Rust developers and the Consortium should help the language continue to grow in popularity, while simultaneously fostering continued innovation among developers.