Linux Archive

We removed ads from OSNews. Donate to our fundraiser to ensure our future! It’s weekend, you might be visiting friends or relatives, and perhaps some of them are curious about switching away from Windows or macOS to Linux. There’s countless guides out there about this very topic, but to help you along a bit and cut through the avalanche of “AI” and SEO slop, here’s a true beginners’ guide to desktop Linux written by KDE developer Akseli Lahtinen, second most famous developer out of Finland after Linus Torvalds. There has been quite a surge in interest towards desktop Linux lately. The userbase, atleast according to some metrics, seems to be climbing. I realised today that it’s been 4 years for me since I did the switch. I have gathered some know-how that maybe a complete newbie could find useful. I also try to untangle some jargon I’ve learned: It may not be exactly technically correct, but this is meant for a more regular user anyway. ↫ Akseli Lahtinen This won’t be particularly interesting for most people who read a site like OSNews, but it’s a great roundup for newcomers in your circle.

As promised in the first iteration, we will now explore how GPU drivers work in more detail by exploring an application known as VkCube. As the program name implies, this application uses the Vulkan API to render a rotating cube on the screen. Its simplicity makes it a prime candidate to be used as a learning aid in our journey through GPU drivers. This article will first introduce the concept of User Mode Drivers (UMDs) and Kernel Mode Drivers (KMDs), breaking down the steps needed to actually describe VkCube‘s workload to the GPU. This will be done in a more compact way for brevity as it’s a rather extensive topic that has been detailed in several books. We will wrap up with an overview of the actual API offered by Tyr. As previously stated, this is the same API offered by Panthor, which is the C driver for the same hardware. ↫ Daniel Almeida There isn’t much to add here, except maybe this kitten.

RISC-V has been supported in the upstream Linux kernel since 2017. But without a common hardware baseline, ensuring compatibility across builds and distros hasn’t been easy. The ecosystem was in need of a compelling, clearly defined hardware target – something both software and hardware teams could rally around to produce silicon capable of running stable, enterprise-grade software. This target arrived in October 2024 with the ratification of the application-class RVA23 Profile – RISC-V-speak for a baseline configuration, similar to microarchitecture feature levels in x86. The culmination of years of progress, RVA23 brings together the work done to shape the ISA and standardize key extensions such as vector, bit manipulation and hypervisor. ↫ James De Vile at RISC-V International’s blog Such a standard, stable baseline is incredibly welcome, and RISC-V working to have everything part of the upstream Linux kernel is crucial. Having to deal with out-of-tree patches and drivers and specific builds for specific boards is a nightmare – look at Linux on ARM – and hinders adoption of RISC-V.

This release includes some Ext4 performance improvements; XFS support for large atomic writes; support for USB audio offload; support for zero-copy send TCP payloads from DMABUF memory; various futex improvements; initial support for Intel Trusted Domain Extensions; automatic weighted interleaved memory allocation policy; support for sending coredumps over an AF_UNIX socket, and make easier to build your kernel optimized for your local CPU. As always, there are many other features, new drivers, improvements and fixes. ↫ KernelNewbies: Linux 6.16 You’ll get it eventually, usually when the first few point releases iron out any troubling issues.

With recent efforts to improve accessibility in GNOME and KDE, as well as a renewed focus on highlighting the many issues that still need fixing, the Linux desktop is making meaningful strides in becoming more accessible to those among us with disabilities. Obviously, the Linux desktop is bigger than just GNOME and KDE, so today we have elementary OS improving its accessibility features in a variety of ways. July is Disability Pride Month, an opportunity for us to consider how we’re serving our disabled community and work on breaking down barriers to access. Last year we had the pleasure of being introduced to Florian—a fully blind cybersecurity enthusiast—and thanks to his feedback we completely rewrote navigation in Onboarding to be more keyboard and screen reader friendly, as well as took another look at Installation and Initial Setup to vastly improve our entire first run experience for blind folks. Plus, we implemented the screen reader interface in the  +  window switcher. Thanks to this feedback, elementary OS 8 can be installed and set up completely blind, an important win for maintaining your independence as a person with vision disabilities. Since the release of OS 8 we’ve been working on things like improving contrast, support for Dark Mode screenshots and brand colors in AppCenter, turning on or snoozing Dark Mode without canceling your schedule, expanding the scope of the “Reduce Motion” setting, and adding more options to reduce distracting notification bubbles. Plus, thanks to feedback from Aaron who you may know from his blog series on Linux accessibility, Notifications and the Shortcut Overlay both got releases that add screen reader support. ↫ Danielle Foré at elementary’s blog I’m glad we’re finally putting to rest this idea that accessibility features should be afterthoughts, relevant to only a minute percentage of people. Not only is the disabled community way bigger than we might think, many of the features they require are simply also extremely nice and beneficial to users who might not actually require them. I know tons of people who, for instance, love reduce motion features simply because it makes their operating system feel faster, or people who just don’t want to be bothered with notifications the instant they arrive. Accessibility goes far beyond what we traditionally think of as accessibility features, like screen readers or high contrast modes. Making software more accessible for those that require it, also makes software more accessible for those that merely desire it. Even though elementary OS probably isn’t the type of distribution that appeals to the average OSNews reader, I’m incredibly happy they’re taking accessibility seriously, and I intend to continue to highlight such improvements.

Since Void Linux uses a rolling release model, there’s not much to report on in the form of new releases and major new features, so I’m taking the release of version 0.60 of XBPS, Void Linux’ package manager, to cheat my way into talking about this excellent Linux distribution. I always think of Void as the “BSD of Linux distributions”, which should give you some vague hint as to what it’s going for. XBPS 0.60 doesn’t come packed with major new features either, and mostly fixes a ton of bugs, addresses few memory leaks, and changes the way held dependencies and directory removal/creation works when reinstalling a packages, just to name a few. There’s also some performance improvements, as there were apparently some problems in that department due to the increasing number of virtual packages in the Void repository. If you’re looking for a more traditional, hands-on Linux distribution, Void is an excellent choice. It’s my back-up for if (let’s face it: when) Fedora messes something up.

Highlights of Linux 6.15 include Rust support for hrtimer and ARMv7, a new setcpuid= boot parameter for x86 CPUs, support for sched_ext to count and report internal events, x86 Intel and AMD PMU enhancements, nested virtualization support for VGICv3 on ARM, and support for emulating FEAT_PMUv3 on Apple Silicon. ↫ Marius Nestor at 9To5Linux On top of these highlights, there’s also a ton of other changes, from the usual additions of new drivers, to better support for RISC-V, and so much more.

A Linux kernel driver that turns a rotary phone dial into an evdev input device. ↫ Stefan Wiehler The year of Linux on the desktop is finally here. Thanks to Oleksandr Natalenko for pointing this gem out.

I had to dig through our extensive archive – OSNews was founded in 1997, after all – to see if we reported on it at the time, but it turns out we didn’t: in 2006, Intel announced that in 2007, it would cease production of a range of old chips, including the 386 and 486. In Product Change Notification 106013-01, Intel proclaimed these chips dead. Intel Corporation has been manufacturing its MCS 51, MCS 251 and MCS 96 Microcontroller Product Lines for over 25 years now, and the Intel 186 Processor Families, the Intel 386 Processor Families and the Intel 486 Processor Families for over 15 years now. Additionally, we have been manufacturing the i960 32 Bit RISC Processor Families for over 15 years. However, at this time, the forecasted volumes for these product lines are now too low to continue production of these products beyond the year 2007. Therefore, Intel will cease manufacturing silicon wafers for our 6″ based processes in 2007. Affected products include Intel’s MCS 51, MCS 251, MCS 96, 80X18X, 80X38X, 80X486DXX, the i960 Family of Microcomputers, in addition to the 82371SB, 82439TX and the 82439HX Chipsets. Intel has no choice but to issue a Product Discontinuance Notice (PDN) effective 3/30/06. Last time orders will be accepted till 3/30/07 with last time ship dates of 9/28/07. ↫ Intel Product Change Notification 106013-01 Considering the 386, 486, and i960 families of processors were only used for niche embedded at very low volumes at that point in time, it made sense to call it quits. We’re 18 years down the line now, and I don’t think anyone really mourns the end of production for these processors. Windows ended support for these chips well before the 2007 end of production date, with Windows 2000 being the last Windows version that would run on a 486, albeit only barely, since it officially required a Pentium processor. Linux, though, continued to support the 486, but that, too, is now coming to an end. In a patch submitted to the LKML, Ingo Molnár, support for a variety of “complicated hardware emulation facilities” for x86-32 will be removed, effectively ending support for 486 and very early 586 processors, by increasing the minimum kernel support features to include TSC and CX8 (CMPXCHG8B) hardware support. Linus Torvalds has expressed interest in removing support for the 486 back in 2022, so this move doesn’t come as a huge surprise. While most tech news outlets leave it at that, as I was reading this news, I immediately thought of the Vortex86 line of processors and what this would mean for Linux support for those processors. In case you’re unaware, the Vortex86 is a line of x86-32-compatible processors, originating at SiS, but now developed and produced by DMP Electronics in Taiwain. The last two variants were the Vortex86DX3, a dual-core chip running at 1Ghz, and the Vortex86EX2, a chip with two asymmetrical cores that can run two operating systems at once. Their platform support documents for Windows and Linux are from 2021, so we can’t rely on those for more information. Digging through some of the documentation from ICOP, who sell industrial PCs based on the latest Vortex86DX3, I think support in modern kernels is very much hit and miss even before this news. All Vortex86 processors are supposedly i586 (with later variants being i686, even), but some of the earlier versions were compatible with the 486SX. On top of that, Linux 4.14 seems to be the last kernel that supports any of these chips out-of-the-box based on the documentation by DMP – but then, if you go back to ICOP, you’ll find news items about Linux 5.16 adding better support for Vortex86, so I’m definitely confused. My uneducated guess is that the DX3 and EX2 will probably work even after these changes to the Linux kernel, but earlier models might have more problems. Even on the LKML I can find messages from the kind of people who know their stuff who don’t know all the ins and outs of these Vortex86 processors, and which instructions they actually support. It won’t matter much for people relying on Vortex86 processors in industrial and commercial settings, though, since they tend to use custom stacks built by the vendor, so they’re going to be just fine. What’s more interesting is the what I assume is a small enthusiast market using Vortex86 processors who might want to run modern Linux kernels on them. I have a feeling these code removals might lead to some issues on especially the earlier models, meaning you’ll have to use older kernels. I’ve always been fascinated by the Vortex86 line of processors, and on numerous occasions I’ve hovered over the buy button on some industrial PC using the VortexDX3 (or earlier) processor. Let me know if you’re interested in seeing what this chip can do, and if there’s enough interest, I can see if I can set a Ko-Fi goal to buy one these and mess around with Windows Embedded/CE, Linux, and god knows what else these things can be made to run.

VectorVFS is a lightweight Python package that transforms your Linux filesystem into a vector database by leveraging the native VFS (Virtual File System) extended attributes. Rather than maintaining a separate index or external database, VectorVFS stores vector embeddings directly alongside each file—turning your existing directory structure into an efficient and semantically searchable embedding store. VectorVFS supports Meta’s Perception Encoders (PE) which includes image/video encoders for vision language understanding, it outperforms InternVL3, Qwen2.5VL and SigLIP2 for zero-shot image tasks. We support both CPU and GPU but if you have a large collection of images it might take a while in the first time to embed all items if you are not using a GPU. ↫ Christian S. Perone It won’t surprise many of you that this goes a bit above my paygrade, but according to my limited understanding, VectorVFS stores information about files inside the xattr part of inodes. The information being stored is converted into vectors first, and this is the part that breaks my brain a bit, because vectors in this context are far too complex for me to understand. I vaguely understand the end result here – making files searchable using vector magic without using a dedicated database or separate files by using extended attributes in inodes – but the process is far more complicated to understand. It still seems like a very interesting approach, though, and I’d love for people smarter than me to take VectorVFS apart and explain it in easier terms for those of us who don’t fully grasp it.

Apparently, the Bcachefs people are having problems with case-folding, and Linus Torvalds himself is not happy about it. Torvalds holds the only right opinion in this matter, which is that filesystems should obviously be case-sensitive. Case-insensitive names are horribly wrong, and you shouldn’t have done them at all. The problem wasn’t the lack of testing, the problem was implementing it in the first place. Dammit. Case sensitivity is a BUG. The fact that filesystem people still think it’s a feature, I cannot understand. It’s like they revere the old FAT filesystem so much that they have to recreate it – badly. ↫ Linus Torvalds on the LKML It boggles my mind that a modern operating system like macOS still defaults to being case-insensitive (but case-preserving), and opting to install macOS the correct way, i.e. with case-sensitivity, can still lead to issues and bugs because macOS isn’t used to it. In 2025. Windows’ NTFS is at least case-sensitive, but apparently Win32 applications get all weird about it; if you have several files with identical names save for the case used, Win32 applications will only allow you to open one of them. I’m not sure how up to date that information is, though. Regardless, the notion that Readme.txt is considered the same as readme.txt is absolutely insane, and should be one of those weird relics we got rid of back in the ’90s.

One of the strong points of Linux has always been how solid the experience of installing and managing software is. Contrarily to what happens in the Windows and macOS world, software on Linux is obtained through something called a package manager, a piece of software that manages any piece of software the user installs, as well as its dependencies, automatically. ↫ Luca Bramè at Libre.News It truly is. I can’t imagine using any operating system that relies (almost) exclusively on me going out to individual websites to download random installers or disk images, all with their own unique update mechanisms I need to keep track of, that eat up resources and interrupt my workflow. The combination of Fedora’s repository’s with the odd Copr or Flatpak package – all managed transparently through KDE’s Discover – is effectively perfect. I never have to manually install anything, nor do I ever have to rely on tarballs like back in the dark ages. Dealing with a Windows or macOS machine is a nightmare compared to this. Managing applications on those operating systems feels hopelessly archaic and outdated, and I have no idea how users tolerate that kind of nonsense. They’ve got a dozen or more updaters running in the background, cluttering up the system tray and eating resources, or whenever they open an application they get an annoying popup interrupting their work to ask them to update. It’s barbaric and user-hostile, and nobody should be dealing with that in 2025. It’s also highly unlikely things will ever improve for Windows or macOS users, since any attempt to bolt a package manager into them invariably fails. The official Windows and macOS application stores have been abject failures in more ways than one, and tools like winget are just glorified download managers that run regular installers in silent mode – incredibly crude and only really good for batch-downloading some installers. The Linux world is far from perfect, but they nailed application management early on, and the competition has basically sat still ever since.

Long ago, during the time of creation, I confidently waved my hand and allocated a 1GB ESP partition and a 1GB boot partition, thinking to myself with a confident smile that this would surely be more than enough for the foreseeable future. However, this foreseeable future quickly vanished along with my smile. What was bound to happen eventually came, but I didn’t expect it to arrive so soon. What could possibly require such a large boot partition? And how should we resolve this? Here, I would like to introduce the boot partition issue I encountered, as well as temporary coping methods and final solutions, mentioning the problems encountered along the way for reference. ↫ fernvenue Some of us will definitely run into this issue at some point, so if you’re doing a fresh installation it might make sense to allocate a bit more space to your boot partition. If you have a running system and are bumping into the limitations of your boot partition and don’t want to reinstall, the linked article provides some possible solutions.

We’ve talked about Chimera Linux a few times now on OSNews, so I won’t be repeating what makes it unique once more. The project announced today that it will be shuttering its RISC-V architecture support, and considering RISC-V has been supported by Chimera Linux pretty much since the beginning, this is a big step. The reason is as sad as it is predictable: there’s simply no RISC-V hardware out there fit for the purpose of building a Linux distribution and all of its packages. Up until this point, Chimera Linux built its RISC-V variant “on an x86_64 machine with qemu-user binfmt emulation coupled with transparent cbuild support”. There are various problems with this setup, like serious reliability problems, not being able to test packages, and a lack of performance. The setup was intended to be a temporary solution until proper, performanct RISC-V hardware became available, but this simply hasn’t happened, and it doesn’t seem like this is going to change soon. Most of the existing RISC-V hardware options simply lack the performance to be used as build machines (think Raspberry Pi 3/4 levels of performance), making them even slower than the emulation setup they’re currently using. The only machine that in theory would be performant enough to serve as a build machine is the Milk-V Pioneer, but this machine has serious other problems, as the project notes: Milk-V Pioneer is a board with 64 out-of-order cores; it is the only of its kind, with the cores being supposedly similar to something like ARM Cortex-A72. This would be enough in theory, however these boards are hard to get here (especially with Sophgon having some trouble, new US sanctions, and Mouser pulling all the Milk-V products) and from the information that is available to me, it is rather unstable, receives very little support, and is ridden with various hardware problems. ↫ Chimera Linux website So, not only is the Milk-V Pioneer difficult to get due to, among other things, US sanctions, it’s also not very stable and receives very little support. Aside from the Pioneer and the various slow and therefore unsuitable options, there’s nothing else in the pipeline either for performant RISC-V hardware, making it quite difficult to support the architecture. Of course, this could always change in the future, but for now, supporting RISC-V is clearly not an option for Chimera Linux. This is clearly sad news, especially for those of us hoping RISC-V becomes an open source hardware platform that we can use every day, and I wonder how many other projects are dealing with the same problem.