Linux Archive
Linus Torvalds just released Linux 5.19 as stable for the newest version of the Linux kernel. He also mentioned this is the first time he released the new Linux kernel from an ARM64 laptop in the form of an Apple MacBook running an AArch64 Apple M2 SoC. Linux 5.19 brings many new features from initial LoongArch CPU support to continued work on bringing-up AMD Zen 4 CPUs, AMD RDNA3 enablement continuing, more work on Intel DG2/Alchemist, Intel Idle driver support for Alder Lake, initial Raptor Lake P graphics support, Zstd compressed firmware, and some nice performance improvements. In addition, Torvalds intends to call the next release Linux 6.0, because he’s “starting to worry about getting confused by big numbers again”.
In addition to the OpenChrome DRM/KMS driver hoping to be finally mainlined in 2022 for supporting aging VIA graphics hardware from the long-ago days of their x86 chipsets, separately there is a DRM/KMS kernel driver in the works for something even older… A Linux DRM graphics driver for the Atari Falcon from the early 90’s. Over the past two years a DRM driver has been in the works for the Atari graphics hardware with its built-in graphics chipset. This is not to be confused with the 2021-launched Atari VCS mini PC / game console, but the Atari Falcon personal computers out of the Atari Corporation from the early 90’s that featured Motorola 68000 series processors and a programmable video controller. It’s not yet in mainline, so it’ll be fun to see if Torvalds is up for including such an old and niche driver once it’s matured. I’ve always wanted an Atari Falcon, but they’re even more expensive than most other classic computers, so that’s most likely never going to happen.
And the second post by Chris Siebenmann, this time about how the Linux console has gotten slower over the years. If you’ve been running x86 Linux servers for long enough, you’ve probably noticed two changes in the kernel’s text console. On the one hand, the text console has gotten substantially bigger, sporting sizes like 128×40 instead of the much smaller old sizes, for example 80×25. On the other hand, text output to the console has generally gotten slower, usually much slower than you would expect for the change in console size. These two changes are not unrelated, because they are both part of a fundamental change in how the kernel console normally worked and works on x86 hardware. Hint: the two posts are related.
I’ve got two fantastic posts about Linux today, from the same author – Chris Siebenmann. First, the history behind kernel mode setting in Linux. In the older days of Linux, the kernel didn’t know very much about graphics (at least on PCs). Instead, setting up and handling graphics hardware was the domain of the X server; the kernel gave it access to PCI (or AGP) resources, and the X server directly stored values and read things out. Part of what the X server did was set the graphics mode (ie, the modeline resolution, depth, and scan frequencies), initially from explicit modelines and then over time from EDID information and other things you didn’t have to configure (which was great). This was user space mode setting. There were a variety of reasons to do this at the time (cf) but it had various drawbacks, including requiring the X server to have significant privileges (cf Fedora removing them). You can see where this is going.
If you have a 2013- or 2014-era iPad sitting around unused because it’s not getting updates from Apple anymore and has stopped running the apps you need, some developers are working on an alternative software solution for you. Developer Konrad Dybcio and a Linux enthusiast going by “quaack723” have collaborated to get Linux kernel version 5.18 booting on an old iPad Air 2, a major feat for a device that was designed to never run any operating system other than Apple’s. This is an amazing achievement, and further goes to show that given enough time, someone will port Linux to it.
I’ll cut to the chase; through a combination of unlikely discoveries, crazy hacks and the 90s BBS warez scene I’ve been able to port Lotus 1-2-3 natively to Linux – an operating system that literally didn’t exist when 1-2-3 was released! If you want to hear how a proprietary application could be ported to new operating systems 30 years after release, read on! This isn’t running through an emulator or a VM – this is a real port. Amazing work.
The day has finally come: NVIDIA IS PUBLISHING THEIR LINUX GPU KERNEL MODULES AS OPEN-SOURCE! To much excitement and a sign of the times, the embargo has just expired on this super-exciting milestone that many of us have been hoping to see for many years. Over the past two decades NVIDIA has offered great Linux driver support with their proprietary driver stack, but with the success of AMD’s open-source driver effort going on for more than a decade, many have been calling for NVIDIA to open up their drivers. Their user-space software is remaining closed-source but as of today they have formally opened up their Linux GPU kernel modules and will be maintaining it moving forward. Here’s the scoop on this landmark open-source decision at NVIDIA. I can’t believe this is happening. NVIDIA is open sourcing all of its kernel driver modules, for both enterprise stuff and desktop hardware, under both the GPL and MIT license, it will available on Github, and NVIDIA welcomes community contributions where they make sense. This isn’t just throwing the open source community a random bone – this looks and feels like the real deal. They’re even aiming to have their open source driver mainlined into the Linux kernel once API/ABI has stabalised. This is a massive win for the open source community, and I am incredibly excited about what this will mean for the future of the Linux desktop.
The Sound Blaster X7 is a DAC (Digital Analog Converter) and amplifier. It allows several inputs to be mixed together toward a single output. Its configuration is maintained directly on the device and can be controlled by either a mobile device over Bluetooth or from a Windows machine over USB. When using my work laptop, I can’t change the X7 volume or output. This is an issue when you need to jump into a quick call as you can’t switch over to headset easily. Since control over Bluetooth works well from the Android application, it is possible to control all the features I need over Bluetooth. There is only one issue: the only thing I’ve ever reversed is a USB msi keyboard to implement support on Linux. I don’t know much about how Bluetooth works, nor about Android and from what I could gather, I can’t live capture the Bluetooth traffic (on my device) like I did for USB. It is nothing that can’t be fixed by a bit of reading and some work, so let’s do this. It’s amazing to me that a lot of more obscure and less popular hardware has Linux support only because some random person in Nowhere, Nebraska, had a need for it.
Up until now, all installs of Raspberry Pi OS have had a default user called “pi”. This isn’t that much of a weakness – just knowing a valid user name doesn’t really help much if someone wants to hack into your system; they would also need to know your password, and you’d need to have enabled some form of remote access in the first place. But nonetheless, it could potentially make a brute-force attack slightly easier, and in response to this, some countries are now introducing legislation to forbid any Internet-connected device from having default login credentials. So with this latest release, the default “pi” user is being removed, and instead you will create a user the first time you boot a newly-flashed Raspberry Pi OS image. This is in line with the way most operating systems work nowadays, and, while it may cause a few issues where software (and documentation) assumes the existence of the “pi” user, it feels like a sensible change to make at this point. This is a pretty substantial change that might break some applications that assume the default “pi” user exists.
The comments have pointed out that the person I was linking to is a transphobic bigot, and that deadnaming was taking place. I had no idea this was the case, and was entirely unaware of the situation. Still, that is not an excuse, and I should have done better due diligence to ensure this didn’t happen. Rest assured, there was no ill intent on my part whatsoever – just ignorance of the people involved. My sincerest apologies to everyone involved, and I will strive to do better. elementaryOS was never going to be long for this world. They go years without releases, new releases require fresh installations (often no upgrade path), the only way to install software out of the box is through their virtually empty application store (you need to manually enable things like apt repositories), and so on. A lot of people suggest elementaryOS as a distribution for beginners, but I never understood why – it will leave users locked into an operating system that barely has any applications, requires fresh installations, and requires a ton of manual fiddling and command line work to make more usable and capable. At that point, you might as well jump straight to Mint, pop!_OS, Fedora, or any of the other truly capable, user friendly, foolproof Linux distributions that don’t try to lock users out of all kinds of useful features and applications. It’s no surprise to me that the company behind elementaryOS has been unable to make any money. It always gave me major Lindows/Linspire vibes.
The PipeWire project has made major strides over the past few years, bringing shiny new features, and paving the way for new possibilities in the Linux multimedia scene. With 2021 seeing significant progress made on all fronts, let’s take a moment to look back at what was accomplished, and what lies ahead for 2022. Just one of the many project that make Linux easier to use on the desktop.
Linux themes and icon sets, inspired by other operating systems, have been around for as long as Linux has had a GUI. Some times those themes get pretty close to looking like the original. But… What if — what if — you could make your Linux desktop look almost exactly like Windows 95? It’s damn headerbars in GNOME (and now also Xfce) that mess this utopia up. They looks preposterously bad using these classic operating systems skins.
Surprisingly, yes! It’s hard to judge how bad the performance really is, since it’s in a virtual machine, but all the software that I tested was definitely usable. It’s somewhat slow, but that’s exactly what you’d expect. As we used a lot of unsafe hacks (disabling dependency and file conflict checking, for instance) to get this to actually work, I wouldn’t recommend using this system for anything other than proving it’s possible. Now is this useful? The short answer is no. The long answer is also no. I can think of exactly zero uses of this experiment (and I must be pretty crazy for doing it). This is the kind of nonsense computing I can get behind.
In 2021, there were no Valhall devices running mainline Linux. While a lack of devices poses an obvious obstacle to device driver development, there is no better time to write drivers than before hardware reaches end-users. Developing and distributing production-quality drivers takes time, and we don’t want users to be reliant on closed source blobs. If development doesn’t start until a device hits shelves, that device could reach “end-of-life” by the time there are mature open drivers. But with a head start, we can have drivers ready by the time devices reach end users. Let’s see how. Amazing work.
I’ve used NixOS as the only OS on my laptop for around three years at this point. Installing it has felt sort of like a curse: on the one hand, it’s so clearly the only operating system that actually gets how package management should be done. After using it, I can’t go back to anything else. One the other hand, it’s extremely complicated constantly changing software that requires configuration with the second-worst homegrown config programming language I’ve ever used. I don’t think that NixOS is the future, but I do absolutely think that the ideas in it are, so I want to write about what I think it gets right and what it gets wrong, in the hopes that other projects can take note. As such, this post will not assume knowledge of NixOS — if you’ve used NixOS significantly, there probably isn’t anything new in here for you. NixOS is talked about a lot – but it seems impenetrable for a newcomer or outsider to get into it.
I’ve spent the past several months trying on and off to make Linux run on the Presario. The 486SX is the oldest CPU Linux still supports! I was quite hindered by my lack of any floppy disks – fortunately, I managed to get my hands on a few working ones for Christmas this year and made some headway, first getting MS-DOS 6.22 installed on the new hard disk, then messing with the Linux kernel configuration until I got it to work. And yesterday I finally got it! Here are the steps for configuring a basic kernel with Linux 5.14.8. A lack of usefulness should not be a hindrance to having fun.
Linux 5.16 has many new features including the FUTEX2 futex_waitv system call for helping Steam Play (and Wine), memory folios have been mainlined, AMD Ryzen 6000 mobile series support is getting into better shape, Intel Alder Lake S graphics are now considered stable, Intel AMX support for Sapphire Rapids has landed, big AMD Ryzen with Radeon graphics performance improvements, and a wealth of other hardware improvements. And this new kernel release will find its way to your computer soon if you’re using either a bleeding edge distribution or manually added a kernel repository with up-to-date kernels (I tend go with xanmod).
Some time ago I stopped releasing EasyOS as an ISO file, from then onward as a drive image file only. This has been contentious, and I receive emails from people lamenting the demise of the ISO. So, I should post some thoughts why I made this decision. Not an exhaustive rationale, just some thoughts while I think of them right now… The ISO9660 file format is very old, going right back to 1988, and has since then had enhancements bolted on, see the Wikipedia ISO9660 page. In addition, there is the “hybrid ISO”, enabling booting from a USB-stick, and on top of that enhancements to enable booting from either or both legacy-BIOS and UEFI firmware computers, see here. I think I agree. ISO files have become a bit of a headache lately, and I’d much rather just use a straightforward image I can dd to a USB drive.
The current solutions involve packaging entire alternate runtimes in containerized environments. Flatpak, Snap, AppImage, Docker, and Steam: these all provide an app packaging mechanism that replaces most or all of the system’s runtime libraries, and they now all use containerization to accomplish this. Flatpak calls itself “the future of application distribution”. I am not a fan. I’m going to outline here some of the technical, security and usability problems with Flatpak and others. I’ll try to avoid addressing “fixable” problems (like theming) and instead focus on fundamental problems inherent in their design. I aim to convince you that these are not the future of desktop Linux apps. I fully agree. If you’re a Linux application developer, packaging your application up as an RPM and DEB is really all you need to do; you’ll cover by far the most desktop Linux users, and your code will most likely be packaged up by package maintainers of smaller package management systems as well. All these “solutions” just add additional layers of confusion, bloat, issues, and bugs that can be easily avoided by sticking to your distribution’s own package manager. I simply avoid any application packaged up in any of these formats – with the exception of Steam – and move on to something from a developer who does understand and care about desktop Linux.
Let’s say you got your filthy hands on an ISO of Red Star OS Desktop 3.0 (like, 5 years ago but you forgot about it). The obvious next step is to install it on your main computer and give it access to the outside so it can spread love and goodness. Just kidding, install that motherfucker in a virtual machine (VirtualBox, VMware, etc), just because. These articles looking at North Korea’s Red Star OS pop up every few years, and they’re always a fun read.
