SUSE has unveiled a new support package aimed at customers concerned about data sovereignty. From a report: Called "SUSE Sovereign Premium Support," the service geo-pins support to a given region rather than adopting the traditional follow-the-sun model, where support comes from whatever region is online. The latter approach could break sovereignty regulations or policies, as it might involve transferring data out of a region. Ensuring that support is available from a specific region is therefore crucial, particularly for European customers.

SUSE CEO Dirk-Peter van Leeuwen told The Register: "Digital sovereignty has become a really hot topic in the last half year, and specifically in Europe, where companies feel an increasing need to get things done in-house, in-country, or in-region within Europe, with less dependency on non-European vendors and supply chains and people."

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: At KubeCon North America, SUSE announced a significant rebranding effort, several new product offerings, and the launch of SUSE AI, a secure platform for deploying and running generative AI (gen AI) applications. SUSE has renamed its entire portfolio to make product names more descriptive and customer-friendly. Notable changes include:

- Rancher, SUSE's Kubernetes offering, is now SUSE Rancher.
- Liberty Linux, the company's Red Hat Enterprise Linux (RHEL)/CentOS clone and support offering, becomes SUSE Multi Linux Support.
- Harvester is rebranded as SUSE Virtualization
- Longhorn is now SUSE Storage.

[...] Also, like everyone else, SUSE now has an AI offering: SUSE AI. This isn't an AI chatbot, like Red Hat's Lightspeed AI tool. No, it's a secure platform for deploying and running gen AI applications. This new offering addresses key challenges faced by enterprises as they move from AI experimentation to deployment, particularly in areas of security and compliance. These are SUSE AI's top features, as highlighted by Vaughan-Nichols:

1. Security by Design: SUSE AI provides security and certifications at the software infrastructure level, along with zero-trust security tools, templates, and compliance playbooks.
2. Multifaceted Trust: The platform ensures that generated data is correct and private customer and IP data remain secure. It supports deployment across various environments, including on-premise, hybrid, cloud, and air-gapped setups.
3. Choice and Flexibility: SUSE AI allows customers to select and deploy their preferred AI components and LLMs.
4. Simplified Operations: The platform provides simplified cluster operations, persistent storage, and easy access to pre-configured shared tools and services.

"If you're plugged into KDE social media, you probably see a lot of requests for donations..." writes KDE developer Nate Graham on his personal blog. But "We know that the fraction of people who subscribe to these channels is small, so there's a huge number of people who may not even know they can donate to KDE, let alone that donations are critically important to its continued existence..." From 6.2 onwards, Plasma itself will show a system notification asking for a donation once per year, in December. The idea here is to get the message that KDE really does need your financial help in front of more eyeballs — especially eyeballs not currently looking at KDE's public-facing promotion efforts... [W]e tried our best to minimize the annoying-ness factor: It's small and unobtrusive, and no matter what you do with it (click any button, close it, etc) it'll go away until next year. It's implemented as a KDE Daemon (KDED) module, which allows users and distributors to permanently disable it if they like. You can also disable just the popup on System Settings' Notifications page, accessible from the configure button in the notification's header.

Ultimately the decision to do this came down to the following factors:

— We looked at FOSS peers like Thunderbird and Wikipedia which have similar things (and in Wikipedia's case, the message is vastly more intrusive and naggy). In both cases, it didn't drive everyone away and instead instead resulted in a massive increase in donations that the projects have been able to use to employ lots of people.

- KDE really needs something like this to help our finances grow sustainably in line with our userbase and adoption by vendors and distributors.
The blog post also answers the question: what are you going to do with all that money? This is a question the KDE e.V. board of directors as a whole would need to answer, and any decision on it will be made collectively. But as one of the five members on that board, I can tell you my personal answer and the one that as your representative, I'd advocate for. It's basically the platform I ran on two years ago: extend an offer of full-time employment to our current people, and hire even more! I want us to end up with paid QA people and distro developers, and even more software engineers. I want us to fund the creation of a next-generation KDE OS we can offer directly to institutions looking to switch to Linux, and a hardware certification program to go along with it. I want us to to extend our promotional activities and outreach to other major distros and vendors and pitch our software to them directly. I want to see Ubuntu, Red Hat Enterprise Linux, and SUSE Linux Enterprise Desktop ship Plasma by default. I want us to use this money to take over the world — with freedom, empowerment, and kindness.

These have been dreams for a long time, and throughout KDE we've been slowly moving towards them over the years. With a lot more money, we can turbocharge the pace! If that stuff sounds good, you can start with a donation today.
A reaction from GamingOnLinux: I think it is fair for KDE to expose that they need funding and asking that from inside the UI would not hurt for a software that delivered so much for free (as in freedom and as in "gratis").
Linux magazine points out that other new features for 6.2 "include the ability to block apps from inhibiting sleep mode, a new 'fill' mode for wallpaper, an overhauled System Settings Accessibility page, and the usual slew of bug fixes."

Azure used to be a cloud platform dedicated to Windows. Now, it's the most widely used operating system on Microsoft Azure. The New Stack's Joab Jackson writes: These days, Microsoft expends considerable effort that Linux runs as smoothly as possible on Azure, according to a talk given earlier this year at the Linux Foundation Open Source Summit given by two Microsoft Azure Linux Platforms Group program managers, Jack Aboutboul, and Krum Kashan. "Linux is the #1 operating system in Azure today," Aboutoul said. And all must be supported in a way that Microsoft users have come to expects. Hence, the need for the Microsoft's Linux Platforms Group, which provides support Linux to both the internal customers and to Azure customers. These days, the duo of engineers explained, Microsoft knows about as much as anyone about how to operate Linux at hyperscale. [...]

As of today, there are hundreds of Azure and Azure-based services running on Linux, including the Azure Kubernetes Service (AKS), OpenAI, HDInsight, and many of the other database services. "A lot of the infrastructure powering everything else is running on Linux," Aboutoul said. "They're different flavors of Linux running all over the place," Aboutoul said. To run these services, Microsoft maintains its own kernel, Azure Linux, and in 2023 the company released its own version of Linux, Azure Linux. But Azure Linux is just a small portion of all the other flavors of Linux running on Azure, all of which Microsoft must work with to support.

Overall, there are about 20,000 third-party Software as a Service (SaaS) packages in the Azure marketplace that rely on some Linux distribution. And when things go wrong, it is the Azure service engineers who get the help tickets. The company keeps a set of endorsed Linux distributions, which include Red Hat Enterprise Linux, Debian, Flatcar, Suse, Canonical, and Oracle Linux and CentOS (as managed by OpenLogic, not Red Hat). [...] Overall, the company gets about 1,000 images a month from these endorsed partners alone. Many of the distributions have multiple images (Suse has a regular one, and another one for high-performance computing, for instance).

An anonymous reader quotes a report from ZDNet: At SUSECon in Berlin, SUSE, a global Linux and cloud-native software leader, announced significant enhancements across its entire Linux distribution family. These new capabilities focus on providing faster time-to-value and reduced operational costs, emphasizing the importance of choice in today's complex IT landscape. SUSE Linux Enterprise Server (SLES) 15 Service Pack (SP) 6 is at the heart of these upgrades. This update future-proofs IT workloads with a new Long Term Service (LTS) Pack Support Core. How long is long-term? Would you believe 19 years? This gives SLES the longest-term support period in the enterprise Linux market. Even Ubuntu, for which Canonical recently extended its LTS to 12 years, doesn't come close.

You may ask yourself, "Why 19 years?" SUSE General Manager of Business Critical Linux (BCL) Rick Spencer, explained in an interview that the reason is that on 03:14:08 Greenwich Mean Time (GMT, aka Coordinated Universal Time) Tuesday, January 19, 2038, we reach the end of computing time. Well, not really, but Linux, and all the other Unix-based operating systems, including some versions of MacOS, reach what's called the Epoch. That's when the time-keeping code in 32-bit Unix-based operating systems reaches the end of the seconds it's been counting since the beginning of time -- 00:00:00 GMT on January 1, 1970, as far as Linux and Unix systems are concerned -- and resets to zero. Just like the Y2K bug, that means that all unpatched 32-bit operating systems and software will have fits. The Linux kernel itself had the problem fixed in 2020's Linux 5.6 kernel, but many other programs haven't dealt with it. Until then, though, if you're still running SLES 15 SP6, you'll be covered. I strongly suggest upgrading before then, but if you want to stick with that distro to the bitter end, you can. The new SLES also boasts enhanced security features like confidential computing support with encryption in memory, utilizing Intel TDX and AMD SEV processors, along with remote attestation via SUSE Manager. Additionally, SLES for SAP Applications 15 SP6 offers a secure and reliable platform for running mission-critical SAP workloads, incorporating innovations from Trento to help system administrators avoid infrastructure issues.

SUSE, a Luxembourg-based open-source company, is launching a new vendor- and LLM-agnostic generative AI platform called SUSE AI solutions. The company aims to leverage the potential of AI to gain a stronger foothold in the U.S. market, where it has struggled to establish brand recognition compared to competitors like Red Hat and Canonical. SUSE CEO Dirk-Peter van Leeuwen believes that the open-source model provides infinite potential for enterprise customers, offering support, security, and long-term stability. The company's recent fork of CentOS has attracted a significant number of users, and its portfolio, including Kubernetes service Rancher and security service Neuvector, positions SUSE well in a market where enterprises are looking to consolidate platforms. Despite ownership changes over the years, SUSE remains committed to expanding its presence in the U.S. market.

Longtime Slashdot reader DVega shares a report from Phoronix: ReiserFS lead developer and convicted murderer Hans Reiser a few months back wrote letters to be made public apologizing for his social mistakes and other commentary. In his written communications he also made a last request for ReiserFS in the Linux kernel: "Assuming that the decision is to remove [ReiserFS] V3 from the kernel, I have just one request: that for one last release the README be edited to add Mikhail Gilula, Konstantin Shvachko, and Anatoly Pinchuk to the credits, and to delete anything in there I might have said about why they were not credited. It is time to let go."

Hans credits his improved social and communication skills learned in prison among other details shared in the public letters. Per the indirect request by Hans Reiser, SUSE's Jan Kara has now altered the ReiserFS README file with the changes going in today to the Linux 6.10 kernel. The negative language was removed and instead acknowledging their contributions.

Jeremy Allison — Sam (Slashdot reader #8,157) is a Distinguished Engineer at Rocky Linux creator CIQ. This week he published a blog post responding to promises of Linux distros "carefully selecting only the most polished and pristine open source patches from the raw upstream open source Linux kernel in order to create the secure distribution kernel you depend on in your business."

But do carefully curated software patches (applied to a known "frozen" Linux kernel) really bring greater security? "After a lot of hard work and data analysis by my CIQ kernel engineering colleagues Ronnie Sahlberg and Jonathan Maple, we finally have an answer to this question. It's no." The data shows that "frozen" vendor Linux kernels, created by branching off a release point and then using a team of engineers to select specific patches to back-port to that branch, are buggier than the upstream "stable" Linux kernel created by Greg Kroah-Hartman. How can this be? If you want the full details the link to the white paper is here. But the results of the analysis couldn't be clearer.

- A "frozen" vendor kernel is an insecure kernel. A vendor kernel released later in the release schedule is doubly so.

- The number of known bugs in a "frozen" vendor kernel grows over time. The growth in the number of bugs even accelerates over time.

- There are too many open bugs in these kernels for it to be feasible to analyze or even classify them....

[T]hinking that you're making a more secure choice by using a "frozen" vendor kernel isn't a luxury we can still afford to believe. As Greg Kroah-Hartman explicitly said in his talk "Demystifying the Linux Kernel Security Process": "If you are not using the latest stable / longterm kernel, your system is insecure."
CIQ describes its report as "a count of all the known bugs from an upstream kernel that were introduced, but never fixed in RHEL 8." For the most recent RHEL 8 kernels, at the time of writing, these counts are: RHEL 8.6 : 5034 RHEL 8.7 : 4767 RHEL 8.8 : 4594

In RHEL 8.8 we have a total of 4594 known bugs with fixes that exist upstream, but for which known fixes have not been back-ported to RHEL 8.8. The situation is worse for RHEL 8.6 and RHEL 8.7 as they cut off back-porting earlier than RHEL 8.8 but of course that did not prevent new bugs from being discovered and fixed upstream....

This whitepaper is not meant as a criticism of the engineers working at any Linux vendors who are dedicated to producing high quality work in their products on behalf of their customers. This problem is extremely difficult to solve. We know this is an open secret amongst many in the industry and would like to put concrete numbers describing the problem to encourage discussion. Our hope is for Linux vendors and the community as a whole to rally behind the kernel.org stable kernels as the best long term supported solution. As engineers, we would prefer this to allow us to spend more time fixing customer specific bugs and submitting feature improvements upstream, rather than the endless grind of backporting upstream changes into vendor kernels, a practice which can introduce more bugs than it fixes.
ZDNet calls it "an open secret in the Linux community." It's not enough to use a long-term support release. You must use the most up-to-date release to be as secure as possible. Unfortunately, almost no one does that. Nevertheless, as Google Linux kernel engineer Kees Cook explained, "So what is a vendor to do? The answer is simple: if painful: Continuously update to the latest kernel release, either major or stable." Why? As Kroah-Hartman explained, "Any bug has the potential of being a security issue at the kernel level...."

Although [CIQ's] programmers examined RHEL 8.8 specifically, this is a general problem. They would have found the same results if they had examined SUSE, Ubuntu, or Debian Linux. Rolling-release Linux distros such as Arch, Gentoo, and OpenSUSE Tumbleweed constantly release the latest updates, but they're not used in businesses.
Jeremy Allison's post points out that "the Linux kernel used by Android devices is based on the upstream kernel and also has a stable internal kernel ABI, so this isn't an insurmountable problem..."

Michael Larabel reports via Phoronix: While Fedora 41 in late 2024 is aiming to have more reproducible package builds, openSUSE Factory has already achieved a significant milestone in bit-by-bit reproducible builds. Since last month openSUSE Factory has been producing bit-by-bit reproducible builds sans the likes of embedded signatures. OpenSUSE Tumbleweed packages for that rolling-release distribution are being verified for bit-by-bit reproducible builds. SUSE/openSUSE is still verifying all packages are yielding reproducible builds but so far it's looking like 95% or more of packages are working out. You can learn more via the openSUSE blog.

"Until recently, Linux kernel developers have been the ones keeping long-term support (LTS) versions of the Linux kernel patched and up to date," writes ZDNet.

"Then, because it was too much work with too little support, the Linux kernel developers decided to no longer support the older kernels." Greg Kroah-Hartman, the Linux kernel maintainer for the stable branch, announced that the Linux 4.14.336 release was the last maintenance update to the six-year-old LTS Linux 4.14 kernel series. It was the last of the line for 4.14. Or was it?

Kroah-Hartman had stated, "All users of the 4.14 kernel series must upgrade." Maybe not. OpenELA, a trade association of the Linux distributors CIQ (the company backing Rocky Linux), Oracle, and SUSE, is now offering — via its kernel-lts — a new lease on life for 4.14.

This renewed version, tagged with the following format — x.y.z-openela — is already out as v4.14.339-openela. The OpenELA acknowledges the large debt they owe to Kroah-Hartman and Sasha Levin of the Linux Kernel Stable project but underlines that their project is not affiliated with them or any of the other upstream stable maintainers. That said, the OpenELA team will automatically pull most LTS-maintained stable tree patches from the upstream stable branches. When there are cases where patches can't be applied cleanly, OpenELA kernel-lts maintainers will deal with these issues. In addition, a digest of non-applied patches will accompany each release of its LTS kernel, in mbox format.
"The OpenELA kernel-lts project is the first forum for enterprise Linux distribution vendors to pool our resources," an Oracle Linux SVP tells ZDNet, "and collaborate on those older kernels after upstream support for those kernels has ended." And the CEO of CIQ adds that after community support has ended, "We believe that open collaboration is the best way to maintain foundational enterprise infrastructure.

"Through OpenELA, vendors, users, and the open source community at large can work together to provide the longevity that professional IT organizations require for enterprise Linux."

In 2003, Hans Reiser answered questions from Slashdot's readers...

Today Wikipedia describes Hans Reiser as "a computer programmer, entrepreneur, and convicted murderer... Prior to his incarceration, Reiser created the ReiserFS computer file system, which may be used by the Linux kernel but which is now scheduled for removal in 2025, as well as its attempted successor, Reiser4."

This week alanw (Slashdot reader #1,822), spotted a development on the Linux kernel mailing list. "Hans Reiser (imprisoned for the murder of his wife) has written a letter, asking it to be published to Slashdot." Reiser writes: I was asked by a kind Fredrick Brennan for my comments that I might offer on the discussion of removing ReiserFS V3 from the kernel. I don't post directly because I am in prison for killing my wife Nina in 2006.

I am very sorry for my crime — a proper apology would be off topic for this forum, but available to any who ask.

A detailed apology for how I interacted with the Linux kernel community, and some history of V3 and V4, are included, along with descriptions of what the technical issues were. I have been attending prison workshops, and working hard on improving my social skills to aid my becoming less of a danger to society. The man I am now would do things very differently from how I did things then.
Click here for the rest of Reiser's introduction, along with a link to the full text of the letter...

The letter is dated November 26, 2023, and ends with an address where Reiser can be mailed. Ars Technica has a good summary of Reiser's lengthy letter from prison — along with an explanation for how it came to be. With the ReiserFS recently considered obsolete and slated for removal from the Linux kernel entirely, Fredrick R. Brennan, font designer and (now regretful) founder of 8chan, wrote to the filesystem's creator, Hans Reiser, asking if he wanted to reply to the discussion on the Linux Kernel Mailing List (LKML). Reiser, 59, serving a potential life sentence in a California prison for the 2006 murder of his estranged wife, Nina Reiser, wrote back with more than 6,500 words, which Brennan then forwarded to the LKML. It's not often you see somebody apologize for killing their wife, explain their coding decisions around balanced trees versus extensible hashing, and suggest that elementary schools offer the same kinds of emotional intelligence curriculum that they've worked through in prison, in a software mailing list. It's quite a document...

It covers, broadly, why Reiser believes his system failed to gain mindshare among Linux users, beyond the most obvious reason. This leads Reiser to detail the technical possibilities, his interpersonal and leadership failings and development, some lingering regrets about dealings with SUSE and Oracle and the Linux community at large, and other topics, including modern Russian geopolitics... Reiser asks that a number of people who worked on ReiserFS be included in "one last release" of the README, and to "delete anything in there I might have said about why they were not credited." He says prison has changed him in conflict resolution and with his "tendency to see people in extremes...."

Reiser writes that he understood the difficulty ahead in getting the Linux world to "shift paradigms" but lacked the understanding of how to "make friends and allies of people" who might initially have felt excluded. This is followed by a heady discussion of "balanced trees instead of extensible hashing," Oracle's history with implementing balanced trees, getting synchronicity just right, I/O schedulers, block size, seeks and rotational delays on magnetic hard drives, and tails. It leads up to a crucial decision in ReiserFS' development, the hard non-compatible shift from V3 to Reiser 4. Format changes, Reiser writes, are "unwanted by many for good reasons." But "I just had to fix all these flaws, fix them and make a filesystem that was done right. It's hard to explain why I had to do it, but I just couldn't rest as long as the design was wrong and I knew it was wrong," he writes. SUSE didn't want a format change, but Reiser, with hindsight, sees his pushback as "utterly inarticulate and unsociable." The push for Reiser 4 in the Linux kernel was similar, "only worse...."

He encourages people to "allow those who worked so hard to build a beautiful filesystem for the users to escape the effects of my reputation." Under a "Conclusion" sub-heading, Reiser is fairly succinct in summarizing a rather wide-ranging letter, minus the minutiae about filesystem architecture.

I wish I had learned the things I have been learning in prison about talking through problems, and believing I can talk through problems and doing it, before I had married or joined the LKML. I hope that day when they teach these things in Elementary School comes.

I thank Richard Stallman for his inspiration, software, and great sacrifices,

It has been an honor to be of even passing value to the users of Linux. I wish all of you well.


It both is and is not a response to Brennan's initial prompt, asking how he felt about ReiserFS being slated for exclusion from the Linux kernel. There is, at the moment, no reply to the thread started by Brennan.

It's "a free and open-source, software-defined storage platform," according to Wikipedia, providing object storage, block storage, and file storage "built on a common distributed cluster foundation". The charter advisory board for Ceph included people from Canonical, CERN, Cisco, Fujitsu, Intel, Red Hat, SanDisk, and SUSE.

And Nite_Hawk (Slashdot reader #1,304) is one of its core engineers — a former Red Hat principal software engineer named Mark Nelson. (He's now leading R&D for a small cloud systems company called Clyso that provides Ceph consulting.) And he's returned to Slashdot to share a blog post describing "a journey to 1 TiB/s". This gnarly tale-from-Production starts while assisting Clyso with "a fairly hip and cutting edge company that wanted to transition their HDD-backed Ceph cluster to a 10 petabyte NVMe deployment" using object-based storage devices [or OSDs]...) I can't believe they figured it out first. That was the thought going through my head back in mid-December after several weeks of 12-hour days debugging why this cluster was slow... Half-forgotten superstitions from the 90s about appeasing SCSI gods flitted through my consciousness...

Ultimately they decided to go with a Dell architecture we designed, which quoted at roughly 13% cheaper than the original configuration despite having several key advantages. The new configuration has less memory per OSD (still comfortably 12GiB each), but faster memory throughput. It also provides more aggregate CPU resources, significantly more aggregate network throughput, a simpler single-socket configuration, and utilizes the newest generation of AMD processors and DDR5 RAM. By employing smaller nodes, we halved the impact of a node failure on cluster recovery....

The initial single-OSD test looked fantastic for large reads and writes and showed nearly the same throughput we saw when running FIO tests directly against the drives. As soon as we ran the 8-OSD test, however, we observed a performance drop. Subsequent single-OSD tests continued to perform poorly until several hours later when they recovered. So long as a multi-OSD test was not introduced, performance remained high. Confusingly, we were unable to invoke the same behavior when running FIO tests directly against the drives. Just as confusing, we saw that during the 8 OSD test, a single OSD would use significantly more CPU than the others. A wallclock profile of the OSD under load showed significant time spent in io_submit, which is what we typically see when the kernel starts blocking because a drive's queue becomes full...

For over a week, we looked at everything from bios settings, NVMe multipath, low-level NVMe debugging, changing kernel/Ubuntu versions, and checking every single kernel, OS, and Ceph setting we could think of. None these things fully resolved the issue. We even performed blktrace and iowatcher analysis during "good" and "bad" single OSD tests, and could directly observe the slow IO completion behavior. At this point, we started getting the hardware vendors involved. Ultimately it turned out to be unnecessary. There was one minor, and two major fixes that got things back on track.
It's a long blog post, but here's where it ends up:

• Fix One: "Ceph is incredibly sensitive to latency introduced by CPU c-state transitions. A quick check of the bios on these nodes showed that they weren't running in maximum performance mode which disables c-states."

• Fix Two: [A very clever engineer working for the customer] "ran a perf profile during a bad run and made a very astute discovery: A huge amount of time is spent in the kernel contending on a spin lock while updating the IOMMU mappings. He disabled IOMMU in the kernel and immediately saw a huge increase in performance during the 8-node tests." In a comment below, Nelson adds that "We've never seen the IOMMU issue before with Ceph... I'm hoping we can work with the vendors to understand better what's going on and get it fixed without having to completely disable IOMMU."

• Fix Three: "We were not, in fact, building RocksDB with the correct compile flags... It turns out that Canonical fixed this for their own builds as did Gentoo after seeing the note I wrote in do_cmake.sh over 6 years ago... With the issue understood, we built custom 17.2.7 packages with a fix in place. Compaction time dropped by around 3X and 4K random write performance doubled."

The story has a happy ending, with performance testing eventually showing data being read at 635 GiB/s — and a colleague daring them to attempt 1 TiB/s. They built a new testing configuration targeting 63 nodes — achieving 950GiB/s — then tried some more performance optimizations...

Linux kernel 6.7 has been released, including support for the new next-gen copy-on-write (COW) bcachefs file system. The Register reports: Linus Torvalds announced the release on Sunday, noting that it is "one of the largest kernel releases we've ever had." Among the bigger and more visible changes are a whole new file system, along with fresh functionality for several existing ones; improved graphics support for several vendors' hardware; and the removal of an entire CPU architecture. [...] The single biggest feature of 6.7 is the new bcachefs file system, which we examined in March 2022. As this is the first release of Linux to include the new file system, it definitely would be premature to trust any important data to it yet, but this is a welcome change. The executive summary is that bcachefs is a next-generation file system that, like Btrfs and ZFS, provides COW functionality. COW enables the almost instant creation of "snapshots" of all or part of a drive or volume, which enables the OS to make disk operations transactional: In other words, to provide an "undo" function for complex sets of disk write operations.

Having a COW file system on Linux isn't new. The existing next-gen file system in the kernel, Btrfs, also supports COW snapshots. The version in 6.7 sees several refinements. It inherits a feature implemented for Steam OS: Two Btrfs file systems with the same ID can be mounted simultaneously, for failover scenarios. It also has improved quota support and a new raid_stripe_tree that improves handling of arrays of dissimilar drives. Btrfs remains somewhat controversial. Red Hat banished it from RHEL years ago (although Oracle Linux still offers it) but SUSE's distros depend heavily upon it. It will be interesting to see how quickly SUSE's Snapper tool gains support for bcachefs: This new COW contender may reveal unquestioned assumptions built into the code. Since Snapper is also used in several non-SUSE distros, including Spiral Linux, Garuda, and siduction, they're tied to Btrfs as well.

The other widely used FOSS next-gen file system, OpenZFS, also supports COW, but licensing conflicts prevent ZFS being fully integrated into the Linux kernel. So although multiple distros (such as NixOS, Proxmox, TrueNAS Scale, Ubuntu, and Void Linux) support ZFS, it must remain separate and distinct. This results in limitations, such as the ZFS Advanced Read Cache being separate from Linux's page cache. Bcachefs is all-GPL and doesn't suffer from such limitations. It aims to supply the important features of ZFS, such as integrated volume management, while being as fast as ext4 or XFS, and also surpass Btrfs in both performance and, crucially, reliability. A full list of changes in this release can be viewed via KernelNewbies.

Next April a new LTS Ubuntu arrives, and alongside it will be a whole new immutable desktop edition. At this year's Ubuntu conference in Riga, Latvia, Canonical revealed more details about its forthcoming immutable desktop distro. From a report: Core Desktop is not the next version of Ubuntu itself. Ordinary desktop and server Ubuntu aren't going anywhere, and the next release, numbered 24.04 and codenamed Noble Numbat as we mentioned last month, will be the default and come with all the usual editions and flavors. Nor is this a whole new product: it is a graphical desktop edition of the existing Ubuntu Core distro, as we examined on its release in June last year, a couple of months after 22.04. Ubuntu Core is Canonical's Internet of Things (IoT) distro, intended to be embedded on edge devices, such as digital signs and smart displays. It is an immutable distro, meaning that the root filesystem is read-only and there's no conventional package manager.

Rather than being a basis for customization, like a conventional Linux, the idea is that immutable distros are rolled out and updated more like a phone or tablet OS: there's a single fixed and heavily tested OS image, and it's deployed onto the devices out in the field without modification. Updates are monolithic: a whole fresh image is pushed out, and all the OS components are upgraded in a single operation to the same combination. That isn't unique. Most of the major Linux vendors have immutable offerings, and The Reg has looked at several over the years, including MicroOS, the basis of SUSE's next-gen enterprise OS ALP. As well as the well-known ChromeOS, another immutable desktop is the educational distro Endless OS.

[...] Canonical believes it has some unique new angles. Core Desktop is constructed as additional layers on top of the existing Ubuntu Core distro, and like Core, it's entirely built with a single packaging system: Ubuntu's Snap. While Snap remains controversial, it does have some compelling advantages over both SUSE and Red Hat's tooling. SUSE's transactional_update tool, while simpler than its rivals in implementation, requires a snapshot-capable filesystem, meaning that its immutable distros must use Btrfs. While it has many admirers, the number and the contents of the orange and red cells in the feature tables here in its own documentation reflect the FOSS desk's serious reservations about Btrfs.

Long-time Slashdot reader williamyf writes: In the ongoing battle between Red Hat and other "Enterprise Linux -- RHEL compatible" distros, today the OpenELA (Open Enterprise Linux Association), a body Consisting of CIQ (stewards of Rocky Linux), Oracle and Suse, released source code for a generic "Enterprise Linux Distro" (Sources available for RHEL 8 and RHEL 9). A Steering committee for the foundation was also formed.

War between Red Hat and what they call "clones" (mostly Oracle; CentOS, Rocky, Alma and others seem to be collateral damage) has been raging on for years. First, in 2011, Red Hat changed the way they distributed kernel patches. Then, in 2014, Red Hat absorbed CentOS. In 2019 Red Hat transformed CentOS to CentOS stream, and shortened support Timetables for CentOS 8, all out of the blue. Then, in 2023, RedHat severely restricted source code access to non-customers.

What will be RedHat's reaction to this development? My bet is that they will stop to release source code of distro modules under BSD, MIT, APACHE and MPL Licenses for RHEL and in certain Windows for CentOS Stream. What is your bet? Let us know in the comments.

An anonymous reader shares a report: When Mike McGrath, Red Hat's Red Hat Core Platforms vice president, announced that Red Hat was putting new restrictions on who could access Red Hat Enterprise Linux (RHEL)'s code, other Linux companies that depended on RHEL's code for their own distro releases were, in a word, unhappy. Three of them, CIQ, Oracle, and SUSE, came together to form the Open Enterprise Linux Association (OpenELA). Their united goal was to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code." Now, the first OpenELA code release is available.

As Thomas Di Giacomo, SUSE's chief technology and product officer, said in a statement, "We're pleased to deliver on our promise of making source code available and to continue our work together to provide choice to our customers while we ensure that Enterprise Linux source code remains freely accessible to the public." Why are they doing this? Gregory Kurtzer, CIQ's CEO, and Rocky Linux's founder, explained: "Organizations worldwide standardized on CentOS because it was freely available, followed the Enterprise Linux standard, and was well supported. After CentOS was discontinued, it left not only a gaping hole in the ecosystem but also clearly showed how the community needs to come together and do better. OpenELA is exactly that -- the community's answer to ensuring a collaborative and stable future for all professional IT departments and enterprise use cases."

Two years after being listed on the Frankfurt Stock Exchange, the Linux-for-enterprise company SUSE is switching back to private ownership. The Register reports: On Wednesday the developer announced that its majority shareholder, an entity called Marcel LUX III SARL, intends to take it private by delisting it from the Frankfurt Stock Exchange and merging it with an unlisted Luxembourg entity. Marcel is an entity controlled by EQT Private Equity, a Swedish investment firm, which acquired it from MicroFocus in 2018.

The announcement offers scant detail about the rationale for the delisting, other than a canned quote from SUSE CEO Dirk-Peter van Leeuwen who said, "I believe in the strategic opportunity of taking the company private -- it gives us the right setting to grow the business and deliver on our strategy with the new leadership team in place." Van Leeuwen took the big chair at SUSE just over three months back, on May 1. The deal values SUSE at 16 euros per share -- well below the 30-euro price of the 2021 float, but above the Thursday closing price of 9.605 euros.

Interestingly, Marcel is happy for shareholders not to take the money and run. "There is no obligation for shareholders to accept the Offer," explains the announcement's detail of the transaction's structure. "EQT Private Equity does not intend to pursue a squeeze-out. Therefore, shareholders who wish to stay invested in SUSE in a private setting may do so." Shareholders who stick around will therefore score their portion of a special dividend SUSE will pay out as part of this transaction. Those who sell will get the aforementioned 16-euros per share, less their portion of the interim dividend. The transaction to take SUSE private is expected to conclude in the final quarter of 2023.

Why aren't more people using Linux on the desktop? Slashdot reader technology_dude shares one solution: Jack Wallen at ZDNet says establishing an "official" version of Linux may (or may not) help Linux on the desktop increase the number of users, mostly as someplace to point new users. It makes sense to me. What does Slashdot think and what would be the challenges, other than acceptance of a particular flavor?
Wallen argues this would also create a standard for hardware and software vendors to target, which "could equate to even more software and hardware being made available to Linux." (And an "official" Linux might also be more appealing to business users.) Wallen suggests it be "maintained and controlled by a collective of people from users, developers, and corporations (such as Intel and AMD) with a vested interest in the success of this project... There would also be corporate backing for things like marketing (such as TV commercials)." He also suggests basing it on Debian, and supporting both Snap and Flatpak...

In comments on the original submission, long-time Slashdot reader bobbomo points instead to kernel.org, arguing "There already is an official version of Linux called mainline. Everything else is backports." And jd (Slashdot user #1,658) believes that the official Linux is the Linux Standard Base. "All distributions, more-or-less, conform to the LSB, which gives you a pseudo 'official' Linux. About the one variable is the package manager. And there are ways to work around that."

Unfortunately, according to Wikipedia... The LSB standard stopped being updated in 2015 and current Linux distributions do not adhere to or offer it; however, the lsb_release command is sometimes still available.[citation needed] On February 7, 2023, a former maintainer of the LSB wrote, "The LSB project is essentially abandoned."
That post (on the lsb-discuss mailing list) argues the LSB approach was "partially superseded" by Snaps and Flatpaks (for application portability and stability). And of course, long-time Slashdot user menkhaura shares the obligatory XKCD comic...

It's not exactly the same thing, but days after ZDNet's article, CIQ, Oracle, and SUSE announced the Open Enterprise Linux Association, a new collaborative trade association to foster "the development of distributions compatible with Red Hat Enterprise Linux."

So where does that leave us? Share your own thoughts in the comments.

And should there be an "official" version of Linux?

In a groundbreaking move, CIQ, Oracle, and SUSE have come together to announce the formation of the Open Enterprise Linux Association (OpenELA). From a report: The goal of this new collaborative trade association is to foster "the development of distributions compatible with Red Hat Enterprise Linux (RHEL) by providing open and free enterprise Linux source code."

The inception of OpenELA is a direct response to Red Hat's recent alterations to RHEL source code availability. This new Delaware 501(c)(6) US nonprofit association will provide an open process for organizations to access source code. This will enable it to build RHEL-compatible distributions. The initiative underscores the importance of community-driven source code, which serves as a foundation for creating compatible distributions.

Mike McGrath, Red Hat's vice president of Red Hat Core Platforms, sparked this when he announced Red Hat would be changing how users can access RHEL's source code. For the non-Hatters among you, Core Platforms is the division in charge of RHEL. McGrath wrote, "CentOS Stream will now be the sole repository for public RHEL-related source code releases. For Red Hat customers and partners, source code will remain available via the Red Hat Customer Portal."

This made it much more difficult for RHEL clone vendors, such as AlmaLinux, Rocky Linux, and Oracle Linux, to create perfect RHEL variant distributions. AlmaLinux elected to try to work with Red Hat's new source code rules. Oracle restarted its old fighting ways with IBM/Red Hat; SUSE announced an RHEL-compatible distro fork plan; and Rocky Linux found new ways to obtain RHEL code. Now the last two, along with CIQ, which started Rocky Linux, have joined forces.

In February of 1994 Jon "maddog" Hall interviewed a young Linus Torvalds (then just 24). Nearly three decades later — as Hall approaches his 73rd birthday — he's shared a long essay looking back, but also assessing today's controversy about Red Hat's licensing of RHEL. A (slightly- condensed] excerpt: [O]ver time some customers developed a pattern of purchasing a small number of RHEL systems, then using the "bug-for-bug" compatible version of Red Hat from some other distribution. This, of course, saved the customer money, however it also reduced the amount of revenue that Red Hat received for the same amount of work. This forced Red Hat to charge more for each license they sold, or lay off Red Hat employees, or not do projects they might have otherwise funded. So recently Red Hat/IBM made a business decision to limit their customers to those who would buy a license from them for every single system that would run RHEL and only distribute their source-code and the information necessary on how to build that distribution to those customers. Therefore the people who receive those binaries would receive the sources so they could fix bugs and extend the operating system as they wished.....this was, and is, the essence of the GPL.

Most, if not all, of the articles I have read have said something along the lines of "IBM/Red Hat seem to be following the GPL..but...but...but... the community! "

Which community? There are plenty of distributions for people who do not need the same level of engineering and support that IBM and Red Hat offer. Red Hat, and IBM, continue to send their changes for GPLed code "upstream" to flow down to all the other distributions. They continue to share ideas with the larger community. [...]

I now see a lot of people coming out of the woodwork and beating their breasts and saying how they are going to protect the investment of people who want to use RHEL for free [...] So far I have seen four different distributions saying that they will continue the production of "not RHEL", generating even more distributions for the average user to say "which one should I use"? If they really want to do this, why not just work together to produce one good one? Why not make their own distributions a RHEL competitor? How long will they keep beating their breasts when they find out that they can not make any money at doing it? SuSE said that they would invest ten million dollars in developing a competitor to RHEL. Fantastic! COMPETE. Create an enterprise competitor to Red Hat with the same business channels, world-wide support team, etc. etc. You will find it is not inexpensive to do that. Ten million may get you started.

My answer to all this? RHEL customers will have to decide what they want to do. I am sure that IBM and Red Hat hope that their customers will see the value of RHEL and the support that Red Hat/IBM and their channel partners provide for it. The rest of the customers who just want to buy one copy of RHEL and then run a "free" distribution on all their other systems no matter how it is created, well it seems that IBM does not want to do business with them anymore, so they will have to go to other suppliers who have enterprise capable distributions of Linux and who can tolerate that type of customer. [...]

I want to make sure people know that I do not have any hate for people and companies who set business conditions as long as they do not violate the licenses they are under. Business is business.

However I will point out that as "evil" as Red Hat and IBM have been portrayed in this business change there is no mention at all of all the companies that support Open Source "Permissive Licenses", which do not guarantee the sources to their end users, or offer only "Closed Source" Licenses....who do not allow and have never allowed clones to be made....these people and companies do not have any right to throw stones (and you know who you are).

Red Hat and IBM are making their sources available to all those who receive their binaries under contract. That is the GPL.

For all the researchers, students, hobbyists and people with little or no money, there are literally hundreds of distributions that they can choose, and many that run across other interesting architectures that RHEL does not even address.
Hall answered questions from Slashdot users in 2000 and again in 2013.

Further reading: Red Hat CEO Jim Whitehurst answering questions from Slashdot readers in 2017.