Mfw CentOS Stream 9, using a kernel, compiler, and glibc version from 3 years ago, still manages to pull ahead of software released a few weeks ago on hardware released years after Stream 9’s original release.

So basically ostree deploy fails if you have an existing populated ESP (EFI System Partition), so you’ll have to partition manually atm (in my case, I just made another ESP on the same disk). Other than that, I haven’t run into any problems with Win11 + Fedora on the same disk, mostly because I don’t boot into windows.

You can read about the issue here: https://github.com/fedora-silverblue/issue-tracker/issues/284

Here’s the docs on manual partitioning: https://docs.fedoraproject.org/en-US/fedora-silverblue/installation/#manual-partition

It’s definitely a pain. One of many papercuts you’ll find with an “emerging” desktop edition on a distro already known to push new stuff before the Linux ecosystem is ready.

Just be sure to make a backup of your windows data in a separate disk, keep boot drives for normal fedora (in case this ends up being too difficult), windows (in case you give up), and Fedora Kinoite (because duh), and ffs, don’t trust ChatGPT with your sensitive data on your main PC :)

Can’t believe he figured it out. What a shame. Guess we’ll have to go provoke another country to invade our fellow flourishing independent democracies, who play a key role in the world’s trade.

Seriously though, I hope he’s just giving himself an easy out here. There’s always too much war going on.

Also see: systemd-bsod. Generates QR codes, too. I think blue for userspace boot-time errors and black for kernel stuff might be nice.

Go for FreeBSD: this might require a learning curve, because this is an OS I’ve never used. Are commands that different from debian?

Both of them are, at the very least, unix-like, so the core command set is mostly the same, albeit with sometimes large functional differences.

Simply install debian 12.5 again, the easiest choice.

You are familiar with Debian. This is probably the choice I’d go with.

Kernels are also updated more often than with debian as far as I know.

That’s why Debian has backports.

Mmm Russian propagandists going hard today, or rather, as hard as ever, ensuring to amplify the messages of individuals who already have questionable allegiance to the US in the first place. Just keep in mind the Ukrainians still want to fight. It’s not like the US are the ones trying to kill the Ukrainian president to get their way.

This is a great start, but tbh, I’m not fully sold on “verified” flathub apps. Verification requires a token to be placed into a source repo or a website, but there appears to be nothing on actually verifying that the source/site are the original creators. So, for example, if someone packaged a malicious version of librefox and established it under io.github.librewolf-community instead of the canonical io.gitlab.librewolf-community, I’m concerned it’ll still show as verified (though quickly removed). The process can be read about here.

The cheapest you’ll find that is still pretty good for HDDs is serverpartdeals. They have recertified Seagate Exos X22 20TB drives with 2 year warranties for $215. They also offer new drives with the full 5 years, ofc. Exos can be a little loud, as with other enterprise drives. You’ll still need a way to read from it in case you don’t have a spare drive bay, too.

Hah, those are the load times I used to get on my Xbox One with its dinky HDD. At the very least, The Midnight Ride has been updated to post next-gen, and I now get really small loading times (<5 sec) on my SSD. The game feels less rough around the edges, too. Only took 3 hours to set up :,)

Yes, all their images are purposefully normal fedora atomic images with stuff tacked on top. Some of that stuff comes in just scripts to make management a bit easier, some of it comes in the form of utilities like distrobox. They also come with zfs or proprietary Nvidia drivers or other things so you don’t have to manage them yourself, alongside tailscale and rpmfusion for nonfree stuff (like codecs). Some of them also have some light configurations, some of them have heavier configurations (especially in the case of bazzite).

You can totally do everything ublue does from a stock Fedora atomic image. Ublue just makes it a little more convenient. A sort of “oh, well I was going to do that anyway”.

Here’s the base dockerfile. As you can see, it confirms all of the above.

The US’s Department of Defense is one of Red Hat’s biggest customers. Other than that, the US government theoretically uses Linux quite extensively, going as far as making significant contributions such as SELinux. It was mentioned already, but academia uses Linux a lot, too. I saw lots of machines at SLAC running CentOS 7.

GNU/Hurd

It wouldn’t be too difficult(tm) to fork their kernel and make custom configs of it. Here’s the git repo that holds their rpms and their respective kernel configs, it’s just that nobody has cared enough to create/propose “slimmed down” specialized kernel images: https://src.fedoraproject.org/rpms/kernel/tree/rawhide You can just clone the repo and point COPR to it, then automatically build custom kernels.

Awhile ago there was a proposal to move the x86 microarchitecture level. Here’s recent discussion on that proposal: https://discussion.fedoraproject.org/t/what-happened-to-bumping-the-minimum-supported-architecture-from-x86-64-to-x86-64-v2/96787/2

In general, though, Fedora would not want to leave any users behind. Instead, the proposal for hwcaps is currently being drafted: https://pagure.io/fesco/issue/3151 With hwcaps, default installs will be x86_64 v1, but will be upgraded to “optimized” packages if available upon updating. This makes packaging a bit awkward, though. Packagers already need to maintain packages for multiple versions of the distro. In fact, they need to support F38, F39, F40, and rawhide atm. Needing to maintain an extra 3 builds for each package on top of x86, x64, aarch64, ppc64le, and s390x is a bit of a burden, so success might be limited.

Distrobox, while feature-rich, is still a bit hacky (though it’s still more reliable in my experience than toolbx). You’re not the first to want this, though: https://github.com/fedora-silverblue/issue-tracker/issues/440

I’d really like it if Fedora didn’t discourage packaging static libs, but still discouraged building packages with static libs. It’d be nice to have them for development purposes.

I also wish they made “third party” software a bit easier to access in their installer and distro as a whole. The option to enable Nvidia drivers is buried, and even though flathub is now unrestricted when toggled in the installer, it’s not the first priority when prompted for software to install in gnome software.

A longer support cycle with less releases would also be nice, but would defeat the purpose of the distro. I guess it’d make more sense if CentOS Stream released more frequently and with more packages available in EPEL, similar to Ubuntu.

It’d be dangerous if an installed app claimed to be something like sudo or bash. Even if a mechanism was created for flatpak apps to claim a single shell command, there is no centralized authority on all flatpak apps to vet them. If there was for flathub, and each uploaded package was checked, that still leaves every other non-flathub flatpak repo which must implement the same vetting. Because there’s no way to guarantee to do it safely, and because flatpak devs are unwilling to compromise, this is just what we get.

https://github.com/flatpak/flatpak/issues/1188

If anyone’s curious, here’s the RHBZ ticket listing the products RH has patched this in: https://bugzilla.redhat.com/show_bug.cgi?id=2262126

+1 to running whatever is packaged by your distro. For me, Fedora is rarely out of date. If worse comes to worse, you can always volunteer to become a packager and improve the ecosystem for everyone while fixing your own problems.

This is not April fools. The submitter did want to mess with people, though.

https://joshuastrobl.social/@me/112197672362783955

Hopefully DNF5 gets in for F41, especially since it was supposed to get in as the default for the current release, F39. If anyone’s curious, here’s the vote for deferring: https://pagure.io/fesco/issue/3039

The reasoning for the upgrade: https://fedoraproject.org/wiki/Changes/ReplaceDnfWithDnf5#Benefit_to_Fedora

And the reasoning given by the DNF5 team for targeting F41 instead of F40: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/EYE2JY537OM7GFW46EK7YIBLHJ52USAZ/ (though fesco also wanted to keep it in F41 to not disturb the mass branching from F40 to RHEL 10)

And some things that need fixing before it becomes default: https://github.com/rpm-software-management/dnf5/issues/1057

And some commands that will be/are implemented: https://github.com/rpm-software-management/dnf5/issues/429

Personally, I just hope DNF4’s (what)provides comes back in full.