Linux Archive
With that initial explanation out of the way, in 2022 I’ve been getting my Chumby working with the mainline Linux kernel and slowly trying to submit fixes upstream for issues as I find them. To be clear, I’m not trying to get the stock Chumby software working with the new kernel. That’s likely impossible. The stock software is heavily dependent on Flash which is a dead end. I’m just getting the new kernel running well enough so that I can develop my own custom software for it. I’m going to write a few posts about that process and some of the fun challenges I had to overcome. This first post in the series will talk about some of the work I did with U-Boot. If you’re into Linux kernel development, there’s massive number of devices out there running outdated kernels you could be updating for fun, in your spare time.
Linus Torvalds has backed the idea of possibly removing Intel 486 (i486) processor support from the Linux kernel. After the Linux kernel dropped i386 support a decade ago, i486 has been the minimum x86 processor support for the mainline Linux kernel. This latest attempt to kill off i486 support ultimately arose from Linus Torvalds himself with expressing the idea of possible requiring x86 32-bit CPUs with “cmpxchg8b” support, which would mean Pentium CPUs and later. I think that would be a fair call. It’s highly unlikely any modern additions to the Linux kernel are usable on a 486 anyway, so existing kernels which still have support for this ancient processor should suffice. On top of that, there’s no doubt in my mind that at least someone or some group of people will step up to maintain a special 486 branch if there is indeed any residual need for it.
Do you have some old 386 or 486 machines lying around, collecting dust, but want them to become productive members of your computer household? Fret no more – there’s gray386linux and gray486linux, distributions specifically tailored for these two older architectures. I’m not entirely sure what you’d actually do with them, but fascinating projects nonetheless.
Linux command line for you and me is a book for newcomers to command line environment. Exactly as it says on the tin. This is a great, easy to use resource for command line use. Even though I’ve used Linux for more than two decades, and have been Linux-only for a few years now, I rarely use the command line, and having a resource like this in my back pocket for the few times I do dive into the command line is very nice – especially when you need to use some of the less obvious commands.
extrowerk tells us about a new hacker-friendly device – a $20 LTE modem stick with a quadcore CPU and WiFi, capable of running fully-featured Linux distributions. This discovery hinges on a mountain of work by a Chinese hacker , who’s figured out this stick runs Android, hacked its bootloader, tweaked a Linux kernel for it and created a Debian distribution for the stick – calling this the OpenStick project. ’s writeup translates the ’s tutorial for us and makes a few more useful notes. With this writeup in hand, we have unlocked a whole new SBC to use in our projects – at a surprisingly low price! There’s so much computing power in cheap, disposable technology these days, and you can do fun things with it.
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.
