Yes, probably. It is possible to flash and use dasharo (a downstream fork of coreboot) onto a modern MSI Z790A motherboard, which gets you pcie gen 5, 14th gen intel, and so on. I’m not sure if the necessary code to get it running has been upstreamed into coreboot yet. https://docs.dasharo.com/unified/msi/overview/

From there, you can use corna’s me_cleaner to disable (and clean) the management engine. There are reports of it working on alder lake: https://docs.dasharo.com/unified/msi/overview/

Here’s a full tutorial on disabling your ME on modern systems: https://github.com/mostav02/Remove_IntelME_FPT?tab=readme-ov-file#neutralizing-me-and-flashing-via-fpt

To be honest, though, I wouldn’t bother unless you’re doing it for fun. I’m not sure if this entire process necessarily works on the Z790+14th gen intel anyway.

To everyone saying you can’t mirror a flatpak repo… you’re absolutely right. There should be a far easier way to set up your own mirror without needing to build everything from scratch. That being said, if you wanted to try to make your own repo with every one of flathub’s apps, here you go:

https://github.com/flathub

https://docs.flatpak.org/en/latest/hosting-a-repository.html

Edit: Some did get a flathub mirror working. The issue is that a. Fastly works good enough and b. There is no concept of “packages” on the server side. It’s just one big addressed content store because of ostree, and syncing is apparently difficult? Idk, not being able to sync the state of content is like the entire point of ostree…

https://github.com/flathub/flathub/issues/813

It’s a good thing for the owners of the codebase, but often, a bad thing for the community (even if the community contributes to said codebase).

For example, FOSS maintainers sometimes will (want to) relicense to protect their income stream:

https://github.com/CaffeineMC/sodium-fabric/issues/2400

https://github.com/LizardByte/Sunshine/pull/150

While corporations might literally have maintainers sign away their rights so they can take the work from their own community:

https://lwn.net/Articles/937369/ (canonical requires a CLA, though this + the subsequent re-license might have happened anyway)

https://lwn.net/Articles/935592/ (RPM spec files are MIT licensed at the Fedora level. There are likely chnages to RPM files contributed by the community that are now source-restricted in RHEL)

https://networkbuilders.intel.com/docs/networkbuilders/accelerate-snort-performance-with-hyperscan-and-intel-xeon-processors-on-public-clouds-1680176363.pdf (See section 2.2. Previously, this work was BSD)

Mixed bag, really.

Same as any FF or chromium fork. The further away from the original you are, the longer security and performance updates will take to trickle down.

No. They likely don’t have the manpower to update it. It is run by students, after all.

To be fair, all the FF engineers probably dgaf about a platform where they don’t even have the freedom to use their own browser engine.

Floorp is great. It has so many features that make it better than stock FF.

If a new user installs malware from flathub while trying out mint for the first time, they’ll probably blame mint instead of flathub. Nobody will say “damn, I should have listened to that warning” while their “discrod” app rm -rf’s their entire PC away, they’ll instead claim Linux is crap and go somewhere else. Doing this helps keep mint safe, and definitely encourages unverified FOSS apps to hurry up and get verified.

I know ssh -X works fine in a rootless podman container, and so does waypipe. I’d be shocked if xpipe didn’t.

Don’t feed the trolls :)

I used to be a Kagi subscriber because I believed in their image for Orion. Their strong views on privacy, imo, directly conflict with their action to keep the product closed source “because it’d slow them down”, so I ended up unsubscribing. Good to see I unsubbed just in time.

The entire thing. It needs to be completely rewritten in rust, complete with unit tests and Miri in CI, and converted to a high performance microkernel. Everything evolves into a crab /s

Calamares has poor integration with the rest of the ecosystem including their existing tooling. For example, it has no kickstart support, and no support for their immutable installs (afaik, anyway). It was less effort to put their existing cockpit tooling into anaconda and make a whole new web ui than it would be to add support for all their stuff into calamares.

It wouldn’t be too difficult™ 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’s something we might see with the next EL release cycle. rpm-ostree has treefiles complete with the option for (experimental) lockfiles. There’s already config files for CentOS Stream to build CentOS Stream CoreOS, and those can be adapted for Alma. I think, atm, it’s more of an issue of general interest than technical limitations.

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

We might not be as lucky with the next one (or the ones in the past).

Or the ones in the present, for what that’s worth

I think that’s the issue here, but that might just be poor documentation

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