I don’t remember how exactly this happened, but killswitch option in Linux ProtonVPN client somehow got broken in a way that I couldn’t connect to internet at all because killswitch was activated and couldn’t disable killswitch at the same time, I had to create another user and remove previous one. It also bombarded me with some errors regarding “kdewallet” that I don’t understand. Worth noting, I’ve been using this client with killswitch on many Gnome distros before and never had this issue anywhere else.

FWIW, the thing with killswitch it not due to Bazzite, nor KDE. There’s a f*ck load of user reports all over the internet with different systems that have experienced the same thing; e.g. this one by a GNOME user on Pop!_OS. As for your criticism on kdewallet, I was also bothered by it the last few times I engaged with KDE Plasma. I suppose I was doing something wrong. Regardless, it was an unpleasant experience.

Immutable structure creates difficulties for customization (more applicable to desktop systems than handhelds/custom consoles).

FWIW, it seems that 2/3 of Bazzite’s user base uses it (primarily) as a game console anyways.

I will agree with you that Desktop Linux leaves a lot to be desired from a security perspective. But, I’m not sure if these are its biggest problems.

Not all distros ship SELinux and the ones that do, don’t actually configure it securely.

Is SELinux employed on Desktop Linux the very same way we find on Android? Unfortunately, no. So, there’s definitely a ton of mileage to be had here. But, there’s literally nothing that stops you from making a fortress out of it. So, the ones that are intimately familiar with SELinux will leverage it to perfectly suit their needs. Which, is the only truly sensible way one should use SELinux to lock their system. Being dictated by the defaults set by the distro is only a counterproductive exercise of comparing/contrasting threat models.

New users are expected to keep copying and pasting commands from their browsers to their terminal which compromises some Linux security defenses.

They’re absolutely not expected to do so. What makes you even think that’s the case?

KDE, GNOME and Sway are the only functional Desktop Environments/Window Managers that support Wayland all, while the Other DEs are not even close to shipping with Wayland.

This is your best point. I agree that other DEs should haste in supporting Wayland. Though, at least I find solace in GNOME and KDE Plasma being the most used DEs/WMs to begin with. Hence, even if only those two would support Wayland, we would still have allowed over half of Linux’ users to choose Wayland.

Most if not all of the Linux Distros in 2025 ship with Grub bootloader, which suffers from a lot of problems, instead of using the bootloaders that does not support BIOS and will improve the reliability of booting and provide a more stable experience.

Sorry, I’m not familiar with this problem/issue. Would you please be so kind to explain why I (or anyone else, for that matter) should worry about this? Like, what “problems” are we talking about? How is (allegedly) GRUB not reliable or stable compared to the others?

Btw, just curious, what are your thoughts on secureblue?

I’ve heard it has poor long term stability.

Relatively speaking, sure. But I’d argue this is by design. Basically, every ‘modern’ distro is trying to solve the problem that come with updates on an ‘open’/‘free’ operating system. The solution they come up with essentially dictates a huge part of the identity of the distro. As I’ve noted elsewhere, these include the following:

• Some choose to outright freeze packages and only come with security updates
• Others have (almost) excessive testing to prevent breakage
• Yet others employ rollbacks to ensure that the (eventual/inevitable) breakage can easily be deflected
• Finally, there are distros that fall on a spectrum in regards to their more radical state management in hopes of minimizing breakage
• (Though, I’m sure I’ve forgotten some other methods…)
• And, of course, we find combinations of the above employed on the very same distro/system

And, of course, we shouldn’t forget to mention Arch’s approach; lay the responsibility on the user 😅. So, Arch ‘breaking’/‘borking’ after an update is a user error. Which other distro can tout such an impressive entry in their documentation for system maintenance?

To be fair, this makes total sense. The user can basically build their system from scratch. So…, why wouldn’t they be capable to come up with their solution to the above problem? Besides, the ArchWiki continues to be a guiding light whatever solution they’d like to adopt: be it ‘freezing’ the kernel, or using better tested software, perhaps setting up Snapper for rollbacks etc…

Is there a distro that’s like Arch for installation but more stable?

Gentoo

Well articulated reply. Thank you!

Isn’t Bazzite built on Fedora Silverblue

Kinda.

installs the Steam Flatpak?

Actually no. Bazzite installs Steam from the RPM Fusion repo.

As for an attempt to shed light on why Fedora is absent from Steam’s numbers, see this comment. Finally, perhaps this is worth looking into to see how big Fedora’s gaming community is compared to the rest of its users.

Unfortunately, based on what I saw on the Proton website, if I want to use it on linux it looks like the only way is to get it on Ubuntu, Debian, or Fedora using the console.

For official support, yes. Thankfully, ProtonVPN is also available as a flatpak. As such, any distro that allows installing (unverified) flatpaks through its GUI software store suffices. Though, not all distros are created equally in this respect. Focusing on Kubuntu and Linux Mint specifically:

• Kubuntu requires the use of CLI to set this up.
• Linux Mint, on the other hand, supports it by default. Though, by default, unverified flatpaks are hidden. Thankfully, you can change that in the preferences window of its software manager.

My pleasure fam! Btw, I’m in no place to dictate what’s right or wrong (or whatsoever). I just wanted to add their perspective on the matter*.

Article by a Red Hat engineer that also makes a ton of contributions to FOSS in their free time: Don’t change your login shell, use a modern terminal emulator

Not OP, but when I cold turkey switched to Fedora Silverblue over three years ago, I benefited a lot from this guide.

Glad you’re so appreciative and worked through it! I gladly share, discuss, and respond.

Thank you for being you!

I’ll have to read up on palette filters. :) I do semi-regularly use ffmpeg, but palette filters are not something I have heard or used before.

Please allow me to point you towards the relevant parts within its documentation; palettegen and paletteuse.

Together, they constitute -from what I can gather- the absolute minimal required to create a .gif with desirable qualities. As such, they will make their appearances within the following two commands that closely mirror the examples found in the documentation:

ffmpeg -i input.mp4 -vf palettegen palette.png

This generates a representative palette with 255 colors maximum from the video. Note that AFAIU the set of colors this can draw from is the same as the one used for gifs. Which will likely come into play when we try to understand why this works in the first place.

ffmpeg -i input.mp4 -i palette.png -lavfi paletteuse output.gif

This starts with converting the colors found in the original .mp4 to their closest counterparts found within the palette. Then, with converted colors, it’s turned into a .gif. Note that AFAIU we’ve effectively eliminated the algorithm that would otherwise kick in to convert the .mp4’s wide arrange of colors into the ones compatible with gif.

To be clear, I don’t claim to understand why this actually works 😅. But, combined, the above two commands do yield desirable gifs. Like, for example, the one found below.

Note that we can achieve the same with just a single command. For that, consider the command found below.

ffmpeg -i input.mp4 -vf "split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse" output.gif

I assume in this case it’s a downsampling into fewer colors, evading the issues of almost-same-colors?

That would also be my conjecture.

Especially given the last square/check pattern makes me thing of codecs splitting into square blocks and then encoding those. It could make sense that this division leads to different results for one reason or another, which then produces a check pattern without it being there before.

Makes sense.

deleted by creator

I wonder what this means for Linux Journal as a platform.

Step 1 ‐ install BalenaEtcher.

FWIW, perhaps you should reconsider if you should even use balenaEtcher.

I never figured out step 1. It’s not in the software store.

Unfortunately, this does happen at times. Therefore, it’s a good idea to be aware of alternatives. One such example would be Fedora Media Writer that you may install as a flatpak. Though, the most popular is probably Ventoy.

Eventually I found an APPimg file, and it installed Balena Etcher. But it wouldn’t launch after being installed.

Unfortunately, AppImages aren’t as reliable as one might expect. Assuming that your distro supports it OOTB, you’re still often required to explicitly allow it to be run as an executable. Which is a good thing for the sake of secure defaults*. Granting it is simply done by:

1. Right-clicking the AppImage you wish to execute
2. Go into “Properties”
3. Turn the switch ON that’s found to the right of “Executable as Program”

You can put multiple ISOs on it, and choose at boot.

FWIW, the aforementioned Ventoy does just that.

This sounded like really positive news, linux as an ecosystem desperately needs to revisit its init process choices, but there really doesn’t seem to be any hint of it elsewhere.

I’d also love to see something like this come into fruition. And hate the fact that everything points towards this being some LLM-hallucination. Thankfully, while not written in Rust, we have dinit to be excited/optimistic about.

There is a rye that’s written in rust and which has an init command rye init. I wonder if it’s a case of an LLM latching on to that and just making up the rest?

Excellent observation! That’s probably it.

but describing an entire nonexistent init system without some kind of directive in that direction?

Someone else, i.e. the user called “notabot”, had already made the following interesting observations:

• rye is software that actually exists and is found within the repos
• rye is written in rust
• rye has an init command; rye init

I don’t think it’s too far-fetched to think that an LLM is aware of the above. But, it failed to understand what rye actually is and how its init command isn’t competing with systemd.

Yeah lol. There are definitely some oddities going on that I find hard to wrap my head around.

For example, last week this article was published on the same website and attributed to the same author. In the article, the author talks about the release of Fedora 41. The thing is, however, that Fedora 41 was released last October. Heck, Fedora 42 has been released for two months now. Like, why wouldn’t they want to talk about Fedora 42 instead?

Excellent find.

I also noticed this, but I gave them the benefit of the doubt as Arch is a community-driven distro and perhaps they were trying to allude to that fact.

So I was interested to dig more into this…, but I wasn’t able to find any other source that talked about this. Furthermore, while some digging suggests that the author is a real person, the text didn’t score well on https://undetectable.ai/ . Do with that whatever you will*

FWIW, trying to install it within a distrobox container gave the following error:

error: target not found: rye-init

Which, AFAIK, suggests that the package is not found in the repo. Nor does going through https://archlinux.org/packages/ yield any results. At this point, my best best would be to spin up a VM and see if that makes a difference. But I’m not really in the mood at the moment.

Regardless, has somebody checked the package out for themselves? Or, have they seen discussions on it elsewhere?

Thank you so much for your patience in teaching me something new! Much, much appreciated!

With the help of your observations, I can confidently say that the different dither methods don’t play much of a role after filtering with a better palette has already been done. So palette-filtering -if we can refer to it as such- is the actual MVP in resolving this issue.

animated webp may also be an option

Hehe :P , I’ll take note of this and perhaps resort to it the next time. The whole palette-filtering stuff seemed like some occult incantations that somehow worked. But I would much rather use a different (sane) format instead.

Again, I would like to stress that I’ve very much enjoyed this interaction! While it’s been (mostly) totally unrelated to the original post, this has actually been one of the most informative interactions found within its comments. Therefore, thank you!