Linux Archive

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.

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.

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.

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.

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.

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.

We are especially proud to present you Tails 4.0, the first version of Tails based on Debian 10 (Buster). It brings new versions of most of the software included in Tails and some important usability and performance improvements. Tails 4.0 introduces more changes than any other version since years. The list of changes is indeed quite long, and note that it contains quite a number of security fixes too, so you should update as quickly as possible.

The desktop environment that turns your Samsung phone or tablet into a PC when connected to an external display, nicknamed ‘DeX,’ has been around for a while now. Nearly a year ago, Samsung introduced the Linux on DeX beta, which could run a full Linux OS on top of DeX. Sadly, the project seems to have been discontinued. Samsung is sending out an email to testers explaining that the beta program has ended, and that Linux on DeX will not be supported on devices running Android 10. That’s definitely a bit of a shame. While I haven’t yet tried Dex on my brand new Note 10+, the idea of messing around with a full Linux distribution running on my phone was a neat and interesting concept.