Ubuntu just announced on their forum that they're shipping a kernel that can make certain AMD workloads up to 42 times slower. Linus Torvalds is drawing clearer boundaries around AI-generated code in the Linux kernel. Secure Boot just passed a major certificate expiration deadline. We'll talk about what that means. Cosmic Desktop 1.3 is out, and it brings a polished new frosted glass design, which looks pretty slick. And you know how I like to say that Linux is everywhere? Well, one developer decided to add another place to the list, and that's a Sega Genesis from 1994. All of this and more on This Week in Linux. Now let's jump right into your source for Linux good news. Ubuntu plans to ship a kernel update where they already know it can make one AMD workload about 42 times slower. So one kernel update turned nine seconds into six minutes. on the bright side that means you have an extra time to make another cup of coffee but overall it's really not that bad actually the impact is not as bad as it sounds the issue is in the ubuntu kernel 7.0.0-28.28 and that just rolls right off the tongue and this is affecting 2604 and 2404 users who are on the hardware enablement stack or the hwe stack and this also only affects people who are using AMD GPUs, but more importantly, those users who are running compute-heavy ROCKM workloads, especially stable diffusion XL image generation through Comfy UI. Now, this is not exclusive to Ubuntu either. Any distro that has 7.0.12 could be affected by this. One report shows how specific this can be. On an RX 6950 XT, SDXL took 9.14 seconds with kernel 7.0.11 and 388 seconds with kernel 7.0.12. In the same test with the smaller SD 1.5 model, it stayed close to normal. And this was found using Fedora 44, although since this report was made, Fedora has already updated the kernel with a fix, so it isn't part of the news as it was found and already fixed. This is an issue with Ubuntu because they're using an older kernel based on the 7.0 series that was released in the LTS release. The bug is in AMD GPU's shared memory path. A retry loop could spin for about a second with no chance to succeed, adding delay each time that memory operation returned. It's kind of like the software coding version of getting to an elevator, seeing the button was already pressed, and then pressing it again, as if that somehow makes it arrive faster. You know you've done it. You know you've done it. Anyway, there is a fix for this. The fix removes that loop and is already in upstream Linux 7.0.13. Ubuntu's timing means their kernel update will arrive with the issue, but they are shipping it anyway because it carries critical security fixes. The corrected code is queued for the next update in Ubuntu. Ubuntu recommends that affected ROKM users stay on their current kernel until the next update is available, or drink more coffee or switch to tea because that usually takes longer to make. To be clear, that's not from the Ubuntu kernel team. They didn't say that. I said that the coffee and TR turnovers are for me. I'm just trying to be helpful. Now, this is unfortunate, but I do think Canonical handled this warning pretty well. The team identified the users most likely to be noticing this, explained why the security update is moving forward, and already has a fix lined up. So yeah, if you see the 42 times performance loss in a headline somewhere, technically that's true, but it's a very specific use case. And if you have AMD, it doesn't mean you're gonna have an issue with this. if you don't run AI workloads, you're probably fine. Although speaking of AI workloads, Linus Torvalds made his voice heard on the AI code debate in the kernel mailing list. A couple of years ago, Linus Torvalds called AI 90% marketing, but that was a couple of years ago, and today things have changed. There's been a debate about AI in the Linux kernel recently, and Linus has stepped in to address it in a very Linus kind of way. The argument started on a Linux kernel mailing lists around Shashiko, an agentic system that reviews proposed kernel changes with LLMs. One developer suggested maintainers should triage and verify Shashiko's reviews before passing them to patch authors. Another warned that extra gatekeeping could defeat the total purpose of the tool, which would be helping maintainers. And others have expressed opinions about, you know, being anti-AI in general. So Linus stepped in with a very Linus kind of answer. He said that Linux is not anti-AI. He called AI a useful tool and told people who strongly disagree that they can fork it or just walk away. That, my friends, is a conflict resolution with the subtlety of a sledgehammer. And I respect it. Whether you like AI or not, clarity is kind of rare these days, so nice to have clarity. Of course, using AI is optional. It's not a mandate or anything. Linus acknowledged that these tools can create extra work and unverified reports while also finding bugs that humans missed there's pros and cons here he sees these as tools that can help maintainers and dismissing them outright is like turning your nose up at other tools like compilers that also help maintainers and have for many many years and this is not really a new thing from linus he said things like similar at the open source summit back in may in his keynote when the subject of AI came up I was in attendance of that keynote by the way Not relevant but I was so I wanted to tell you The kernel already has rules for AI code, too. AI-assisted contributions must follow the normal development process and Linux licensing rules. An AI agent cannot add a signed-off-by tag. A human must review the code, certify it, and take full responsibility for it. Contributors should also disclose the tool and model with an assisted by tag. Although there is some debate around the assisted by tag because apparently some AI companies are trying to use that as promotion. So that might change, but we'll see. So the Linux team will judge AI-assisted work with whether the patch is correct, reviewed, licensed properly, and worth merging. So the code will not be just AI slop despite what you might have heard. In fact, let me just say that not everything AI produces is slop. We are way past the Will Smith eating spaghetti days. Vibe coding is not a blanket term describing all use of AI to make code either. Vibe coding is a term that describes someone who uses AI to generate code and doesn't understand that code. They trust it blindly because they don't know any better. They don't know how to write code, so they just can't review it or anything like that. So they just rely on it, like on the vibes, hoping it's good. That's vibe coding. That's AI slob. A developer who works on the Linux kernel, I'm willing to bet that they know how to code. And if they used AI to generate code, then they can review it, correct it, certify it, and whatever. That's far from VibeCoding and far from AI slop. Okay, sure, AI is not perfect, and using it does mean that a person needs to be involved. I mean, you can't just put in a prompt and hope for the best. But using it responsibly, that should be fine. So there's a situation related to Secure Boot and Linux with certificate expiration. A certificate used to start Linux systems expired in June, and computers kept booting like nothing happened. Secure Boot checks whether early boot software is signed by a trusted certificate and absent from its block list. Most Linux distributions use a small program called a shim as the trusted step before grub and the kernel. Microsoft's UEFI CA 2011 certificate used to sign Linux shims expired on June 27th of this year. Existing shims keep working because UEFI checks trust and revocation instead of the date printed on the certificate. Secure Boot is kind of like a bouncer checking the guest list, but then their buddy shows up and they're like, come on in, man. Future updates create the real pressure, though. Microsoft now signs new shims with its 2023 certificate. A computer that lacks that certificate may reject a future Linux installer or shim update. Although there is the option to like fire the bouncer and just turn off secure boot. But the real question there is, should you turn it off? And that's kind of nuanced because there's pros and cons to secure boot. Let me know if you want me to make a video about that in the comments. Now, distros are preparing. AlmaLinux says their current x86-64 shim carries both the 2011 and the 2023 signatures. Debian 13.6 was released this week, includes FWUPD or FWPD 2.0.20, which can update the certificate authority, key exchange key, and DBX revocation list. That DBX update also addresses a separate problem because many old vulnerable shim versions remained trusted. An attacker with administrative access or control of the boot process could use one to bypass secure boot and run code before Linux starts. Revoking those binaries finally checks some very old names off the guest list. I think this is interesting because it kind of shows why security maintenance can feel backwards at times. A expired certificate can remain trusted while a signed old program can be unsafe. Oh, technology. Most users on maintained hardware and distributions should receive the needed updates through their vendor or FWAPD. If you have older machines or running virtual machines, you might want to take a closer look. System 76 gave Cosmic a major visual upgrade, and the best part is that you can control exactly how much of it you see. Cosmic 1.3 introduces Frosted Glass, a blurred translucent style for panels, applets, menus, and supported app surfaces. You can adjust it from being super subtle and basically being nearly see-through or almost opaque under Settings, Desktop, Appearance, and Frosted Glass. I think it looks pretty slick. And it also kind of lets you kind of like have a personality with the wallpaper inside of your system more because a lot of times people are hiding things with their windows. You don't even get to see the wallpaper. And this makes it much more easy to see this stuff because, you know, it's translucent. And in some cases, almost see-through. But it also doesn't do it so much that it turns everything into like a reading test for the windows. Why frosted glass, you might be asking? Well, I think it's because glass is a solid and a frosted effect makes sense. Liquid glass. Now that's just nonsense. This effect took months of work across the Cosmic desktop stack. Third-party Cosmic apps also need a newer Lib Cosmic library before they can support it, so the look may vary between apps at first. And version 1.3 also adds useful hardware details. Cosmic System Monitor can estimate power use for AMD and Intel GPUs, show GPU power and total VRAM and track memory use on Intel graphics And also NVIDIA support improves GPU suspension Panels can now remain fully hidden or keep their chosen style when a window is maximized. AVIF images work as wallpapers now. Applet pop-ups should animate more smoothly, and known Bluetooth devices now appear in the applet. The compositor fixes texture corruption on multiple GPU computers. There's improvements to full-screen window stacking, magnification, minimized window sizing, pointer themes, and more. Cosmic has come a long way with this release, and some reports are saying it is ready for production, and others are cautioning against it. But I haven't tried it yet, so I don't really know. But I will say that I do think this frosted glass effect looks pretty slick. App images have been around for years, and they are a convenient way to download an app from a developer's website, like you would an .exe file for Windows or a .dmg file for Mac. And yet app images don't really have an official management system. So they can be files that you downloaded and forgot where you put them, or maybe you never just take them out of your downloads folder. Plus the official instructions for installing them, while technically universal, is not the user-friendliest approach. Or you can, I guess, you can do the file management system, like the file manager structure, where you right-click an app image in your file manager and then edit the permissions in the properties window and that sort of thing. But still, that's not very user-friendly because they don't even tell you that on their website that you can do that. So you just kind of have to Jedi your way through it with the force, I guess. So let's talk about App Manager. App Manager turns that into the drag and drop applications flow many people know from macOS. Double click an app image and App Manager opens a small window with the app icon and an applications folder. Drag it across and App Manager moves the file into the slash applications folder in your home folder. It creates a desktop launcher, copies the icon, and adds the app to your menu. So your app images finally have a home in your slash home folder. App Manager also handles the chores app images leave to the user. So one of the things that kind of irritates me about app images is that for updates, some app images work with letting you know there's an update available when you open it, but also some don't, and you just have to manually go and check yourself, which is kind of a bummer. where app manager will do this, like check for the updates in the background, but also a lot more. It can import a folder full of app images. You can use a smaller Z-Sync Delta updates when supported. So that's like, instead of installing and downloading a new app image every single time there's an update, it can get bits and pieces in transactional style. And that's much better. Also, you can keep app data beside the file in a portable mode. You can install versions side by side and extract an app for faster startup. App Manager uses U Runtime, which can mount an app image or extract and run it without relying on the older Fuse 2 package. Many applications still expect the Fuse 2 package, so this is outstanding because many distros have migrated to Fuse 3 and dropped Fuse 2 support by default, so some app images just won't load on those distros that have made the transition to Fuse 3. Unfortunately, app images are not integrated into the system by design, So if you are on a distro with Fuse 2 and run a Fuse 2 app image, then well, just nothing happens. No error, no warning, just nothing. So I really like the fact that it uses the U Runtime project because making that possible to use app images without having to worry about Fuse 2 and Fuse 3 is really nice. And App Manager looks really good. I like the fact that it keeps the portable nature of app images while also adding parts that are usually missed by people like management and simplifying the process of installing and setting it up and that sort of thing. especially for those who are switching from Mac, since it's just how they expect with a very nice touch of being able to drag into the applications folder and that sort of thing. I really like that part. So if you use App Images and you liked a nice clean experience of how to use them and manage them, then check out App Manager. FreeBSD have removed all GPL code from its base system. So FreeBSD is now GPL free, but GPL software is still welcome through FreeBSD's ports and packages. The base system is the kernel and core user line components. and there wasn't much GPL code left for quite some time. The final holdout was Dialog, the terminal tool behind text boxes, menus, and progress screens, which was licensed under LGPL. FreeBSD's installer moved to the BSD-licensed BSD Dialog about four years ago. The last package using it was DPV, and it had already been disconnected for more than two years, but on July 7th, developers removed Dialog, DPV, LibDPV, and LibFigPAR, and then retired the now empty GNU directory. FreeBSD's official policy aims for complete BSD licensed operating system. The BSD license lets developers reuse the code in open or proprietary products. The GPL uses copyleft to add sharing requirements when covered code is redistributed. Both support software freedom through different rules, which means a single tiny terminal window can start a full-size licensing debate. You know, GPL versus BSD. Personally, I prefer the GPL in terms of requiring the sharing of the code, but you know. The change only covers the base system plan for FreeBSD 16 currently expected in 2027 December But even after that users can keep installing GPL and LGPL applications from the ports That's not all, FreeBSD is pairing that with a bunch of hardware work. Its laptop project is targeting eight hours of active use, modern standby, hybrid core scheduling, newer Linux DRM graphics code, and Wi-Fi 6 through Intel, Realtek, and MediaTek drivers. A KDE desktop option is also being built into the installer with Nvidia users having an option to select drivers for their hardware. Plus they are working toward basic AMD Rock'em compute support. This is a long-term FreeBSD design goal reaching the finish line while the system keeps adding new capabilities. And we talk about FreeBSD because I think FreeBSD is a really interesting project. It's not Linux based, but that's okay because it is interesting. And if you like this kind of thing, be sure to subscribe because I will continue to talk about FreeBSD because a lot of people seem to appreciate this coverage. So let me know if you think so too in the comments below. This episode, I wanted to try something new. I wanted to do like some kind of lightning round where we do a bunch of rapid fire topics that might not be able to fit into the show like because we don't have enough space and that sort of thing. But I wanted to cover them on the show anyway. So let's do that. We're going to through four topics, just rapid fire and see how it goes. First up, we're gonna talk about StillOS with 10.2. StillOS 10.2 is focused on making Linux easier from the moment installation ends. It updates key desktop parts to GNOME 49, adds a more useful first boot guide, and can automatically install hardware drivers, including NVIDIA, from one common image. Their SwayEye, SwayEye, SwayEye, Web App System is now Wayland native. It supports offline apps and media controls and can move between services like Google Drive and Docs without spawning a small army of windows. Steel Control can now edit arc menu and dash to panel layouts, which now makes it a complete solution for customizing GNOME without ever having to touch extension settings yourself. That's a nice touch. With this release, the project's developers are also putting a focus on community building, trying to build an active, welcoming community to help shape what comes next. And fun fact, the developer of SteelOS is Cam, the editor of this show. Blender 5.2 LTS has arrived with two years of fixes and enough new nodes to make a flowchart jealous. Its new node-based physics system gives artists procedural control over hair and cloth, while geometry nodes can now react directly to audio. Blender also adds online asset libraries, a texture cache that can reduce memory use, and major EVE improvements, including twice the speed in scenes packed with instances. Clonezilla Live 3.3-15 updates its rescue toolkit with Debian SID packages from July 5th in the Linux kernel 7.0.14. The release adds a text interface for network manager, reverse connection network cloning, and new tools for converting Clonezilla ISOs to QCal2 and checking NRD modules. It also improves handling for multiple partition disks and fixes incorrect results if Control-C is pressed while saving an NTFS partition. Linux is now running on both the Sega Genesis or Mega Drive and its 32x add-on because apparently 1990s consoles were simply waiting for better operating system support. Linux MD uses a Mega EverDrive's special mapper to give the MegaDrive 4MB of RAM instead of the 256KB of built-in RAM, plus uBoot and an on-screen text-based command line interface. The 32X port goes further by booting Linux across both 23MHz SH2 processors using software synchronization and the original 6800 CPU to help root interrupts. So if you have a Sega Genesis from 1994 with the 32X add-on, you can run Linux on that machine. It's slow, gloriously impractical, impressive, and just, it's just awesome. Thanks for watching this episode of This Week in Linux. If you like what I do here on this show and what we kept up to date with what's going on in the Linux and open source world, then be sure to subscribe. And of course, remember to like that smash button. And if you'd like to support the show and the Tux Digital Network, then consider becoming a patron or a member by going to tuxdigital.com slash membership, where you get a bunch of cool perks, like access to the patron-only section of our Discord server, unedited content, behind-the-scenes content, members-only live streams, hangouts with me on Discord, we do that occasionally, also discounts at the Tux Digital store, and so much more. And speaking of the TuxDigital store, you can also support the show by ordering T-shirts or mugs or whatever from the store. You can check out the Linux is Everywhere shirt or the This Week in Linux shirt. Both of these are available on the store at tuxdigital.com slash store. And while you're there, check out all the other cool stuff we have like hats, mugs, hoodies, and more at tuxdigital.com slash store. I'll see you next time for another episode of Your Source for Linux Canoes. Thanks again for watching. I'm Michael Tunnell. I hope you're doing swell. Be sure to ring notification bell. And until next time, I bid you farewell.
