BrianFagioli shares a report from BetaNews: As we close out 2024, we Linux enthusiasts are once again looking ahead to what the future holds. While Linux has long been the unsung hero of technology, powering servers, supercomputers, and the cloud, it's also a dominant force in the consumer space, even if many don't realize it. With Android leading the way as the most widely used Linux-based operating system, 2025 is shaping up to be another landmark year for the open source world Here are the predictions mentioned in the article:

- Linux will continue to dominate the enterprise sector
- Linux will further solidify its role in powering cloud infrastructure, with major providers like AWS and Google Cloud relying on it. - Gaming on Linux is set to grow in 2025
- Linux will play a major role in AI development
- Linux's appeal to developers and tech enthusiasts will remain strong
- The open source movement will grow stronger

What additional predictions do you have for Linux in 2025?

BrianFagioli writes: Linux Mint has reclaimed its position as the top-ranked Linux distribution on DistroWatch, dethroning MX Linux. The latest page hit rankings, which reflect the popularity of distributions among DistroWatch users, place Linux Mint in first place with 2,412 hits per day. MX Linux, previously the reigning champ, now sits in second with 2,280 hits.

Slashdot reader prisoninmate shared this report from the blog 9to5Linux Renowned Linux kernel developer Greg Kroah-Hartman announced Thursday that the Linux 6.12 kernel series has been officially marked as LTS (Long Term Support) on the kernel.org website with a predicted life expectancy of at least two years.

Linux kernel 6.12 was released on November 17th, 2024, and introduces new features like real-time "PREEMPT_RT" support, a new scheduler called sched_ext, and DRM panic messages as QR codes, as well as numerous new and updated drivers for better hardware support...

Linux kernel 6.12 joins the many other long-term support kernel branches, namely Linux 6.6 LTS, Linux 6.1 LTS, Linux 5.15 LTS, Linux 5.10 LTS, and Linux 5.4 LTS. Apart from the latter, the rest of them, including Linux kernel 6.12, will be officially supported until the end of December 2026. Hopefully, Linux kernel 6.12 will be supported for more than two years as the kernel maintainers usually aim for four years of support for a new LTS kernel, especially if there's demand from hardware manufacturers and other companies that aim to use a long-term supported kernel in their devices.

Slashdot reader prisoninmate shared this report from 9to5Linux: Linux kernel 4.19, the last of the Linux 4.x kernel series, has now reached the end of its supported life as announced earlier on the Linux kernel mailing list by kernel developer Greg Kroah-Hartman. The Linux 4.19 kernel branch was released more than six years ago, on October 22nd, 2018, and it received no less than 325 maintenance updates, the last one being Linux 4.19.325. The biggest highlights of Linux kernel 4.19 were initial Wi-Fi 6 support, the EROFS file system, and a union mount filesystem implementation.
Kroah-Hartman said on the mailing list. "This one is finished, it is end-of-life as of right now... It had a good life..." As a "fun" proof that this one is finished (and that any company saying they care about it really should have their statements validated with facts), I looked at the "unfixed" CVEs from this kernel release. Currently it is a list 983 CVEs long, too long to list here.... Note, this does NOT count the hardware CVEs which kernel.org does not track, and many are sill unfixed in this kernel branch.

Yes, CVE counts don't mean much these days, but hey, it's a signal of something, right? I take it to mean that no one is caring enough to backport the needed fixes to this branch, which means that you shouldn't be using it anymore.

Anyway, please move off to a more modern kernel if you were using this one for some reason. Like 6.12.y, the next LTS kernel we will be supporting for multiple years.

An anonymous reader shared this report from Phoronix: New Linux patches from Huawei engineers are preparing new driver support for controlling High Bandwidth Memory (HBM) with the ARM-based Kunpeng high performance SoC...

[I]t would appear there is a new Kunpeng SoC coming that will feature integrated High Bandwidth Memory (HBM).Unless I missed something, this Kunpeng SoC with HBM memory hasn't been formally announced yet and I haven't been able to find any other references short of pointing to prior kernel patches working on this HBM integration... It will be interesting to see what comes of Huawei Kunpeng SoCs with HBM memory and ultimately how well they perform against other AArch64 server processors as well as the Intel Xeon and AMD EPYC competition.

Greg Kroah-Hartman noted some coming changes in Linux 6.13 will make it possible to create "way more" Rust-based kernel drivers. "The veteran kernel developer believes we're at a tipping point of seeing more upstream Rust drivers ahead," reports Phoronix: These Rust char/misc changes are on top of the main Rust pull for Linux 6.13 that brought 3k lines of code for providing more Rust infrastructure. Linux 6.13 separately is also bringing Rust file abstractions.
"Sorry for doing this at the end of the merge window," Greg Kroah-Hartman wrote in the pull request, explaining that "conference and holiday travel got in the way on my side (hence the 5am pull request emails...)" Loads of things in here...

— Rust misc driver bindings and other rust changes to make misc drivers actually possible. I think this is the tipping point, expect to see way more rust drivers going forward now that these bindings are present.

Next merge window hopefully we will have pci and platform drivers working, which will fully enable almost all driver subsystems to start accepting (or at least getting) rust drivers. This is the end result of a lot of work from a lot of people, congrats to all of them for getting this far, you've proved many of us wrong in the best way possible, working code :)

An anonymous reader quotes a report from Ars Technica: Over the past decade, a new class of infections has threatened Windows users. By infecting the firmware that runs immediately before the operating system loads, these UEFI bootkits continue to run even when the hard drive is replaced or reformatted. Now the same type of chip-dwelling malware has been found in the wild for backdooring Linux machines. Researchers at security firm ESET said Wednesday that Bootkitty -- the name unknown threat actors gave to their Linux bootkit -- was uploaded to VirusTotal earlier this month. Compared to its Windows cousins, Bootkitty is still relatively rudimentary, containing imperfections in key under-the-hood functionality and lacking the means to infect all Linux distributions other than Ubuntu. That has led the company researchers to suspect the new bootkit is likely a proof-of-concept release. To date, ESET has found no evidence of actual infections in the wild.

Still, Bootkitty suggests threat actors may be actively developing a Linux version of the same sort of unkillable bootkit that previously was found only targeting Windows machines. "Whether a proof of concept or not, Bootkitty marks an interesting move forward in the UEFI threat landscape, breaking the belief about modern UEFI bootkits being Windows-exclusive threats," ESET researchers wrote. "Even though the current version from VirusTotal does not, at the moment, represent a real threat to the majority of Linux systems, it emphasizes the necessity of being prepared for potential future threats." [...] As ESET notes, the discovery is nonetheless significant because it demonstrates someone -- most likely a malicious threat actor -- is pouring resources and considerable know-how into creating working UEFI bootkits for Linux. Currently, there are few simple ways for people to check the integrity of the UEFI running on either Windows or Linux devices. The demand for these sorts of defenses will likely grow in the coming years.

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.

"Get your head examined. And get the fuck out of here with this shit." That's how Bcachefs developer Kent Overstreet ended a post on the Linux kernel mailing list.

This was followed by "insufficient action to restore the community's faith in having otherwise productive technical discussions without the fear of personal attacks," according to an official ruling by committee enforcing the kernel community's code of conduct. After formalizing an updated enforcement process for unacceptable behaviors, it then recommended that during the Linux 6.13 kernel development cycle, Overstreet's participation should be restricted (with his pull requests declined). Phoronix covered their ruling, and ItsFOSS and The Register offer some of the backstory.

Overstreet had already acknowledged that "Things really went off the rails (and I lost my cool, and earned the ire of the CoC committee)" in a 6,200-word blog post on his Patreon page. But he also emphasized that "I'm going to keep writing code no matter what. Things may turn into more of a hassle to actually get the code, but people who want to keep running bcachefs will always be able to (that's the beauty of open source, we can always fork), and I will keep supporting my users..."

More excerpts from Overstreet's blog post: I got an emails from multiple people, including from Linus, to the effect of "trust me, you don't want to be known as an asshole — you should probably send him an apology"... Linus is a genuinely good guy: I know a lot of people reading this will have also seen our pull request arguments, so I specifically wanted to say that here: I think he and I do get under each other's skin, but those arguments are the kind of arguments you get between people who care deeply about their work and simply have different perspectives on the situation...

[M]y response was to say "no" to a public apology, for a variety of reasons: because this was the result of an ongoing situation that had now impacted two different teams and projects, and I think that issue needs attention — and I think there's broader issues at stake here, regarding the CoC board. But mostly, because that kind of thing feels like it ought to be kept personal... I'd like a better process that isn't so heavy handed for dealing with situations where tensions rise and communications break down. As for that process: just talk to people... [W]e're a community. We're not interchangeable cogs to be kicked out and replaced when someone is "causing a problem", we should be watching out for each other...

Another note that I was raising with the CoC is that a culture of dismissiveness, of finding ways to avoid the technical discussions we're supposed to be having, really is toxic, and moreso than mere flamewars... we really do need to be engaging properly with each other in order to do our work well.
After the official response from the committee, Overstreet responded on the kernel mailing list. "I do want to apologize for things getting this heated the other day, but I need to also tell you why I reacted the way I did... I do take correctness issues very seriously, and I will get frosty or genuinely angry if they're being ignored or brushed aside."

"You can use any Linux distribution inside of the Windows Subsystem for Linux" Microsoft recently reminded Windows users, "even if it is not available in the Microsoft Store, by importing it with a tar file."

But being an official distro "makes it easier for Windows Subsystem for Linux users to install and discover it with actions like wsl --list --online and wsl --install," Microsoft pointed out this week. And "We're excited to announce that Red Hat will soon be delivering a Red Hat Enterprise Linux WSL distro image in the coming months..."

Thank you to the Red Hat team as their feedback has been invaluable as we built out this new architecture, and we're looking forwards to the release...! Ron Pacheco, senior director, Red Hat Enterprise Linux Ecosystem, Red Hat says:

"Developers have their preferred platforms for developing applications for multiple operating systems, and WSL is an important platform for many of them. Red Hat is committed to driving greater choice and flexibility for developers, which is why we're working closely with the Microsoft team to bring Red Hat Enterprise Linux, the largest commercially available open source Linux distribution, to all WSL users."
Read Pacheco's own blog post here.

But in addition Microsoft is also releasing "a new way to make WSL distros," they announced this week, "with a new architecture that backs how WSL distros are packaged and installed." Up until now, you could make a WSL distro by either creating an appx package and distributing it via the Microsoft Store, or by importing a .tar file with wsl -import. We wanted to improve this by making it possible to create a WSL distro without needing to write Windows code, and for users to more easily install their distros from a file or network share which is common in enterprise scenarios... With the tar based architecture, you can start with the same .tar file (which can be an exported Linux container!) and just edit it to add details to make it a WSL distro... These options will describe key distro attributes, like the name of the distro, its icon in Windows, and its out of box experience (OOBE) which is what happens when you run WSL for the first time. You'll notice that the oobe_command option points to a file which is a Linux executable, meaning you can set up your full experience just in Linux if you wish.

ZDNet's Steven Vaughan-Nichols interviews Jim Zemlin, Executive Director of The Linux Foundation and "head janitor of open source." An anonymous Slashdot reader shares an excerpt from the article: When I first met Zemlin, he was the head of the Free Standards Group (FSG). The FSG's main project was the Linux Standard Base (LSB) project. The LSB's goal was to get everyone in the Linux desktop world to agree on standards to ensure compatibility among distributions and their applications. Oh well, some struggles are never-ending. Another group, the Open Source Development Labs (OSDL), was simultaneously working on standardizing enterprise Linux. The two non-profits had the same goal of making Linux more useful and popular, so they agreed to merge. Zemlin was the natural pick to head this new group, which would be called The Linux Foundation.

At the time, he told me: "The combination of the two groups really enables the Linux platform and all the members of the Linux Foundation to work really effectively. I clearly understand what the organization's charter needs to be: We need to provide services that are useful to the community and industry, as well as protect, promote, and continue to standardize the platform." While initially focused on Linux, the Foundation's scope expanded significantly around 2010. Until then, the organization had hosted about a dozen projects related to the Linux operating system. However, as Linux gained dominance in various sectors, including high-performance computing, automotive, embedded systems, mobile devices, and cloud computing, the Linux Foundation started to broaden its horizons. Zemlin says there are three words that sum up the Linux Foundation's effort to keep open source safe and open to a new generation of developers: helpful, hopeful, and humble.

"You must be genuinely helpful to developers. We're the janitors of open source. The Linux Foundation takes care of all the boring but important stuff necessary to support software development so developers can focus on code. This work includes events, project marketing, project infrastructure, finances for projects, training and education, legal assistance, standards, facilitation, open source evangelism, and much, much more."

He continued: "The hopeful part is really the optimistic part. When in 2007, people were saying that this would never work. When leaders of huge companies tell everyone that you know all that you're doing is a cancer or terrible, you have to have a sense of optimism that there are better days ahead. You have to always be thinking, 'No, we can do it and stick with it.'"

However, Zemlin concluded that the number one trait that's "important in working in open source is this idea of humility. I work with hundreds of people every day, and none of them work at the Linux Foundation. We must lead through influence, and that really has been the secret for 20 years of working here without going totally insane. If you can check your ego and take criticism, open source actually turns out to be a really fun community to work with."

Five local privilege escalation (LPE) vulnerabilities in the Linux utility "needrestart" -- widely used on Ubuntu to manage service updates -- allow attackers with local access to escalate privileges to root. The flaws were discovered by Qualys in needrestart version 0.8, and fixed in version 3.8. BleepingComputer reports: Complete information about the flaws was made available in a separate text file, but a summary can be found below:

- CVE-2024-48990: Needrestart executes the Python interpreter with a PYTHONPATH environment variable extracted from running processes. If a local attacker controls this variable, they can execute arbitrary code as root during Python initialization by planting a malicious shared library.
- CVE-2024-48992: The Ruby interpreter used by needrestart is vulnerable when processing an attacker-controlled RUBYLIB environment variable. This allows local attackers to execute arbitrary Ruby code as root by injecting malicious libraries into the process.
- CVE-2024-48991: A race condition in needrestart allows a local attacker to replace the Python interpreter binary being validated with a malicious executable. By timing the replacement carefully, they can trick needrestart into running their code as root.
- CVE-2024-10224: Perl's ScanDeps module, used by needrestart, improperly handles filenames provided by the attacker. An attacker can craft filenames resembling shell commands (e.g., command|) to execute arbitrary commands as root when the file is opened.
- CVE-2024-11003: Needrestart's reliance on Perl's ScanDeps module exposes it to vulnerabilities in ScanDeps itself, where insecure use of eval() functions can lead to arbitrary code execution when processing attacker-controlled input. The report notes that attackers would need to have local access to the operation system through malware or a compromised account in order to exploit these flaws. "Apart from upgrading to version 3.8 or later, which includes patches for all the identified vulnerabilities, it is recommended to modify the needrestart.conf file to disable the interpreter scanning feature, which prevents the vulnerabilities from being exploited," adds BleepingComputer.

Longtime Slashdot reader slack_justyb writes: The Fast Light Toolkit released version 1.4.0 of the venerable, though sometimes looking a bit dated, toolkit from the '90s. New in this version are better CMake support, HiDPI support, and initial support for Wayland on Linux and Wayland on FreeBSD. Programs compiled and linked to this library launch using Wayland if it is available at runtime and fall back to X11 if not. FLTK 1.4.0 can be downloaded here. Documentation is also available.

Slashdot unixbhaskar writes: Linus has released a fresh Linux kernel for public consumption. Please give it a try and report any glitches to the maintainers for improvement. Also, please do not forget to express your appreciation to those tireless folks who did all the hard work for you.
The blog OMG Ubuntu calls it "one of the most biggest kernel releases for a while," joking that it's a "really real-time kernel." The headline feature in Linux 6.12 is mainline support for PREEMPT_RT. This patch set dramatically improves the performance of real-time applications by making kernel processes pre-emptible — effectively enabled proper real-time computing... Meanwhile, Linus Torvalds himself contributes a new method for user-space address masking designed to claw back some of the performance lost due to Spectre-v1 mitigations.

You might have heard that kernel devs have been working to add QR error codes to Linux's kernel panic BSOD screen (as a waterfall of error text is often cut off and not easily copied for ad-hoc debugging). Well, Linux 6.12 adds support for those during Direct Rendering Manager panics...

A slew of new RISC-V CPU ISA extensions are supported in Linux 6.12; hybrid CPU scaling in the Intel P-State driver lands ahead of upcoming Intel Core Ultra 2000 chips; and AMD P-State driver improves AMD Boost and AMD Preferred Core features.
More coverage from the blog 9to5Linux highlights a new scheduler called sched_ext, Clang support (including LTO) for nolibc, support for NVIDIA's virtual command queue implementation for SMMUv3, and "an updated cpuidle tool that now displays the residency value of cpuidle states for a clearer and more detailed view of idle state information when using cpuidle-info." Linux kernel 6.12 also introduces SWIG bindings for libcpupower to make it easier for developers to write scripts that use and extend the functionality of libcpupower, support for translating normalized error addresses reported by an AMD memory controller into system physical addresses using a UEFI mechanism called platform runtime mechanism (PRM), as well as simplified loading of microcode patches on AMD Zen and newer CPUs by using the family, model, and stepping encoded in the patch revision number...

Moreover, Linux 6.12 adds support for running as a protected guest on Android as well as perf and support for a bunch of new interconnect PMUs. It also adds the final conversions to the new Intel VFM CPU model matching macros, rewrites the PCM buffer allocation handling and locking optimizations, and improves the USB audio driver...

Automotive Grade Linux is a collaborative open source project developing "an open platform from the ground up that can serve as the de facto industry standard" for fast development of new features. Automakers have joined with tech companies and suppliers to speed up development (and adoption) of "a fully open software stack for the connected car" — hosted at the Linux Foundation, and "with Linux at its core..."

And this week they created a new Open Source Program Office expert group, led by Toyota, to promote the establishment of Open Source Program Offices within the automotive industry, "and encourage the sharing of information and best practices between them." Open source software has become more prevalent across the automotive industry as automakers invest more time and resources into software development. Automakers like Toyota and Subaru are using open source software for infotainment and instrument cluster applications. Other open source applications across the automotive industry include R&D, testing, vehicle-to-cloud and fleet management. "Historically, there has been little code contributed back to the open source community," said Dan Cauchy, Executive Director of Automotive Grade Linux. "Often, this was because the internal procedures or IT infrastructure weren't in place to support open source contributions. The rise of software-defined vehicles has led to a growing trend of automakers not just using, but also contributing, to open source software. Many organizations are also establishing Open Source Program Offices to streamline and organize open source activities to better support business goals."

Automakers including Toyota, Honda, and Volvo have already established Open Source Program Offices. The new AGL OSPO Expert Group provides a neutral space for them to share pain points and collaborate on solutions, exchange information, and develop best practices that can help other automakers build their own OSPOs. "Toyota has been participating in AGL and the broader open source community for over a decade," said Masato Endo, Group Manager of Open Source Program Group, Toyota. "We established an OSPO earlier this year to promote the use of open source software internally and to help guide how and where we contribute. We are looking forward to working with other open source leaders to solve common problems, collaborate on best practices, and invigorate open source activities in the automotive industry."

The AGL OSPO EG is led by Toyota with support from Panasonic and AISIN Corporation.