Long-time Slashdot reader xiando quotes the backstory from LinuxReviews.org: CentOS used to be the go-to alternative for those who wanted to use Red Hat Enterprise Linux (RHEL) without having to pay RedHat to use it. It was a almost 1:1 clone until RedHat took control of it and turned it into what is now a RHEL beta-version, not a stable RHEL release without the branding. Almalinux is one of several projects that have made their own RHEL forks in response. The first Almalinux version is now released.
ZDNet notes that CentOS co-founder Gregory Kurtzer has announced his own RHEL clone and CentOS replacement named Rocky Linux. But they offer this report on AlmaLinux: CloudLinux — which was founded in 2009 to provide a customized, high-performance, lightweight RHEL/CentOS server clone for multitenancy web and server hosting companies — came ready to deliver. The new free AlmaLinux is now stable and ready for production workloads. The company also announced the formation of a non-profit organization: AlmaLinux Open Source Foundation. This group will take over managing the AlmaLinux project going forward. CloudLinux has committed a $1 million annual endowment to support the project.

Jack Aboutboul, former Red Hat and Fedora engineer and architect, will be AlmaLinux's community manager. Altogether, Aboutboul brings over 20 years of experience in open-source communities as a participant, manager, and evangelist... "In an effort to fill the void soon to be left by the demise of CentOS as a stable release, AlmaLinux has been developed in close collaboration with the Linux community," said Aboutaboul in a statement. "These efforts resulted in a production-ready alternative to CentOS that is supported by community members...."

In talking with CentOS business users, who deployed CentOS on web and host servers, I found many of them to be very hopeful about AlmaLinux. One from a mid-Atlantic-based Linux hosting company said, "What we want is a stable Linux that our customers can rely on from year to year. Since CentOS Stream can't deliver that, we think — hope — that AlmaLinux can do it for us and our users instead...."

This first release of AlmaLinux is a one-to-one binary compatible fork of RHEL 8.3. Looking ahead, AlmaLinux will seek to keep step-in-step with future RHEL releases... The GitHub page has already been published and the completed source code has been published in the main download repository. The CloudLinux engineering team has also published FAQ on AlmaLinux Wiki.
"The sudden shift in direction for CentOS that was announced in December created a big void for millions of CentOS users," said Simon Phipps, open source advocate and a former president of the Open Source Initiative who is on the governing board of the AlmaLinux project. In a statement, Phipps said that "As a drop-in open-source replacement, AlmaLinux provides those users with continuity and new opportunity to be part of a vibrant community built around creating and supporting this new Linux distribution under non-profit governance.

"I give a lot of credit to CloudLinux for stepping in to offer CentOS users a lifeline to continue with AlmaLinux."

wiredog shares a ZDNet report: I have literally been covering SCO's legal attempts to prove that IBM illegally copied Unix's source code into Linux for over 17 years. I've written well over 500 stories on this lawsuit and its variants. I really thought it was dead, done, and buried. I was wrong. Xinuos, which bought SCO's Unix products and intellectual property (IP) in 2011, like a bad zombie movie, is now suing IBM and Red Hat [for] "illegally Copying Xinuos' software code for its server operating systems." For those of you who haven't been around for this epic IP lawsuit, you can get the full story with "27 eight-by-ten color glossy photographs and circles and arrows and a paragraph on the back of each one" from Groklaw. If you'd rather not spend a couple of weeks going over the cases, here's my shortened version. Back in 2001, SCO, a Unix company, joined forces with Caldera, a Linux company, to form what should have been a major Red Hat rival. Instead, two years later, SCO sued IBM in an all-out legal attack against Linux.

The fact that most of you don't know either company's name gives you an idea of how well that lawsuit went. SCO's Linux lawsuit made no sense and no one at the time gave it much of a chance of succeeding. Over time it was revealed that Microsoft had been using SCO as a sock puppet against Linux. Unfortunately for Microsoft and SCO, it soon became abundantly clear that SCO didn't have a real case against Linux and its allies. SCO lost battle after battle. The fatal blow came in 2007 when SCO was proven to have never owned the copyrights to Unix. So, by 2011, the only thing of value left in SCO, its Unix operating systems, was sold to UnXis. This acquisition, which puzzled most, actually made some sense. SCO's Unix products, OpenServer and Unixware, still had a small, but real market. At the time, UnXis now under the name, Xinuos, stated it had no interest in SCO's worthless lawsuits. In 2016, CEO Sean Synder said, "We are not SCO. We are investors who bought the products. We did not buy the ability to pursue litigation against IBM, and we have absolutely no interest in that." So, what changed? The company appears to have fallen on hard times. As Synder stated: "systems, like our FreeBSD-based OpenServer 10, have been pushed out of the market." Officially, in his statement, Snyder now says, "While this case is about Xinuos and the theft of our intellectual property, it is also about market manipulation that has harmed consumers, competitors, the open-source community, and innovation itself."

nickwinlund77 shares a report from The Register: The chorus of disapproval over Richard M Stallman, founder and former president of the Free Software Foundation (FSF), rejoining the organization has intensified as Linux giant Red Hat confirmed it was pulling funding. Stallman announced he had returned to the FSF's Board of Directors last weekend -- news that has not gone down well with all in the community and Red Hat is the latest to register its dismay.

CTO Chris Wright tweeted overnight: "I am really outraged by FSF's decision to reinstate RMS. At a moment in time where diversity and inclusion awareness is growing, this is a step backwards." Describing itself as "appalled" at the return of Stallman to the FSF board of directors "considering the circumstances of Richard Stallman's original resignation in 2019," Red Hat said it decided to act. "We are immediately suspending all Red Hat funding of the FSF and any FSF-hosted events. In addition, many Red Hat contributors have told us they no longer plan to participate in FSF-led or backed events, and we stand behind them," said Red Hat.

An anonymous reader shares an excerpt from a ZDNet article, written by Steven J. Vaughan-Nichols: Linux is the poster-child for the C language. But times change. The Rust language has been slowly gathering support for use as a system language in Linux. For example, at the 2020 Linux Plumbers Conference, developers gave serious thought to using the Rust language for new Linux inline code. So, where is it today? I asked Linux's creator, Linus Torvalds, and the Linux stable kernel maintainer Greg Kroah-Hartman for their thoughts. [...] What does Torvalds make of all this? He's in "the 'wait and see' camp -- I'm interested in the project, but I think it's driven by people who are very excited about Rust, and I want to see how it actually then ends up working in practice." "Personally," Torvalds is "in no way "pushing" for Rust, [but] I'm open to it considering the promised advantages and avoiding some safety pitfalls, but I also know that sometimes promises don't pan out."

Torvalds thinks "Rust's primary first target seems to be drivers, simply because that's where you find just a lot of different possible targets, and you have these individual parts of the kernel that are fairly small and independent. That may not be a very interesting target to some people, but it's the obvious one." Another point is taking on drivers first for "any initial trials to drivers is simply the architecture side," said Torvalds. "Lots of drivers are only relevant on a couple of target architectures, so the whole issue with Rust code not being supported on some architectures is less of an issue." Kroah-Hartman agrees that "drivers are probably the first place for an attempt like this as they are the 'end leafs' of the tree of dependencies in the kernel source. They depend on core kernel functionality, but nothing depends on them."

Torvalds knows some people don't like the idea of Rust in userspace at all. "People complain[ing] about "Rustification" in userspace isn't a great sign for any future kernel use, but hey, we'll see. The kernel is different from userspace projects -- more difficult in some respects (we use a lot of very odd header files that pushes the boundary of what can be called "C"), but easier in many other respects (mainly in the sense that the kernel is fairly self-contained, and then doesn't rely on other projects for the final binary)." From where Kroah-Hartman sits, "it will all come down to how well the interaction between the kernel core structures and lifetime rules that are written in C can be mapped into Rust structures and lifetime rules for drivers in Rust to be able to use them properly. That's going to take a lot of careful work by the developers wanting to hook this all up and I wish them the best of luck."

In his This Week in Programming column, Mike Melanson writes: Rustaceans' dreams of Rust's inclusion in the Linux kernel are one tiny, ever so slight step closer to becoming a reality, with this week's "intentionally bare-bones" inclusion in Linux-next, the development branch of the Linux kernel... Curb your enthusiasm, however, as this remains a rather tentative first step of many necessary steps before Rust fully lands in the Linux kernel.

A rather brief post on LWN.net summarizes where we are rather succinctly:

Followers of the linux-next integration tree may have noticed a significant addition: initial support for writing device drivers in the Rust language. There is some documentation in Documentation/rust, while the code itself is in the rust top-level directory. Appearance in linux-next generally implies readiness for the upcoming merge window, but it is not clear if that is the case here; this code has not seen a lot of wider review yet. It is, regardless, an important step toward the ability to write drivers in a safer language.

Indeed, Miguel Ojeda, a software developer and maintainer of the Rust for Linux project writes that the proposed inclusion "does not mean we will make it into mainline, of course, but it is a nice step to make things as smooth as possible," with some changes expected before any decision as to Rust's inclusion are made.

For those of you less familiar with Rust, part of the appeal here comes with Rust's memory safety features, especially in comparison to C, which the Linux kernel is currently coded in. Part of the problem, however, is that Rust is compiled based on LLVM, as opposed to GCC, and subsequently supports fewer architectures. This is a problem we've seen play out recently, as the Python cryptography library has replaced some old C code with Rust, leading to a situation where certain architectures will not be supported. Presently, the proposal to include Rust in the Linux kernel limits this issue by saying that Rust would be used, at least initially, for writing drivers that, as noted in another LWN.net article on the topic, "would never be used on the more obscure architectures anyway."

"Three recently unearthed vulnerabilities in the Linux kernel, located in the iSCSI module used for accessing shared data storage facilities, could allow root privileges to anyone with a user account," reports SC Media: "If you already had execution on a box, either because you have a user account on the machine, or you've compromised some service that doesn't have repaired permissions, you can do whatever you want basically," said Adam Nichols, principal of the Software Security practice at GRIMM. While the vulnerabilities "are in code that is not remotely accessible, so this isn't like a remote exploit," said Nichols, they are still troublesome. They take "any existing threat that might be there. It just makes it that much worse," he explained. "And if you have users on the system that you don't really trust with root access it, it breaks them as well."

Referring to the theory that 'many eyes make all bugs shallow,' Linux code "is not getting many eyes or the eyes are looking at it and saying that seems fine," said Nichols. "But, [the bugs] have been in there since the code was first written, and they haven't really changed over the last 15 years...." That the flaws slipped detection for so long has a lot to do with the sprawl of the the Linux kernel. It "has gotten so big" and "there's so much code there," said Nichols. "The real strategy is make sure you're loading as little code as possible."

The bugs are in all Linux distributions, Nichols said, although the kernel driver is not loaded by default. Whether a normal user can load the vulnerable kernel module varies. They can, for instance, on all Red Hat based distros that GRIMM tested, he said. "Even though it's not loaded by default, you can get it loaded and then of course you can exploit it without any trouble...."

The bugs have been patched in the following kernel releases: 5.11.4, 5.10.21, 5.4.103, 4.19.179, 4.14.224, 4.9.260, and 4.4.260. All older kernels are end-of- life and will not receive patches.

An official version of the popular 7-zip archiving program has been released for Linux for the first time. Bleeping Computer reports: Linux already had support for the 7-zip archive file format through a POSIX port called p7zip but it was maintained by a different developer. As the p7zip developer has not maintained their project for 4-5 years, 7-Zip developer Igor Pavlov decided to create a new official Linux version based on the latest 7-Zip source code. Pavlov has released 7-Zip for Linux in AMD64, ARM64, x86, and armhf versions, which users can download [via their respective links].

"These new 7-Zip binaries for Linux were linked (compiled) by GCC without -static switch. And compiled 32-bit executables (x86 and armhf) didn't work on some arm64 and amd64 systems, probably because of missing of some required .so files." "Please write here, if you have some advices how to compile and link binaries that will work in most Linux systems," Pavlov stated on his release page.

The Linux Foundation has announced the launch of Sigstore, a new nonprofit initiative that aims to improve open source software supply chain security by making it easier for developers to adopt cryptographic signing for different components of the software development process. From a report: Sigstore will be free for software providers and developers, who can use it to securely sign software artifacts such as release files, container images, binaries, and bill-of-material manifests. Signing materials are then stored in a tamper-proof public log. The service's code and operation tooling will be fully open source and maintained and developed by the Sigstore community. Founding members include Red Hat, Google, and Purdue University. The idea for the service came from Luke Hinds, security engineering lead in Red Hat's Office of the CTO. He pitched the concept to Google software engineer Dan Lorenc, and the two began to work on it. Now the Sigstore project has a "small but agile community" working on its development, Lorenc says.

David Plummer is a retired Microsoft operating systems engineer, "going back to the MS-DOS and Windows 95 days." (He adds that in the early '90s he'd fixed a few handle leaks in the early source code of Linux, "and sent my changes off to Linus at Rutgers.")

This weekend on YouTube he shared his thoughts on "the classic confrontation: Windows versus Linux," promising an "epic operating systems face-off." Some highlights: On Usability: "Linux's itself lacks a proper user interface beyond the command line. That command line can be incredibly powerful, particularly if you're adept with Bash or Zsh or similar, but you can't really describe it as particularly usable. Of course most distributions do come with a desktop user interface of some kind if you prefer, but as a bit of a shell designer myself, if I might be so bold, they're generally pretty terrible. At least the Mint distribution looks pretty nice.

"Windows, on the other hand, includes by default a desktop shell interface that, if you set aside the entirely subjective design aesthetics, is professionally designed, usability tested and takes into consideration the varying levels of accessibility required by people with different limitations. In terms of usability, particularly if you do include accessibility in that metric, Windows comes out ahead..."

On Updates: "Windows users are well served by a dedicated Windows Update team at Microsoft, but the process has occasionally had its hiccups and growing pains. It's very easy to update a Linux system, and while there's no professional team sitting by the big red phone ready to respond to Day Zero exploits, the updates do come out with reasonable alacrity, and in some cases you can even update the kernel without rebooting.

"Keep in mind, however, that Linux is a monolithic kernel, which means that it's all one big happy kernel. Almost everything is in there. If they hadn't started to add that ability a few years back, you'd be rebooting for every driver install. The reality is that some parts of the Linux kernel are just going to require a reboot, just as some parts of the Windows system are going to as well. I think we can likely all agree, however, that Windows software is hardly selective about rebooting the system, and you're asked to do it far too often.

"While we're on the topic of upgrades, we can't overlook the fact that upgrades are generally free in the Open Source world, unless you're using a pre-built distribution from a vendor. To it's credit, though, I don't remember the last time Microsoft actually charged for an operating system upgrade if you were just a normal end user or enthusiast. Still, this point goes to Linux."
Plummer also says he agrees with the argument that open source software is more open to security exploits, "simply because, all else equal, it's easy to figure out where the bugs are to exploit in the first place," while proprietary software has professional test organizations hunting for bugs. "I think it's a bit of a fallacy to rely on the 'many eyeballs' approach..."

Yet he still ultimately concludes Linux is more secure simply because the vast universe of Windows makes it a much more attractive target. Especially since most Windows users retain full administrator privileges...

Slashdot reader b-dayyy quotes the Linux Security blog: While all Linux 'distros' — or distributed versions of Linux software — are secure by design, certain distros go above and beyond when it comes to protecting users' privacy and security. We've put together a list of our favorite specialized secure Linux distros and spoken with some of their lead developers to find out first-hand what makes these distros so great.
This "favorites" list cites six "excellent specialized secure Linux distros." Some highlights from the article:

• In a conversation with the LinuxSecurity editors, Qubes OS Community Manager Andrew David Wong elaborated, "Rather than attempting to fix all of the security bugs in software, Qubes assumes that all software is buggy and compartmentalizes it accordingly, so that when flaws are inevitably exploited, the damage is contained and the user's most valuable data is protected."

• A Kali Linux contributor provides some insight into the distro's history and the benefits it offers users: "Named after a Hindu goddess, Kali has been around for a long time — but it's still updated weekly, can be run in live mode or installed to a drive, and can also be used on ARM devices like Raspberry Pi."

Obviously there's strong opinions among Slashdot readers. So share your own thoughts in the comments.

What's the best Linux distro for enhanced privacy and security?

"In a message to the Linux Kernel Mailing List Wednesday, founding developer Linus Torvalds warned the world not to use the 5.12-rc1 kernel in his public git tree..." writes Ars Technica: As it turns out, when Linus Torvalds flags some code dontuse, he really means it — the problem with this 5.12 release candidate broke swapfile handling in a very unpleasant way. Specifically, the updated code would lose the proper offset pointing to the beginning of the swapfile. Again, in Torvalds' own words, "swapping still happened, but it happened to the wrong part of the filesystem, with the obvious catastrophic end results."

If your imagination is insufficient, this means that when the kernel paged contents of memory out to disk, the data would land on random parts of the same disk and partition the swapfile lived on... not as files, mind you, but as garbage spewed directly to raw sectors on the disk. This means overwriting not only data in existing files, but also rather large chunks of metadata whose corruption would likely render the entire filesystem unmountable and unusable.

Torvalds goes on to point out that if you aren't using swap at all, this problem wouldn't bite you. And if you're using swap partitions, rather than swap files, you'd be similarly unaffected...
Torvalds also advised anyone who'd already pulled his git tree to do a git tag -d v5.12-rc1 "to actually get rid of the original tag name..." — or at least, to not use it for anything.

"I want everybody to be aware..." Torvalds writes, "because _if_ it bites you, it bites you hard, and you can end up with a filesystem that is essentially overwritten by random swap data. This is what we in the industry call 'double ungood'."

Linux overlord Linus Torvalds has revealed that inclement weather in the USA meant he recently endured six electricity-free days in his Portland, Oregon, home during which he was unable to tend to the kernel. As a result he therefore pondered adding an extra week to the merge window for version 5.12 of the Linux kernel. The Register reports: "As you can tell, I didn't do that," he said in his State of The Kernel update that announced release candidate one of the new kernel cut. "To a large part because people were actually very good about sending in their pull requests, so by the time I finally got power back, everything was nicely lined up and I got things merged up ok." It wasn't just penguinistas behaving well that helped. Torvalds said this version of the kernel has received around 10,000 commits. That's rather fewer than the 12,000 or 13,000 he usually sees.

In case anyone was inconvenienced by blackout-induced inability to merge, Torvalds said he's open to help any kernel devs for whom his unavailability caused problems but is not open to all late pulls. Torvalds rated the new release as offering "a fair amount of historical cleanup" on account of "removing the legacy OPROFILE support (the user tools have been using the "perf" interface for years), and removing several legacy SoC platforms and various drivers that no longer make any sense." Among the big inclusions in 5.12 are Clang Link-Time Optimizations, which make for better compiler performance, and support for Intel's eASIC NX5 silicon that aims to offer an alternative to FPGAs in edge and cloud applications. Qualcomm's Snapdragon 888 5G SoC also gains support.

AmiMoJo shares a report: Last month, the Linux Mint team published a post on the organization's official blog about the importance of installing security updates on machines running the Linux distribution. The essence of the post was that a sizeable number of Linux Mint devices was running outdated applications, packages or even an outdated version of the operating system itself. A sizeable number of devices run on Linux Mint 17.x, according to the blog post, a version of Linux Mint that reached end of support in April 2019. A new blog post, published yesterday, provides information on how the team plans to reduce the update reluctance of Linux Mint users. Next to showing reminders to users, Linux Mint's Update Manager may enforce some of the updates according to the blog post.

"In some cases the Update Manager will be able to remind you to apply updates. In a few of them it might even insist." Upcoming versions will provide information on the implementation, how the "insisting" part may look like, and whether the installation of updates will be enforced. All of this boils down to a single question: how far should operating system developers go when it comes to updates? BetaNews adds: "And now, it seems the Linux Mint developers are taking a page out of Microsoft's playbook by planning to force some updates on its users. Yes, folks, Linux Mint is becoming more like Windows 10."

Slashdot reader b-dayyy writes: CrowdSec is a massively multiplayer firewall designed to protect Linux servers, services, containers, or virtual machines exposed on the Internet with a server-side agent. It was inspired by Fail2Ban and aims to be a modernized, collaborative version of that intrusion-prevention tool.

CrowdSec is free and open-source (under an MIT License), with the source code available on GitHub. It uses a behavior analysis system to qualify whether someone is trying to hack you, based on your logs. If your agent detects such aggression, the offending IP is then dealt with and sent for curation. If this signal passes the curation process, the IP is then redistributed to all users sharing a similar technological profile to 'immunize' them against this IP.

The goal is to leverage the power of the crowd to create a real-time IP reputation database. As for the IP that aggressed your machine, you can choose to remedy the threat in any manner you feel appropriate. Ultimately, CrowdSec leverages the power of the community to create an extremely accurate IP reputation system that benefits all its users.

It was clear to the founders that Open Source was going to be one of the main pillars of CrowdSec. The project's founders have been working on open-source projects for decades — they didn't just jump on the train. Rather, they are strong Open Source believers. They believe that the crowd is key to the mass hacking plague we are experiencing, and that Open Source is the best lever to create a community and have people contribute their knowledge to the project, ultimately make it better and more secure.

The solution recently turned 1.x, introducing a major architectural change: the introduction of a local REST API.

Slashdot reader Finuz writes: Offensive Security has released Kali Linux 2021.1, the latest version of its popular open source penetration testing platform. You can download it or upgrade to it. Kali NetHunter, the distro's mobile pentesting platform, now has an upgraded BusyBox engine and tools updated to the latest version (or, in some cases, completely rewritten). There are two new Kali ARM images: one that can be used with VMs on Apple Silicon Macs (Apple M1) and the other for the Raspberry Pi 400's wireless card.

ZDNet brings an update about the future of Red Hat Enterprise Linux: When Red Hat, CentOS's Linux parent company, announced it was "shifting focus from CentOS Linux, the rebuild of Red Hat Enterprise Linux (RHEL), to CentOS Stream," CentOS users were not happy. Now, in an effort to mollify them and to keep its promise to open-source organizations, Red Hat is introducing a new, free RHEL for Open Source Infrastructure. If your non-profit organization, project, standard body, or foundation is "engaged with open source," you can get a free RHEL subscription via this program. Earlier this year, Red Hat introduced no-cost RHEL for small production workloads and for customer development teams...

Jason Brooks, a Red Hat Open Source Program Office Manager explained:

Supporting the open-source software ecosystem is a core objective for Red Hat... We know that we are part of a larger, interdependent ecosystem that we benefit from and which we do our best to foster and support. This support comes in many forms, but often includes helping open source software projects, foundations, and standards bodies access enterprise technologies for development and testing.

We frequently provide no-cost access to RHEL to these groups, but the process isn't as formalized, consistent, accessible, or transparent as we'd like it to be. With the announcement that we will be shifting our resources to CentOS Stream at the end of 2021, we want to make sure that those organizations engaged with open source have access to RHEL as they build and test the future of open-source software...

The GNOME Foundation's executive director Neil McGovern, said:

As a non-profit, we rely on donations to help us achieve our goal of a world where everyone is empowered by technology they can trust. RHEL subscriptions are an essential part of this. With full operating system management and security updates, we can concentrate on the services we provide to GNOME users and developers without having to worry about the underlying systems. Red Hat has generously provided these services to GNOME at zero cost for years, and we look forward to continuing our relationship for a long time to come.

GNOME is also the default desktop in RHEL Workstation.

Worried about the security of Linux and open-source code, Google is sponsoring a pair of full-time developers to work on the kernel's security. From a report: The internet giant builds code from its own repositories rather than downloading outside binaries, though given the pace at which code is being added to Linux, this task is non-trivial. Google's open-source security team lead Dan Lorenc spoke to The Register about its approach, and why it will not use pre-built binaries despite their convenience. But first: the two individuals full-time sponsored by Google are Gustavo Silva, whose work includes eliminating some classes of buffer overflow risks and on kernel self-protection, and Nathan Chancellor, who fixes bugs in the Clang/LLVM compilers and improves compiler warnings. Both are already working at the Linux Foundation, so what is new?

"Gustavo's been working on the Linux kernel at the Linux Foundation for several years now," Lorenc tells us. "We've actually been sponsoring it within the Foundation for a number of years. The main change is that we're trying to talk about it more, to encourage other companies to participate. It's a model that works, we're trying to expand it, find contributors that want to turn this into a full-time thing, and giving them the funding to do that." It is in the nature of open source that Google's funding benefits other Linux users, and it is also in the company's interests. How important is Linux to Google? "It's absolutely critical. Google started on Linux. We use it everywhere," says Lorenc. That being the case, why can Google only manage "Gold" membership of the Linux Foundation ($100,000 per annum), whereas others including Microsoft, Intel, Facebook, and Red Hat are "Platinum", which contributes $500,000 annually? "I'm not sure about that stuff. There are dozens of sub-foundations which we are also members of," he adds. Google is ahead of AWS, which is a mere "Silver" member ($20,000 a year).

"When NASA's Perseverance rover landed on Mars this week, it also brought the Linux operating system to the Red Planet," reports PC Magazine: The tidbit was mentioned in an interview NASA software engineer Tim Canham gave to IEEE Spectrum. The helicopter-like drone on board the Perseverance rover uses a Linux-powered software framework the space agency open-sourced a few years ago. "This the first time we'll be flying Linux on Mars. We're actually running on a Linux operating system," Canham said.

It also might be the first time NASA has brought a Linux-based device to Mars. "There isn't a previous use of Linux that I'm aware of, definitely on the previous rovers," Canham told PCMag in an email.

Past Mars rovers have used proprietary OSes, largely from the software company Wind River Systems. The same is true for the Perseverance rover itself; the machine has been installed with Wind River's VxWorks, which was used on past Mars missions.
The article also notes that the helicopter-like drone Ingenuity "was built using off-the-shelf parts, including Qualcomm's Snapdragon 801 processor, a smartphone chip."

"Ingenuity is purely a technology demonstration," notes ZDNet. "It's not designed to support the Perseverance mission, which is searching for signs of ancient life and collecting rock and dirt samples for later missions to return to Earth. Its mission is to show that it's possible to fly on Mars using commercial off-the-shelf hardware and open-source software."

When Dave McKay first used computers, punched paper tape was in vogue, "and he has been programming ever since," according to his biography page at How-To Geek. It adds that "His use of computers pre-dates the birth of the PC and the public release of Unix."

Now long-time Slashdot reader sbinning shares McKay's "short history of UNIX and how Linux got its start," which ultimately asks if commercial Unix was killed by Linux: Unix is still out there, running mission-critical systems that are functioning correctly, and operating stably. That'll continue until the support for the applications, operating systems or hardware platform ceases. If something's genuinely mission-critical and it's working, you leave it working. I suspect someone, somewhere, will always be running a commercial UNIX or Unix-like operating system.

But for new installs? There are enough variations of Linux to make the case to go for a commercial Unix very, very difficult.

According to Phoronix, AMD currently has several interesting job openings on the Linux front. From the report: While AMD has been delivering reliable Linux support with their recent launches, there is room for improvement in areas like more timely compiler support for new processors, better alignment of their new hardware enablement for getting the code not only upstreamed but into distributions for launch-day, and similar areas. Based on recent job postings, it looks like AMD is working to make such strides.

Here is a look at some of the new and currently active Linux-related job openings at AMD: [Manager Linux Kernel Development, Linux Technical Lead, Linux Engineer, and Linux Systems Architect, among other traditional software/hardware engineering roles].

Several of these new job descriptions do begin with, "step up into a new organization built to engage more strategically and deeply with the technical teams of our commercial customers." Interestingly, I only see that opening line on their current Linux job postings. When asking AMD if there is a "new (Linux) organization" at AMD, the comment was there is no organization to announce but this is part of the overall expansion at AMD. So for now it's back to dreaming about a new unit akin to the defunct AMD Operating System Research Center that previously drove their Linux support or Intel's former Open-Source Technology Center.