Since I wanted to see how Linux would detect the drive that meant I needed to find a way to boot Linux. After a bit of googling I discovered the make tinyconfig option which makes a very small (but useless) kernel, small enough to fit on a floppy. I enabled a couple of other options, found a small enough initramfs, and was able to get it to boot on the 486. And as expected Linux has no problem with seeing that the drive is connected and the drive’s full capacity. Next step is to actually get Linux installed to the hard drive. I’d rather not roll my own distro but maybe I’ll have to. Another possibility is to boot Linux from floppy and then download a kernel and initrd from a current distro and kexec over to it. But that feels to me like reinventing iPXE. That’s version 5.8 of the Linux kernel running on a 486. I shouldn’t be surprised that this is possible, yet I’m still surprised this is possible.
To meet our customers where they are and relieve customer challenges in managing multiple security solutions to protect their unique range of platforms and products, we have been working to extend the richness of Microsoft Defender ATP to non-Windows platforms. Today we are excited to announce general availability of Microsoft Defender Advanced Threat Protection (ATP) for Linux! Adding Linux into the existing selection of natively supported platforms by Microsoft Defender ATP marks an important moment for all our customers. It makes Microsoft Defender Security Center a truly unified surface for monitoring and managing security of the full spectrum of desktop and server platforms that are common across enterprise environments (Windows, Windows Server, macOS, and Linux). Defender ATP is an enterprise product, so this news doesn’t mean the end-user program that ships with Windows is coming to Linux. Still, seeing Microsoft embracing Linux left, right, and centre is still a weird sight for someone who still hasn’t forgiven Microsoft for their role in killing any chances of BeOS catching on. I’m still bitter over that one.
A few weeks ago, we talked about how Ubuntu is forcing snap packages on users, even when using apt. Since various distributions are based on Ubuntu, a lot of users of those distributions are wondering if snaps will infect their systems, too. One of the most popular Ubuntu-based distributions, Linux Mint, has a clear answer. First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed. Second, to address this situation we’ll do exactly what we said we would: • In Linux Mint 20, Chromium won’t be an empty package which installs snapd behind your back. It will be an empty package which tells you why it’s empty and tells you where to look to get Chromium yourself.• In Linux Mint 20, APT will forbid snapd from getting installed. You’ll still be able to install it yourself and we’ll document this in the release notes, but by default APT won’t allow repository packages from doing this on your behalf. This is good news, and the right route to take.
As far as Linux 5.7 goes there are many new features and improvements like an Apple USB “Fast Charge” driver, Intel Tiger Lake “Gen12” graphics are now deemed stable and promoted out of the experimental flag, AMD Renoir graphics are in good shape, F2FS Zstd support, Qualcomm Snapdragon 865 support on this mainline kernel, and a lot more. You can of course build the new kernel yourself, but it’ll make its way to your distribution of choice soon enough.
10 years ago, systemd was announced and swiftly rose to become one of the most persistently controversial and polarizing pieces of software in recent history, and especially in the GNU/Linux world. The quality and nature of debate has not improved in the least from the major flame wars around 2012-2014, and systemd still remains poorly understood and understudied from both a technical and social level despite paradoxically having disproportionate levels of attention focused on it. I am writing this essay both for my own solace, so I can finally lay it to rest, but also with the hopes that my analysis can provide some context to what has been a decade-long farce, and not, as in Benno Rice’s now famous characterization, tragedy. The end of this massive article posits a very interesting question. What init system does Chrome OS use? And Android? Do you know, without looking it up? Probably not. What does that tell you?
When the parts were almost in, I had decided to really start digging into NixOS. Friends on IRC and Discord had been trying to get me to use it for years, and I was really impressed with a simple setup that I had in a virtual machine. So I decided to jump head-first down that rabbit hole, and I’m honestly really glad I did. NixOS is built on a more functional approach to package management called Nix. Parts of the configuration can be easily broken off into modules that can be reused across machines in a deployment. If Ansible or other tools like it let you customize an existing Linux distribution to meet your needs, NixOS allows you to craft your own Linux distribution around your needs. Unfortunately, the Nix and NixOS documentation is a bit more dense than most other Linux programs/distributions are, and it’s a bit easy to get lost in it. I’m going to attempt to explain a lot of the guiding principles behind Nix and NixOS and how they fit into how I use NixOS on my desktop. I’m hearing more and more people talk about NixOS lately, and I’ve been wondering why. This article is an excellent overview into this unusual Linux distribution.
The Linux kernel lockdown patches were merged into the 5.4 kernel last year, which means they’re now part of multiple distributions. For me this was a 7-year journey, which means it’s easy to forget that others aren’t as invested in the code as I am. Here’s what these patches are intended to achieve, why they’re implemented in the current form and what people should take into account when deploying the feature. Root is a user – a privileged user, but nevertheless a user. Root is not identical to the kernel. Processes running as root still can’t dereference addresses that belong to the kernel, are still subject to the whims of the scheduler and so on. But historically that boundary has been very porous. Various interfaces make it straightforward for root to modify kernel code (such as loading modules or using /dev/mem), while others make it less straightforward (being able to load new ACPI tables that can cause the ACPI interpreter to overwrite the kernel, for instance). In the past that wasn’t seen as a significant issue, since there were no widely deployed mechanisms for verifying the integrity of the kernel in the first place. But once UEFI secure boot became widely deployed, this was a problem. If you verify your boot chain but allow root to modify that kernel, the benefits of the verified boot chain are significantly reduced. Even if root can’t modify the on-disk kernel, root can just hot-patch the kernel and then make this persistent by dropping a binary that repeats the process on system boot. These patches are intended to prevent that, and this blog post goes into detail about how it all works.
Intel’s Dynamic Platform and Thermal Framework (DPTF) is a feature that’s becoming increasingly common on highly portable Intel-based devices. The adaptive policy it implements is based around the idea that thermal management of a system is becoming increasingly complicated – the appropriate set of cooling constraints to place on a system may differ based on a whole bunch of criteria (eg, if a tablet is being held vertically rather than lying on a table, it’s probably going to be able to dissipate heat more effectively, so you should impose different constraints). One way of providing these criteria to the OS is to embed them in the system firmware, allowing an OS-level agent to read that and then incorporate OS-level knowledge into a final policy decision. Unfortunately, while Intel have released some amount of support for DPTF on Linux, they haven’t included support for the adaptive policy. And even more annoyingly, many modern laptops run in a heavily conservative thermal state if the OS doesn’t support the adaptive policy, meaning that the CPU throttles down extremely quickly and the laptop runs excessively slowly. It’s been a while since I really got stuck into a laptop reverse engineering project, and I don’t have much else to do right now, so I’ve been working on this. It’s been a combination of examining what source Intel have released, reverse engineering the Windows code and staring hard at hex dumps until they made some sort of sense. Here’s where I am. Someone has to do the dirty work.
I guess current world events are starting to affect the flow of news in our sector, too, since there’s a decided lack of interesting stuff to talk about. So, let’s talk about this: One of the immediate differences Ubuntu 20.04 desktop/laptop users will notice when booting in UEFI mode is the boot splash screen improvements thanks to leveraging Red Hat’s work on providing a flicker-free boot experience and pulling in the UEFI BGRT system/motherboard logo during the boot process to provide a more transitive experience. Canonical in turn is working on pushing some of their improvements back into upstream Plymouth. The Ubuntu 20.04 LTS boot experience is on-par to what has been found in Fedora and other Linux distributions like Arch Linux for over one year. I love it when different distributions and other projects work together to improve something that isn’t particularly sexy or high on anybody’s agenda, yet still is a welcome improvement. This is a great example of that.
Earlier this evening, Linus released Linux 5.6, which contains our first release of WireGuard. This is quite exciting. It means that kernels from here on out will have WireGuard built-in by default. And for those of you who were scared away prior by the “dOnT uSe tHiS k0de!!1!” warnings everywhere, you now have something more stable to work with. The last several weeks of 5.6 development and stabilization have been exciting, with our codebase undergoing a quick security audit, and some real headway in terms of getting into distributions. WireGuard is probably the biggest new feature in 5.6, announced earlier today.
Ars Technica reports on a story from the early 2000s 2020: When software and operating system giant Microsoft announced its support for inclusion of the exFAT filesystem directly into the Linux kernel back in August, it didn’t get a ton of press coverage. But filesystem vendor Paragon Software clearly noticed this month’s merge of the Microsoft-approved, largely Samsung-authored version of exFAT into the VFS for-next repository, which will in turn merge into Linux 5.7—and Paragon doesn’t seem happy about it. Yesterday, Paragon issued a press release about European gateway-modem vendor Sagemcom adopting its version of exFAT into an upcoming series of Linux-based routers. Unfortunately, it chose to preface the announcement with a stream of FUD (Fear, Uncertainty, and Doubt) that wouldn’t have looked out of place on Steve Ballmer’s letterhead in the 1990s. This is some “get the facts” level of tripe. You’d think that in 2020, we’d be spared this sort of nonsense, and I’m sad I’m even spending precious bits on this one – but at least we get the name of Paragon out so you can avoid them like the plague.
For those managing to get their hands on a recently released Loongson 3A4000/3B4000 or even older Loongson 3 MIPS64 processors, improving the support is on the way with the upcoming Linux 5.7 kernel. Queued as part of the MIPS architecture work for Linux 5.7 are a number of Loongson improvements, in particular for the Loongson 3 series. The Loongson processors are pretty much impossible to come by outside of China, and gained some fame as the platform of choice for Richard Stallman.
In the previous installment of this three-part series, we took a look at the reasons why having truly open source-friendly Linux-based phones are not only a good thing to have but are also necessary to shake up things in the mobile space. The idea, of course, isn’t new and goes as far back as the OpenMoko community-driven project and even the mostly-but-not-totally open source Nokia N900 and N9. Those days are long gone, however, and the smartphone industry has changed drastically over the last decade and so have the attempts at making Linux phones. In this part, we take stock of the options that are currently available not just to Linux enthusiasts but to privacy and freedom-loving people as well. I’d love to have a mobile operating system based on Linux that isn’t Android, but it seems like all the options still have a long, long way to go.
We’ve known that Intel’s P-State Linux CPU frequency scaling driver in general can be a bit quirky and especially so when dealing with Intel integrated graphics where the iGPU and CPU share the same power envelope. This has been shown with examples like using the “powersave” governor to boost iGPU performance while discrete graphics owners are generally best off switching over to the “performance” governor. As the latest though on helping the iGPU front with P-State, there is a new patch series talking up big gains in performance and power efficiency. Francisco Jerez of Intel’s open-source driver team sent out a set of ten patches today working on GPU-bound efficiency improvements for the Intel P-State driver. This is a very welcome patchset, since the interplay between Intel processor and Intel integrated GPU isn’t exactly optimal, as we’ve talked about before.
Admittedly it’s been while since I last wrote about this (formerly MATE-based) desktop environment, but it’s still out there, shipping as default experience in Ubuntu Kylin, doing its thing. But not for much longer, it seems. Based on an updated shared on Chinese social media, the UKUI team appear to be rebuilding UKUI using Qt. The plan, they say, is to stick to to the same “easy, excellent, expert, elaborate” mantra that the original UKUI desktop was (supposedly) built to. I’m highlighting this here because there’s a ton of interesting Linux desktop work going on in China that we in the west rarely talk about, such as Deepin and its Qt-based Deepin Desktop Environment that’s also available on some other distributions. UKUI fits in that same bucket. There’s, of course, legitimate concerns over code from China, but since these projects are open source, it would seem there’s little to worry about on that front. The fact of the matter is that, totalitarian dictatorship or not, Chinese people are just regular folks, and many of them are probably excellent programmers and designers that can contribute a lot to the health, variety, and competition within the desktop Linux and wider open source community.
Many older VPN offerings are “way too huge and complex, and it’s basically impossible to overview and verify if they are secure or not,” says Jan Jonsson, CEO of VPN service provider Mullvad, which powers Firefox maker Mozilla’s new VPN service. That explains some of the excitement around WireGuard, an open source VPN software and protocol that will soon be part of the Linux kernel—the heart of the open source operating system that powers everything from web servers to Android phones to cars. I’ve always been wary of the countless VPN services littering YouTube and podcast sponsor slots, since you can never be quite sure if you can trust them. Luckily I don’t need a VPN, but I’m glad Linux is getting it built-in.
Don’t use ZFS. It’s that simple. It was always more of a buzzword than anything else, I feel, and the licensing issues just make it a non-starter for me. The benchmarks I’ve seen do not make ZFS look all that great. And as far as I can tell, it has no real maintenance behind it either any more, so from a long-term stability standpoint, why would you ever want to use it in the first place? ZFS could be the fastest file system in the world and randomly disperse kittens and I still wouldn’t touch it with a ten metre pole if I were Linus. Oracle is a colony of snakes led by the biggest snake of them all, and adding their code – even through shims or interfaces – should be a complete non-starter for any project.
A little over a month ago I wrote about an issue I was having in Linux, where playing a video would cause processor usage to skyrocket, and hence, increase the heat output considerably, causing the fans in my laptop to spin up loudly. This behaviour was Linux-specific, as it didn’t happen when using the same laptop in Windows. I experienced the problem on KDE Neon and the latest KDE release and on Linux Mint running Cinnamon. After publication of the article, and at the suggestion of lakerssuperman2, I tried the latest release of Ubuntu running GNOME, but there, too, I experienced the problem. Many other readers were quite helpful in trying to get the problem fixed – or at least diagnosed – but I wasn’t getting anywhere. Until just-me pointed something out: I have the same laptop. I watch YouTube daily and don’t remember the fans ever kicking in for that. But I just noticed that you have the 4K screen (my model has the FHD screen – by choice) – so that might explain the difference. This turned out to be an interesting avenue of investigation. I had considered the resolution of my display as a possible culprit before, but disregarded it since I couldn’t imagine the difference between 1080p and 4K having any meaningful impact. After some fiddling with my settings, however, I concluded that while the resolution indeed was not the problem – something related to it was: user interface scaling. As soon as I turned off 200% scaling and set it to 100% – making the user interface near-unusably small in the process – the problem disappeared entirely. Finally, after years of fighting this problem, I seemed to have nailed the cause, with the help of the OSNews readership (thank you!). I couldn’t believe it looked like it was something as simple as UI scaling. Of course, running 4K at 100% scaling on a 13″ display is not exactly ideal, so I set to experiment with different combinations of resolutions and scaling factors to pinpoint if certain combinations were more or less problematic than others. Running a quick command to enable fractional scaling (gsettings set org.gnome.mutter experimental-features "") to give me access to 125%, 150%, and 175% scaling factors, I discovered that setting the factor to anything but 100% would cause the problem. I eventually settled on a decent middle ground of 2048×1152 at 100% scaling, with the UI fonts set to 11. Of course, this doesn’t make optimal use of a 4K display, but things look great and crisp, correctly sized, and completely usable. But most importantly, temperatures and processor usage is now effectively on par with Windows. This means that there is an issue somewhere with how scaling seems to be implemented in either X.org, the Intel driver, the Mutter/Kwin window managers, or any combination thereof. Since both Mutter and Kwin seem to have the problem, my gut feeling is that there’s an issue somewhere in the Intel driver or in how the driver interacts with X.org (as a side note, I tried running Ubuntu with Wayland and GNOME, but performance as a whole seemed problematic there). Ever since, I’ve been running Linux on my XPS 13 without any issues, the fans never even turn on, temperatures remain well within expected values, and I have no more issues playing videos. Thanks to you, OSNews readers, I’ve been able to solve – or at least, circumvent – an issue that has been frustrating me for a long, long time.
I like using Linux. I use it on my desktop – especially now that League of Legends runs incredibly well on Linux thanks to the Lutris and League of Linux reddit community. I’d also like to use Linux on my laptop (an XPS 13 9370), but here I run into a major hurdle that despite a lot of trials and tribulations, I have been unable to overcome: playing video. Of course, Linux – in my case, Linux Mint – can play any format under the sun just fine, either locally, on-demand, or streaming, and in my case, it’s YouTube video that matters (720p-1080p). The problem lies not in what desktop Linux can play, but in how it does so. Decoding video on my laptop running Linux is apparently remarkably inefficient, to the point where the processor reaches temperatures of 60-70°C, and since the fan kicks in at around 60°C, watching video on Linux means constant fan noise. When playing the same videos on Windows on the exact same laptop, temperatures stay comfortably below 40°C, without ever even coming close to spinning up a fan. I have tried everything. Here’s an itemised list of things I’ve tried, including multiple different combinations: I’ve installed tlp. This has had no effect. I’ve manually configured my processor – through tlp – to make sure it doesn’t turbo beyond 50%. This has had no effect. I’ve disabled Intel Turbo Boost in UEFI altogether. This has had no effect. I’ve undervolted my CPU. This gives me maybe 1-2 degrees every now and then, so effectively it hasn’t helped. I’ve tried the latest mainline kernel just to see if there’s been improvements in power management or any Intel drivers. This has had no effect. I’ve tried the Chromium builds with VAAPI support to enable hardware acceleration on YouTube video. This has had no effect. I’ve tried downloading YouTube videos with youtube-dl and playing them back locally. This has had no effect. I’ve tried forcing H264 on YouTube. This has had no effect. There’s probably things I’ve tried that I’ve forgotten about and thus aren’t on this list. As you can imagine, my past few days and weeks have been frustrating, to say the least. I even decided to install Linux Mint on my Surface Pro 4 to see if similar problems pop-up there, and lo and behold, that device, too, sees massive temperature spikes when using Linux instead of Windows. I understand and can accept if Linux isn’t as efficient as Windows when it comes to power management and decoding video, and am okay with a few degrees here and there. However, I just cannot understand nor accept a 20-30°C difference with something as elemental as decoding video. After all of this, I can only conclude that desktop Linux has an incredibly bad video decoding pipeline compared to Windows, and considering I’ve been struggling with this several times over the past few years without any noticeable improvement, it seems like it’s not something high on anybody’s list of things to improve. Linux’ inefficient video decoding pipeline won’t be much of an issue on desktop machines – playing video has virtually no material temperature impact on my desktop since my custom watercooled GTX 1070 and i7-7700K are way overkill – but on thermally constrained laptops, the problem becomes massively apparent. It is frustrating. I prefer Linux over Windows, I want to use it on my laptop, but as it stands now, I simply can’t. I’m at my wits’ end.
I recently found some USB devices on eBay (Epiphan VGA2USB LR) that could take VGA as input and present the output as a webcam. Given that I was keen on the idea of not needing to lug out a VGA monitor ever again and there was claimed Linux support I took the risk and bought the whole job lot for about £20 (25 USD). When they arrived, I plugged one in under the expectation that it would come up as USB UVC Devices but they did not. Was I missing something? Turns out that he was, and that was the start of a rather wild ride.