Para_lyzed

Not sure what the title was before you changed it, but if I see a post in my feed that looks like this (without the “very bad take” part), I wouldn’t even want to open the post to see the description. I’m glad you clarified by editing the title, but without making your stance clear in the title from the very beginning, it would be bound to receive a barrage of downvotes.

This is a bit late, but I just wanted to follow up to let you know that Fedora 40 updated to kernel 6.9 last week.

Fedora has pretty good SELinux configured out of the box, and isn’t focused on opsec. It’s just sane defaults and proper limitations to access. It also switched to Walyand-by-default this release, completely removing X11 from the default packages, which mitigates many of the “app spying on other app” scenarios that a previous user in the thread was talking about. That’s not to say that Fedora is the pinnacle of Linux security or anything, but it comes with pretty good defaults for the average user. You’d have to get into kernel hardening and deep into SELinux to do better as an end user, which is not something that most users are inclined to spend time or energy on.

Seconding partclone here, it’s the easiest solution for imaging that only backs up the data on the partition that is used. Plus, it’s in RescueZilla, which is pretty intuitive and user friendly for those that prefer GUIs

Shouldn’t be too long left, I’d expect it to hit Fedora 40 sometime this month. I also shared instructions on how to temporarily upgrade the kernel to the one in Fedora 41’s repos (which is past 6.9) if you were interested in trying that, though the instructions are untested as of yet (the issue doesn’t affect me since I don’t play games). It’s easily revertible if you wanted to give it a try. I probably wouldn’t bother if you use secure boot, because I’ve had issues with signing things before with similar steps, though those are the official steps from the Fedora documentation, so it may be that they just work fine.

Is it related to the issue described in the post attached to this comment? The linked comment also links to an issue page with details about the issue the poster experienced. If so, then that issue should actually be fixed in kernel 6.9 (which still has not been added to the Fedora 40 repos), and not caused by it.

An extension of this issue is present in 6.8.9+ before 6.9, which is why I ask if this seems to be related (since the versions are pretty close in time and Fedora doesn’t even have 6.9 yet).

It really depends on the individual case. There are many CS professions where the title “engineer” or “scientist” is incredibly accurate. I believe that is a minority of course, and further depends on how broad your definition of “cs people” is. There are specialties within the incredibly broad field of computer science that require education in classical engineering, as well as specialties that focus on research and experimentation with the scientific method.

Hm, it could be a new issue then. I’m not seeing it on the Bazzite issues page, perhaps you should open a new issue on it here, and provide your hardware specs. At the very least, you could see if this issue is reproducible on other installs, and someone there could help to obtain more useful debug info to determine the actual problem. You could also report it on the Mozilla Bugzilla page, as chances are this is a Firefox issue and not a Bazzite issue, but I admit that the interface for bug reports is less intuitive for non-developers there. Bazzite devs would likely direct you to there first anyway though.

All I can really say myself is that I don’t experience this on Fedora Atomic KDE 40.20240607 with Mullvad Browser or the Firefox flatpak. I suspect it is either a hardware/config issue (on fresh install, I’d say a config issue is a distro issue if you haven’t changed anything), or that this is Bazzite specific and not present in upstream Fedora Atomic. Regardless, it’s a good idea to report this so that other users don’t experience the same bug

Sounds about in line with what I’d expect. If that works for you where the flatpak doesn’t, then it at least makes a viable solution for the short term (though I don’t know how much overhead would be introduced). A minute of delay is ridiculously long for startup, so I still don’t know why you were having that issue with the flatpak

Is it? I was looking a few months ago at Nix support in Fedora Atomic (which Bazzite is based on), and it required some minor hacks to get the /nix folder and Nix itself working properly with rpm-ostree distros, as root is otherwise immutable. Plus, Nix isn’t available by default in the Fedora repos it seems. I believe it required something along the lines of making a /var/nix folder and symlinking it, but I believe you’d also have to work around SELinux contexts on the folder and symlink. I’ve heard of people even having issues after that, so I wouldn’t consider it “official” support. Here’s an open issue thread about it

Is this new, or has it been happening for a few days/weeks? I’m on Fedora Atomic (which Bazzite is based on) and have never experienced this (though I mostly use Mullvad browser, a fork of Firefox). I tried Bazzite a few weeks ago and also never experienced this with the Firefox flatpak. If it’s been happening for awhile, it may be hardware-specific or a config thing. Out of curiosity (just to get a 1:1 comparison), do you experience the same thing with the Mullvad browser flatpak?

Not that I know of? I’m not sure where to even find that information if it does exist

555 is still the big driver release that fixes a ton of Wayland issues with explicit sync support. It’s still in beta as of now

While I don’t particularly agree with the sentiment, those in the field of Computer Science could be argued to be “scientists”, though often not in the classical sense. As a Computer Science major myself, I would never consider myself a “scientist” in the classical definition of the term. Those involved in actual research, yes, though that does not describe me despite the title of my Bachelor’s. I would consider those involved in the theoretical side of Computer Science to be more akin to mathematicians, as most of the theory is based in mathematical proofs and models (take for instance the field describing formal computational models as a means to defining how computers operate, and how effective specific algorithms are in that context). Though I could understand the argument that those involved heavily in the theoretical side of Computer Science may be considered scientists, given their similarity to theoretical physicists. In that sense, there is also active experimentation to test hypotheses about algorithmic runtime. It’s a fascinating niche of Computer Science that I studied briefly in university, but likely will not be pursuing in the future.

Generally those involved with active development of commercial software don’t fit into that category, though. It’s very much a question of semantics.

Then I don’t really understand the issue here. It’s syntactically similar to C++ with the benefits of being memory safe. It’s a different language, so there are different conventions and some different syntax of course, but that’s to be said about any 2 languages; they are always different in some ways. I don’t see a reason to complain about the aesthetic value of a language you don’t know how to use, especially when it’s similar to one that you seem to be using regularly.

Its syntax is incredibly similar to C++, the programming language it is targeting as a replacement. I don’t really understand the confusion here; have you never used C++?

The partition manager should be KDE Partition Manager on the KDE Bazzite, and Disks on the GNOME Bazzite (I don’t think GParted is installed by default)

SteamOS currently runs 6.1, which is an LTS kernel, it just isn’t the latest LTS kernel (that’s 6.6 released at the end of 2023). Steam also makes modifications to the kernel they use in SteamOS, so they have their own versions custom built for Steam Decks. I should revise my previous statement slightly. Debian Bookworm is on 6.1 as well, but SteamOS 3.6 (in beta) uses 6.5 (which is non-LTS). Debian skips every other LTS kernel because they release every 2 years, but SteamOS (eventually) upgrades each LTS kernel or some non-LTS between? They did the same thing with 5.13 a couple years ago (5.10 and 5.15 are LTS). I don’t really follow their releases since I don’t own a Steam Deck, so I don’t really know the rationale there. Funnily enough, looking through posts about it online, it seems that SteamOS is sometimes ahead of Debian on the minor kernel version and sometimes behind (when they’re on an LTS kernel). Currently, they are behind Debian on minor release (6.1.52 vs 6.1.76). Very strange, no idea what’s going on there.

But I specifically mean the packaging delays. There are sometimes sync issues with drivers, like this recent one with no free stuff that is used alongside the normal stuff.

Hm, interesting. I don’t recall experiencing anything like that personally since I hardly use anything from RPMFusion, but that does seem frustrating. Looks like it was fixed very quickly, at least.

And with Cisco-openh264 they cant to anything, Cisco ships the packages which is legally binding, and there are issues sometimes.

Ah yeah, I’ve heard about that. I can’t remember the last time I installed Cisco’s openh264 though since I started using VLC, which can handle video and audio formats without installing extra codecs. I think MPV can do the same? I’m not sure what comes with my browser, but it is packaged as a flatpak and seems to run media just fine. Maybe there is some other use for openh264 that I’m not aware of that just doesn’t come up in my normal use, but I don’t think I’ve installed any media codecs in Fedora for a couple years now. Granted, I don’t play videos often (but I do play MP4s when I do), and all my music is in FLAC format, so I’m probably an edge case. I also don’t game, but I remember seeing something recently in this sub where someone may have had codec issues while playing a game.

But Fedora is doing a great job, and the fact that rpmfusion exists alone is pretty hillarious. These are obviously Fedora people maintaining the stuff in secret, in a country where patent laws are not enforced (but are also in place afaik).

Well, Fedora is a community project, so it’s very difficult for anything individual maintainers do to come back to Fedora so long as the name isn’t put on it directly. If I were to speculate, most of the RPMFusion maintainers are Fedora community contributors (and I imagine they likely wouldn’t work at Red Hat, given Red Hat’s apprehension towards copyrighted material). I don’t think it’s really any different legally speaking from a Fedora contributor working on a personal project on the side. The fact that you can manually add the repo to Fedora doesn’t connect the two in a legally binding sense. So as long as it isn’t being funded by Fedora, and their branding is absent, then it shouldn’t really matter. I don’t know about the actual legal aspects of the packages they are distributing, or what country/countries RPMFusion repos are hosted in, but so long as nobody is profiting/losing substantial profit, it likely isn’t even worth pursuing any legal recourse to begin with.

You are at the bleeding edge, but I often find bugs that are simply there and need to be fixed. Once KDE Plasma 6 is on some LTS release like CentOS Stream, I may think about switching.

Yeah, that’s fair. There are definitely bugs that pop up every once and awhile, but for the most part they’re minor (at least the ones I notice). This kernel bug is among the more major bugs I’ve seen with Fedora in the past few years, but I only know about it from this post; I haven’t experienced it myself. I imagine there have been similar things (or worse) like this that have gone over my head as I didn’t experience them myself. Perhaps my experience has also been more stable because I’ve been using GNOME up until Fedora 40. I do find my experience with Fedora to be much more stable than Arch, but that is to be expected given their release models. I can only recall having experienced 1 or 2 bugs in the past year on Fedora, which is less than I experienced when I used Ubuntu many, many years ago, and the bugs were fixed much faster than they were on Ubuntu, where it would often take months for a patched version of the package to enter the Ubuntu repos. That’s all anecdotal, however.

The reason I usually recommend Fedora to people (and uBlue images by extension) is that it sits on some middle ground between the rolling release bleeding edge distros like Arch, and the stable, LTS, frozen for 2 years distros like Debian. I have grievances with both of those models that are addressed with Fedora, and that’s what makes it a good distro for me. My experience with bugs hasn’t really been any more common than when I was using LTS distros, but that may be a fluke. I will likely be moving one of my servers to Debian in the future though, because it makes sense for its purpose. Different release models benefit different uses (and people), of course.

Actually, this particular issue is a bug in the Linux kernel that has been patched in version 6.9. The display manager isn’t going to change anything other than (maybe) the issues their wife had on Bazzite. In fact, OP stated in their post that they are running an AMD GPU (5700XT). Fedora 40 (and Bazzite by extension) ships without X11 installed now. You can always install the X11 package as an overlay and switch to it if you want with Fedora Atomic or Bazzite. It’s still in the repos, it just isn’t the default anymore. So realistically, the solution here is to wait for the 6.9 release to be added to the Fedora 40 repos, or for a 6.8 version which has the fix backported (which will be much sooner, probably a few days after the backport is merged, though I don’t know if that has already happened yet or when it will if not). The reason Mint works is because it uses a much older kernel version, so this bug is not present. The bug was first introduced in 6.6.30.

Yes, that may be the case, but that comes with its own downsides as well. The most recent version of SteamOS runs the 6.1.52 kernel from September (thus it should be unaffected by this bug, since it was introduced in 6.6.30). I don’t follow kernel changelogs very closely (so I don’t know all the new features and improvements that are being missed from new versions), but there are lots of optimizations and new features constantly being added to the kernel. Of course, the tradeoff is that you don’t get new bugs, but you also have to backport bug fixes or else you’ll have the bugs present in your current version for a very long time (often the kernel devs do this, but depending on what version a given distro uses, the distro maintainers may have to do it themselves). It’s not as big of a freeze as Debian based systems (EDIT: Some of the time; right now they are technically behind Debian on the kernel minor release, but in SteamOS 3.6 (which is in beta), they will be updating to 6.5), of course, but it’s a choice that has tradeoffs. Different people will subscribe to different opinions on kernel updates, given that no one way is clearly superior for user experience and features alike.

As for proprietary packages that are held from Fedora for copyright issues (media codecs and Nvidia drivers, for instance), there are always uBlue images like Bazzite, Bluefin, and Aurora that fix that. One of the very few stipulations to the Red Hat sponsorship for Fedora is that they do everything possible to avoid legal trouble, hence why those packages aren’t included in the base repos or installed by default. It’s a small caveat that disappears once you install the correct packages.

I think SteamOS is by far the most optimized OS for the Steam Deck, but I don’t think it’s very useful to use it on any other hardware (there are better options). Kernel updates will always be a point of conflict for at least some people regardless of what model you use, but I personally appreciate the quick turnaround for major kernel versions in Fedora. It’s actually improved my experience on my laptop significantly, as there have been recent changes that apply to my specific hardware (in some of the 6.6 releases, for instance). Of course, anyone can be free to prefer a slower rollout, and that is equally valid. The bug fixes for the issue OP is having should be backported to 6.8 anyway, so it shouldn’t necessitate waiting for 6.9 to hit Fedora in a few weeks.