An anonymous reader quotes a report from ZDNet, written by Steven J. Vaughan-Nichols: Microsoft now has its very own, honest-to-goodness general-purpose Linux distribution: Common Base Linux, (CBL)-Mariner. And, just like any Linux distro, you can download it and run it yourself. Microsoft didn't make a big fuss about releasing CBL-Mariner. It quietly released the code on GitHub and anyone can use it. Indeed, Juan Manuel Rey, a Microsoft Senior Program Manager for Azure VMware, recently published a guide on how to build an ISO CBL-Mariner image. Before this, if you were a Linux expert, with a spot of work you could run it, but now, thanks to Rey, anyone with a bit of Linux skill can do it.

CBL-Mariner is not a Linux desktop. Like Azure Sphere, Microsoft's first specialized Linux distro, which is used for securing edge computing services, it's a server-side Linux. This Microsoft-branded Linux is an internal Linux distribution. It's meant for Microsoft's cloud infrastructure and edge products and services. Its main job is to provide a consistent Linux platform for these devices and services. Just like Fedora is to Red Hat, it keeps Microsoft on Linux's cutting edge. CBL-Mariner is built around the idea that you only need a small common core set of packages to address the needs of cloud and edge services. If you need more, CBL-Mariner also makes it easy to layer on additional packages on top of its common core. Once that's done, its simple build system easily enables you to create RPM packages from SPEC and source files. Or, you can also use it to create ISOs or Virtual hard disk (VHD) images.

As you'd expect the basic CBL-Mariner is a very lightweight Linux. You can use it as a container or a container host. With its limited size also comes a minimal attack surface. This also makes it easy to deploy security patches to it via RPM. Its designers make a particular point of delivering the latest security patches and fixes to its users. For more about its security features see CBL-Mariner's GitHub security features list. Like any other Linux distro, CBL-Mariner is built on the shoulders of giants. Microsoft credits VMware's Photon OS Project, a secure Linux, The Fedora Project, Linux from Scratch -- a guide to building Linux from source, the OpenMamba distro, and, yes, even GNU and the Free Software Foundation (FSF). To try it for yourself, you'll build it on Ubuntu 18.04. Frankly, I'd be surprised if you couldn't build it on any Ubuntu Linux distro from 18.04 on up. I did it on my Ubuntu 20.04.2 desktop. You'll also need the latest version of the Go language and Docker.

"The Rust for Linux project, sponsored by Google, has advanced..." reported the Register earlier this week: A new set of patches submitted to the Linux kernel mailing list summarizes the progress of the project to enable Rust to be used alongside C for implementing the Linux kernel. The progress is significant.

- ARM and RISC-V architectures are now supported, thanks to work on rustc_codgen_gcc, which is a GCC codegen for rustc. This means that rustc does the initial compilation of Rust code but GCC (the GNU Compiler Collection) does the backend compilation, enabling support for the architectures that GCC supports...

- Overall, "the Rust support is still to be considered experimental. However, as noted back in April, support is good enough that kernel developers can start working on the Rust abstractions for subsystems and write drivers and other modules," continued project leader Miguel Ojeda, a computer scientist at CERN in Geneva, Switzerland, now working full time on Rust for Linux...

There is substantial support for the project across the industry. Google said in April "we feel that Rust is now ready to join C as a practical language for implementing the kernel" and that it would reduce the number of potential bugs and security vulnerabilities. Google is sponsoring Ojeda to work full time on the project for a year, via the ISRG (Internet Security Research Group), which said last month that it is part of "efforts to move the internet's critical software infrastructure to memory safe code," under the project name Prossimo. The ISRG is also the nonprofit organisation behind Let's Encrypt free security certificates. Ojeda also mentioned that Microsoft's Linux Systems Group is contributing and hopes to submit "select Hyper-V drivers written in Rust." Arm is promising assistance with Rust for Linux on ARM-based systems. IBM has contributed Rust kernel support for its PowerPC processor.

More detail is promised at the forthcoming Linux Plumber's Conference in September. In the meantime, the project is on GitHub here.
"In addition, we would like to announce that we are organizing a new conference that focuses on Rust and the Linux kernel..." Ojeda posted. "Details will be announced soon." And for context, the Register adds: Linus Torvalds has said on several occasions that he welcomes the possibility of using Rust alongside C for kernel development, and told IT Wire in April that it is "getting to the point where maybe it might be mergeable for 5.14 or something like that."

"Linus Torvalds has just released the Linux 5.13 kernel as stable," reports Phoronix: Linux 5.13 brings initial but still early support for the Apple M1 with basic support but not yet accelerated graphics and a lot more to iron out moving ahead. There are also new Linux 5.13 security features like the Landlock security module, Clang control flow integrity support, and optionally randomizing the kernel stack offset at each system call. There is also AMD fun this cycle around FreeSync HDMI support, initial Aldebaran bring-up, and more. Intel has more work on Alder Lake, a new cooling driver, and more discrete graphics bring-up. There are also other changes for Linux 5.13 around faster IO_uring, a generic USB display driver, and other new hardware enablement.
"5.13 overall is actually fairly large," Linus Torvalds posted on the Linux Kernel Mailing List, calling it "one of the bigger 5.x releases, with over 16,000 commits (over 17k if you count merges), from over 2,000 developers. But it's a "big all over" kind of thing, not something particular that stands out as particularly unusual..."

"When Red Hat killed off CentOS Linux in a highly controversial December 2020 announcement, Gregory Kurtzer immediately announced his intention to recreate CentOS with a new distribution named after his deceased mentor," Ars Technica reported in February.

And this week, "The Rocky Enterprise Software Foundation has announced general availability (GA) of Rocky Linux 8.4," reports ZDNet. "It's an important milestone because it's the first Rocky Linux general availability release ever." Huge companies, including Disney, GoDaddy, Rackspace, Toyota and Verizon, relied on CentOS, and they were reportedly not happy about RedHat's decision... It turns out that Kurtzer's decision has been a popular one. Besides quickly building up an army of hundreds of contributors for the project, Rocky Linux 8.4 - which follows the May 18 release of Red Hat's RHEL 8.4 - was downloaded at least 10,000 times within half a day of its release... "If we extrapolate the count to include our other mirrors we are probably at least 3-4x that (if not even way more)!" boasts Kurtzer in a LinkedIn post. "Lots of reports coming in of people and organizations already replacing their CentOS systems (and even other Linux distributions) with Rocky. The media is flying off the hook and business analysts also validating to me personally that Rocky Linux might soon be the most utilized Linux operating system used in enterprise and cloud!"

Rocky Linux 8.4 took seven months for the newly formed community to release, and is available for x86_64 and ARM64 (aarch64) architecture hardware in various ISOs.
"Sufficient testing has been performed such that we have confidence in its stability for production systems," explains a blog post at RockyLinux.org, adding that free community support is available through the forums as well as live chat avaiable through IRC and Rocky Linux Mattermost. "Paid commercial support is currently available through CIQ..."

"Corporations come and go, their interests as transient as they are self-serving. But a community persists, and that's who we dedicate Rocky Linux to: you." Rocky is more than the next free and open, community enterprise operating system. It's a community. A commitment to an ideal bigger than the sum of its parts, and a promise that our principles — embedded even within our repositories and ISOs — are immutable...

This is just the beginning, and the Rocky Enterprise Software Foundation is more than just Rocky Linux — it's a home for those that believe that open source isn't just a switch that can be toggled at will, and that projects that many rely on not be subject to the whims of a few. To this point, you can easily find all of our sources, our build infrastructure, Git repositories, and everything else anyone would need to fork our work and ensure that it continues if need be...

When we announced our release candidate, we asked you to come build the next free, open, community enterprise operating system with us. Now we're asking you for more: join us as we build our community.
They also thanked 11 sponsors and partners for contributing "resources, financial backing, software, and infrastructure."

mrflash818 writes: The Internet Security Research Group (ISRG) -- parent organization of the better-known Let's Encrypt project -- has provided prominent developer Miguel Ojeda with a one-year contract to work on Rust in Linux and other security efforts on a full-time basis. Rust is a low-level programming language offering most of the flexibility and performance of C -- the language used for kernels in Unix and Unix-like operating systems since the 1970s -- in a safer way. Efforts to make Rust a viable language for Linux kernel development began at the 2020 Linux Plumbers conference, with acceptance for the idea coming from Linus Torvalds himself. Torvalds specifically requested Rust compiler availability in the default kernel build environment to support such efforts -- not to replace the entire source code of the Linux kernel with Rust-developed equivalents, but to make it possible for new development to work properly. Using Rust for new code in the kernel -- which might mean new hardware drivers or even replacement of GNU Coreutils -- potentially decreases the number of bugs lurking in the kernel. Rust simply won't allow a developer to leak memory or create the potential for buffer overflows -- significant sources of performance and security issues in complex C-language code.

"Everything from Visual Studio Code to Microsoft Edge and Teams package links were affected," reports Windows Central. They note Azure's status page (which now shows the issue lasting for more than 22 hours), though however long it lasted, "it's a virtual eternity for those whose entire ecosystem is crippled by such an outage."

According to Ars Technica, starting on Wednesday, "packages.microsoft.com — the repository from which Microsoft serves software installers for Linux distributions including CentOS, Debian, Fedora, OpenSUSE, and more — went down hard..." The outage impacted users trying to install .NET Core, Microsoft Teams, Microsoft SQL Server for Linux (yes, that's a thing) and more — as well as Azure's own devops pipelines.

We first became aware of the problem Wednesday evening when we saw 404 errors in the output of apt update on an Ubuntu workstation with Microsoft Teams installed. The outage is somewhat better-documented at this .NET Core issue report on Github, with many users from all around the world sharing their experiences and theories...

The entire repository cluster that serves all Linux packages for Microsoft was completely down — issuing a range of HTTP 404 (content not found) and 500 (Internal Server Error) messages for any URL — for roughly 18 hours. Microsoft engineer Rahul Bhandari confirmed the outage roughly five hours after it was initially reported, with a cryptic comment about the infrastructure team "running into some space issues."

Eighteen hours after the issue was detailed, Bhandari said that the mirrors were once again available — although with temporarily degraded performance, likely due to cold caches.

"Google said Thursday it's funding a project to increase Linux security by writing parts of the operating system's core in the Rust programming language, a modernization effort that could bolster the security of the internet and smartphones," reports CNET: If the project succeeds, it'll be possible to add new elements written in Rust into the heart of Linux, called the kernel. Such a change would mark a major technological and cultural shift for an open-source software project that's become foundational to Google's Android and Chrome operating systems as well as vast swaths of the internet. Miguel Ojeda, who's written software used by the Large Hadron Collider particle accelerator and worked on programming language security, is being contracted to write software in Rust for the Linux kernel. Google is paying for the contract, which is being extended through the Internet Security Research Group, a nonprofit that's also made it easier to secure website communications through the Let's Encrypt effort.

Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages...

Google credits the Linux community programmers who began the Rust for Linux project. "The community had already done and continues to do great work toward adding Rust support to the Linux kernel build system," Google said in a blog post...

[Rust] has been the most loved programming language for five years running in Stack Overflow's annual developer survey. "Rust represents the best alternative to C and C++ currently available," Microsoft's security team concluded in 2019. The team said Rust would have prevented memory problems at fault in 70% of its significant security issues. And because Rust's checks happen while software is being built, the safety doesn't come at the expense of performance when the software is running.

The goal of the Linux on Rust project isn't to replace all of Linux's C code but rather to improve selective and new parts.

The nonprofit Linux Foundation "asked the open source community: How has Linux impacted your life? Needless to say, responses poured in from across the globe sharing memories, sentiments and important moments that changed your lives forever."

Their web site now features a selection of stories from America, Canada, Brazil, Chile, Costa Rica, Ireland, Germany, France, Italy, Sweden, the Netherlands, Nigeria, South Africa, India, Nepal, Sri Lanka, Kuwait, the Philippines, Bosnia & Herzegovina and China. And each story's author received a special honor... We are grateful you took the time to tell us your stories. We're thrilled to share 30 of the responses we received, randomly selected from all submissions.

As a thank you to these 30 folks for sharing their stories, and in celebration of the 30th Anniversary of Linux, 30 penguins were adopted from the Southern African Foundation for the Conservation of Coastal Birds in their honor, and each of our submitters got to name their adopted penguin.
One Kuwait-based developer had written "when I was able to use it instead of Windows, it made me happier because I didn't have to restart it every couple of days for instability."

And a story from Nepal says "Linux enabled me to become a software engineer. I would not have been able to afford Microsoft Windows... I had the opportunity to interact with various people from great communities and learn from their contributions. So I am very much thankful to Linus and each and every member of the free and open source community for helping me become a better programmer and a better person."

Google said Thursday it's funding a project to increase Linux security by writing parts of the operating system's core in the Rust programming language, a modernization effort that could bolster the security of the internet and smartphones. From a report: If the project succeeds, it'll be possible to add new elements written in Rust into the heart of Linux, called the kernel. Such a change would mark a major technological and cultural shift for an open-source software project that's become foundational to Google's Android and Chrome operating systems as well as vast swaths of the internet.

Miguel Ojeda, who's written software used by the Large Hadron Collider particle accelerator and worked on programming language security, is being contracted to write software in Rust for the Linux kernel. Google is paying for the contract, which is being extended through the Internet Security Research Group, a nonprofit that's also made it easier to secure website communications through the Let's Encrypt effort. Adding Rust modules to the Linux kernel would improve security by closing some avenues for hackers can use to attack phones, computers or servers. Since it was launched in 1991, Linux has been written solely in the powerful but old C programming language. The language was developed in 1972 and is more vulnerable to hacks than contemporary programming languages.

Long-time Slashdot reader wildstoo writes: In a blog post on Thursday, GitHub security researcher Kevin Backhouse announced that Polkit, a Linux system service included in several modern Linux distros that provides an organized way for non-privileged processes to communicate with privileged ones, has been harbouring a major security bug for seven years.

The bug, assigned (CVE-2021-3560) allows a non-privileged user to gain administrative shell access with a handful of standard command line tools. The bug was fixed on June 3, 2021 in a coordinated disclosure.
"It's used by systemd," GitHub's blog post points out, "so any Linux distribution that uses systemd also uses polkit..."

"It's very simple and quick to exploit, so it's important that you update your Linux installations as soon as possible. Any system that has polkit version 0.113 (or later) installed is vulnerable. That includes popular distributions such as RHEL 8 and Ubuntu 20.04."

An anonymous reader quotes a report from ZDNet: The Linux Foundation Public Health (LFPN) is getting the Global COVID Certificate Network (GCCN) ready for deployment. The GCCN [...] really is a coronavirus vaccine passport. It will do this by establishing a global trust registry network. This will enable interoperable and trustworthy exchanges of COVID certificates among countries for safe reopening and provide related technology and guidance for implementation. It's being built by the Linux Foundation Public Health and its allies, Affinidi, AOKPass, Blockchain Labs, Evernym, IBM, Indicio.Tech, LACChain, Lumedic, Proof Market, and ThoughtWorks. These companies have already implemented COVID certificate or pass systems for governments and industries. Together they will define and implement GCCN. This, it's hoped, will be the model for a true international vaccine registry.

Once completed, the GCCN's trust registry network will enable each country to publish a list of the authorized issuers of COVID certificates that can be digitally verified by authorities in other countries. This will bridge the gap between technical specifications (e.g. W3C Verifiable Credentials or SMART Health Card) and a complete trust architecture required for safe reopening. This is vital because as Brian Behlendorf, the Linux Foundation's General Manager for Blockchain, Healthcare, and Identity explained, "The first wave of apps for proving one's COVID status did not allow that proof to be shown beyond a single state or nation, did not avoid vendor lock-in and did not distinguish between rich health data and simple passes. The Blueprint gives this industry a way to solve those issues while meeting a high bar for privacy and integrity, and GCCN turns those plans into action."

Once in place, the GCCN will support Global COVID Certificates (GCC). These certificates will have three use cases: Vaccination, recovery from infection, and test results. They will be available in both paper and digital formats. Participating governments and industry alliances will decide what COVID certificates they issue and accept. The GCC schema definitions and minimal datasets will follow the recommendations of the Blueprint, as well as GCCN's technical and governance documents, implementation guide, and open-source reference implementations, which will be developed in collaboration with supporting organizations and the broader LFPH community. Besides setting the specs and designs, the GCCN community will also offer peer-based implementation and governance guidance to governments and industries to help them implement COVID certificate systems. This will include how to build national and state trust registries and infrastructure. They'll also provide guidance on how to leverage GCC into their existing coronavirus vaccine systems.

AmiMoJo shares a report from Phoronix: The Linux x86/x86_64 kernel code already had logic in place for reserving portions of the first 1MB of RAM to avoid the BIOS or kernel potentially clobbering that space among other reasons while now Linux 5.13 is doing away with that 'wankery' and will just unconditionally always reserve the first 1MB of RAM. The Linux kernel was already catering to Intel Sandy Bridge graphics accessing memory below the 1MB mark, the first 64K of memory are known to be corrupted by some BIOSes, and similar problems coming up in that low area of memory. But rather than dealing with all that logic and other possible niche cases besides the EGA/VGA frame-buffer and BIOS, the kernel is playing it safe and just always reserving the first 1MB of RAM so it will not get clobbered by the kernel.

KDE Plasma 5.22 is now available, bringing "hugely improved" Wayland support, better performance for gaming, adaptive panel transparency for the panel and widgets, and more. Phoronix reports: There is now support for variable rate refresh (VRR) / Adaptive-Sync on Wayland, vertical/horizontal maximization now working with KWin Wayland, global menu applet support under Wayland, support for activities, and a lot of other general improvements and fixes so the overall Wayland support is much more polished and nearly at par to the X.Org Server support.

The performance for gaming with KDE Plasma on Wayland should also be better with now having direct scan-out support for full-screen windows. Rounding out the graphics fun with this release is also GPU hot-plugging support on Wayland for KWin, such as if using an external GPU or USB display adapter. KDE Plasma 5.22 also delivers on adaptive panel transparency for the panel and widgets, desktop notification improvements, Plasma System Monitor has replaced KSysGuard as the default system monitoring application, and a variety of other improvements. You can view the full changelog for Plasma 5.22 here.

"You can now use GUI app support on Windows Subsystem for Linux (WSL)," Microsoft announced this week, "so that all the tools and workflows of Linux run on your developer machine." Bleeping Computer has already tested it running Gnome's file manager Nautilus, the open-source application monitor/task manager Stacer, the backup software Timeshift, and even the game Hedgewars.

Though it's currently available only to the millions who've registered for Windows 10 "Insider Preview" builds, it's already drawing positive reviews. "With the Windows Subsystem for Linux, developers no longer need to dual-boot a Windows and Linux system," argues the Windows Central site, "as you can now install all the Linux stuff a developer would need right on top of Windows instead."

Finally formally announced at this week's annual Microsoft Build conference, the new functionality runs graphical Linux apps "seamlessly," according to Tech Radar, calling the feature "highly anticipated." Arguably, one of the biggest, and surely the most exciting update to the Windows 10 WSL, Microsoft has been working on WSLg for quite a while and in fact first demoed it at last year's conference, before releasing the preview in April... Microsoft recommends running WSLg after enabling support for virtual GPU (vGPU) for WSL, in order to take advantage of 3D acceleration within the Linux apps.... WSLg also supports audio and microphone devices, which means the graphical Linux apps will also be able to record and play audio.

Keeping in line with its developer slant, Microsoft also announced that since WSLg can now help Linux apps leverage the graphics hardware on the Windows machine, the subsystem can be used to efficiently run Linux AI and ML workloads... If WSLg developers are to be believed, the update is expected to be generally available alongside the upcoming release of Windows.
Bleeping Computer explains that WSLg launches a "companion system distro" with Wayland, X, and Pulse Audio servers, calling its bundling with Windows 10 "an exciting development as it blurs the lines between Linux and Windows 10, and fans get the benefits of both worlds."

"To help realize the possibility of carbon-free applications, Microsoft, the consultancies Accenture and ThoughtWorks, the Linux Foundation, and Microsoft-owned code-sharing site, GitHub, have launched The Green Software Foundation," reports ZDNet: Announced at Microsoft's Build 2021 developer conference, the foundation is trying to promote the idea of green software engineering - a new field that looks to make code more efficient and reduce carbon emitted from the hardware it's running on... The foundation wants to set standards, best practices and patterns for building green software; nurture the creation of trusted open-source and open-data projects and support academic research; and grow an international community of green software ambassadors. The goal is to help the Information and Communication Technology sector to reduce its greenhouse gas emissions by 45% before 2030.

That includes mobile network operators, ISPs, data centers, and all the laptops being snapped up during the pandemic. "We envision a future where carbon-free software is standard - where software development, deployment, and use contribute to the global climate solution without every developer having to be an expert," Erica Brescia, COO of GitHub said in a statement. Microsoft president Brad Smith said "the world confronts an urgent carbon problem."

"It will take all of us working together to create innovative solutions to drastically reduce emissions. Microsoft is joining with organizations who are serious about an environmentally sustainable future to drive adoption of green software development to help our customers and partners around the world reduce their carbon footprint."
VentureBeat also points out that Microsoft "recently launched a $1 billion Climate Innovation Fund to accelerate the global development of carbon reduction, capture, and removal technologies."

But Bloomberg explores the rationale behind the new foundation: Data centers now account for about 1% of global electricity demand, and that's forecast to rise to 3% to 8% in the next decade, the companies said in a statement Tuesday, timed to Microsoft's Build developers conference... While it's tough to determine exactly how much carbon is emitted by individual software programs, groups like the Green Software Foundation examine metrics such as how much electricity is needed, whether microprocessors are being used efficiently, and the carbon emitted in networking. The foundation plans to look at curricula and developing certifications that would give engineers expertise in this space. As with areas like data science and cybersecurity, there will be an opportunity for engineers to specialize in green software development, but everyone who builds software will need at least some background in it, said Jeff Sandquist, a Microsoft vice president for developer relations.

"This will be the responsibility of everybody on the development team, much like when we look at security, or performance or reliability," he said. "Building the application in a sustainable way is going to matter."

Microsoft is making the promised support for Linux graphical user interface (GUI) apps on Windows 10 available to customers as of the next Windows 10 release, officials said on May 25. Microsoft officials made the announcement on Day 1 of its virtual Build 2021 developers conference. From a report: During his Day 1 keynote, CEO Satya Nadella basically acknowledged there will be another event "soon" about the next Windows. He said: ""And soon we will share one of the most significant updates of Windows of the past decade." He said he has been self-hosting it over the past several months and called it "the next generation of Windows."

Microsoft released a preview of Linux GUI apps on the Windows Subsystem for Linux (WSL) in April, 2021. This capability is meant to allow developers to run their preferred Linux tools, utilities and apps directly on Windows 10. With GUI app support, users can now run GUI apps for testing, development and daily use without having to set up a virtual machine.

An anonymous reader shares a report: One month ago the University of Minnesota was banned from contributing to the Linux kernel when it was revealed the university researchers were trying to intentionally submit bugs into the kernel via new patches as "hypocrite commits" as part of a questionable research paper. Linux kernel developers have finally finished reviewing all UMN.edu patches to address problematic merges to the kernel and also cleaning up / fixing their questionable patches. Sent in on Thursday by Greg Kroah-Hartman was char/misc fixes for 5.13-rc3. While char/misc fixes at this mid-stage of the kernel cycle tend to not be too exciting, this pull request has the changes for addressing the patches from University of Minnesota researchers. [...] Going by the umn.edu Git activity that puts 37 patches as having been reverted with this pull request. The reverts span from ALSA to the media subsystem, networking, and other areas. That is 37 reverts out of 150+ patches from umn.edu developers over the years.

An anonymous reader quotes a report from ZDNet: Swedish private equity firm EQT had high hopes for its SUSE IPO on the Frankfurt Stock Exchange, and set the European Linux and cloud power's IPO price at 30 euros per share. Alas, SUSE's shares opened at 29.50 euros per share. By the close of business on May 20th, the stock crept up to 30.39 euros. This gave it a market cap of around 5 billion euros (approximately $6.1 billion). This is nothing to sneeze at, but it wasn't what EQT hoped for either. Before the IPO, EQT had sought an IPO price as high as 34 euros per share. Still, this was no failure. SUSE and its backers sold 37.8 million shares in the IPO, for 1.1 billion euros. EQT is still keeping a stake. SUSE itself continues to do well with reported revenue of $503 million for the 2020 financial year.

Linux on Chromebooks is finally coming out of beta with the release of Chrome OS 91, Google said at its developer I/O conference. From a report: The company had offered Linux apps on Chrome OS alongside Android apps, hoping to reach an audience of developers with IDEs and so on. However, the Linux Development Environment, as Google had dubbed it, had been in beta ever since while first launched. The company had added new features at a steady cadence, enabling things like GPU acceleration, better support for USB drives, and so on so people could be more productive while using Linux apps. Alongside Linux, Google also announced that it would be bringing Android 11 to Chromebooks. Technically, the update has already started with Chrome OS 90 for select Chromebooks, and it'll come with a host of new features including increased optimization of Android apps and a new dark theme. Google's increased support of Android is no coincidence. The company says that the operating system sees 3x increased usage of Android apps, and the new Android 11 update will see Android move to a virtual machine rather than the current container based method, making it easier to update in the future.

This week Linus Torvalds continued a long email interview with Jeremy Andrews, founding partner/CEO of Tag1 (a global technology consulting firm and the second all-time leading contributor to Drupal). In the first part Torvalds had discussed everything from Apple's ARM64 chips and Rust drivers, to his own Fedora-based home work environment — and reflections on the early days of Linux.

But the second part offers some deeper insight into the way Torvalds thinks, some personal insight, what he'd share with other project maintainers — and some thoughts on getting corporations to contribute to open source development: While open source has been hugely successful, many of the biggest users, for example corporations, do nothing or little to support or contribute back to the very open source projects they rely on. Even developers of surprisingly large and successful projects (if measured by number of users) can be lucky to earn enough to buy coffee for the week. Do you think this is something that can be solved? Is the open source model sustainable?

Linus Torvalds: I really don't have an answer to this, and for some reason the kernel has always avoided the problem. Yes, there are companies that are pure "users" of Linux, but they still end up wanting support, so they then rely on contractors or Linux distributions, and those obviously then end up as one of the big sources of kernel developer jobs.

And a fair number of big tech companies that use the kernel end up actively participating in the development process. Sometimes they end up doing a lot of internal work and not being great at feeding things back upstream (I won't name names, and some of them really are trying to do better), but it's actually very encouraging how many big companies are very openly involved with upstream kernel development, and are major parts of the community.

So for some reason, the kernel development community has been pretty successful about integrating with all the commercial interests. Of course, some of that has been very much conscious: Linux has very much always been open to commercial users, and I very consciously avoided the whole anti-corporate mindset that you can most definitely find in some of the "Free Software" groups. I think the GPLv2 is a great license, but at the same time I've been very much against some of the more extreme forms of "Free Software", and I — and Linux — was very much part of the whole rebranding to use "Open Source".

Because frankly, some of the almost religious overtones of rms and the FSF were just nutty, and a certain portion of the community was actively driving commercial use away.

And I say that as somebody who has always been wary of being too tainted by commercial interests... I do think that some projects may have shot themselves in the foot by being a bit too anti-commercial, and made it really hard for companies to participate...

But is it sustainable? Yes. I'm personally 100% convinced that not only is open source sustainable, but for complex technical issues you really need open source simply because the problem space ends up being too complex to manage inside one single company. Even a big and competent tech company.

But it does require a certain openness on both sides. Not all companies will be good partners, and some developers don't necessarily want to work with big companies.
In the interview Torvalds also thanks the generous education system in Finland, and describes what it was like moving from Finland to America. And as for how long he'll continue working on Linux, Torvalds says, "I do enjoy what I do, and as long as I feel I'm actually helping the project, I'll be around...

"in the end, I really enjoy what I do. I'd be bored to tears without kernel development."

"The Linux Foundation has lifted the lid on a new open source digital infrastructure project aimed at the agriculture industry," reports VentureBeat: The AgStack Foundation, as the new project will be known, is designed to foster collaboration among all key stakeholders in the global agriculture space, spanning private business, governments, and academia.

As with just about every other industry in recent years, there has been a growing digital transformation across the agriculture sector that has ushered in new connected devices for farmers and myriad AI and automated tools to optimize crop growth and circumvent critical obstacles, such as labor shortages. Open source technologies bring the added benefit of data and tools that any party can reuse for free, lowering the barrier to entry and helping keep companies from getting locked into proprietary software operated by a handful of big players...

The AgStack Foundation will be focused on supporting the creation and maintenance of free and sector-specific digital infrastructure for both applications and the associated data. It will lean on existing technologies and agricultural standards; public data and models; and other open source projects, such as Kubernetes, Hyperledger, Open Horizon, Postgres, and Django, according to a statement.

"Current practices in AgTech are involved in building proprietary infrastructure and point-to-point connectivity in order to derive value from applications," AgStack executive director Sumer Johal told VentureBeat. "This is an unnecessarily costly use of human capital. Like an operating system, we aspire to reduce the time and effort required by companies to produce their own proprietary applications and for content consumers to consume this interoperably."

This week ZDNet dedicated an article to "the most popular Fedora Linux in years." Red Hat's community Linux distribution Fedora has always been popular with open-source and Linux developers, but this latest release, Fedora 34 seems to be something special. As Matthew Miller, Fedora Project Leader, tweeted, "The beta for F34 was one of the most popular ever, with twice as many systems showing up in my stats as typical."

Why? Nick Gerace, a Rancher software engineer, thinks it's because "I've never seen the project in a better state, and I think GNOME 40 is a large motivator as well. Probably a combination of each, from anecdotal evidence." He's onto something. When Canonical released Ubuntu 21.04 a few days earlier, their developers opted to stay with the tried and true GNOME 39 desktop. Fedora's people decided to go with GNOME 40 for their default desktop even though it's a radical update to the GNOME interface. Besides boasting a new look, GNOME 40 is based on the new GTK 4.0 graphical toolkit. Under the pretty new exterior, this update also fixed numerous issues and smoothed out many rough spots.

If you'd rather have another desktop, you can also get Fedora 34 with the newest KDE Plasma Desktop, Xfce 4.16, Cinnamon, etc. You name your favorite Linux desktop interface, Fedora will almost certainly deliver it to you... Another feature I like is that, since Fedora 33, the default file system is Btrfs. I find it faster and more responsive than ext4, perhaps the most popular Linux desktop file system. What's different this time around is that it now defaults to using Btrfs transparent compression. Besides saving significant storage space — typically from 20 to 40% — Red Hat also claims this increases the lifespan of SSDs and other flash media.
Although the article does point out that most users will never reach the end of that SSD lifespan (approximately ten years of normal use), it suggests that "developers, who might for example compile Linux kernels every day, might reach that point before a PC's usual end of useful life."

In a possibly related note, Linus Torvalds said this week in a new interview that "I use Fedora on all my machines, not because it's necessarily 'preferred', but because it's what I'm used to. I don't care deeply about the distribution — to me it's mainly a way to get Linux installed on a machine and get all my tools set up, so that I can then replace the kernel and work on just that."

Linus Torvalds gave a long new email interview to Jeremy Andrews, founding partner/CEO of Tag1 (a global technology consulting firm and the second all-time leading contributor to Drupal). Torvalds discusses everything from the creation of Git, licenses, Apple's ARM64 chips, and Rust drivers, to his own Fedora-based home work environment — and how proud he is of the pathname lookup in Linux's virtual filesystem. ("Nothing else out there comes even close.")

But with all that, early on Torvalds also reflects that Linux began as a personal project at the age of 21, "not out of some big dream to create a new operating system." Instead it "literally grew kind of haphazardly from me initially just trying to learn the in-and-outs of my new PC hardware.

"So when I released the very first version, it was really more of a 'look at what I did', and sure, I was hoping that others would find it interesting, but it wasn't a real serious and usable OS. It was more of a proof of concept, and just a personal project I had worked on for several months at that time..."

This year, in August, Linux will celebrate its 30th anniversary! That's amazing, congratulations! At what point during this journey did you realize what you'd done, that Linux was so much more than "just a hobby"?

Linus Torvalds: This may sound a bit ridiculous, but that actually happened very early. Already by late '91 (and certainly by early '92) Linux had already become much bigger than I had expected.

And yeah, considering that by that point, there were probably just a few hundred users (and even "users" may be too strong — people were tinkering with it), it probably sounds odd considering how Linux then later ended up growing much bigger. But in many ways for me personally, the big inflection point was when I realized that other people are actually using it, and interested in it, and it started to have a life of its own. People started sending patches, and the system was actually starting to do much more than I had initially really envisioned....

That "anybody can maintain their own version" worried some people about the GPLv2, but I really think it's a strength, not a weakness. Somewhat unintuitively, I think it's actually what has caused Linux to avoid fragmenting: everybody can make their own fork of the project, and that's OK. In fact, that was one of the core design principles of "Git" — every clone of the repository is its own little fork, and people (and companies) forking off their own version is how all development really gets done.

So forking isn't a problem, as long as you can then merge back the good parts. And that's where the GPLv2 comes in. The right to fork and do your own thing is important, but the other side of the coin is equally important — the right to then always join back together when a fork was shown to be successful...

I very much don't regret the choice of license, because I really do think the GPLv2 is a huge part of why Linux has been successful.

Money really isn't that great of a motivator. It doesn't pull people together. Having a common project, and really feeling that you really can be a full partner in that project, that motivates people, I think.

syn3rg shares a report from ZDNet: A Linux backdoor recently discovered by researchers has avoided VirusTotal detection since 2018. Dubbed RotaJakiro, the Linux malware has been described by the Qihoo 360 Netlab team as a backdoor targeting Linux 64-bit systems. RotaJakiro was first detected on March 25 when a Netlab distributed denial-of-service (DDoS) botnet C2 command tracking system, BotMon, flagged a suspicious file.

At the time of discovery, there were no malware detections on VirusTotal for the file, despite four samples having been uploaded -- two in 2018, one in 2020, and another in 2021. Netlab researchers say the Linux malware changes its use of encryption to fly under the radar, including ZLIB compression and combinations of AES, XOR, and key rotation during its activities, such as the obfuscation of command-and-control (C2) server communication. At present, the team says that they do not know the malware's "true purpose" beyond a focus on compromising Linux systems.

There are 12 functions in total including exfiltrating and stealing data, file and plugin management -- including query/download/delete -- and reporting device information. However, the team cites a "lack of visibility" into the plugins that is preventing a more thorough examination of the malware's overall capabilities. In addition, RotaJakiro will treat root and non-root users on compromised systems differently and will change its persistence methods depending on which accounts exist.

destinyland writes: LWN has a terrific update what's happened since the discovery of University of Minnesota researchers intentionally submitting buggy code to the Linux kernel:

The writing of a paper on this research [PDF] was not the immediate cause of the recent events; instead, it was the posting of a buggy patch originating from an experimental static-analysis tool run by another developer at UMN. That led developers in the kernel community to suspect that the effort to submit intentionally malicious patches was still ongoing. Since then, it has become apparent that this is not the case, but by the time the full story became clear, the discussion was already running at full speed.

The old saying still holds true: one should not attribute to malice that which can be adequately explained by incompetence.

On April 22, a brief statement was issued by the Linux Foundation technical advisory board (TAB) stating that, among other things, the recent patches appeared to have been submitted in good faith.

Meanwhile, the Linux Foundation and the TAB sent a letter to the UMN researchers outlining how the situation should be addressed; that letter has not been publicly posted, but ZDNet apparently got a copy from somewhere. Among other things, the letter asked for a complete disclosure of the buggy patches sent as part of the UMN project and the withdrawal of the paper resulting from this work.

In response, the UMN researchers posted an open letter apologizing to the community, followed a few days later by a summary of the work they did [PDF] as part of the "hypocrite commits" project. Five patches were submitted overall from two sock-puppet accounts, but one of those was an ordinary bug fix that was sent from the wrong account by mistake. Of the remaining four, one of them was an attempt to insert a bug that was, itself, buggy, so the patch was actually valid; the other three (1, 2, 3) contained real bugs. None of those three were accepted by maintainers, though the reasons for rejection were not always the bugs in question.

The paper itself has been withdrawn and will not be presented in May as was planned...

One of the first things that happened when this whole affair exploded was the posting by Greg Kroah-Hartman of a 190-part patch series reverting as many patches from UMN as he could find... As it happens, these "easy reverts" also needed manual review; once the initial anger passed there was little desire to revert patches that were not actually buggy. That review process has been ongoing over the course of the last week and has involved the efforts of a number of developers. Most of the suspect patches have turned out to be acceptable, if not great, and have been removed from the revert list; if your editor's count is correct, 42 patches are still set to be pulled out of the kernel...

A look at the full set of UMN patches reinforces some early impressions, though. First is that almost all of them do address some sort of real (if obscure and hard to hit) problem...

Saturday University of Minnesota researchers emailed the Linux kernel mailing list apologizing for submitting buggy code as part of a research project to see whether it would be accepted.

Late Saturday night, the kernel team's Greg Kroah-Hartman replied: Thank you for your response.

As you know, the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.

Until those actions are taken, we do not have anything further to discuss about this issue.

thanks

Earlier this week Greg Kroah-Hartman of the Linux kernel development team banned the University of Minnesota from contributing after researchers there submitted what he called "obviously-incorrect patches" believed to be part of a research project into whether buggy code would be accepted.

Today the professor in charge of that project, as well as two of its researchers, sent an email to the Linux kernel mailing list saying they "sincerely apologize for any harm our research group did to the Linux kernel community." Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the "hypocrite commits" paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research, and to waste its effort reviewing these patches without its knowledge or permission.

We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities... We are a research group whose members devote their careers to improving the Linux kernel. We have been working on finding and patching vulnerabilities in Linux for the past five years...

This current incident has caused a great deal of anger in the Linux community toward us, the research group, and the University of Minnesota. We apologize unconditionally for what we now recognize was a breach of the shared trust in the open source community and seek forgiveness for our missteps. We seek to rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software... We are committed to following best practices for collaborative research by consulting with community leaders and members about the nature of our research projects, and ensuring that our work meets not only the requirements of the Institutional Review Board but also the expectations that the community has articulated to us in the wake of this incident.

While this issue has been painful for us as well, and we are genuinely sorry for the extra work that the Linux kernel community has undertaken, we have learned some important lessons about research with the open source community from this incident. We can and will do better, and we believe we have much to contribute in the future, and will work hard to regain your trust.
Their email also says their work did not introduce vulnerabilities into the Linux code. ("The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code.")

And the email also clarifies that their research was only done in August of 2020, and "All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the 'hypocrite commits' paper. These 190 patches were in response to real bugs in the code and all correct — as far as we can discern — when we submitted them... Our recent patches in April 2021 are not part of the 'hypocrite commits' paper either."

UPDATE (4/25): Late Saturday night the kernel team's Greg Kroah-Hartman rejected the apology, writing that "the Linux Foundation and the Linux Foundation's Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.

"Until those actions are taken, we do not have anything further to discuss about this issue."

jonesy16 writes: While users have long been able to run Linux GUI apps on Windows by installing a separate X Server, this marks the first time that native support is available through the Windows Subsystem for Linux (WSL). Audio support and hardware acceleration are also provided, seemingly enabling a limitless set of use cases for those wishing to live the dual OS life. The change is identified in the recent preview build release along with a more in-depth discussion of the graphical subsystem now called WSLg.

Canonical released Ubuntu 21.04 with native Microsoft Active Directory integration, Wayland graphics by default, and a Flutter application development SDK. Separately, Canonical and Microsoft have announced performance optimization and joint support for Microsoft SQL Server on Ubuntu. Canonical blog adds: "Native Active Directory integration and certified Microsoft SQL Server on Ubuntu are top priorities for our enterprise customers." said Mark Shuttleworth, CEO of Canonical. "For developers and innovators, Ubuntu 21.04 delivers Wayland and Flutter for smoother graphics and clean, beautiful, design-led cross-platform development." You can read the full list of new features and changelog here.

Greg Kroah-Hartman, who is one of the head honchos of the Linux kernel development and maintenance team, has banned the University of Minnesota (UMN) from further contributing to the Linux Kernel. The University had apparently introduced questionable patches into the kernel of Linux. From a report: The UMN had worked on a research paper dubbed "On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits". Obviously, the "Open-Source Software" (OSS) here is indicating the Linux kernel and the University had stealthily introduced Use-After-Free (UAF) vulnerability to test the susceptibility of Linux. So far so good perhaps as one can see it as ethical experimenting. However, the UMN apparently sent another round of "obviously-incorrect patches" into the kernel in the form of "a new static analyzer" causing distaste to Greg Kroah-Hartman who has now decided to ban the University from making any further contributions.

An anonymous reader writes: Debian Project Secretary Kurt Roeckx has announced the results of a closely-watched vote on what statement would be made about Richard Stallman's readmission to the Free Software Foundation's board.
Seven options were considered, with the Debian project's 420 voting developers also asked to rank their preferred outcomes:

• Option 1: "Call for the FSF board removal, as in rms-open-letter.github.io"

• Option 2: "Call for Stallman's resignation from all FSF bodies"

• Option 3: "Discourage collaboration with the FSF while Stallman is in a leading position"

• Option 4: "Call on the FSF to further its governance processes"

• Option 5: "Support Stallman's reinstatement, as in rms-support-letter.github.io"

• Option 6: "Denounce the witch-hunt against RMS and the FSF"

• Option 7: "Debian will not issue a public statement on this issue"

While all seven options achieved a quorum of votes, two failed to achieve a majority — options 5 and 6. ("Support Stallman's reinstatement" and "Denounce the witch-hunt...") The option receiving the most votes was #7 (not issuing a public statement) — but it wasn't that simple. The vote's final outcome was determined by comparing every possible pair of options to determine which option would still be preferred by a majority of voters in each possible comparision.

In this case, that winner was still the option which had also received the most votes:


Debian will not issue a public statement on this issue.
The Debian Project will not issue a public statement on whether Richard Stallman should be removed from leadership positions or not.

Any individual (including Debian members) wishing to (co-)sign any of the open letters on this subject is invited to do this in a personal capacity.


The results are captured in an elaborate graph. Numbers inside the ovals show the final ratio of yes to no votes (so a number higher than 1.00 indicates a majority, with much higher numbers indicating much larger majorities). Numbers outside the ovals (along the lines) indicate the number of voters who'd preferred the winning choice over the losing choice (toward which the arrow is pointing).

The winning option is highlighted in blue.

Long-time Slashdot reader xiando shares news from LinuxReviews: Linux Kernel Runtime Guard (LKRG) is a security module for the Linux kernel developed by Openwall. The latest release adds compatibility with Linux kernels up to soon to be released 5.12, support for building LKRG into kernel images, support for old 32-bit x86 machines and more...

The Linux Kernel Runtime Guard is an out-of-tree kernel module you can install as a kernel module, or, with the 0.9.0 release, build into your Linux kernel. It does run-time integrity checks to detect security vulnerability exploits against the Linux kernel.
An Openwall developer also notes in the announcement that "During LKRG development and testing I've found 7 Linux kernel bugs, 4 of them have CVE numbers."

Slashdot reader LeeLynx shares news from The Register about a Slackware 15 beta release (following the debut of February's alpha), "nearly five years after the distribution last saw a major update." (And nearly 28 years after its initial release back in 1993...) Created by Patrick Volkerding (who still lays claim to the title Benevolent Dictator For Life), the current release version arrived in the form of 2016's 14.2... The Linux kernel has been updated to 5.10.30 (at time of writing) with 5.11.14 available for testing. Desktop fans may be pleased to see, among the many updates, KDE Plasma hitting 5.21.4 as well as updates for old faithfuls, such as Mozilla Firefox and Thunderbird.

The beta itself dropped on 12 April (with the 5.10.29 kernel) and Volkerding noted: "I'm going to go ahead and call this a beta even though there's still no fix for the illegal instruction issue with 32-bit mariadb. But there should be soon."

Tinkering has continued since, judging by the change log, although the beta tag brings hope there will be a release before long.

Google's Android team supports Rust for developing the Android operating system. Now they're also helping evaluate Rust for Linux kernel development. Their hopes, among other things, are that "New code written in Rust has a reduced risk of memory safety bugs, data races and logic bugs overall," that "abstractions that are easier to reason about," and "More people get involved overall in developing the kernel, thanks to the usage of a modern language."

Linus Torvalds responded in a new interview with IT Wire (shared by Slashdot reader juul_advocate): The first patches for Rust support in the Linux kernel have been posted and the man behind the kernel says the fact that these are being discussed is much more important than a long post by Google about the language. Linus Torvalds told iTWire in response to queries that Rust support was "not there yet", adding that things were "getting to the point where maybe it might be mergeable for 5.14 or something like that..." Torvalds said that it was still early days for Rust support, "but at least it's in a 'this kind of works, there's an example, we can build on it'."

Asked about a suggestion by a commenter on the Linux Weekly News website, who said, during a discussion on the Google post, "The solution here is simple: just use C++ instead of Rust", Torvalds could not restrain himself from chortling. "LOL," was his response. "C++ solves _none_ of the C issues, and only makes things worse. It really is a crap language.

"For people who don't like C, go to a language that actually offers you something worthwhile. Like languages with memory safety and [which] can avoid some of the dangers of C, or languages that have internal GC [garbage collection] support and make memory management easier. C++ solves all the wrong problems, and anybody who says 'rewrite the kernel in C++' is too ignorant to even know that."

He said that when one spoke of the dangers of C, one was also speaking about part of what made C so powerful, "and allows you to implement all those low-level things efficiently".
Torvalds added that, while garbage collection is "a very good thing in most other situations," it's "generally not necessarily something you can do in a low-level system programming."

Long-time Slashdot reader xiando quotes LinuxReviews: The community distribution Arch Linux has up to now required you to manually install it by entering a whole lot of scary commands in a terminal. Arch version 2021.04.01 features a new guided installer [reached by] typing python -m archinstall guided into the console you get when you boot the Arch Linux installation ISO.

It is not very novice-friendly, or user-friendly, but it gets the job done and it will work fine for those with some basic GNU/Linux knowledge.
Tech Radar writes that previously Arch Linux had "a rather convoluted installation process, which has given rise to a stream of Arch-based distros that are easier to install," adding that the new installer "was reportedly promoted as an official installation mechanism back in January, and was actively worked upon leading to its inclusion in the installation medium." Users have been calling on Arch Linux for simplifying the installation process for a long time, to bring it in line with other Linux distros. However, the Arch philosophy has always been to put the users in charge of every aspect of their installation, which is the antithesis of automated installers.
Phoronix calls the new installer "very quick and easy," although "granted not as user-friendly / polished as say the Debian Installer, Red Hat's Anaconda installer, even Ubuntu's Subiquity, and other TUI/GUI Linux installers out there." They also note that Archinstall "does allow automatically partitioning the drive with your choice of file-system options, automatically installing a desktop environment if desired, configuring the network interfaces, and all the other basics." The method is quick enough that I'll likely use archinstall for future Arch Linux benchmarks on Phoronix as it also then applies a sane set of defaults for users... Five minutes or less and off to the races, ready for Arch Linux."
But Slashdot reader I75BJC still favors "scary commands in a terminal," leaving this comment on the original submission: If you can't type with the big adults, stay on your PlayStation.

Even Apple, with its very good GUI has a command line. The command line commands are more flexible, more specific, more subtle than the pointy-clicky GUI.

IBM has announced a COBOL compiler for Linux on x86. "IBM COBOL for Linux on x86 1.1 brings IBM's COBOL compilation technologies and capabilities to the Linux on x86 environment," said IBM in an announcement, describing it as "the latest addition to the IBM COBOL compiler family, which includes Enterprise COBOL for z/OS and COBOL for AIX." The Register reports: COBOL -- the common business-oriented language -- has its roots in the 1950s and is synonymous with the mainframe age and difficulties paying down technical debt accrued since a bygone era of computing. So why is IBM -- which is today obsessed with hybrid clouds -- bothering to offer a COBOL compiler for Linux on x86? Because IBM thinks you may want your COBOL apps in a hybrid cloud, albeit the kind of hybrid IBM fancies, which can mean a mix of z/OS, AIX, mainframes, POWER systems and actual public clouds.
[...]
But the announcement also suggests IBM doesn't completely believe this COBOL on x86 Linux caper has a future as it concludes: "This solution also provides organizations with the flexibility to move workloads back to IBM Z should performance and throughput requirements increase, or to share business logic and data with CICS Transaction Server for z/OS." The new offering requires RHEL 7.8 or later, or Ubuntu Server 16.04 LTS, 18.04 LTS, or later.

New submitter juul_advocate shares a report from iTWire: The outcome of a general resolution proposed by the Debian GNU/Linux project, to decide how to react to the return of Free Software Foundation founder Richard Stallman to the board, will be known on April 17, with voting now underway. The original proposal for a GR was made by Steve Langasek, who also works for Canonical, the company behind Ubuntu, and calls for co-signing an existing letter which wants Stallman gone and the FSF board sacked. There has been a lot of discussion around the issue.

Six alternatives have been proposed. The proposals are:
- remove the entire FSF board as in an existing letter;
- seek Stallman's resignation from all FSF bodies;
- discourage collaboration with the FSF while Stallman remains in a leading position;
- ask FSF to further its governance processes;
- support Stallman's reinstatement;
- denounce the witch hunt against Stallman and the FSF; and
- issue no public statement on the issue. During the organization's LibrePlanet virtual event on March 19, Stallman announced that he was rejoining the board and does not intend to resign again. His return has drawn condemnation from many people in the free software community. Just days after his announcement, an open letter calling for Stallman to be removed again and for the FSF's entire board to resign was signed by hundreds of people.

Linux giant Red Hat has decided to pull funding, while the 'Open Source Initiative' said that it "will not participate in any events that include Richard M. Stallman," adding that it "cannot collaborate with the Free Software Foundation until Stallman is removed from the organization's leadership."

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."