Steven Vaughan-Nichols writes via ZDNet: I'd been waiting for Oracle to throw its hat into the ring for the Red Hat Enterprise Linux (RHEL) Linux source-code fight. I knew it was only a matter of time. On July 10, Oracle's Edward Screven, chief corporate architect, and Wim Coekaerts, head of Oracle Linux development, declared: "IBM's actions are not in your best interest. By killing CentOS as a RHEL alternative and attacking AlmaLinux and Rocky Linux, IBM is eliminating one way your customers save money and make a larger share of their wallet available to you."

In fact, Oracle now presents itself as an open-source Linux champion: "Oracle has always made Oracle Linux binaries and source freely available to all. We do not have subscription agreements that interfere with a subscriber's rights to redistribute Oracle Linux. On the other hand, IBM subscription agreements specify that you're in breach if you use those subscription services to exercise your GPLv2 rights." As of June 21, IBM no longer publicly releases RHEL source code -- in short, the gloves are off, and the fight's on. But this is also just the latest move in a fight that's older than many of you. [...]

Mike McGrath, Red Hat's vice president of core platforms, explained why Red Hat would no longer be releasing RHEL's code, but only CentOS Stream's code, because "thousands of [Red Hat] people spend their time writing code to enable new features, fixing bugs, integrating different packages and then supporting that work for a long time ... We have to pay the people to do that work." That sentiment is certainly true. But I also feel that Oracle takes the worst possible spin, with Screven and Coekaerts commenting: "IBM doesn't want to continue publicly releasing RHEL source code because it has to pay its engineers? That seems odd, given that Red Hat as a successful independent open source company chose to publicly release RHEL source and pay its engineers for many years before IBM acquired Red Hat in 2019 for $34 billion."

So, what will Oracle do now? For starters, Oracle Linux will continue to be RHEL-compatible through RHEL 9.2. After that release -- and without access to the published RHEL source code -- there are no guarantees. But Screven and Coekaerts suggest that "if an incompatibility does affect a customer or ISV, Oracle will work to remediate the problem." As for Oracle Linux's code: "Oracle is committed to Linux freedom. Oracle makes the following promise: as long as Oracle distributes Linux, Oracle will make the binaries and source code for that distribution publicly and freely available. Furthermore, Oracle welcomes downstream distributions of every kind, community, and commercial. We are happy to work with distributors to ease that process, work together on the content of Oracle Linux, and ensure Oracle software products are certified on your distribution."

John.Banister writes: SUSE announced that they're spending $10 million on maintaining a fork of RHEL, with the source code of the fork to be freely available to all. I don't know that people who want to copy RHEL source will necessarily see copying the source of a fork as furthering their goals, but it could be that SUSE will build a nice alternative enterprise Linux to complement their current product. And, I reckon, better SUSE than Oracle, since I keep reading comments on people getting screwed by Oracle, but not so many on people getting screwed by SUSE. ZDNet's Steven Vaughan-Nichols writes: This all started when Red Hat's VP of core platforms, Mike McGrath, declared, "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." That may not sound like much to you, but those were fighting words to many open-source and Linux distributors. According to Linux's fundamental license, the GPLv2, no restrictions can be placed on distributing the source code to those who've received the binaries. In the view of many in the open-source community, that's exactly what Red Hat has done.

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.

According to Statcounter, the Linux share on the desktop has passed 3% for the first time. GamingOnLinux reports: While it has been close a couple of times, the trend according to their stats is pretty clear that Linux use has been slowly rising over the last few years. This does not include ChromeOS, even though it's based on Linux, as they track that separately so this is just plain desktop Linux.

Across this year their stats show for Linux:

January - 2.91%
February - 2.94%
March - 2.85%
April - 2.83%
May - 2.7%
June - 3.07%

Linus Torvalds has delivered the first release candidate for version 6.5 of the Linux kernel, but warned this release may not go entirely smoothly. From a report: Torvalds's headline assessment of rc1 is "none of it looks hugely unusual." "The biggest single mention probably goes to what wasn't merged, with the bcachefs pull request resulting in a long thread (we didn't hit a hundred emails yet, but it's not far away)." As The Register reported in 2022, bcachefs is a filesystem that's been in development for nigh on a decade without being added to the kernel.

Kernel-watching outlet Phoronix on Sunday wrote that the filesystem is in good shape but debate over "code changes needed to the kernel outside of the kernel module itself" have proved contentious. As a result, conversation on the Linux kernel mailing list is "often becoming heated" when the topic turns to bcachefs. In his announcement post for rc1, Torvalds wrote "Let's calm this party down."

Wednesday Greg Kroah-Hartman announced the release of the 6.4.2 kernel. "All users of the 6.4 kernel series must upgrade."

The Hacker News reports: Details have emerged about a newly identified security flaw in the Linux kernel that could allow a user to gain elevated privileges on a target host. Dubbed StackRot (CVE-2023-3269, CVSS score: 7.8), the flaw impacts Linux versions 6.1 through 6.4. There is no evidence that the shortcoming has been exploited in the wild to date.

"As StackRot is a Linux kernel vulnerability found in the memory management subsystem, it affects almost all kernel configurations and requires minimal capabilities to trigger," Peking University security researcher Ruihan Li said. "However, it should be noted that maple nodes are freed using RCU callbacks, delaying the actual memory deallocation until after the RCU grace period. Consequently, exploiting this vulnerability is considered challenging."

Following responsible disclosure on June 15, 2023, it has been addressed in stable versions 6.1.37, 6.3.11, and 6.4.1 as of July 1, 2023, after a two-week effort led by Linus Torvalds. A proof-of-concept (PoC) exploit and additional technical specifics about the bug are expected to be made public by the end of the month.
ZDNet points out that Linux 6.4 "offers improved hardware enablement for ARM boards" and does a better job with the power demands of Steam Deck gaming devices. And "On the software side, the Linux 6.4 release includes more upstreamed Rust code. We're getting ever closer to full in-kernel Rust language support."

The Register also notes that Linux 6.4 also includes "the beginnings of support for Apple's M2 processors," along with support for hibernation of RISC-V CPUs, "a likely presage to such silicon powering laptop computers."

The June Steam Survey results show that AMD CPUs have gained significant popularity among Linux gamers, with a market share of 67% -- a remarkable 7% increase from the previous month. Phoronix reports: In part that's due to the Steam Deck being powered by an AMD SoC but it's been a trend building for some time of AMD's increasing Ryzen CPU popularity among Linux users to their open-source driver work and continuing to build more good will with the community.

In comparison, last June the AMD CPU Linux gaming marketshare came in at 45% while Intel was at 54%. Or at the start of 2023, AMD CPUs were at a 55% marketshare among Linux gamers. Or if going back six years, AMD CPU use among Linux gamers was a mere 18% during the early Ryzen days. It's also the direct opposite on the Windows side. When looking at the Steam Survey results for June limited to Windows, there Intel has a 68% marketshare to AMD at 32%.

Beyond the Steam Deck, it's looking like AMD's efforts around open-source drivers, AMD expanding their Linux client (Ryzen) development efforts over the past two years, promises around OpenSIL, and other efforts commonly covered on Phoronix are paying off for AMD in wooing over their Linux gaming customer base.

Reactions continue to Red Hat's announcement that they'd start limiting access to Red Hat Enterprise Linux sources, reports Ars Technica: Rocky Linux, launched by CentOS co-founder Greg Kurtzer as a replacement RHEL-compatible distro, announced Thursday that it believes Red Hat's moves "violate the spirit and purpose of open source." Using a few different methods (Universal Base Image containers, pay-per-use public cloud instances), Rocky Linux intends to maintain what it considers legitimate access to RHEL code under the GNU General Public License (GPL) and make the code public as soon as it exists.
"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".

End-of-life for Red Hat 7 is scheduled to happen in one year. Thursday Red Hat announced an add-on option for four more years of "extended support" for RHEL 7: As we near the end of the standard 10-year life cycle of RHEL 7, some IT organizations are finding that they cannot complete their planned migrations before June 30, 2024. To support IT teams while they catch up on their migration schedules, Red Hat is announcing a one-time, 4 year ELS maintenance period for RHEL 7 ELS. While Red Hat is providing more time, we strongly recommend customers migrate to a newer version of RHEL to take advantage of new features and enhancements...

For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...

ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.

When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.
CentOS 7 will also hit its end-of-life in one year on June 30 of 2024.

Wikipedia defines the Yocto Project as "a Linux Foundation collaborative open source project whose goal is to produce tools and processes that enable the creation of Linux distributions for embedded and IoT software that are independent of the underlying architecture of the embedded hardware."

This week the Linux Foundation shared an update on the 12-year-old Yocto Project: In an effort to support the community, The Yocto Project announced the first Long Term Support (LTS) release in October 2020. Today, we are delighted to announce that we are expanding the LTS release and extending the lifecycle from 2 to 4 years as standard.

The continued growth of the Yocto Project coincides with the welcomed addition of Exein as a Platinum Member, joining AMD/Xilinx, Arm, AWS, BMW Group, Cisco, Comcast, Intel, Meta and WindRiver. As a Member, Exein brings its embedded security expertise across billions of devices to the core of the Yocto Project...

"The Yocto Project has been at the forefront of OS technologies for over a decade," said Andrew Wafaa, Yocto Project Chairperson. "The adaptability and variety of the tooling provided are clearly making a difference to the community. We are delighted to welcome Exein as a member as their knowledge and experience in providing secure Yocto Project based builds to customers will enable us to adapt to the modern landscape being set by the US Digital Strategy and the EU Cyber Resilience Act."

"We're extremely excited to become a Platinum Partner of the Yocto Project," said Gianni Cuozzo, founder and CEO of Exein. "The Yocto Project is the most important project in the embedded Linux space, powering billions of devices every year. We take great pride in contributing our extensive knowledge and expertise in embedded security to foster a future that is both enhanced and secure for Yocto-powered devices. We are dedicated to supporting the growth of the Yocto Project as a whole, aiming to improve its support for modern languages like Rust, and assist developers and OEMs in aligning with the goals outlined in the EU Cyber Resilience Act."

Linux magazine reports that "Former Snap co-developer Alan Pope, who left Canonical in 2021 after 10 years with the company, has developed unsnap, a script that replaces snaps with Flatpaks where available. The script, hosted on GitHub, has been tested by the developers for use on Ubuntu and all derivatives that offer snapd and packages in the Snap format."

Pope clarifies its status on GitHub: Let's say it's "Pre-alpha", as in "It kinda works on my computer". Unless you plan on contributing (see below) it's probably not ready for you, yet.
And Pope notes the existence of "related projects" like the custom-desktop project by Natan Junges "which provides a set of packages to revert an existing Ubuntu install back to something many users may appreciate more." And "deb-get enables Ubuntu users to install and update deb-based packages of popular applications"

But Linux magazine tested out unsnap: The flatpak list command can be used to determine which snaps were converted to Flatpak format. For snaps with a Flatpak equivalent, unsnap converted these snaps cleanly, and all of the programs remained functional. The script left the remaining snaps and the infrastructure untouched...

An equivalent Flatpak must be available, which is very often the case with graphical applications. With a little manual work, the Snap infrastructure can also be removed.

gatzke writes: Upsetting many in the open-source community was Red Hat's announcement last week that they would begin limiting access to the Red Hat Enterprise Linux sources by putting them behind the Red Hat Customer Portal and publicly would be limited to the CentOS Stream sources. In turn this causes problems for free-of-cost derivatives like AlmaLinux moving forward. Red Hat this week issued another blog post trying to address some of the criticism.

Red Hat's blog this week featured a post by Mike McGrath, the VP of Core Platforms Engineering at Red Hat. In the post he talks up "Red Hat's commitment to open source." Some of the key takeaways include:
"Despite what's currently being said about Red Hat, we make our hard work readily accessible to non-customers. Red Hat uses and will always use an open source development model. When we find a bug or write a feature, we contribute our code upstream. This benefits everyone in the community, not just Red Hat and our customers.
... We will always send our code upstream and abide by the open source licenses our products use, which includes the GPL. When I say we abide by the various open source licenses that apply to our code, I mean it.
... I feel that much of the anger from our recent decision around the downstream sources comes from either those who do not want to pay for the time, effort and resources going into RHEL or those who want to repackage it for their own profit. This demand for RHEL code is disingenuous.
... Simply rebuilding code, without adding value or changing it in any way, represents a real threat to open source companies everywhere. This is a real threat to open source, and one that has the potential to revert open source back into a hobbyist- and hackers-only activity."

Long-time Slashdot reader internet-redstar writes: In little longer than 1 year, RHEL7 and CentOS 7 will go EOL. Large enterprises with thousands of these servers are struggling to meet that deadline. Now they also have the option to use Project78 from Linux Belgium which offers a Cloud and OnPrem version to aid in the transition to RHEL 8 or Rocky Linux 8. It promises a 100% success rate for in-place OS upgrading and a 95% success rate for application migrations in a Upgrade-as-a-Service package.
In April Red Hat's senior technical marketing manager shared their thoughts about next year's end of life for CentOS Linux and the End-of-Maintenance for Red Hat Enterprise Linux 7 (along with some tips): The good news is that these events won't require a complete infrastructure overhaul. Tools are available to move from your current configuration to a place where you'll have years of support. While June of '24 may sound a ways off, do not delay. It will be here faster than you think. Start planning now. Start moving soon. Give yourself plenty of runway, and don't forget that we aren't just your software vendor at Red Hat. We are your partners and are here to help you with these transitions.
UPDATE (7/3): Thursday Red Hat announced an add-on option for four more years of "extended support" for RHEL 7: As we near the end of the standard 10-year life cycle of RHEL 7, some IT organizations are finding that they cannot complete their planned migrations before June 30, 2024. To support IT teams while they catch up on their migration schedules, Red Hat is announcing a one-time, 4 year ELS maintenance period for RHEL 7 ELS. While Red Hat is providing more time, we strongly recommend customers migrate to a newer version of RHEL to take advantage of new features and enhancements...

For organizations that need to remain on a major release beyond the standard life cycle, we offer the Extended Life Cycle Support (ELS) Add-On. This add-on currently extends support of major releases for up to 2 years after the end of the standard release life cycle. As an optional, add-on subscription, ELS gives you access to troubleshooting for the last minor release, selected urgent priority bug fixes and certain Red Hat-defined security fixes...

ELS for RHEL 7 is now available for 4 years, starting on July 1, 2024. Organizations must be on RHEL 7.9 to take advantage of this. Compared to previous major releases, ELS for RHEL 7 (RHEL 7.9) expands the scope of security fixes by including updates that address Important CVEs. It also includes maintenance for Red Hat Enterprise Linux for SAP Solutions and Red Hat Enterprise Linux High Availability and Resilient Storage add-ons. And to help you create your long-term IT infrastructure strategy, Red Hat plans to offer ELS for 3 years for both RHEL 8 and 9.

When you're ready to upgrade from RHEL 7 — or any other version — Red Hat is here to help. We offer in-place upgrade tools and detailed guidance to streamline upgrades and application migrations. You can also engage Red Hat Consulting to plan and execute your upgrade projects.

"CentOS Stream will now be the sole repository for public RHEL-related source code releases..." Red Hat posted this week on its blog, arguing that "The engagement around CentOS Stream, the engineering levels of investment, and the new priorities we're addressing for customers and partners now make maintaining separate, redundant, repositories inefficient."

Long-time Slashdot reader slack_justyb notes this means patches and changes will now hit CentOS Stream before actually hitting RHEL, which "will make it difficult for other distributions such as Alma Linux, Rocky Linux, and Oracle Linux to provide assured binary compatibility as their only source now will be ahead of what RHEL is actually using."

"Some commentators are pointing out that it's possible to sign up for a free Red Hat Developer account, and obtain the source code legitimately that way," writes the Register. "This is perfectly true, but the problem is that the license agreement that you have to sign to get that account prevents you from redistributing the software." Hackaday notes that beyond the the GPL v2 license on the kernel, Red Hat also has "an additional user agreement that terminates access to updates if the code is re-published."

Rocky Linux officially "remains confident in its ability to continue as a bug-for-bug compatible and freely available alternative to Red Hat Enterprise Linux, despite changes in accessibility." While this decision does change the automation we use for building Rocky Linux, we have already created a short term mitigation and are developing the longer term strategy. There will be no disruption or change for any Rocky Linux users, collaborators, or partners... The project pledges to keep its promise to maintain the full life-span of support for Rocky 8 and 9, and to continue to produce future RHEL-compatible versions as long as the option remains, allowing organizations to maintain the flexibility, control, and freedom they rely upon for their critical infrastructure. This is the open source way.
Gregory Kurtzer, founder of the Rocky Linux project, calls Red Hat's move "a minor inconvenience for the Rocky Linux team," but with "no disruption to Rocky Linux users. Moving forward we are becoming even more stable, supported, and secure."

AlmaLinux also weighs in: Can you just use CentOS Stream sources?
No, we are committed to remaining a downstream RHEL clone, and using CentOS Stream sources would make us upstream of RHEL. CentOS Stream sources, while being upstream of RHEL, do not always include all patches and updates that are included in RHEL packages.

Is Red Hat trying to kill downstream clones?
We cannot speak to Red Hat's intentions, and can only point to the things they have said publicly. We have had an incredible working relationship with Red Hat through the life of AlmaLinux OS and we hope to see that continue.

SUSE's latest release of SUSE Linux Enterprise 15 Service Pack 5 (SLE 15 SP5) has a focus on security, claiming it as the first distro to offer full support for confidential computing to protect data. From a report: According to SUSE, the latest version of its enterprise platform is designed to deliver high-performance computing capabilities, with an inevitable mention of AI/ML workloads, plus it claims to have extended its live-patching capabilities. The release also comes just weeks after the community release openSUSE Leap 15.5 was made available, with the two sharing a common core. The Reg's resident open source guru noted that Leap 15.6 has now been confirmed as under development, which implies that a future SLE 15 SP6 should also be in the pipeline.

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

Long-time Slashdot reader waspleg shared this story from Hot Hardware: Red Hat Linux developer Richard WM Jones has shared an eyebrow raising tale of Linux bug hunting. Jones noticed that Linux 6.4 has a bug which means it will hang on boot about 1 in 1,000 times. Jones set out to pinpoint the bug, and prove he had caught it red handed. However, his headlining travail, involving booting Linux 292,612 times (and another 1,000 times to confirm the bug) apparently "only took 21 hours." It also seems that the bug is less common with Intel hardware than AMD based machines.

Slashdot reader e065c8515d206cb0e190 shared the big announcement from Debian.org: After 1 year, 9 months, and 28 days of development, the Debian project is proud to present its new stable version 12 (code name bookworm).

bookworm will be supported for the next 5 years thanks to the combined work of the Debian Security team and the Debian Long Term Support team...

This release contains over 11,089 new packages for a total count of 64,419 packages, while over 6,296 packages have been removed as obsolete. 43,254 packages were updated in this release. The overall disk usage for bookworm is 365,016,420 kB (365 GB), and is made up of 1,341,564,204 lines of code.

bookworm has more translated man pages than ever thanks to our translators who have made man-pages available in multiple languages such as: Czech, Danish, Greek, Finnish, Indonesian, Macedonian, Norwegian (Bokmål), Russian, Serbian, Swedish, Ukrainian, and Vietnamese. All of the systemd man pages are now completely available in German.

The Debian Med Blend introduces a new package: shiny-server which simplifies scientific web applications using R. We have kept to our efforts of providing Continuous Integration support for Debian Med team packages. Install the metapackages at version 3.8.x for Debian bookworm.

The Debian Astro Blend continues to provide a one-stop solution for professional astronomers, enthusiasts, and hobbyists with updates to almost all versions of the software packages in the blend. astap and planetary-system-stacker help with image stacking and astrometry resolution. openvlbi, the open source correlator, is now included.

Support for Secure Boot on ARM64 has been reintroduced: users of UEFI-capable ARM64 hardware can boot with Secure Boot mode enabled to take full advantage of the security feature.
9to5Linux has screenshots, and highlights some new features: Debian 12 also brings read/write support for APFS (Apple File System) with the apfsprogs and apfs-dkms utilities, a new tool called ntfs2btrfs that lets you convert NTFS drives to Btrfs, a new malloc implementation called mimalloc, a new kernel SMB server called ksmbd-tools, and support for the merged-usr root file system layout...

This release also includes completely new artwork called Emerald, designed (once again) by Juliette Taka. New fonts are also present in this major Debian release, along with a new fnt command-line tool for accessing 1,500 DFSG-compliant fonts.
Debian 12 "bookworm" ships with several desktop environments, including:

• Gnome 43,
• KDE Plasma 5.27,
• LXDE 11,
• LXQt 1.2.0,
• MATE 1.26,
• Xfce 4.18

Linux computer vendor System76 shared some news in a recent blog post. "We prefer to disable the Intel Management Engine wherever possible to reduce the amount of closed firmware running on System76 hardware. We've resolved a coreboot bug that allows the Intel ME (Management Engine) to once again be disabled."

Phoronix reports that the move will "benefit their latest Intel Core 13th Gen 'Raptor Lake' wares as well as prior generation devices." Intel ME is disabled for their latest Raptor lake laptops and most older platforms with some exceptions like where having a silicon issue with Tiger Lake. System76 has also added a new firmware setup menu option for enabling/disabling UEFI Secure Boot. The motivation here with making it easier to toggle Secure Boot is for allowing Windows 11 support with SB active while running System76 Open Firmware.

The Red Hat Package Managers for LibreOffice "have recently been orphaned," according to a post by Red Hat manager Matthias Clasen on the "LibreOffice packages" mailing list, "and I thought it would be good to explain the reasons behind this." The Red Hat Display Systems team (the team behind most of Red Hat's desktop efforts) has maintained the LibreOffice packages in Fedora for years as part of our work to support LibreOffice for Red Hat Enterprise Linux. We are adjusting our engineering priorities for RHEL for Workstations and focusing on gaps in Wayland, building out HDR support, building out what's needed for color-sensitive work, and a host of other refinements required by Workstation users. This is work that will improve the workstation experience for Fedora as well as RHEL users, and which, we hope, will be positively received by the entire Linux community.

The tradeoff is that we are pivoting away from work we had been doing on desktop applications and will cease shipping LibreOffice as part of RHEL starting in a future RHEL version. This also limits our ability to maintain it in future versions of Fedora.

We will continue to maintain LibreOffice in currently supported versions of RHEL (RHEL 7, 8 and 9) with needed CVEs and similar for the lifetime of those releases (as published on the Red Hat website). As part of that, the engineers doing that work will contribute some fixes upstream to ensure LibreOffice works better as a Flatpak, which we expect to be the way that most people consume LibreOffice in the long term.

Any community member is of course free to take over maintenance, both for the RPMs [Red Hat Package Managers] in Fedora and the Fedora LibreOffice Flatpak, but be aware that this is a sizable block of packages and dependencies and a significant amount of work to keep up with.
Commenters on LWN.net are now debating its impact.

One pointed out that "You will still find it in GNOME Software, which will install a Flatpak from FlatHub rather than an RPM from the distro."

motang writes: Canonical, the sponsor of widely popular Ubuntu Linux, plans on shipping the next LTS in two versions. In addition to the traditional version, there will be one immutable desktop OS flavor. From Canonical blog: The technology behind snaps extends beyond the distribution of desktop applications however. With Ubuntu Core this philosophy of security and stability applies equally to the components that make up the entire Ubuntu operating system. Rather than treating the OS as a single immutable 'blob,' Ubuntu Core breaks it up into discrete components. The base of Ubuntu Core, for example, is built on four primary snaps:

Gadget: Defines the system's bootloader, partition layout and default configurations for snaps.
Kernel: Containing the Linux kernel and hardware drivers.
Base: A minimal Ubuntu OS image containing only the necessary services and utilities to support the applications running on top.
Snapd: Manages the lifecycle of all snaps in an Ubuntu Core system.
Additional OS snaps can then be layered onto this image to enable other elements of the operating system such as a desktop environment.

When Red Hat laid off 4% of its global staff, Fedora Program Manager Ben Cotton was "a member of that 4%," according to a new post on Cotton's blog: I've received so much support from people since the news started spreading. It's like that end scene of "It's a Wonderful Life" and I'm George Bailey. I'm proud of the contributions I've made to the Fedora community over the last five years, and it feels good to have others recognize that.
Cotton joined Red Hat in 2018, but "I was a Fedora contributor long before" Cotton writes, adding later that "I fully intend to still be participating in the Fedora community when my account hits the 20-year mark in May 2029." (Cotton's first foray into Fedora was joining its Docs team in 2009, and then volunteering to be the Docs project leader in 2011...)

And the blog post adds that professionally Cotton is "already pursuing a few opportunities... In the meantime, I have (at least) a few weeks to relax for a bit." I've told folks that if Fedora falls off the rails, then I have failed. I'm working with Matthew, Justin, and others to ensure coverage of the core job duties one way or another. I've worked hard over the years to automate tasks that can be automated. The documentation is far more comprehensive than what I inherited. No doubt there are gaps in what I've left for my successors. However, my goal is that in a few months, nobody will notice that I'm gone. That's my measure of success...

As to what the broader implication behind the loss of my position might be, I don't know. There's no indication that my role was targeted specifically. There are definitely people in Red Hat who continue to view Fedora as strategically important.