"The latest version of the Linux kernel adds an array of improvements," writes the blog OMG Ubuntu, " including a new memory sealing system call, a speed boost for AES-XTS encryption on Intel and AMD CPUs, and expanding Rust language support within the kernel to RISC-V." Plus, like in all kernel releases, there's a glut of groundwork to offer "initial support" for upcoming CPUs, GPUs, NPUs, Wi-Fi, and other hardware (that most of us don't use yet, but require Linux support to be in place for when devices that use them filter out)...

Linux 6.10 adds (after much gnashing) the mseal() system call to prevent changes being made to portions of the virtual address space. For now, this will mainly benefit Google Chrome, which plans to use it to harden its sandboxing. Work is underway by kernel contributors to allow other apps to benefit, though. A similarly initially-controversial change merged is a new memory-allocation profiling subsystem. This helps developers fine-tune memory usage and more readily identify memory leaks. An explainer from LWN summarizes it well.

Elsewhere, Linux 6.10 offers encrypted interactions with trusted platform modules (TPM) in order to "make the kernel's use of the TPM reasonably robust in the face of external snooping and packet alteration attacks". The documentation for this feature explains: "for every in-kernel operation we use null primary salted HMAC to protect the integrity [and] we use parameter encryption to protect key sealing and parameter decryption to protect key unsealing and random number generation." Sticking with security, the Linux kernel's Landlock security module can now apply policies to ioctl() calls (Input/Output Control), restricting potential misuse and improving overall system security.

On the networking side there's significant performance improvements to zero-copy send operations using io_uring, and the newly-added ability to "bundle" multiple buffers for send and receive operations also offers an uptick in performance...

A couple of months ago Canonical announced Ubuntu support for the RISC-V Milk-V Mars single-board computer. Linux 6.10 mainlines support for the Milk-V Mars, which will make that effort a lot more viable (especially with the Ubuntu 24.10 kernel likely to be v6.10 or newer). Others RISC-V improvements abound in Linux 6.10, including support for the Rust language, boot image compression in BZ2, LZ4, LZMA, LZO, and Zstandard (instead of only Gzip); and newer AMD GPUs thanks to kernel-mode FPU support in RISC-V.
Phoronix has their own rundown of Linux 6.10, plus a list of some of the highlights, which includes:

• The initial DRM Panic infrastructure
• The new Panthor DRM driver for newer Arm Mali graphics
• Better AMD ROCm/AMDKFD support for "small" Ryzen APUs and new additions for AMD Zen 5.
• AMD GPU display support on RISC-V hardware thanks to RISC-V kernel mode FPU
• More Intel Xe2 graphics preparations
• Better IO_uring zero-copy performance
• Faster AES-XTS disk/file encryption with modern Intel and AMD CPUs
• Continued online repair work for XFS
• Steam Deck IMU support
• TPM bus encryption and integrity protection

Jowi Morales reports via Tom's Hardware: There's a vast difference between hardware and software developers, which opens up pitfalls for those trying to coordinate the two teams. Arm and x86 researchers encountered it years ago -- and Linus Torvalds, the creator of Linux, fears RISC-V development may fall into the same chasm again. "Even when you do hardware design in a more open manner, hardware people are different enough from software people [that] there's a fairly big gulf between the Verilog and even the kernel, much less higher up the stack where you are working in what [is] so far away from the hardware that you really have no idea how the hardware works," he said (video here). "So, it's really hard to kind of work across this very wide gulf of things and I suspect the hardware designers, some of them have some overlap, but they will learn by doing mistakes -- all the same mistakes that have been done before." [...]

"They'll have all the same issues we have on the Arm side and that x86 had before them," he says. "It will take a few generations for them to say, 'Oh, we didn't think about that,' because they have new people involved." But even if RISC-V development is still expected to make many mistakes, he also said it will be much easier to develop the hardware now. Linus says, "It took a few decades to really get to the point where Arm and x86 are competing on fairly equal ground because there was al this software that was fairly PC-centric and that has passed. That will make it easier for new architectures like RISC-V to then come in."

Google plans to support its own long-term support (LTS) kernel releases for Android devices for four years, a move aimed at bolstering the security of the mobile operating system. This decision, reported by AndroidAuthority, comes in response to the Linux community's recent reduction of LTS support from six years to two years, a change that posed potential challenges for Android's security ecosystem.

The Android Common Kernel (ACK) branches, derived from upstream Linux LTS releases, form the basis of most Android devices' kernels. Google maintains these forks to incorporate Android-specific features and backport critical functionality. Regular updates to these kernels address vulnerabilities disclosed in monthly Android Security Bulletins. While the extended support period benefits Android users and manufacturers, it places significant demands on Linux kernel developers.

Its FOSS writes: When it comes to Linux, we get to see some really cool, and sometimes quirky projects (read Hannah Montana Linux) that try to show off what's possible, and that's not a bad thing. One such quirky undertaking has recently surfaced, which sees a sophomore trying to one-up their friend, who had booted Linux off NFS. With their work, they have been able to run Arch Linux on Google Drive.
Their ultimate idea included FUSE (which allows running file-system code in userspace). The developer's blog post explains that when Linux boots, "the kernel unpacks a temporary filesystem into RAM which has the tools to mount the real filesystem... it's very helpful! We can mount a FUSE filesystem in that step and boot normally.... " Thankfully, Dracut makes it easy enough to build a custom initramfs... I decide to build this on top of Arch Linux because it's relatively lightweight and I'm familiar with how it work."
Doing testing in an Amazon S3 container, they built an EFI image — then spent days trying to enable networking... And the adventure continues. ("Would it be possible to manually switch the root without a specialized system call? What if I just chroot?") After they'd made a few more tweaks, "I sit there, in front of my computer, staring. It can't have been that easy, can it? Surely, this is a profane act, and the spirit of Dennis Ritchie ought't've stopped me, right? Nobody stopped me, so I kept going..." I build the unified EFI file, throw it on a USB drive under /BOOT/EFI, and stick it in my old server... This is my magnum opus. My Great Work. This is the mark I will leave on this planet long after I am gone: The Cloud Native Computer.

Despite how silly this project is, there are a few less-silly uses I can think of, like booting Linux off of SSH, or perhaps booting Linux off of a Git repository and tracking every change in Git using gitfs. The possibilities are endless, despite the middling usefulness.

If there is anything I know about technology, it's that moving everything to The Cloud is the current trend. As such, I am prepared to commercialize this for any company wishing to leave their unreliable hardware storage behind and move entirely to The Cloud. Please request a quote if you are interested in True Cloud Native Computing.

Unfortunately, I don't know what to do next with this. Maybe I should install Nix?

Linux's vDSO (or virtual dynamic shared object) is "a small shared library that the kernel automatically maps into the address space of all user-space applications," according to its man page. "There are some system calls the kernel provides that user-space code ends up using frequently, to the point that such calls can dominate overall performance... due both to the frequency of the call as well as the context-switch overhead that results from exiting user space and entering the kernel."

But Linus Torvalds had a lot to say about a proposed getrandom() upgrade, reports Phoronix: This getrandom() work in the vDSO has been through 20+ rounds of review over the past 2+ years, but... Torvalds took some time out of his U.S. Independence Day to argue the merits of the patches on the Linux kernel mailing list. Torvalds kicked things off by writing:


Nobody has explained to me what has changed since your last vdso getrandom, and I'm not planning on pulling it unless that fundamental flaw is fixed. Why is this _so_ critical that it needs a vdso? Why isn't user space just doing it itself? What's so magical about this all?

This all seems entirely pointless to me still, because it's optimizing something that nobody seems to care about, adding new VM infrastructure, new magic system calls, yadda yadda. I was very sceptical last time, and absolutely _nothing_ has changed. Not a peep on why it's now suddenly so hugely important again. We don't add stuff "just because we can". We need to have a damn good reason for it. And I still don't see the reason, and I haven't seen anybody even trying to explain the reason.


And then he responded to himself, adding:


In other words, I want to see actual *users* piping up and saying "this is a problem, here's my real load that spends 10% of time on getrandom(), and this fixes it". I'm not AT ALL interested in microbenchmarks or theoretical "if users need high-performance random numbers". I need a real actual live user that says "I can't just use rdrand and my own chacha mixing on top" and explains why having a SSE2 chachacha in kernel code exposed as a vdso is so critical, and a magical buffer maintained by the kernel."


Torvalds also added in a third message:


One final note: the reason I'm so negative about this all is that the random number subsystem has such an absolutely _horrendous_ history of two main conflicting issues: people wanting reasonable usable random numbers on one side, and then the people that discuss what the word "entropy" means on the other side. And honestly, I don't want the kernel stuck even *more* in the middle of that morass....
Torvalds made additional comments. ("This smells. It's BS...") Advocating for the change was WiredGuard developer Jason Donenfeld, and more communication happened (and continues to happen... 40 messages and counting).

At one point the discussion evolved to Torvalds saying "Bah. I guess I'll have to walk through the patch series once again. I'm still not thrilled about it. But I'll give it another go..."

"After sixteen years since the introduction of Python 3, the Fedora project announces that Python 2.7, the last of the Python 2 series, will be retired," according to long-time Slashdot reader slack_justyb.

From the announcement on the Fedora changes page: The python2.7 package will be retired without replacement from Fedora Linux 41. There will be no Python 2 in Fedora 41+ other than PyPy. Packages requiring python2.7 on runtime or buildtime will have to deal with the retirement or be retired as well.
"This also comes with the announcement that GIMP 3 will be coming to Fedora 41 to remove any last Python 2 dependencies," adds slack_justyb. GIMP 2 was originally released on March 23, 2004. GIMP will be updated to GIMP 3 with Python 3 support. Python 2 dependencies of GIMP will be retired.
Python 2's end of life was originally 2015, but was extended to 2020. The Python maintainers close with this: The Python maintainers will no longer regularly backport security fixes to Python 2.7 in RHEL, due to the the end of maintenance of RHEL 7 and the retirement of the Python 2.7 application stream in RHEL 8. We provided this obsolete package for 5 years beyond its retirement date and will continue to provide it until Fedora 40 goes end of life. Enough has been enough.

An anonymous reader quotes a report from ZDNet, written by Steven Vaughan-Nichols: Hold onto your SSH keys, folks! A critical vulnerability has just rocked OpenSSH, Linux's secure remote access foundation, causing seasoned sysadmins to break out in a cold sweat. Dubbed "regreSSHion" and tagged as CVE-2024-6387, this nasty bug allows unauthenticated remote code execution (RCE) on OpenSSH servers running on glibc-based Linux systems. We're not talking about some minor privilege escalation here -- this flaw hands over full root access on a silver platter. For those who've been around the Linux block a few times, this feels like deja vu. The vulnerability is a regression of CVE-2006-5051, a bug patched back in 2006. This old foe somehow snuck back into the code in October 2020 with OpenSSH 8.5p1. Thankfully, the Qualys Threat Research Unit uncovered this digital skeleton in OpenSSH's closet. Unfortunately, this vulnerability affects the default configuration and doesn't need any user interaction to exploit. In other words, it's a vulnerability that keeps security professionals up at night.

It's hard to overstate the potential impact of this flaw. OpenSSH is the de facto standard for secure remote access and file transfer in Unix-like systems, including Linux and macOS. It's the Swiss Army knife of secure communication for sysadmins and developers worldwide. The good news is that not all Linux distributions have the vulnerable code. Old OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109. Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable. The bad news is that the vulnerability resurfaced in OpenSSH 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component. Qualys has found over 14 million potentially vulnerable OpenSSH server internet instances. The company believes that approximately 700,000 of these external internet-facing instances are definitely vulnerable. A patch, OpenSSH 9.8/9.8p1 is now available. Many, but not all, Linux distributions have made it available. If you can get it, install it as soon as possible. If for whatever reason you're not able to install a patch, Vaughan-Nichols recommends you set LoginGraceTime to 0 in the sshd configuration file and use network-based controls to restrict SSH access, while also configuring firewalls and monitoring tools to detect and block exploit attempts.

It was analgous to the "Blue Screen of Death" that Windows gives for critical errors, Phoronix wrote. To enable error messages for things like a kernel panic, Linux 6.10 introduced a new panic handler infrastructure for "Direct Rendering Manager" (or DRM) drivers.

Phoronix also published a follow-up from Red Hat engineer Javier Martinez Canillas (who was involved in the new DRM Panic infrastructure). Given complaints about being too like Microsoft Windows following his recent Linux "Blue Screen of Death" showcase... Javier showed that a black screen of death is possible if so desired... After all, it's all open-source and thus can customize to your heart's content.
And now the panic handler is getting even more new features, Phoronix reported Friday: With the code in Linux 6.10 when DRM Panic is triggered, an ASCII art version of Linux's mascot, Tux the penguin, is rendered as part of the display. With Linux 6.11 it will also be able to handle displaying a monochrome image as the logo.

If ASCII art on error messages doesn't satisfy your tastes in 2024+, the DRM Panic code will be able to support a monochrome graphical logo that leverages the Linux kernel's boot-up logo support. The ASCII art penguin will still be used when no graphical logo is found or when the existing "LOGO" Kconfig option is disabled. (Those Tux logo assets being here.)

This monochrome logo support in the DRM Panic handler was sent out as part of this week's drm-misc-next pull request ahead of the Linux 6.11 merge window in July. This week's drm-misc-next material also includes TTM memory management improvements, various fixes to the smaller Direct Rendering Manager drivers, and also the previously talked about monochrome TV support for the Raspberry Pi.
Long-time Slashdot reader unixbhaskar thinks the new option "will certainly satisfy the modern people... But it is not as eye candy as people think... Moreover, it is monochrome, so certainly not resource-hungry. Plus, if all else fails, the ASCII art logo is still there to show!"

Slashdot reader unixbhaskar shared this report from Phoronix: Larry Finger who has contributed to the Linux kernel since 2005 and has seen more than 1,500 kernel patches upstreamed into the mainline Linux kernel has sadly passed away. His wife shared the news of Larry Finger's passing this weekend on the linux-wireless mailing list in a brief statement.
Reactions are being shared around the internet. LWN writes: The LWN Kernel Source Database shows that Finger contributed to 94 releases in the (Git era) kernel history, starting with 2.6.16 — 1,464 commits in total. He will be missed... In part to his contributions, the Linux wireless hardware support has come a long way over the past two decades.
Larry was a frequent contributor to the Linux Wireless and Linux Kernel mailing lists. (Here's a 2006 discussion he had about Git with Linus Torvalds.) Larry also answered 54 Linux questions on Quora, and in 2005 wrote three articles for Linux Journal. And Larry's GitHub profile shows 122 contributions to open source projects just in 2024.

In Reddit's Linux forum, one commenter wrote, "He was 84 years old and was still writing code. What a legend. May he rest in peace."

In 2022, Red Hat announced plans to extend RHEL to the automotive industry through Red Hat In-Vehicle Operating System (providing automakers with an open and functionally-safe platform). And this week Red Hat announced it achieved ISO 26262 ASIL-B certification from exida for the Linux math library (libm.so glibc) — a fundamental component of that Red Hat In-Vehicle Operating System.

From Red Hat's announcement: This milestone underscores Red Hat's pioneering role in obtaining continuous and comprehensive Safety Element out of Context certification for Linux in automotive... This certification demonstrates that the engineering of the math library components individually and as a whole meet or exceed stringent functional safety standards, ensuring substantial reliability and performance for the automotive industry. The certification of the math library is a significant milestone that strengthens the confidence in Linux as a viable platform of choice for safety related automotive applications of the future...

By working with the broader open source community, Red Hat can make use of the rigorous testing and analysis performed by Linux maintainers, collaborating across upstream communities to deliver open standards-based solutions. This approach enhances long-term maintainability and limits vendor lock-in, providing greater transparency and performance. Red Hat In-Vehicle Operating System is poised to offer a safety certified Linux-based operating system capable of concurrently supporting multiple safety and non-safety related applications in a single instance. These applications include advanced driver-assistance systems (ADAS), digital cockpit, infotainment, body control, telematics, artificial intelligence (AI) models and more. Red Hat is also working with key industry leaders to deliver pre-tested, pre-integrated software solutions, accelerating the route to market for SDV concepts.
"Red Hat is fully committed to attaining continuous and comprehensive safety certification of Linux natively for automotive applications," according to the announcement, "and has the industry's largest pool of Linux maintainers and contributors committed to this initiative..."

Or, as Network World puts it, "The phrase 'open source for the open road' is now being used to describe the inevitable fit between the character of Linux and the need for highly customizable code in all sorts of automotive equipment."

"A good portion of my home directory got deleted," complained a bug report for systemd filed last week. It requested an update to a flag for the systemd-tmpfiles tool which cleans up files and directories: "a huge warning next to --purge. This option is dangerous, so it should be made clear that it's dangerous."

The Register explains: As long as five years ago, systemd-tmpfiles had moved on past managing only temporary files — as its name might suggest to the unwary. Now it manages all sorts of files created on the fly ... such as things like users' home directories. If you invoke the systemd-tmpfiles --purge command without specifying that very important config file which tells it which files to handle, version 256 will merrily purge your entire home directory.
The bug report first drew a cool response from systemd developer Luca Boccassi of Microsoft: So an option that is literally documented as saying "all files and directories created by a tmpfiles.d/ entry will be deleted", that you knew nothing about, sounded like a "good idea"? Did you even go and look what tmpfiles.d entries you had beforehand? Maybe don't just run random commands that you know nothing about, while ignoring what the documentation tells you? Just a thought eh
But the report then triggered "much discussion," reports Phoronix. Some excerpts:

• Lennart Poettering: "I think we should fail --purge if no config file is specified on the command line. I see no world where an invocation without one would make sense, and it would have caught the problem here."

• Red Hat open source developer Zbigniew Jedrzejewski-Szmek: "We need to rethink how --purge works. The principle of not ever destroying user data is paramount. There can be commands which do remove user data, but they need to be minimized and guarded."

• Systemd contributor Betonhaus: "Having a function that declares irreplaceable files — such as the contents of a home directory — to be temporary files that can be easily purged, is at best poor user interfacing design and at worst a severe design flaw."

But in the end, Phoronix writes, systemd-tmpfiles behavior "is now improved upon."

"Merged Wednesday was this patch that now makes systemd-tmpfiles accept a configuration file when running purge. That way the user must knowingly supply the configuration file(s) to which files they would ultimately like removed. The documentation has also been improved upon to make the behavior more clear."

Thanks to long-time Slashdot reader slack_justyb for sharing the news.

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

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

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

In 2016, Phoronix remembered how the early days of Linux kernel mode-setting (KMS) had brought hopes for improved error messages. And one long-awaited feature was errors messages for "Direct Rendering Manager" (or DRM) drivers — something analgous to the "Blue Screen of Death" Windows gives for critical errors.

Now Linux 6.10 is introducing a new DRM panic handler infrastructure enabling messages when a panic occurs, Phoronix reports today. "This is especially important for those building a kernel without VT/FBCON support where otherwise viewing the kernel panic message isn't otherwise easily available." With Linux 6.10 the initial DRM Panic code has landed as well as wiring up the DRM/KMS driver support for the SimpleDRM, MGAG200, IMX, and AST drivers. There is work underway on extending DRM Panic support to other drivers that we'll likely see over the coming kernel cycles for more widespread support... On Linux 6.10+ with platforms having the DRM Panic driver support, this "Blue Screen of Death" functionality can be tested via a route such as echo c > /proc/sysrq-trigger.
The article links to a picture shared on Mastodon by Red Hat engineer Javier Martinez Canillas of the error message being generated on a BeaglePlay single board computer.

Phoronix also points out that some operating systems have even considered QR codes for kernel error messages...

ZDNet published a new article this week with their own tips for new Linux users. It begins by arguing that switching to the Linux desktop "is easier than you think" and "you'll find help everywhere". (And also that "You won't want for apps.") That doesn't mean it has everything. For example, there is no version of Adobe Photoshop. There is GIMP (which is just as powerful as Photoshop) but for those of you accustomed to Adobe's de facto standard, you're out of luck. The worst-case scenario is you have to learn a new piece of software to meet your graphic needs. At the same time, you might have to turn to proprietary software. For open-source purists, that's a no-go. But for those who just need to get things done, you'll find a mixture of open-source and proprietary software will give you everything you need to be productive and entertained.
Their article also recommends new users should "weed out Arch-based distributions," while warning that "Linux is more secure, but..." The truth is, any time you have a computer connected to a network, it's vulnerable and it doesn't matter what operating system you use. To that end, it's crucial that you keep your operating system (and the installed applications) up to date. Fortunately, most Linux operating systems make this very easy...

You're probably used to the slow trickle of updates and improvements found in the likes of Windows or MacOS. On Linux, you can count on that process being considerably faster. This is especially important with updates. When a vulnerability is found in an application that affects Linux, it is fixed far faster than it would be on competing platforms. The reason for this is that most Linux software is created and maintained by developers who don't have to answer to boards or committees or have a painfully slow bug resolution process. It might be announced that a vulnerability has been discovered in an application and the fix is officially released the next day. I've seen that very thing happen more times than I can count.

But it's not just about vulnerabilities. Developers add new features to software all the time and even listen to users. You could contact a developer of an open-source application with an idea and find it implemented in the next update. Linux is always evolving and it does so much faster than other operating systems.
And there's one final caveat. "Not all hardware will work (but most will)." I'll say this (and I stand by it): Ubuntu Linux probably has the best hardware detection and support of any operating system on the market. But that doesn't mean it works with everything. Certain peripherals you own could have trouble working with Linux. Two of the more problematic pieces of hardware are scanners and wireless chips. When I find a piece of hardware that isn't supported, here's one thing I've often done: I try a different Linux distribution... (Fedora often ships with a newer kernel than Ubuntu Linux, and therefore supports more modern hardware.)

Keep in mind that most Linux distributions are offered as Live images, which means you can test-drive them without making any changes to your hard drive. This is a great way to tell if a distribution will support all the hardware you need to use.
Agree? Disagree? Share your reactions in the comments...

And what advice would you give to a first-time Linux user?

Slashdot reader BrianFagioli shares his report from BetaNews: The PC community is abuzz with Qualcomm's recent announcement of its Snapdragon X Elite SoC, a powerhouse chipset that promises to revolutionize the performance and energy efficiency of laptops and tablets. While Windows 11 Copilot+ PCs are set to feature this advanced processor, Linux enthusiasts have reasons to celebrate as well. You see, TUXEDO Computers is bringing this cutting-edge technology to the Linux world with its upcoming ARM notebook, positioning it as a strong competitor to Windows 11 Copilot+ devices.

In a recent update, TUXEDO Computers revealed its ambitious project of developing an ARM notebook powered by the Snapdragon X Elite SoC from Qualcomm. This announcement has generated significant excitement, as it presents a viable alternative to traditional x86 notebooks, offering comparable performance with lower energy consumption, directly challenging the dominance of Windows 11 Copilot+... Benchmarks suggest that the Snapdragon X Elite can not only rival but potentially surpass Apple's M2 SoCs, boasting higher energy efficiency. TUXEDO's preliminary tests confirm these impressive claims, setting the stage for a fierce competition with Windows 11 Copilot+ PCs.
"We recently presented a prototype of the ARM notebook we are working on at the Computex computer trade fair in Taiwan," according to TUXEDO's announcement.

"On the software side, a port of TUXEDO OS with KDE Plasma to the ARM platform is our goal for this project running internally under the working title Drako...

"It is quite conceivable that an ARM notebook from TUXEDO will be under your Christmas tree in 2024... If you have subscribed to our newsletter, you will be the first to know."

Liam Proven reports via The Register: The latest version of the systemd init system is out, with the openly confrontational tag line: "Available soon in your nearest distro, now with 42 percent less Unix philosophy." As Lennart Poettering's announcement points out, this is the first version of systemd whose version number is a nine-bit value. Version 256, as usual, brings in a broad assortment of new features, but also turns off some older features that are now considered deprecated. For instance, it won't run under cgroups version 1 unless forced.

Around since 2008, cgroups is a Linux kernel containerization mechanism originally donated by Google, as The Reg noted a decade ago. Cgroups v2 was merged in 2016 so this isn't a radical change. System V service scripts are now deprecated too, as is the SystemdOptions EFI variable. Additionally, there are some new commands and options. Some are relatively minor, such as the new systemd-vpick binary, which can automatically select the latest member of versioned directories. Before any OpenVMS admirers get excited, no, Linux does not now support versions on files or directories. Instead, this is a fresh option that uses a formalized versioning system involving: "... paths whose trailing components have the .v/ suffix, pointing to a directory. These components will then automatically look for suitable files inside the directory, do a version comparison and open the newest file found (by version)."

The latest function, which The Reg FOSS desk suspects will ruffle some feathers, is a whole new command, run0, which effectively replaces the sudo command as used in Apple's macOS and in Ubuntu ever since the first release. Agent P introduced the new command in a Mastodon thread. He says that the key benefit is that run0 doesn't need setuid, a basic POSIX function, which, to quote its Linux manual page, "sets the effective user ID of the calling process." [...] Another new command is importctl, which handles importing and exporting both block-level and file-system-level disk images. And there's a new type of system service called a capsule, and "a small new service manager" called systemd-ssh-generator, which lets VMs and containers accept SSH connections so long as systemd can find the sshd binary -- even if no networking is available. The release notes are available here.

Steven Vaughan-Nichols reports via ZDNet: While Linux and open-source software (OSS) are no longer constantly under intellectual property (IP) attacks, the Open Invention Network (OIN) patent consortium still stands guard over its patents. Now, OIN, the largest patent non-aggression community, has expanded its protection once again by updating its Linux System definition. Covering more than just Linux, the Linux System definition also protects adjacent open-source technologies. In the past, protection was expanded to Android, Kubernetes, and OpenStack. The OIN accomplishes this by providing a shared defensive patent pool of over 3 million patents from over 3,900 community members. OIN members include Amazon, Google, Microsoft, and essentially all Linux-based companies.

This latest update extends OIN's existing patent risk mitigation efforts to cloud-native computing and enterprise software. In the cloud computing realm, OIN has added patent coverage for projects such as Istio, Falco, Argo, Grafana, and Spire. For enterprise computing, packages such as Apache Atlas and Apache Solr -- used for data management and search at scale, respectively -- are now protected. The update also enhances patent protection for the Internet of Things (IoT), networking, and automotive technologies. OpenThread and packages such as agl-compositor and kukusa.val have been added to the Linux System definition. In the embedded systems space, OIN has supplemented its coverage of technologies like OpenEmbedded by adding the OpenAMP and Matter, the home IoT standard. OIN has included open hardware development tools such as Edalize, cocotb, Amaranth, and Migen, building upon its existing coverage of hardware design tools like Verilator and FuseSoc.

Keith Bergelt, OIN's CEO, emphasized the importance of this update, stating, "Linux and other open-source software projects continue to accelerate the pace of innovation across a growing number of industries. By design, periodic expansion of OIN's Linux System definition enables OIN to keep pace with OSS's growth." [...] Looking ahead, Bergelt said, "We made this conscious decision not to include AI. It's so dynamic. We wait until we see what AI programs have significant usage and adoption levels." This is how the OIN has always worked. The consortium takes its time to ensure it extends its protection to projects that will be around for the long haul. The OIN practices patent non-aggression in core Linux and adjacent open-source technologies by cross-licensing their Linux System patents to one another on a royalty-free basis. When OIN signees are attacked because of their patents, the OIN can spring into action.

T2's open development process and the collection of exotic, vintage and retro hardware can be followed live on YouTube and Twitch.

Now Slashdot reader ReneR writes: Embedded T2 Linux is known for its sophisticated cross compile features as well as supporting all CPU architectures, including: Alpha, Arc, ARM(64), Avr32, HPPA(64), IA64, M68k, MIPS(64), Nios2, PowerPC(64)(le), RISCV(64), s390x, SPARC(64), SuperH, x86(64). But now it's going Desktop!

24.6 comes as a major convenience update, with out-of-the-box Windows application compatibility as well as LibreOffice and Thunderbird cross-compiled and in the default base ISO for the most popular CPU architectures.

Continuing to keep Intel IA-64 Itanium alive, a major, up-to-3x performance improvement was found for OpenSSL, doubling crypto performance for many popular algorithms and SSH.

The project's CI unit testing was further expanded to now cover the whole installation in two variants. The graphical desktop defaults were also polished -- and a T2 branded wallpaper was added! ;-) The release contains 606 changesets, including approximately 750 package updates, 67 issues fixed, 80 packages or features added, 21 removed and 9 other improvements.

"Researchers observed a new Linux variant of the TargetCompany ransomware family that targets VMware ESXi environments," reports BleepingComputer: In a report Wednesday, cybersecurity company Trend Micro says that the new Linux variant for TargetCompany ransomware makes sure that it has administrative privileges before continuing the malicious routine... Once on the target system, the payload checks if it runs in a VMware ESXi environment by executing the 'uname' command and looking for 'vmkernel.' Next, a "TargetInfo.txt" file is created and sent to the command and control (C2) server. It contains victim information such as hostname, IP address, OS details, logged-in users and privileges, unique identifiers, and details about the encrypted files and directories. The ransomware will encrypt files that have VM-related extensions (vmdk, vmem, vswp, vmx, vmsn, nvram), appending the ".locked" extension to the resulting files.

Finally, a ransom note named "HOW TO DECRYPT.txt" is dropped, containing instructions for the victim on how to pay the ransom and retrieve a valid decryption key. "After all tasks have been completed, the shell script deletes the payload using the 'rm -f x' command so all traces that can be used in post-incident investigations are wiped from impacted machines."

Thanks to long-time Slashdot reader joshuark for sharing the article.