rpm-ostree currently does not support DKMS, and it's unlikely that'll be implemented anytime soon, if ever. It does support akmods, though, which is the preferred way to build Kernel modules on Fedora. You could ask if the packager can build that way to support the Fedora Atomic editions.

If you need these Kernel modules now, I think your only option would be to build manually from source, but that has the downside of requiring a manual step every time the Kernel is updated.

Edit: there are a few issue reports already: https://github.com/pop-os/system76-dkms/issues/58 https://github.com/pop-os/system76-acpi-dkms/issues/16

@narc0tic_bird@lemm.ee @million@lemmy.world

A fix has already been published to Steam stable on Flathub. Workarounds can be removed now.

The last commit on that repository was 7 years ago, seems unmaintained. I wouldn't recommend using this.

If someone decides to use it anyway, don't use their udev rules. Just install steam-devices or game-devices-udev instead. If you don't have those packages available in your distro, all rules can be found in the git repo https://codeberg.org/fabiscafe/game-devices-udev

You shouldn't use sudo to run powerprofilesctl

you are vulnerable during pairing which is for like a minute.

I said this twice on the PSA: it's hard to tell if your device is in discoverable mode, and it's easy to forget it in that state, or start it accidentally. I've caught my devices accidentally in discoverable mode many times. You could have your PC a whole week in discoverable mode and never notice it, just by having a settings window left open.

It's more risk than most people should take, hence the warning.

Still, if you're comfortable with the risk, you're free to change the config and allow insecure devices.

The patch disabled insecure legacy devices by default, that's the fix to the vulnerability. The PS3 Controller itself is an insecure device, so it is affected.

No support was dropped, the PSA specifically explains how to re-enable support for insecure devices with a simple config change.

This is not "convenient" to anyone. Watch your tone, don't be an AH.

The controller itself is insecure, it doesn't exactly conform to Bluetooth standard. There's no indication Sony ever planned cross-compatibility, the DualShock 3 was made to be used only on the PS3 console, where the lack of authorization supposedly wouldn't be a problem.

Of course, you can still use it on a system where you can accept the risk, as well as on the PS3, or wired. The controllers are not e-waste yet.

Hi, I can answer about the PS3 controller issue. I thought about making a public announcement about this, but I forgot. I'll work on that now and then link to it here, but to sum up the situation: Support for insecure legacy devices is now disabled due to CVE-2023-45866, and that includes the PS3 controller. You can re-enable support, but that will make your PC vulnerable when Bluetooth is in discoverable mode — that's when you're pairing a device; in GNOME that's when you just have the Bluetooth settings open; easy to have on by accident.

I'll explain how to re-enable support in the PSA post. It's a one-liner, but I won't put it here because I think people should be well-informed of the risks before considering it.

Edit: PSA posted at https://lemmy.world/post/11498269

Wayland and X11 are protocols, they are essentially just documentation. You need an implementation to be able to actually run programs on it, called a compositor. People tend to think of X11 as a single software because historically Xorg became dominant as the main implementation of the specification, so most of us have only ever used Xorg (but Xorg is not the only implementation of X11, there are many others). Wayland, as a newer protocol, hasn't undergone such consolidation yet, there are many competing compositors implementing the protocol in their own way. GNOME has one such compositor, and KDE has their own, and there are many others. So it's not about "Desktop Environments" all running over the same compositor, as it was on Linux in the Xorg days. Instead, the Wayland features you get are the ones your choice of compositor has already implemented, and can vary between different compositors.

You should be able to type ç the way I described for all apps, so you could just remove your custom layout. I highly recommend the English (intl., with AltGr dead keys) layout, it's perfect for coding and writing in English. It's a bit more work to write in Portuguese, though, so it took me a while to get used to it, but it's worth it if coding is what you're doing most of the time. In this layout, you must hold AltGr to get the dead keys, otherwise it's a normal English layout.

You can also use two layouts — one for English/coding, one for Portuguese — and the keyboard shortcut Super+Space to switch between them. I always have two layouts setup like this, but I never switch anymore because I just learned to love the English (intl., with AltGr dead keys) layout — and I don't write much Portuguese nowadays.

I'm using GNOME Wayland on Fedora 39 and I don't have the problem you describe. I just go to settings and select my keyboard layouts:

• English (US, intl., with dead keys)
• English (intl., with AltGr dead keys)

And everything just works. I specially like the second one because it doesn't interfere with keybindings in games, which can be a problem in GNOME Wayland.

Oh, I think I get the issue you're having, you can't find the Çç character on the Linux layout 😅 I always have to explain this to people migrating from Windows, it's AltGr+, (right Alt key plus Comma). I like this shortcut better than the Windows layout, but I understand some people might not like it. Unfortunately, I can't answer your question, as I too don't know how to customize the keyboard layout. I just got used to the Linux layout.

Same here! We 100% Linux people don't get a chart, but we know exactly where we stand.

SELinux in Podman works pretty much the same way it works on Docker, so if you are having problems with Podman, you should also be having problems with Docker, so I don't see how that's impeding your migration. You need to be more specific about the issues you're having to get a good answer.

The post by Chris Smart you linked on your comment below is a good start, but everything there also applies to Docker, so if you still didn't know those basics, you shouldn't be able to use Docker on Fedora either.

About your question of how to set it up, use-case is an important consideration, there is no generic answer that covers all use-cases. I've even found out that for some use-cases (like ad-hoc containers), disabling SELinux within the container (with --security-opt=label=disable) seems to be the most secure option. That's what I've done in contr (see this commit message). I've been meaning to blog about that, but never did because I'm in the process of migrating my blog but too lazy to finish it.

I've put a lot of links about SELinux in containers in this issue.

Although that link exists, that's not what is being used by default. [[ is a shell builtin in ash/busybox, so that takes precedence.

On Alpine:

❯ which [[
/usr/bin/[[

❯ command -V [[
[[ is a shell builtin

gog galaxy through wine is not an option...

That's the primary way I install and play GOG games. It's easy to set up using Bottles. Galaxy used to run horribly on Wine, but it has improved recently. I help maintain the Galaxy installer in Bottles, and earlier this year we increased its grade from silver to gold, meaning all functions work with minimal glitches now.

It isn't perfect yet, it lags for about a minute right after launch, and I'd recommend going into settings and disabling the "Cloud saves" and "Overlay" features as these can cause crashes sometimes. Other than that, everything works well and performance is good.

If you have read it, you might have noticed that the theme of the article is a company called Chainguard. Enterprises can pay them and get a secure software supply chain all the way down to the container image. More than that, their container distro is actually free and open-source, anyone can use it for free, it's a one line change in your build script to go from Alpine to Wolfi. Enterprises can also buy a secure OS for bare-metal from Red Hat, SUSE, etc...

This article lacks focus and mixes unrelated security concepts in questionable ways. It ends like just an ad for Wolfi. Don't get me wrong, Wolfi is neat, it's probably deserving of being talked up. But it doesn't solve the supply-chain issues pointed out by the article (it doesn't even try). Supply-chain attacks are currently not a major issue in Linux distributions, and enterprises are already tackling the issue of provenance elsewhere, and the article itself notes that. Dependency management for enterprise software is NOT the responsibility of Linux distros. So what is the point of the article? To me, this article is security mumble jumbo.

I believe the platform power profiles are standard nowadays and coded in the bios, so Linux should have access to them just like Windows does. You can use the powerprofilesctl command to list and change power profiles. Gnome also has a Power Mode switcher on the top menu, it's the same thing.

I can talk of my experience with the 2021 Asus ROG Strix G15, I have 3 power profiles:

• performance: Power limits to max; Aggressive fan curve with speed limit to max. Generally loud fans. I need this to play demanding games in the summer.
• balanced: Power limits to max; Moderate fan curve with a medium limit. Great perf (under sane ambient temp), while not too loud.
• power-saver: Lowered power limits; Quiet fans.

Those seem to correlate exactly with the power profiles in Armoury Crate: Turbo, Balanced and Silent respectively. I don't think there's any performance being left on the table.

Gaming laptops with AMD CPU + AMD dGPU are a great suit for Linux gaming.

Also, AMD GPUs benefit a lot from undervolting, which is safe to do. It's free performance. I've made a simple systemd service to keep the undervolt always active: https://codeberg.org/jntesteves/amdgpu-tune

Thanks for the report. This issue was supposed to have been fixed in the Flatpak package, but you just brought to my attention that part of the fix was accidentally reverted. I'm sending a new PR right now to try to fix the issue again.

Here's the update, I've got the USB-C/HDMI adapter today. Connected it to the port that connects directly to the dGPU and even during boot Plymouth was already outputting video to the TV. I also tested hot-plugging and it just works as expected.

Now for the problems, I ran benchmarks and the performance was as expected, but frame delivery didn't look as good as when using the HDMI port on this device. It doesn't show on the performance metrics, but looking at the screen, the frametimes looked off, stuttering. I'm still figuring out where the issue might be to report it to upstream. EDIT: For people reading this in the future, I've found the issue to be in GNOME's compositor, Mutter: https://gitlab.gnome.org/GNOME/mutter/-/issues/3070#note_1865351