Linux Archive

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.

As you’d expect, Linux 5.15 includes an impressive itinerary of improvements. These range from small fixes at lower levers through to major restructuring of core functionality. The following roundup highlights the additions that caught my interest/eye but is by no means an exhaustive run-through. The biggest new feature is the new NTFS driver, but there’s a lot more in this release, such as an in-kernel driver for SMB, and more Apple M1 support, to name a few.

A WSL alternative for users who prefer an MS-DOS environment. DOS Subsystem for Linux integrates a real Linux environment into MS-DOS systems, allowing users to make use of both DOS and Linux applications from the DOS command prompt. What is this unholy union.

It’s no secret that the ACPI CPUFreq driver code has at times been less than ideal on recent AMD processors with delivering less than expected performance/behavior with being slow to ramp up to a higher performance state or otherwise coming up short of disabling the power management functionality outright. AMD hasn’t traditionally worked on the Linux CPU frequency scaling code as much as Intel does to their P-State scaling driver and other areas of power management at large. AMD and Valve have been working to improve the performance/power efficiency for modern AMD platforms running on Steam Play (Proton / Wine) and have spearheaded “ was not very performance/power efficiency for modern AMD platforms…a new CPU performance scaling design for AMD platform which has better performance per watt scaling on such as 3D game like Horizon Zero Dawn with VKD3D-Proton on Steam.” Valve has single-handedly made Linux a viable choice for people who play games, and with the Steam Deck on its way, their efforts are only going to ramp up. They’re doing this for their own bottom line, of course, but this is one of those cases where a corporate interest lines up perfectly with a consumer interest.

In this post I’ll try to explain PipeWire in the most simple way possible, to make it accessible to others that want to start following this cool new project but that don’t know where to start. It’s especially important to do this to open the door for more people to join in and follow the current development, which is happening at a fast pace. PipeWire is making its way into the generic Linux desktop market, so now is as good a time as ever to gain a better understanding of what it is and how it works.

A statement from the University of Minnesota Department of Computer Science & Engineering: Leadership in the University of Minnesota Department of Computer Science & Engineering learned today about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel. We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues, if needed. We will report our findings back to the community as soon as practical. This story is crazy. It turns out researchers from the University of Minnesota were intentionally trying to introduce vulnerabilities into the Linux kernel as part of some research study. This was, of course, discovered, and kernel maintainer Greg Kroah-Hartman immediately banned the entire university from submitting any code to the Linux kernel. Replying to the researcher in question, Kroah-Hartman wrote: You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them, and published a paper based on that work. Now you submit a new series of obviously-incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns, and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose, or introduce bugs on purpose. If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. Because of this, I will now have to ban all future contributions from your University and rip out your previous contributions, as they were obviously submitted in bad-faith with the intent to cause problems. This is obviously the only correct course of action, and the swift response by the university is the right one.