Linux Archive
What if you have a PC-98 machine, and you want to run Linux on it, as you do? I mean, CP/M, OS/2, or Windows (2000 and older) might not cut it for you, after all. Well, it turns out that yes, you can run Linux on PC-98 hardware, and thanks to a bunch of work by Nina Kalinina – yes, the same person from a few days ago – there’s now more information gathered in a single place to get you started. Plamo Linux is one of the few Linux distributions to support PC-98 series. Plamo 3.x is the latest distribution that can be installed on PC-9801 and PC-9821 directly. Unfortunately, it is quite old, and is missing lots of useful stuff. This repo is to share a-ha moments and binaries for Plamo on PC-98. ↫ Plamo98 goodies The repository details “upgrading” – it’s a bit more involved than plain upgrading, but it’s not hard – Plamo Linux from 3.x to 4, which gives you access to a bunch of things you might want, like GCC 3.3 over 2.95, KDE 3.x, Python 2.3, and more. There’s also custom BusyBox config files, a newer version of make, and a few other goodies and tools you might want to have. Once it’s all set and done, you can Linux like it’s 2003 on your PC-98. The number of people to whom this is relevant must be extraorinarily small, but at some point, someone is going to want to do this, only to find this repository of existing work. We’ve all been there.
A very exciting set of kernel patches have just been proposed for the Linux kernel, adding multikernel support to Linux. This patch series introduces multikernel architecture support, enabling multiple independent kernel instances to coexist and communicate on a single physical machine. Each kernel instance can run on dedicated CPU cores while sharing the underlying hardware resources. ↫ Cong Wang on the LKML The idea is that you can run multiple instances of the Linux kernel on different CPU cores using kexec, with a dedicated IPI framework taking care of communication between these kernels. The benefits for fault isolation and security is obvious, and it supposedly uses less resources than running virtual machines through kvm and similar technologies. The main feature I’m interested in is that this would potentially allow for “kernel handover”, in which the system goes from using one kernel to the other. I wonder if this would make it possible to implement a system similar to what Android currently uses for updates, where new versions are installed alongside the one you’re running right now, with the system switching over to the new version upon reboot. If you could do something similar with this technology without even having to reboot, that would be quite amazing and a massive improvement to the update experience. It’s obviously just a proposal for now, and there will be much, much discussion to follow I’m sure, but the possibilities are definitely exciting.
As if Francesco P. Lovergine heard my prayers, he wrote an article detailing his experiences with using Guix. Considering he’s a longtime Debian developer, we’re looking at someone who knows a thing or two about Linux. In the last few months, I have installed and upgraded my second preferred GNU/Linux system, GNU Guix, on multiple boxes. Regarding that system, I have already written a few introductory posts in the recent past. This is an update about my experiences as a user and developer. I still think Guix is a giant step forward in packaging and management, in comparison with Debian and other distributions, for elegance and inner coherence. ↫ Francesco P. Lovergine Lovergine found some problems with Guix, most notably those stemming from a lack of manpower. It’s not a hugely popular package management system and associated distribution, so the team of developers behind it is relatively small, and this leads to issues like outdated packages, problems arising from updates, and possible security issues. There’s no specific security team, for instance, but at least it’s easy to roll back updates due to the nature of Guix. Another problem, partially related to the lack of manpower, stems from the fact that the GNU Guix System uses some unusual systems, most notably GNU Shepard. This init system is an alternative to the widely-used systemd, alongside other alternatives like runit (which I use through Void Linux), but due to its relative lack of popularity, it can take some time for more complex packages to be made compatible with it. Especially some packages – like GNOME – that depend more and more on systemd are going to lag behind on Guix. For anyone with decent Linux experience and a willingness to tinker, I don’t think any of these issues – and the others Lovergine mentions – are dealbreakers. Sure, you might not want to deploy the GNU Guix System on a production system or anything that requires solid, strong security, but for personal and enthusiast use it seems like an interesting and somewhat unorthodox Linux distribution.
DistroWatch’s Jesse Smith is bringing some attention to an issue I have never encountered and had never heard of, and it has to do with antivirus software on Windows. It seems it’s not uncommon for antivirus software on Windows to mark Linux ISOs as malware or otherwise dangerous, and it seems people are reporting these findings to DistroWatch, for some reason. DistroWatch makes it clear they don’t host any of the ISOs, and that close to all of these warnings from antivirus software are false positives. So why do multiple Windows virus scanners report that they find malware in Linux downloads? Putting aside the obvious conspiracy theories about anti-virus vendors not wanting to lose customers, what is probably happening is the scanners are detecting an archive file (the ISO) which contains executable code, and flagging it as suspicious. Some of the code is even able to change the disk layout, which is something that looks nasty from a security point of view. It’s entirely understandable that a malware scanner which sees an archive full of executable code that could change the way the system boots would flag it as dangerous. ↫ Jesse Smith at DistroWatch I wonder how many people curious about Linux downloaded an ISO, only to delete is after their Windows antivirus marked it as dangerous. I can’t imagine the number to be particularly high – if you’re downloading a Linux ISO, you’re probably knowledgeable enough to figure out it’s a false positive – but apparently it’s a big enough issue that DistroWatch needs to inform its readers about it, which is absolutely wild to me.
I stumbled upon an LWN.net article from 2023, in which Lars Wirzenius, a long-time Debian developer and friend of Linus Torvalds, recalls the very early days of Linux – in fact, before it was even called Linux. There’s so many fun little stories in here, like how the Linux kernel started out as a multitasking demo written in x86 assembly, which did nothing more than write As and Bs on the screen, or the fact Linux was originally called Freax before Ari Lemmke, one of the administrators of ftp.funet.fi, opted for the name “Linux” when uploading the first release. However, my favourite story is about what installing Linux was like during those early days. During this time, people were interested in trying out this new thing, so Linus needed to provide an installation method and instructions. Since he only had one PC, he came to visit to install it on mine. Since his computer had been used to develop Linux, which had simply grown on top of his Minix installation, it had never actually been installed before. Thus, mine was the first PC where Linux was ever installed. While this was happening, I was taking a nap, and I recommend this method of installing Linux: napping, while Linus does the hard work. ↫ Lars Wirzenius at LWN.net The entire article is a joy to read, and since it’s from 2023, I’m sure I’m late to the party and none of it is news to many of you. On a more topical note, Wirzenius published a short article today detailing why he still uses Debian, after all these decades.
While Nix and NixOS get all the attention when it comes to declarative package management, there are other, competing implementations of the same general idea. Guix, developed as part of the GNU Project, was originally based on Nix, but grew into its own thing. The project recently announced a major change to how it packages Rust and its countless dependencies and optional ‘crates’. We have changed to a simplified Rust packaging model that is easier to automate and allows for modification, replacement and deletion of dependencies at the same time. The new model will significantly reduce our Rust packaging time and will help us to improve both package availability and quality. ↫ Hilton Chain at the Guix blog I hear people talk about Nix and NixOS all the time – I tried it myself, too, but I felt I was using an IBM z17 mainframe to watch a YouTube video – and in fact, Nix has kind of become a meme in and of itself, but you never hear people talk about Guix. With this being OSNews, I’m assuming there’s going to be people here using it, and I’m incredibly curious about your experiences. What are the features and benefits that make you use it? If you’re curious – the best way to try Guix is probably to install the GNU Guix System, the Linux distribution built around Guix and Shepard, GNU’s alternative init system. It’s available for i686, x86_64, ARMv7, and AArch64, and can be virtualised too, of course.
If you have spent any time around HID devices under Linux (for example if you are an avid mouse, touchpad or keyboard user) then you may have noticed that your single physical device actually shows up as multiple device nodes (for free! and nothing happens for free these days!). If you haven’t noticed this, run libinput record and you may be part of the lucky roughly 50% who get free extra event nodes. ↫ Peter Hutterer I’ve honestly always wondered about this, since some of my laptops shows both a trackpad and a mouse configuration panel even when there’s no mouse plugged in. Thanks to this article, I now know why this happens.
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.
Solène Rapenne, who writes a lot about and contributes to operating systems like OpenBSD and Qubes OS, has published a primer about what, exactly, Qubes OS is. I like to call Qubes OS a meta operating system, because it is not a Linux / BSD / Windows based OS: its core is Xen (some kind of virtualization enabled kernel). Not only it’s Xen based, but by design it is meant to run virtual machines, hence the name “meta operating system” which is an OS meant to run many OSes make sense to me. ↫ Solène Rapenne Rapenne explains the various ways in which isolated virtual machines are used in Qubes OS, and it’s easy to see just how secure Qubes OS’ way of doing things is. At the same time, it seems quite cumbersome to me as a regular user, and I don’t think I’m up for dealing with all of that. If you do security research, handle private or classified data, are a whistleblower or an investigative journalist, thoug, Qubes seems like a natural choice. Interesting to note is that Rapenne used to use OpenBSD for her security work, but moved to Qubes OS because its virtual machine infrastructure is far more robust, and hardware support is better, as well.
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.
The year is 2013 and I am hopping mad. systemd is replacing my plaintext logs with a binary format and pumping steroids into init and it is laughing at me. The unix philosophy cries out: is this the end of Linux (or, as many are calling it, GNU plus Linux)? The year is 2025 and I’m here to repent. Not only is systemd a worthy successor to traditional init, but I think that it deserves a defense for what it’s done for the landscape – especially given the hostile reception it initially received (and somehow continues to receive? for some reason?). No software is perfect – except for TempleOS – but I think that systemd has largely been a success story and proven many dire forecasts wrong (including my own). I was wrong! ↫ Tyler Langlois The article goes into detail on a number of awesome features, niceties, and clever things systemd has, and they’re legion. Even as a mere user, I like systemd, as every time I have had to or wanted to interact with it, it’s been a joy to use, with excellent documentation making it remarkably easy even for someone like me to get into it without doing any damage or breaking anything. Every time I read up on system’d more advanced features, I’m surprised by how well thought out and implemented it all seems to be. I’ve experienced several major leaps forward in the Linux world that made using Linux on my computers easier and more reliable, and the adoption of systemd stands among them as one of the biggest leaps forward desktop Linux has ever made. The idea of going back to a random piles of non-standardized init scripts with nebulous dependencies from varying sources and wildly different levels of quality seems like a complete nightmare to me. There’s a lot of charm in doing things ‘the old way’, and I’m not saying you’re wrong for wanting an init system that tries to do less, or that’s easier to read and parse for you, or whatever, but that doesn’t mean systemd is bad, evil, or part of a Red Hat conspiracy to kill Linux.
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.
At the Linux Application Summit (LAS) in April, Sebastian Wick said that, by many metrics, Flatpak is doing great. The Flatpak application-packaging format is popular with upstream developers, and with many users. More and more applications are being published in the Flathub application store, and the format is even being adopted by Linux distributions like Fedora. However, he worried that work on the Flatpak project itself had stagnated, and that there were too few developers able to review and merge code beyond basic maintenance. ↫ Joe Brockmeier at LWN After reading this article and the long list of problems the Flatpak project is facing, I can’t really agree that “Flatpak is doing great”. Apparently, Flatpak is in maintenance mode, while major problems remain untouched, because nobody is working on the big-ticket items anymore. This seems like a big problem for a project that’s still facing a myriad of major issues. For instance, Flatpak still uses PulseAudio instead of Pipewire, which means that if a Flatpak applications needs permission to play audio, it also automatically gets permission to use the microphone. NVIDIA drivers also pose a big problem, network namespacing in Flatpak is “kind of ugly”, you can’t specify backwards-compatible permissions, and tons more problems. There’s a lot of ideas and proposed solutions, but nobody to implement them, leaving Flatpak stagnated. Now that Flatpak is adopted by quite a few popular desktop Linux distributions, it doesn’t seem particularly great that it’s having such issues with finding enough manpower to keep improving it. There’s a clear push, especially among developers of end-user focused applications, for everyone to use Flatpak, but is that push really a wise idea if the project has stagnated? Go into any thread where people discuss the use of Flatpaks, and there’s bound to be people experiencing problems, inevitably followed by suggested fixes to use third-party tools to break the already rather porous sandbox. Flatpak feels like a project that’s far from done or feature-complete, causing normal, every-day users to experience countless problems and issues. Reading straight fromt he horse’s mouth that the project has stagnated and isn’t being actively developed anymore is incredibly worrying.
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.
Tuxguitar is a quite powerful application written in a mixture of Java / C. It is able to render a score in real time either via Fluidsynth or via pure MIDI. The development of Tuxguitar started in 2008 on Sourceforce and after a halt in 2022, the project restarted on Github and is still actively developed. The goal of this article is to try to render a score via Tuxguitar, and various other applications connected to Tuxguitar, via Jack or Pipewire-Jack. The score used throughout this article will be The Pursuit Of Vikings by the band Amon Amarth. It has 2 guitars, a bass and a drum track. ↫ Yann Collette at Fedora Magazine If you’re into audio production and are considering using Linux for your audio needs, this article is a good starting point.
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.
