The guy is trying to address the issue and he is building this in his free time. Give him some credit at least, I am sure this is consuming a lot of his free time.

Fam, you’ve chosen to trust them for reasons that are unclear to me. Honestly, I don’t see anything (yet) that would clear their name. For all we know, they could have ties to some intelligence agency; which the infamous Jia Tan has (retroactively) been accused of as well.

I personally find this Ventoy an amazing piece of software

That’s not the issue. I’ve also made plenty use of it in the past. But at what point do you start to second guess the intent behind the maintainer?

he also seems to be willing to address the issue and be more transparent in the future which is also commendable.

Again, arguably too little too late. They literally ghosted the issue for over a year. Then, within 24 hours of possible proof of malicious code, they appear and (perhaps) “pose the image” of putting in a gargantuan effort to resolve the issue. But, like, where were they for a year? Furthermore, the hints of justifications for their actions are simply not up too par.

Don’t get me wrong. As I clearly hinted at it in my previous comment, if they pull through and provide/produce (bit-by-bit) reproducible builds of Ventoy^[1], then I obviously have no qualms against them or their software. Why would I? But until then, I will steer clear.

What should have happened for you to be more concerned?

Perhaps I’m too skeptical and/or have trust issues, but isn’t this too little too late? This issue had been ignored for so long, but -suddenly- within 24 hours of this very peculiar find^[1], Ventoys maintainer goes into full damage-control mode. Should we just accept that?

Sorry, at least for now, I simply don’t buy it.

I do think uBlue is downstream

It’s indeed downstream~ish. But perhaps just different enough to actually make a meaningful change.

I’m pretty clueless at that point. Never seen something like it. Apologies for not actually being able to help out. Hopefully it will be resolved soon, though.

This is probably not the advice you’d like to hear, but I wonder if rebasing to uBlue’s Kinoite would make any difference. Regardless, wish you the best!

No Nvidia, just intel integrated graphics. Its a dell ispiron 7500.

Yeah, that shouldn’t cause any pecularities.

LayeredPackages: alacritty bat btop distrobox fish flatpak-builder kpeoplevcard light lsd mako neovim parallel python3-neovim shellcheck swaybg swayfx swayidle swaylock syncthing tailscale tmux virt-manager waybar wlogout wlsunset wofi

Hmm…, nothing too outrageous, I think; still, consider rpm-ostree reset to at least rule out the possibility that any of the layered packages are to be blamed. If you’re afraid of losing your working deployment, ensure to evoke the sudo ostree admin pin 1 command to pin it. (ASSUMING THAT THERE ARE ONLY TWO DEPLOYMENTS WHEN YOU DO THIS). After you’ve done the pinning, ensure that you pinned the correct one by checking this with rpm-ostree status; the deployment you wish to pin should state the fact that it’s pinned.

journalctl shows nothing. That’s what I meant by no logs, I should have been clearer. It’s not even getting that far. It’s like it’s stuck in grub, but only when I try the new kernel.

Perhaps I had to be more clear and explicit, boot twice:

• first, into the now broken deployment, wait until the time your system should have booted otherwise. Then, hard reset.
• secondly, to your still working deployment, then evoke the journalctl -b -1 command. This should, unless something is wrong with how systemd is setup on your system, show you the logs of the previous boot. You could even compare it with your current boot (which can be accessed with journal -b) and see where it diverges, though looking at the logs of the corrupt boot sequence should suffice.

The only deviation from the vanilla kargs have been for troubleshooting this and I did it in the grub editor so they aren’t persistent. I tried removing rhgb changed quiet to verbose and debug and loglevel=7 just to see if anything would happen. It still just hangs

Aight. Thank you for putting in the work so we can rule that out!

Anybody else experienced something similar?

FWIW, I just booted my laptop that runs a Fedora Atomic derivative -secureblue to be precise*- and updated to the 6.14.5-300 kernel. Afterwards, I rebooted and found a still functional system. Just so you know; GNOME is installed on my system instead of KDE Plasma, but I don’t think it would have mattered.

Regardless, your issue remains and is rather peculiar. Uhmm…, I’m just thinking out loud at this point, but have you considered the following:

• Is this a system with Nvidia? If so, could it be somehow related?
• How ‘pristine’ is your system? Have you layered a bunch of packages? If so, do you think the issue would persist after a rpm-ostree reset?
• Beyond layering, I have experienced that kernel arguments could cause issues down the line. So, have you tinkered with any of that? If so, do you think the issue would persist if you would remove all user-added kernel arguments?

Aside from the above, I don’t really know what would cause an issue as such.

Or know of a way I can get some more info out of the system

Consider accessing systemd’s journaling with journalctl. This should be (easily) accessible on a successfully booted system. In your case, that would be your working deployment.

Wow, Niri has been shaping up lovely since the last time I checked on it.

That reminds me; I should probably revisit Wayfire (and the other Wayland-WMs) as well 😅. Thank you for the reminder!

To clarify, this is just my list that I shared in the hope that others would follow suit 😅. (Which hasn’t been successful so far…) Consider posting yours 😉!

As someone with a perpetual desire for clean system management—even back in my M$ days^[1]—I deeply resonate with the desire to declare the desired state within a config file and treating it as the single source of truth; this is exactly why NixOS with the Impermanence module has captivated me ever since it appeared on my path, like a long-sought truth.

I’ve only abstained this long due to lacking a spare device for a proper test run that might lead to permanent adoption. Perhaps this summer will finally be the time to take the plunge.

Looking forward to bringing order to chaos at last.

The expectation that package maintainers should backport security patches rather than simply updating to the latest upstream version is a rather peculiar quirk.

Can’t agree more.

Off-topic, but AFAIK the team responsible for PrivacyTools.io’s content has moved to PrivacyGuides.org.

PrivacyTools is now (mostly) solely run by its original owner and its content has ceased to be reliable ever since the likes of NordVPN and Surfshark have appeared at the top of their VPN recommendations.

While I wouldn’t argue that PrivacyGuides is perfect, it’s undoubtedly better than the alternative. And thus unsurprisingly the actual (spiritual) successor of (what used to be) PrivacyTools.

FWIW, PrivacyGuides doesn’t recommend Ubuntu.

P.S. while it doesn’t tackle as many topics as PrivacyGuides does, privsec.dev offers comprehensive guides on the topics it does. FWIW, they also used to be in the PrivacyGuides team (and perhaps even in PrivacyTools).

woah, that’s a lot of information.

Yeah 😅, lol 😂. The first draft was even longer; so much so that it exceeded the character limit :P . FWIW, I had written two drafts on two different days until I landed on (another day) with the third and final version.

Atomic distros do sound pretty good.

Yup, I can vouch for that.

I might try one someday,

Please do :P

but I’ve already setup Fedora Workstation and am very happy with it :D

Glad to hear that, fam! Enjoy!

Thanks for your detailed reply! Note that in the following writing I’ve chosen to address matters in generalities and oversimplifications for the sake of readability and brevity. No need to drown you in technicalities 😅.

On KDE Plasma vs GNOME, I would like to try both out and see which I like better long-term. KDE Plasma seems a bit more familiar (closer to Windows 10) whereas GNOME is a bit more different but I’m open to using either.

That makes perfect sense. As noted by others, while installing both DEs on the same system is technically possible, it often leads to conflicts and inconsistencies. For the cleanest experience, consider dual-booting with separate installations for each DE. Since you’ve already installed Fedora Workstation, you might want to try KDE on a separate installation.

a laptop with an Intel i7-1360P. It’s one of those 2-in-1 convertible 360 degree hinge laptops.

Your hardware should work well with either DE. For future reference, check the Linux Hardware Database and ArchWiki’s laptop entries for compatibility information. Since you’ve confirmed the touchscreen and rotation are working, you’re already past the biggest hardware hurdles!

I would say I’m open to learning how to work with the terminal and customising the distro a bit, but I don’t want to do anything too out of my scope. I don’t want to spend too many hours setting it up, I’d rather have something that works mostly out of the box :D

Both Fedora and openSUSE nail this balance perfectly. They provide sensible defaults that work immediately while giving you room to tinker when you’re ready.

Stable as I don’t want to break my system after an update. I still want an up-to-date distro though. I am open to rolling release distros, but to my knowledge those are usually less stable with more breaking changes than fixed release options.

FWIW, this is where atomic distros really shine: they offer both stability and current software through their unique update model.

Also, how are the “immutable” distros from UB different from the “mutable” distros?

First, a clarification on terminology: The term “immutable” is actually a misnomer that Fedora has moved away from. These systems aren’t truly immutable – they can change, but in a controlled, atomic way. That’s why Fedora now refers to them as “Atomic” systems, which better describes their update mechanism and system architecture.

Fedora offers traditional Fedora and Fedora Atomic for desktops, with Atomic including variants like Silverblue (GNOME) and Kinoite (KDE). For servers with atomic updates, Fedora offers Fedora CoreOS. Universal Blue (uBlue) enhances these atomic systems with additional features and optimizations.

The key differences between traditional and Atomic systems include:

• A read-only base system where core system files are protected from casual changes, ensuring system integrity. On traditional Fedora, you can easily remove or modify system files with commands like sudo rm -rf /usr/bin/important-file, but this fails on Atomic systems with an “Error: Read-only file system” message.
• Many system changes are tracked, which enables you to ‘undo’ these changes and return to a cleaner state. This tracking mechanism is what makes factory reset features possible, which are being investigated for these systems. This is surprisingly rare in Linux, with few exceptions like Pop!_OS and TUXEDO OS.
• Atomic updates mean changes either occur or don’t – no half-updated broken states. On traditional systems, interruptions can leave you with partially updated components (like an updated kernel but broken system libraries), while on Atomic systems, the previous deployment remains fully intact and bootable if an update fails.
• Deployment tracking keeps multiple system versions you can switch between using commands like rpm-ostree status to view deployments and rpm-ostree rollback to return to a previous state.
• Rebasing capability lets you change your entire system base without reinstalling. For example, you can switch from Silverblue to Kinoite with rpm-ostree rebase fedora:fedora/42/x86_64/kinoite.

uBlue enhances these Atomic systems with proactive maintenance. A great example: when the kernel 6.13 update introduced regressions affecting flatpaks, uBlue maintainers pinned the kernel to 6.12, protecting all users while traditional distro users experienced crashes documented in Fedora discussions, Reddit, and EndeavourOS forums.

uBlue also offers streamlined setup with better onboarding than almost any other distro, simplified handling of troublesome hardware, and purpose-built variants optimized for gaming, development, and other specific use cases.

Does it just mean that you’re unable to change system-level settings and such/break anything with a mistyped terminal command?

It’s more nuanced than that. While changing /usr contents is restricted, modifying /etc works the same as in traditional systems (though changes are tracked). The real protection comes from the deployment system - even if something breaks, you can easily roll back to a working state.

What are the downsides to using an immutable distro?

There are some trade-offs to consider:

• Traditional Fedora uses a single approach for software management, while Atomic systems use a combination of methods including Flatpaks, containers, and layering. This creates a more compartmentalized but potentially complex software ecosystem.
• There are also some system limitations to be aware of. Native messaging in browsers installed as flatpaks require workarounds, kernel module options are limited to uBlue’s own akmods repository, and there’s no current support for UKI. Granted, I don’t expect you to engage with the latter two anytime soon.
• Additionally, with uBlue, you’re trusting their maintainers alongside Fedora’s team, though uBlue is mentioned in Fedora’s documentation.

For someone wanting stability without sacrificing current software, uBlue variants (Bluefin for GNOME, Aurora for KDE, or Bazzite for both) offer significant advantages, though standard Fedora remains excellent if you prefer a conventional approach. Your successful experience with Fedora suggests you’re on the right track!

Okay then, new question, for a beginner friendly distro, should I go for Fedora, OpenSUSE, or something else?

OP, consider making up your mind regarding which one between GNOME and KDE Plasma you’d like to use (at least for the foreseeable future). Afterwards, consider answering the following so that we may do a better job at helping you:

• What kind of hardware are we dealing with? Can we have the specs?

Note that both Fedora and openSUSE may be considered beginner-friendly. Though, there does exist some considerable difference in design ethos between these and say something like Linux Mint; the former two give you a relatively bare system and assume (at least some) responsibility from its user while setting up the system. By contrast, Linux Mint offers considerable more hand-holding. This may of may not be to your liking.

Note, however, that Fedora and openSUSE are far from the worst offenders in this regard; within the spectrum, they definitely belong to the better half as we’ve even got distros that assume their users are willing to learn an otherwise useless programming language from scratch. (FYI: I love NixOS and I wouldn’t want it anyway else.)

Therefore, allow me to ask another question:

• How much hand-holding would you deem desirable?

There’s also the fleet of distros by Universal Blue that some swear by. These operate with a different paradigm; most of its users would describe them as a better alternative for newbies (under certain circumstances). But I digress…

Finally, I have noted how you’ve pronounced your preference for a stable system. I do think I understand what you mean by stable, but just to be sure:

• Stable, as in little to no updates except for those related to security? OR Stable, as in not being afraid to bork your system after an update or otherwise (i.e. kinda synonymous to reliable)? OR… Another use/definition that I’ve missed?

I was looking for an official documentation entry on this matter to share with OP, ideally something centralized like Fedora’s RPM Fusion or the comprehensive Arch Wiki. While I found various user-created resources, I was surprised not to locate a centralized official documentation page addressing this topic. I’m quite familiar with Linux Mint’s user-friendly approach, so perhaps I’ve overlooked something? I’d be genuinely delighted if someone could point me to such a resource, as it would be tremendously helpful not just for OP but for the community as a whole.

To add to this, a ‘distro’ -if you will- that was launched recently with this theme would be the aptly-named Blue95.

Without trying to be exhaustive:

But all I know about Linux is 1: it’s a cantankerous beast that can smell your fear and lack of computer skills and 2: that’s apparently not true any more?

Exactly.

I’m pretty much a fairly casual PC-user, I don’t do much more than play games.

Noted.

Will my ability to play games be significantly affected compared to Windows?

Your queries on which specific games work and don’t work should be answered between the databases of ProtonDB, WineHQ, Lutris and Are We Anti-Cheat Yet?. Note, however, that these are not necessarily exhaustive (even if put together); e.g. after visiting the aforementioned websites, you might think that Roblox can’t be played on Linux. But it’s simply one of the many games that exist in the compatibility blind spots between these databases; as the excellent Sober isn’t accounted for.

Can I mod games as freely and as easily as I do on Windows?

There will definitely be a learning curve to be had. Though, AFAIK, there’s nothing that outright prevents you beyond an initial (and potential) knowledge gap.

If a program has no Linux version, is it unusable, or are there workarounds?

Wine is your best friend in these cases. Or, an alternative. Note that -again- compatibility blind spots in these databases continue to exist; like this significant one.

Can Linux run programs that rely on frameworks like .NET or other Windows-specific libraries?

Again, Wine comes to the rescue.

How do OS updates work in Linux? Is there a “Linux Update” program like what Windows has?

This depends entirely on the so-called Linux distribution you end up installing. Some opt to do updates automatically (perhaps in the background even), while others simply prompt the user whenever updates are available. Yet others expect the user to do them manually. What are your preferences in this regard?

How does digital security work on Linux? Is it more vulnerable due to being open source? Is there integrated antivirus software, or will I have to source that myself?

This is somewhat of a controversial topic thanks to articles like this one. Note that while the article continues to be shared and thus remains ‘popular’, the fact of the matter is that at least some parts of it have become outdated since. Refer to this (more recent) article as an addendum. The gist would be that Linux might be secure enough for your intents and purposes. But this depends entirely on what you intend to use it for. Downloading and executing random files from the dark web is probs a bit much and not something any OS would appreciate. But playing your games through Steam and surfing the internet should be fine unless you’re somehow targeted by a resourceful adversary. If you didn’t worry too much about this on Windows and thus went with the default settings -so no hardening whatsoever-, then popular distros like Fedora should be more than fine for your use case. However, if you require more than that, then you may find solace in the fact that projects like Kicksecure and secureblue do exist. (There’s also Qubes OS, but I’ll assume that’s too hardcore.)

Are GPU drivers reliable on Linux?

In most cases, yeah. Historically, Nvidia used to be a pita. And, frankly, continues to be for some peeps. But it has improved significantly over the last couple of years.

Can Linux (in the case of a misconfiguration or serious failure) potentially damage hardware?

Any bad software (irrespective of platform) can potentially damage hardware. Linux is no different in this regard. Though you shouldn’t have to worry about this unless you intend do some janky stuff.

And also, what distro might be best for me?

As gaming seems high on your list, consider Bazzite.

FWIW, I actually do understand the difference 😅.

As the term “immutable distro” has -unfortunately- become a misnomer, I went with the (more) descriptive “atomic distro” instead. At least it rings better than names like “distro with transactional updates”, “distro with (some degree of) managed state” or -heck- “distro with anti-hysteresis properties” 😜.

Granted, perhaps the notion (and/or intention) to lump the likes of NixOS together with Endless OS under one oversimplified umbrella term isn’t being helpful either. But I digress…

Though, I find solace in the fact that (at least within these discussions) Gentoo is regarded as a traditional distro 🤣.

Or…, put more formally: Creating and maintaining precise terminology for the diverse Linux ecosystem is incredibly challenging. While nerds like myself would enjoy the classification work, the effort required to keep terms accurate and widely understood in this ever-evolving landscape is no joke 😭.

Anyhow, I might as well hijack the remainder of this comment to thank you and everyone else that made contributions to this discussion. Much appreciated!