An anonymous reader shared this post from Phoronix: With Linux 6.8 the kernel's Rust code was brought up to Rust 1.75 while new patches posted this weekend port the code over to Rust 1.76 and then the upcoming Rust 1.77...

With Rust 1.77 they have now stabilized the single-field "offset_of" feature used by the kernel's Rust code. Rust 1.77 also adds a "--check-cfg" option that the Rust kernel code will likely transition to in the future. This follows the Rust for Linux policy of tracking the upstream Rust version upgrades until there is a minimum version that can be declared where all used features are considered stable.

From a blog post by Greg Kroah-Hartman: As was recently announced, the Linux kernel project has been accepted as a CVE Numbering Authority (CNA) for vulnerabilities found in Linux.

This is a trend, of more open source projects taking over the haphazard assignments of CVEs against their project by becoming a CNA so that no other group can assign CVEs without their involvment. Here's the curl project doing much the same thing for the same reasons. I'd like to point out the great work that the Python project has done in supporting this effort, and the OpenSSF project also encouraging it and providing documentation and help for open source projects to accomplish this. I'd also like to thank the cve.org group and board as they all made the application process very smooth for us and provided loads of help in making this all possible.

As many of you all know, I have talked a lot about CVEs in the past, and yes, I think the system overall is broken in many ways, but this change is a way for us to take more responsibility for this, and hopefully make the process better over time. It's also work that it looks like all open source projects might be mandated to do with the recent rules and laws being enacted in different parts of the world, so having this in place with the kernel will allow us to notify all sorts of different CNA-like organizations if needed in the future.
Kroah-Hartman links to his post on the kernel mailing list for "more details about how this is all going to work for the kernel." [D]ue to the layer at which the Linux kernel is in a system, almost any bug might be exploitable to compromise the security of the kernel, but the possibility of exploitation is often not evident when the bug is fixed. Because of this, the CVE assignment team are overly cautious and assign CVE numbers to any bugfix that they identify. This explains the seemingly large number of CVEs that are issued by the Linux kernel team...

No CVEs will be assigned for unfixed security issues in the Linux kernel, assignment will only happen after a fix is available as it can be properly tracked that way by the git commit id of the original fix. No CVEs will be assigned for any issue found in a version of the kernel that is not currently being actively supported by the Stable/LTS kernel team.
alanw (Slashdot reader #1,822) worries this could overwhelm the CVE infrastructure, pointing to an ongoing discussion at LWN.net.

But reached for a comment, Greg Kroah-Hartman thinks there's been a misunderstanding. He told Slashdot that the CVE group "explicitly asked for this as part of our application... so if they are comfortable with it, why is no one else?"

Some ZFS news from Phoronix this week. "At the end of last year OpenZFS 2.2.2 was released to fix a rare but nasty data corruption issue, but it turns out there are other data corruption bug(s) still lurking in the OpenZFS file-system codebase." A Phoronix reader wrote in today about an OpenZFS data corruption bug when employing native encryption and making use of send/recv support. Making use of zfs send on an encrypted dataset can cause one or more snapshots to report errors. OpenZFS data corruption issues in this area have apparently been known for years.

Since May 2021 there's been this open issue around ZFS corruption related to snapshots on post-2.0 OpenZFS. That issue remains open. A new ticket has been opened for OpenZFS as well in proposing to add warnings against using ZFS native encryption and the send/receive support in production environments.
jd (Slashdot reader #1,658) spotted the news — and adds a positive note. "Bugs, old and new, are being catalogued and addressed much more quickly now that core development is done under Linux, even though it is not mainstreamed in the kernel."

Andrew Cunningham reports via Ars Technica: For around three years now, the team of independent developers behind the Asahi Linux project has worked to support Linux on Apple Silicon Macs, despite Apple's total lack of involvement. Over the years, the project has gone from a "highly unstable experiment" to a "surprisingly functional and usable desktop operating system." Even Linus Torvalds has used it to run Linux on Apple's hardware. The team has been steadily improving its open source, standards-conformant GPU driver for the M1 and M2 since releasing them in December 2022, and today, the team crossed an important symbolic milestone: The Asahi driver's support for the OpenGL and OpenGL ES graphics have officially passed what Apple offers in macOS. The team's latest graphics driver fully conforms with OpenGL version 4.6 and OpenGL ES version 3.2, the most recent version of either API. Apple's support in macOS tops out at OpenGL 4.1, announced in July 2010.

Developer Alyssa Rosenzweig wrote a detailed blog post that announced the new driver, which had to pass "over 100,000 tests" to be deemed officially conformant. The team achieved this milestone despite the fact that Apple's GPUs don't support some features that would have made implementing these APIs more straightforward. "Regrettably, the M1 doesn't map well to any graphics standard newer than OpenGL ES 3.1," writes Rosenzweig. "While Vulkan makes some of these features optional, the missing features are required to layer DirectX and OpenGL on top. No existing solution on M1 gets past the OpenGL 4.1 feature set... Without hardware support, new features need new tricks. Geometry shaders, tessellation, and transform feedback become compute shaders. Cull distance becomes a transformed interpolated value. Clip control becomes a vertex shader epilogue. The list goes on."

Now that the Asahi GPU driver supports the latest OpenGL and OpenGL ES standards -- released in 2017 and 2015, respectively -- the work turns to supporting the low-overhead Vulkan API on Apple's hardware. Vulkan support in macOS is limited to translation layers like MoltenVK, which translates Vulkan API calls to Metal ones that the hardware and OS can understand. [...] Rosenzweig's blog post didn't give any specific updates on Vulkan except to say that the team was "well on the road" to supporting it. In addition to supporting native Linux apps, supporting more graphics APIs in Asahi will allow the operating system to take better advantage of software like Valve's Proton, which already has a few games written for x86-based Windows PCs running on Arm-based Apple hardware.

Back in 2006 Slashdot reported on a 50-megabyte "micro" distro called Damn Small Linux. (And in 2012 we wrote that it "rose from the dead" with a new release candidate.)

Now Damn Small Linux has been reborn again, according to its developer's web site: Creating the original DSL, a versatile 50MB distribution, was a lot of fun and one of the things I am most proud of as a personal accomplishment. However, as a concept, it was in the right place at the right time, and the computer industry has changed a lot since then. While it would be possible to make a bootable Xwindows 50MB distribution today, it would be missing many drivers and have only a handful of very rudimentary applications. People would find such a distribution a fun toy or something to build upon, but it would not be usable for the average computer user out of the gate....

The new goal of DSL is to pack as much usable desktop distribution into an image small enough to fit on a single CD, or a hard limit of 700MB. This project is meant to service older computers and have them continue to be useful far into the future. Such a notion sits well with my values. I think of this project as my way of keeping otherwise usable hardware out of landfills.

As with most things in the GNU/Linux community, this project continues to stand on the shoulders of giants. I am just one guy without a CS degree, so for now, this project is based on antiX 23 i386... a fantastic distribution that I think shares much of the same spirit as the original DSL project. AntiX shares pedigree with MEPIS and also leans heavily on the geniuses at Debian.
The blog It's FOSS News describes it as "a unique experience in a sea of Debian-based and Fedora-based distros." It is offered with two window managers, Fluxbox and JWM, with apt being fully enabled by default for easy package installations... At the time of writing, only the Alpha ISOs were made available on the official downloads page. It is only a matter of time before we get a stable release.

Jakub Lewkowicz reports via SD Times: The Linux Foundation has recently launched the Post-Quantum Cryptography Alliance (PQCA), a collaborative effort aimed at advancing and facilitating the adoption of post-quantum cryptography in response to the emerging threats of quantum computing. This alliance assembles diverse stakeholders, including industry leaders, researchers, and developers, focusing on creating high-assurance software implementations of standardized algorithms. The initiative is also dedicated to supporting the development and standardization of new post-quantum cryptographic methods, aligning with U.S. National Security Agency's guidelines to ensure cryptographic security against quantum computing threats.

The PQCA endeavors to serve as a pivotal resource for organizations and open-source projects in search of production-ready libraries and packages, fostering cryptographic agility in anticipation of future quantum computing capabilities. Founding members include AWS, Cisco, Google, IBM, IntellectEU, Keyfactor, Kudelski IoT, NVIDIA, QuSecure, SandboxAQ, and the University of Waterloo. [...] [T]he PQCA plans to launch the PQ Code Package Project aimed at creating high-assurance, production-ready software implementations of upcoming post-quantum cryptography standards, beginning with the ML-KEM algorithm. By inviting organizations and individuals to participate, the PQCA is poised to play a critical role in the transition to and standardization of post-quantum cryptography, ensuring enhanced security measures in the face of advancing quantum computing technology. You can learn more about the PQCA on its website or GitHub.

Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they're hard to detect or remove. ArsTechnica: The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.

The vulnerability, tracked as CVE-2023-40547, is what's known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the the web is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from. "An attacker would need to be able to coerce a system into booting from HTTP if it's not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it," Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. "An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code)."

The non-profit Linux Foundation Energy hopes to develop energy-sector solutions (including standards, specifications, and software) supporting rapid decarbonization by collaborating with industry stakeholders.

And now they're involved in a new partnership with America's Joint Office of Energy — which facilitates collaboration between the federal Department of Energy and its Department of Transportation. The partnership's goal? To "build open-source software tools to support communications between EV charging infrastructure and other systems."

The Buildout reports: The partnership and effort — known as "Project EVerest" — is part of the administration's full-court press to improve the charging experience for EV owners as the industry's nationwide buildout hits full stride. "Project EVerest will be a game changer for reliability and interoperability for EV charging," Gabe Klein, executive director of the administration's Joint Office of Energy and Transportation, said yesterday in a post on social media....

Administration officials said that a key driver of the move to institute broad standards for software is to move beyond an era of unreliable and disparate EV charging services throughout the U.S. Dr. K. Shankari, a principal software architect at the Joint Office of Energy and Transportation, said that local and state governments now working to build out EV charging infrastructure could include a requirement that bidding contractors adhere to Project EVerest standards. That, in turn, could have a profound impact on providers of EV charging stations and services by requiring them to adapt to open source standards or lose the opportunity to bid on public projects. Charging availability and reliability are consistently mentioned as key turnoffs for potential EV buyers who want the infrastructure to be ready, easy, and consistent to use before making the move away from gas cars.

Specifically, the new project will aim to create what's known as an open source reference implementation for EV charging infrastructure — a set of standards that will be open to developers who are building applications and back-end software... And, because the software will be available for any company, organization, or developer to use, it will allow the creation of new EV infrastructure software at all levels without software writers having to start from scratch. "LF Energy exists to build the shared technology investment that the entire industry can build on top of," said Alex Thompson of LF Energy during the web conference. "You don't want to be re-inventing the wheel."
The tools will help communication between charging stations (and adjacent chargers), as well as vehicles and batteries, user interfaces and mobile devices, and even backend payment systems or power grids. An announcement from the Joint Office of Energy and Transportation says this software stack "will reduce instances of incompatibility resulting from proprietary systems, ultimately making charging more reliable for EV drivers." "The Joint Office is paving the way for innovation by partnering with an open-source foundation to address the needs of industry and consumers with technical tools that support reliable, safe and interoperable EV charging," said Sarah Hipel, Standards and Reliability Program Manager at the Joint Office.... With this collaborative development model, EVerest will speed up the adoption of EVs and decarbonization of transportation in the United States by accelerating charger development and deployment, increase customizability, and ensure high levels of security for the nation's growing network.
Linux Foundation Energy adds that reliable charging "is key to ensuring that anyone can confidently choose to ride or drive electric," predicting it will increase customizability for different use cases while offering long-term maintainability, avoiding vendor-lock in, and ensuring high levels of security. This is a pioneering example of the federal government collaborating to deploy code into an open source project...

"The EVerest project has been demonstrated in pilots around the world to make EV charging far more reliable and reduces the friction and frustration EV drivers have experienced when a charger fails to work or is not continually maintained," said LF Energy Executive Director Alex Thornton. "We look forward to partnering with the Joint Office to create a robust firmware stack that will stand the test of time, and be maintained by an active and growing global community to ensure the nation's charging infrastructure meets the needs of a growing fleet of electric vehicles today and into the future."
Thanks to Slashdot reader ElectricVs for sharing the article.

Microsoft's Visual Studio Code editor now includes a voice command that launches GitHub Copilot Chat just by saying "Hey Code."

But one Linux blog notes that the editor has suddenly stopped supporting Ubuntu 18.04 LTS — "a move causing issues for scores of developers." VS Code 1.86 (aka the 'January 2024' update) saw Microsoft bump the minimum build requirements for the text editor's popular remote dev tools to â¥glibc 2.28 — but Ubuntu 18.04 LTS uses glibc 2.27, ergo they no longer work.

While Ubuntu 18.04 is supported by Canonical until 2028 (through ESM) a major glibc upgrade is unlikely. Thus, this "breaking change" is truly breaking workflows...

It seems affected developers were caught off-guard as this (rather impactful) change was not signposted before, during, or after the VS Code update (which is installed automatically for most, and the update was pushed out to Ubuntu 18.04 machines). Indeed, most only discovered this issue after update was installed, they tried to connect to a remote server, and discovered it failed. The resulting error message does mention deprecation and links to an FAQ on the VS Code website with workarounds (i.e. downgrade).

But as one developer politely put it.... "It could have checked the libc versions and refused the update. Now, many people are screwed in the middle of their work."
The article points out an upgrade to Ubuntu 20.04 LTS will address the problem. On GitHub a Microsoft engineer posted additional options from VS Code's documentation: If you are unable to upgrade your Linux distribution, the recommended alternative is to use our web client. If you would like to use the desktop version, then you can download the VS Code release 1.85. Depending on your platform, make sure to disable updates to stay on that version.
Microsoft then locked the thread on GitHub as "too heated" and limited conversation to just collaborators.

In a related thread someone suggested installing VS Code's Flatpak, which was still on version 1.85 — and then disabling updates. But soon Microsoft had locked that thread as well as "too heated," again limiting conversation to collaborators.

Linus Torvalds had "some robust exchanges" on the Linux kernel mailing list with a contributor from Google. The subject was inodes, notes the Register, "which as Red Hat puts it are each 'a unique identifier for a specific piece of metadata on a given filesystem.'" Inodes have been the subject of debate on the Linux Kernel Mailing list for the last couple of weeks, with Googler Steven Rostedt and Torvalds engaging in some robust exchanges on the matter. In a thread titled, "Have the inodes all for files and directories all be the same," posters noted that inodes may still have a role when using tar to archive files. Torvalds countered that inodes have had their day. "Yes, inode numbers used to be special, and there's history behind it. But we should basically try very hard to walk away from that broken history," he wrote. "An inode number just isn't a unique descriptor any more. We're not living in the 1970s, and filesystems have changed." But debate on inodes continued. Rostedt eventually suggested that inodes should all have unique numbers...

In response... Torvalds opened: "Stop making things more complicated than they need to be." Then he got a bit shouty. "And dammit, STOP COPYING VFS LAYER FUNCTIONS. It was a bad idea last time, it's a horribly bad idea this time too. I'm not taking this kind of crap." Torvalds's main criticism of Rostedt's approach is that the Google dev didn't fully understand the subject matter — which Rostedt later acknowledged.
"An inode number just isn't a unique descriptor any more," Torvalds wrote at one point.

"We're not living in the 1970s, and filesystems have changed."

prisoninmate shares a 9to5linux report: Flathub is currently one of the most popular app stores for Linux serving 1.6 billion downloads of over 2,400 apps in the Flatpak format, of which more than 850 apps have been verified by their original authors. And now, Flathub proudly announced today that it surpassed 1 million active users of Flatpak apps. The team believes that the recent growth in users comes from several factors, including the availability of some very popular apps (e.g. Firefox, Thunderbird, VLC, Spotify, OBS Studio, Google Chrome, Telegram), support for new and verified apps, the inclusion of Flathub as the default app source for the Steam Deck's desktop mode, as well as the growing adoption among many popular GNU/Linux distributions like Fedora Linux, Linux Mint, KDE neon, and others.

"A Canonical engineer has been experimenting with implementing a Linux scheduler within the Rust programming language..." Phoronix reported Monday, "that works via sched_ext for implementing a scheduler using eBPF that can be loaded during run-time."

The project was started "just for fun" over Christmas, according to a post on X by Canonical-based Linux kernel engineer Andrea Righi, adding "I'm pretty shocked to see that it doesn't just work, but it can even outperform the default Linux scheduler (EEVDF) with certain workloads (i.e., gaming)." Phoronix notes the a YouTube video accompanying the tweet shows "a game with the scx_rustland scheduler outperforming the default Linux kernel scheduler while running a parallel kernel build in the background."

"For sure the build takes longer," Righi acknowledged in a later post. "This scheduler doesn't magically makes everything run faster, it simply prioritizes more the interactive workloads vs CPU-intensive background jobs." Righi followed up by adding "And the whole point of this demo was to prove that, despite the overhead of running a scheduler in user-space, we can still achieve interesting performance, while having the advantages of being in user-space (ease of experimentation/testing, reboot-less updates, etc.)"

Wednesday Righi added some improvements, posting that "Only 19 lines of code (comments included) for ~2x performance improvement on SMT isn't bad... and I spent my lunch break playing Counter Strike 2 to test this patch..."

And work seems to be continuing, judging by a fresh post from Righi on Thursday. "I fixed virtme-ng to run inside Docker and used it to create a github CI workflow for sched-ext that clones the latest kernel, builds it and runs multiple VMs to test all the scx schedulers. And it does that in only ~20min. I'm pretty happy about virtme-ng now."

Linux Mint 21.3 is now available to download, reports the blog OMG Obuntu.

It's the first version to offer Wayland support in its Cinnamon desktop: Following a successful bout of bug-busting in last month's beta release, Mint devs have gone ahead and rubber-stamped a stable release. Thus, you can reasonably expect to not encounter any major issues when installing or using it... [I]t's based on Ubuntu 22.04 LTS and continues to use the Linux 5.15 kernel by default, but newer kernels are available to install within the OS...

In my own testing I find Cinnamon's Wayland support to be well-rounded. It's not perfect but I didn't hit any major snafus that prevented me from working (though admittedly I did only attempt 'basic' tasks like web browsing, playing music, and adding applets). However, Cinnamon's Wayland support is in an early state, is not enabled by default, and Linux Mint devs expect it won't be good enough for everyone until the 23.x series (due 2026) at the earliest. Still, try it out yourself and see if it works for you. Select the 'Cinnamon on Wayland (Experimental)' session from the login screen session selector, and then login as normal...

Additionally, the latest version of Mozilla Firefox is pre-installed (as a deb, not a Snap)
Among the new features are a whole new category of desktop add-ons — "Actions" — which upgrade the right-clicking context menu. (So for .iso files there's two new choices: "Verify" or "Make bootable USB stick".)

The article says there's also "a raft of smaller refinements," plus "a bevvy of buffs and embellishments" for Linux Mint's homegrown apps.

Any Linux Mint users reading Slashdot? Share your thoughts or experiences in the comments...

serviscope_minor shares a Phoronix post: A six year old Linux kernel mailing list discussion has been reignited over the prospects of converting the Linux kernel to supporting modern C++ code. The Linux kernel is predominantly made up of C code with various hand-written Assembly plus the growing work around supporting Rust within the Linux kernel. While it's not clear yet if there's sufficient weight to make it a reality, a Linux kernel mailing list discussion has been restarted over potentially seeing the Linux kernel C code converted to C++ in the future.

Back on 1 April 2018 was a set of 45 patches by Red Hat engineer David Howells to begin converting the kernel to C++. This would allow the mainline kernel to make use of inline template functions, inline overloaded functions, class inheritance, and other features not currently supported by the Linux kernel with its C code. A bit hard to make serious discussions that day and ultimately the patches resided on the Linux kernel mailing list for six years without much discussion. serviscope_minor adds: It is notable that the current discussion is somewhat different from the infamous discussions in the past.

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

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

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

prisoninmate shares a report: Originally released on November 12th, 2017, the long-term supported (LTS) Linux 4.14 kernel series has now reached its end of supported life after being maintained for more than six years. Renowned kernel developer Greg Kroah-Hartman announced today on the Linux kernel mailing list the release of Linux 4.14.336 as what appears to be the last maintenance update to the long-term supported Linux 4.14 kernel series, which is now marked as EOL (End of Life) on the kernel.org website. "This is the LAST 4.14.y kernel to be released. It is now officially end-of-life. Do NOT use this kernel version anymore, please move to a newer one, as shown on the kernel.org releases page," said Greg Kroah-Hartman. "If you are stuck at this version due to a vendor requiring it, go get support from that vendor for this obsolete kernel tree, as that is what you are paying them for."

Previously unknown self-replicating malware has been infecting Linux devices worldwide, installing cryptomining malware using unusual concealment methods. The worm is a customized version of Mirai botnet malware, which takes control of Linux-based internet-connected devices to infect others. Mirai first emerged in 2016, delivering record-setting distributed denial-of-service attacks by compromising vulnerable devices. Once compromised, the worm self-replicates by scanning for and guessing credentials of additional vulnerable devices. While traditionally used for DDoS attacks, this latest variant focuses on covert cryptomining. ArsTechnica adds: On Wednesday, researchers from network security and reliability firm Akamai revealed that a previously unknown Mirai-based network they dubbed NoaBot has been targeting Linux devices since at least last January. Instead of targeting weak telnet passwords, the NoaBot targets weak passwords connecting SSH connections. Another twist: Rather than performing DDoSes, the new botnet installs cryptocurrency mining software, which allows the attackers to generate digital coins using victims' computing resources, electricity, and bandwidth. The cryptominer is a modified version of XMRig, another piece of open source malware. More recently, NoaBot has been used to also deliver P2PInfect, a separate worm researchers from Palo Alto Networks revealed last July.

Akamai has been monitoring NoaBot for the past 12 months in a honeypot that mimics real Linux devices to track various attacks circulating in the wild. To date, attacks have originated from 849 distinct IP addresses, almost all of which are likely hosting a device that's already infected. The following figure tracks the number of attacks delivered to the honeypot over the past year.

An anonymous reader shared this report from The Hacker News: Three new malicious packages have been discovered in the Python Package Index (PyPI) open-source repository with capabilities to deploy a cryptocurrency miner on affected Linux devices.

The three harmful packages, named modularseven, driftme, and catme, attracted a total of 431 downloads over the past month before they were taken down...

The malicious code resides in the __init__.py file, which decodes and retrieves the first stage from a remote server, a shell script ("unmi.sh") that fetches a configuration file for the mining activity as well as the CoinMiner file hosted on GitLab. The ELF binary file is then executed in the background using the nohup command, thus ensuring that the process continues to run even after exiting the session. "Echoing the approach of the earlier 'culturestreak' package, these packages conceal their payload, effectively reducing the detectability of their malicious code by hosting it on a remote URL," said Fortinet FortiGuard Labs researcher Gabby Xiong. "The payload is then incrementally released in various stages to execute its malicious activities."

If you're starting the new year with a new Linux distro, ZDNet just ran an enthusiastic profile of Rhino Linux, calling it "beautiful" with "one of the more useful command-line package managers on the market." Rhino uses a modern take on the highly efficient and customizable Xfce desktop (dubbed "Unicorn") to help make the interface immediately familiar to anyone who logs in. You'll find a dock on the left edge of the screen that contains launchers for common applications, access to the Application Grid (where you can find all of your installed software), and a handy Search Bar (Ulauncher) that allows you to quickly search for and launch any installed app (or even the app settings) you need...

Thanks to myriad configuration options, Xfce can be a bit daunting. At the same time, the array of settings makes Xfce highly customizable, which is exactly what the Rhino developers did when they designed this desktop. For those who want a desktop that makes short work of accessing files, the Rhino developers have added a really nifty tool to the top bar. You'll find a listing of some folders you have in your Home directory (Files, Documents, Music, Pictures, Video). If you click on one of those entries, you'll see a list of the most recently accessed files within the directory. Click on the file you want to open with the default, associated application...

Rhino opts for the Pacstall package manager over the traditional apt-get. That's not to say apt-get isn't on the system — it is. But with Rhino Linux, there's a much easier path to getting the software you want installed... [W]hen you first run the installed OS, you are greeted with a window that allows you to select what package managers you want to use. You can select from Snap, Flatpak, and AppImages (or all three). Next, the developers added a handy tool (rhino-pkg) that makes installing from the command line very simple.
When the distro launched in August, 9to5Linux described it as "a unique distribution for Ubuntu fans who wanted a rolling-release system where they install once and receive updates forever." The theming looks gorgeous and it's provided by the Elementary Xfce Darker icon theme, Xubuntu's Greybird GTK theme, and Ubuntu's Yaru Dark WM theme. It also comes with some cool features, such as a dedicated and full-screen desktop switcher provided by Xfdashboard...

Klaus Zimmermann (a self-described "friendly hacker") recently posted a "State of the Distro" post, choosing his favorite distributions for things like portable installation from a USB drive (Alpine Linux) and for a desktop OS (Debian Linux or Devuan).

But when it comes to a distro for the Raspberry Pi, (at least until the 4), Zimmerman argues that FreeBSD's performance is "unlike any other Linux distribution I've ever seen, even with cpupower activated and overclocking." Nope, no match — FreeBSD's performance on the Pi is still way better, even without overclocking. You can browse a modern web, have things scroll smoothly, watch videos and even play some 3D games like Quake with it! And if you overclock it a little (2GHz) you can even make it run that gargantua MS Teams.

But what about all that lackluster driver support? WiFi drivers still on the 802.11g standard and all? Surely you can't be serious about it when Linux offers all that support out of the box, right? Wrong, actually. For starters, the drivers provided for the Pi's hardware are often half-assed proprietary blobs... I no longer think FreeBSD is really at fault if the driver support for the hardware is not helpful to begin with. Even drivers you find for Linux are shaky at best.

So yes, I will keep using FreeBSD on the Pi. As a desktop. With USB WiFi and audio adapters for those services, because the existing hardware is sort of moot even otherwise. And with those USB adapters — and FreeBSD — the Pi works really well, truly desktop-like.
I'd be curious to hear from Slashdot's readers about their own experiments with Linux (and FreeBSD) on a Raspberry Pi. Zimmerman's final winner, for the "Server" category, was Debian — though of his two servers, one is just an XMPP server set up on a Raspberry Pi. "I found that using Debian on the Pi is a real joy. Easy and simple to set up, familiar environment and all. So I'm keeping it.

"This concept is about to be overshadowed, however, by my growing like of FreeBSD lately..."


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