cm0002

joined 2 weeks ago
 

Bottles, an open-source software tool built on top of Wine that helps users run Windows applications and games on Linux systems by providing a user-friendly GUI, has just released its latest version, 52.1.

This update introduces a new feature – playtime tracking support. A backend has been added for collecting playtime data, complemented by a minimal frontend that begins exposing those statistics in the UI. For users running games via Bottles, this marks the first step toward native session tracking, eliminating the need for external launchers.

 

On ACPI-enabled systems Linux users can enjoy PCIe M.2 connected peripherals that "just work" without any extra fuss. But for those relying on Device Tree (DT) handling by the kernel, new patches from Qualcomm are working on representing PCIe M.2 connectors within DT files.

 

Valve released a new Proton Experimental update for November 7th with a nice batch of game fixes for Linux / SteamOS and Steam Deck gamers.

Proton Experimental is the main testing area, where fixes and improvements eventually come to numbered versions of Proton. See more in the GamingOnLinux guide to all the Proton versions. Below is everything new in the November 7th update.

 

Ryzen AI Software as AMD's collection of tools and libraries for AI inferencing on AMD Ryzen AI class PCs has Linux support with its newest point release. Though this "early access" Linux support is restricted to registered AMD customers.

Earlier this year we reported on AMD previewing a new Linux runtime stack for Ryzen AI NPUs and built off their AMDXDNA kernel accelerator driver. That now appears to be bundled into the Ryzen AI Software collection, which previously was Windows-only. With the newest Ryzen AI Software 1.6.1 point release the only noted change in the release notes is Linux support:

 

This week something that I know a lot of people have been wanting for a long time was implemented: the ability to limit virtual desktops to only the primary screen! Thanks very much to Kristen McWilliam for this long-awaited feature, which arrives in Plasma 6.6.

But wait, there’s more…

 

In addition to GNOME's Mutter compositor removing its X11 back-end support to focus exclusively on Wayland while keeping around XWayland client support, another notable GNOME change this week was the GTK toolkit adding a "reduced motion" accessibility option

 

The supreme court has issued an emergency order temporarily blocking full Snap food aid payments.

The high court’s order came after the Trump administration asked a federal appeals court on Friday to block a judge’s order that it distribute November’s full monthly food stamp benefits amid a US federal government shutdown.

After that request to block was denied, the Trump administration turned to the supreme court in a further attempt to block the order to fully fund Snap food aid payments.

The application to stay reads: “If forced to transfer funds to Snap to make full November allotments, there is no means for the government to recoup those expenditures – which is quintessential irreparable harm. Once those payments are made, there is every indication that the States will promptly disburse them. And once disbursed, the government will be un-able to recover any funds. Worse, these harms will only compound if the decision below stands.

 
 

I promise this isn't a rant or cry for help; I'm just sharing an interesting observation that the Linux community might appreciate. Please know I'm comfortable and knowledgeable enough to be dangerous on any platform, though I generally prefer Unix/Linux and macOS over Windows. I inherited an obsolete, under-powered MacBook Air (Intel i5, 4G RAM, 128G SSD) and I've been testing virtually every popular distro on it for the last few months. I encountered the same Linux shortcoming across every distro, and I thought some of y'all might find this mildly interesting.

There seems to be an underlying issue running Linux on MacBooks, stemming from the fact that MacBooks require a kernel module with proprietary firmware blobs to support their Broadcom wifi & bluetooth hardware. Now, the Broadcom module is readily available in every standard package manager, but it will never be included in the mainstream kernel since it contains closed source software. For distros with a self-contained installer, this is not a huge problem at first - just download and install the appropriate Broadcom package separately to patch your kernel after installation and you should be good, right?

No. Trouble is the kernel and other packages (but mostly kernel) get updated constantly, seemingly without regard to existing kernel module compatibility. Depending on the distro, that Broadcom package might be weeks or even months behind the latest kernel release. The effect of this is that it's never safe to just run software updates on a MacBook, because you're playing roulette with your wifi hardware every time. Desktops with ethernet are easier to recover from because it's easy to plug in, but for a laptop relying on wifi it's a much bigger hassle when your wifi breaks.

Obviously you can just revert to a prior kernel then pin the working kernel version in place, but held packages like your kernel impact other software as well. Simply running Linux on MacBook hardware generates this ongoing cycle of issues over the proprietary software blobs required for the hardware. Typical designed-for-Windows devices face this issue far less frequently, so the added hurdle for MacBooks feels mostly ignored by the general Linux community.

This makes rolling release distros particularly problematic on MacBooks, which is really a shame. Even an atomic distro like Bazzite (which provides that Broadcom module right out of the box, by the way) breaks a MacBook's wifi sooner or later if you install updates normally. I thought I was clever running Kali Linux for awhile. It runs really nicely on this meager hardware and KDE felt zippier than many other distros. I still had to manually install the Broadcom driver after installation, but with a Debian back-end I was really hoping it would pull delayed enough releases to keep the wifi working... it did not. Kali runs a rolling release based on Debian Testing, which still pulls recent enough kernel updates to break the wifi.

Many Arch-based distros won't even install (btw), because the install images require a working networking stack, relying solely on the kernel's built-in hardware support. I'm certain there are workarounds, but there's no obvious, easy way for casual users to inject the required Broadcom module into the downloaded installer. Sadly, the best long term solution I've found is to just stick to annual, major LTS release distros like Debian Stable where enough time passes after most package updates that my cursed Broadcom module has had sufficient time for the dev to catch up.

Don't get me wrong, I've been running Debian + KDE on my older-but-much-beefier MacBook Pro for years now, and it's been a constant source of pleasure to use. I just thought I'd share a little about the unique challenges of a Linux fan who happens to own some aging Mac hardware. Someone here probably knows an obvious solution to make this far easier for the average user. I'm not begging anyone for help, though I certainly welcome your comments. In any case, I hope you enjoyed this read. Mac hardware would be really nice to run Linux if it weren't for this module annoyance.

Author @DetachablePianist@lemmy.ml

view more: next ›