biribiri11

Graphical environments are just programs just like any other.

They are in Fedora, too. It’s just that installing one DE overtop another can cause config file clashes (ie installing Plasma alongside GNOME means GTK apps will have a minimize button when logged into GNOME)

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.

Part of your credit score is also the present. It’s more than a bit predatory, but not having any current financial responsibilities looks bad. For example, if you have no loans whatsoever but paid back a bunch in the past, there’s little evidence saying you can currently pay them off. At least, that’s the theory of it.

I feel guilty even owning a house because it’s gotten so bad

It’s not like prices are going to rise forever. Market cycles are natural. There will be a crash, and there will be cheaper homes once again, and as long as the government is competent, random businesses won’t buy them all with the intent to rent them out to potential homeowners.

For the opponents, what is the proposed alternative?

I’d imagine this is the crux of the problem. Banks need some way to determine if someone will pay back their loans, and what better way than to tabulate their history of doing just that? Should banks be willing to take risks in a system with stuff like the 7 year rule?

SuSE and RH have their own legal teams who have combed through all of this and have decided not to chance it. Personally, I wouldn’t base a significant part of the foundation of any product on something as fickle as a Supreme Court ruling, especially when the product is something major from a group like SuSE or RH.

Yep, 41 unless something else happens: https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation#Current_status Not sure about the atomic desktops, though. F41 is also getting DNF5, so it’ll definitely be a cool release.

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

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(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