Linux Distributors' Alliance Continues Long-Term Support for Linux 4.14 (zdnet.com) 19
"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."
Hans Reiser Sends a Letter From Prison (arstechnica.com) 181
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.
Ceph: a Journey To 1 TiB/s (ceph.io) 16
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...
Biggest Linux Kernel Release Ever Welcomes bcachefs File System, Jettisons Itanium (theregister.com) 52
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.
Canonical Reveals More Details About Ubuntu Core Desktop 22
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.
OpenELA Drops First RHEL, 'Enterprise Linux' Compatible Source Code (theregister.com) 39
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.
CIQ, Oracle and SUSE Unite Behind OpenELA To Take on Red Hat Enterprise Linux (zdnet.com) 18
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."
SUSE To Flip Back Into Private Ownership (theregister.com) 17
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.
Should There Be an 'Official' Version of Linux? (zdnet.com) 283
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?
Oracle, SUSE, and CIQ Go After Red Hat With the Open Enterprise Linux Association (zdnet.com) 70
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.
Jon 'maddog' Hall Defends Red Hat's Re-Licensing of RHEL (lpi.org) 101
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.
RHEL Response Discussed by SFC Conference's Panel - Including a New Enterprise Linux Standard (sfconservancy.org) 66
And long-time free software activist Bradley M. Kuhn (currently a policy fellow/hacker-in-residence for the Software Freedom Conservancy) hosted a lively panel discussion on "the recent change" to public source code releases for Red Hat Enterprise Linux which shed light on what may happen next. The panel also included:
- benny Vasquez, the Chair of the AlmaLinux OS Foundation
- Jeremy Alison, Samba co-founder and software engineer at CIQ (focused on Rocky Linux). Allison is also Jeremy Allison - Sam Slashdot reader #8,157.
- James (Jim) Wright, Oracle's chief architect for Open Source policy/strategy/compliance/alliances
"Red Hat themselves did not reply to our repeated requests to join us on this panel... SUSE was also invited but let us know they were unable to send someone on short notice to Portland for the panel."
One interesting audience question for the panel came from Karsten Wade, a one-time Red Hat senior community architect who left Red Hat in April after 21 years, but said he was "responsible for bringing the CentOS team onboard to Red Hat." Wade argued that CentOS "was always doing a clean rebuild from source RPMS of their own..." So "isn't all of this thunder doing Red Hat's job for them, of trying to get everyone to say, 'This thing is not the equivalent to RHEL.'"
In response Jeremy Alison made a good point. "None of us here are the arbiters of whether it's good enough of a rebuild of Red Hat Linux. The customers are the arbiters." But this led to an audience member asking a very forward-looking question: what are the chances the community could adopt a new (and open) enterprise Linux standard that distributions could follow. AlmaLinux's Vasquez replied, "Chances are real high... I think everyone sees that as the obvious answer. I think that's the obvious next step. I'll leave it at that." And Oracle's Wright added "to the extent that the market asks us to standardize? We're all responsive."
When asked if they'd consider adding features not found in RHEL ("such as high-security gates through reproducible builds") AlmaLinux's Vasquez said "100% -- yeah. One of the things that we're kind of excited about is the opportunities that this opens for us. We had decided we were just going to focus on this north star of 1:1 Red Hat no matter what -- and with that limitation being removed, we have all kinds of options." And CIQ's Alison said "We're working on FIPS certification for an earlier version of Rocky, that Red Hat, I don't believe, FIPS certified. And we're planning to release that."
AlmaLinux's Vasquez emphasized later that "We're just going to build Enterprise Linux. Red Hat has done a great job of establishing a fantastic target for all of us, but they don't own the rights to enterprise Linux. We can make this happen, without forcing an uncomfortable conversation with Red Hat. We can get around this."
And Alison later applied a "Star Wars" quote to Red Hat's predicament. "The more things you try and grab, the more things slip through your fingers." That is, "The more somebody tries to exert control over a codebase, the more the pushback will occur from people who collaborate in that codebase." AlmaLinux's Vasquez also said they're already "in conversations" with independent software vendors about the "flow of support" into non-Red Hat distributions -- though that's always been the case. "Finding ways to reduce the barrier for those independent software vendors to add official support for us is, like, maybe more cumbersome now, but it's the same problem that we've had..."
Early in the discussion Oracle's Jim Wright pointed out that even Red Hat's own web site defines open source code as "designed to be publicly accessible — anyone can see, modify, and distribute the code as they see fit." ("Until now," Wright added pointedly...) There was some mild teasing of Oracle during the 50-minute discussion -- someone asked at one point if they'd re-license their proprietary implementation of ZFS under the GPL. But at the end of the panel, Oracle's Jim Wright still reminded the audience that "If you want to work on open source Linux, we are hiring."
Read Slashdot's transcript of highlights from the discussion.
SUSE Will Fork Red Hat Enterprise Linux (zdnet.com) 51
Others see this as the latest step in the long dance between Red Hat's business licensing demands and open-source licensing. Red Hat has had conflicts with the RHEL clones since 2005, when Red Hat's trademarks were the issue of the day. Usually, these fights stayed confined to the RHEL and its immediate clone rivals. Not this time.
Dirk-Peter van Leeuwen, SUSE CEO, said this: "For decades, collaboration and shared success have been the building blocks of our open-source community. We have a responsibility to defend these values. This investment will preserve the flow of innovation for years to come and ensures that customers and community alike are not subjected to vendor lock-in and have genuine choice tomorrow as well as today." What does that mean? While SUSE will continue to invest in and support its own Linux distributions, SUSE Linux Enterprise (SLE) and openSUSE, SUSE plans on creating its own RHEL-compatible clone. Once completed, this new distro will be contributed to an open-source foundation, which will provide ongoing free access to alternative source code.
Defying Red Hat, Rocky Linux and AlmaLinux Vow to Continue RHEL-Compatible Updates (arstechnica.com) 143
"These methods are possible because of the power of GPL," explains Rocky Linux's blog post. "No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions.... [O]ur unwavering dedication and commitment to open source and the Enterprise Linux community remain steadfast."
"In the unfortunate event that Red Hat decides to ramp up efforts to negatively impact the community, Rocky Linux will persist to continue serving the best interests of the entire open source community. As a reminder, we welcome everyone to contribute to our efforts. You can learn more about how you can join us and all of the various ways to contribute on our wiki."
Ars Technica notes that AlmaLinux is "also working to keep providing RHEL-compatible updates and downstream rebuilds." "The process is more labor intensive as we require gathering data and patches from several sources, comparing them, testing them, and then building them for release," wrote Jack Aboutboul, community manager for AlmaLinux, in a blog post. "But rest assured, updates will continue flowing just as they have been."
The Software Freedom Conservancy's Bradley M. Kuhn weighed in last week with a comprehensive overview of RHEL's business model and its tricky relationship with GPL compliance. Red Hat's business model "skirts" GPL violation but had only twice previously violated the GPL in newsworthy ways, Kuhn wrote. Withholding Complete Corresponding Source (CCS) from the open web doesn't violate the GPL itself, but by doing so, Red Hat makes it more difficult for anyone to verify the company's GPL compliance.
Kuhn expressed sadness that "this long road has led the FOSS community to such a disappointing place."
Red Hat argued that they "do not find value in a RHEL rebuild." Rocky Linux dismissed this view as "narrow-minded," and RHEL-derived AlmaLinux even responded with specific examples, also noting its contributions to the RHEL and CentOS communities. AlmaLinux's community manager wrote "When executed properly, downstream rebuilds provide tremendous value and are a tremendous asset to upstream projects."
And ITWire shares one more reaction: German open source vendor SUSE says it will not be making any changes to its policies on source code access, emphasising "that the freedom to access, modify, and distribute software should remain open to all".
Latest SUSE Linux Enterprise Goes All in With Confidential Computing 7
SUSE announced the latest version at its SUSECON event in Munich, along with a new report on cloud security issues claiming that more than 88 percent of IT teams have reported at least one cloud security incident over the the past year. This appears to be the justification for the claim that SLE 15 SP5 is the first Linux distro to support "the entire spectrum" of confidential computing, allowing customers to run fully encrypted virtual machines on their infrastructure to protect applications and their associated data. Confidential computing relies on hardware-based security mechanisms in the processor to provide this protection, so enterprises hoping to take advantage of this will need to ensure their servers have the necessary support, such as AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) and Intel's Trust Domain Extensions (TDX).
Linux Kernel Fixes Longstanding Bug in Its Handling of Floppy Disks (theregister.com) 57
Back in July 2016, SUSE kernel developer Jiri Kosina submitted a patch. The problem arose because this change broke something else and later got reverted, and so the problem hung around. In July last year, he sent in a new patch that fixed it again for the 5.12 kernel, and was later back-ported to 5.10, an LTS version, and again into kernel 5.15 — another an LTS version, and the one you're running today if you're on the current Ubuntu LTS release, or something built from it such as Linux Mint 21....
Now, in December 2022, a new patch for the forthcoming kernel 6.2 fixes a memory leak that dates back to 5.11 or before.
Microsoft Launches Arm-based Azure VMs Powered by Ampere Chips (techcrunch.com) 13
The Azure Arm-based VMs have up to 64 virtual CPU cores, 8 GB of memory per core and 40 Gbps of networking bandwidth as well as SSD local and attachable storage. Microsoft describes them as "engineered to efficiently run scale-out, cloud-native workloads," including open source databases, Java and .NET applications and gaming, web, app and media servers. Preview releases of Windows 11 Pro and Enterprise and Linux OS distributions including Canonical Ubuntu, Red Hat Enterprise Linux, SUSE Enterprise Linux, CentOS and Debian are available on the VMs day one, with support for Alma Linux and Rocky Linux to arrive in the future. Microsoft notes that Java apps in particular can run with few additional code changes, thanks to the company's contributions to the OpenJDK project.
'I Love the Linux Desktop, But That Doesn't Mean I Don't See Its Problems All Too Well' (theregister.com) 197
[...]
Besides over 200 distros, there are 21 different desktop interfaces and over half-a-dozen different major ways to install software such as the Debian Package Management System (DPKG), Red Hat Package Manager (RPM), Pacman, Zypper, and all too many others. Then there are all the newer containerized ways to install programs including Flatpak, Snap, and AppImage. I can barely keep them all straight and that's part of my job! How can you expect ordinary users to make sense of it all? You can't. None of the major Linux distributors -- Canonical, Red Hat, and SUSE -- really care about the Linux desktop. Sure, they have them. They're also major desktop influencers. But their cash comes from servers, containers, the cloud, and the Internet of Things (IoT). The desktop? Please. We should just be glad they spend as many resources as they do on them.
Now, all this said, I don't want you to get the impression that I don't think the conventional Linux desktop is important. I do. In fact, I think it's critical. Microsoft, you see, is abandoning the traditional PC-based desktop. In its crystal ball, Microsoft sees Azure-based Desktop-as-a-Service (DaaS) as its future. [...] That means that the future of a true desktop operating system will lie in the hands of Apple with macOS and us with Linux. As someone who remembers the transition from centrally controlled mainframes and minicomputers to individually empowered PCs, I do not want to return to a world where all power belongs to Microsoft or any other company. "The Linux desktop will never be as big as Windows once was," writes Vaughan-Nichols in closing. "Between DaaS's rise and the fall of the desktop to smartphones, it can't be. But it may yet, by default, become the most popular true conventional desktop."
Surprise: Microsoft Has a Second Internal-Use-Only Linux Distro (zdnet.com) 59
"It turns out there's another Microsoft-developed Linux distribution that's also for internal use that's known as CBL-Delridge or CBL-D." I discovered the existence of CBL-D for the first time this week in a rather round-about way. I stumbled onto a February 2 blog post from Hayden Barnes. a Senior Engineering Manager at SuSE who led the Windows on Rancher engineering team, which traced his steps in discovering and building his own image of CBL-D. Barnes noted that Microsoft published CBL-Delridge in 2020, the same year that it also published CBL-Mariner. The main difference between the two: Delridge is a custom Debian derivative, while Mariner is a custom Linux From Scratch-style distribution.
CBL-D powers Azure's Cloud Shell. The Azure Cloud Shell provides a set of cloud-management tools packaged in a container. In a note on the GitHub repo for the Cloud Shell, officials noted that "the primary difference between Debian and CBL-D is that Microsoft compiles all the packages included in the CBL-D repository internally. This helps guard against supply chain attacks...."
CBL-Mariner and CBL-Delridge are just two of the Microsoft-developed Linux-related deliverables from the Linux Systems Group. Others include the Windows Subsystem for Linux version 2 (WSL2), which is part of Windows 10; an Azure-tuned Linux kernel which is designed for optimal performance as Hyper-V guests; and Integrity Policy Enforcement (IPE), a proposed Linux Security Module (LSM) from the Enterprise and Security team.