It’s like that new manger you get that thinks they should remove all these processes as they don’t see the use with them. Then slowly as they learn the hard way add all of them back.

And this is the reason “why?” is such a powerful question. If you’re coming into a role and want to reduce overhead, the first question you should ask is why things are done the way they are. In many cases, you’ll discover real tangible benefits to the processes that you would have otherwise missed.

In some cases, the answer will be “I don’t know, that’s just how we’ve always done it.” And those are the ones that are worth scrutinizing further, because that’s one of the most braindead sentences in the English language. If nobody can explain why a process is in place, it’s probably worth reexamining.

“I don’t know, that’s just how we’ve always done it.”

In my experience there often is a reason for it, it’s just that the person who knew the reason for it left the company and it was never properly documented, so now it’s just cargo-cult-policy without any understanding behind it. So you’re right, there’s no way to figure out why it’s done that way or if it should continue to be done that way without thorough reexamination and a pretty analytical approach, and when those reasons are old they can certainly turn out to be badly outdated, but I’d also caution against just blanket assuming that it probably isn’t necessary simply because it’s “the way we’ve always done it” and no one seems to know why. The erosion of institutional knowledge is relentless, but that doesn’t mean it was never known or never for a good reason either. It’s not braindead to follow a policy you don’t understand the reason for, it might be lazy and it might be putting too much trust in the people who made the policies, but it’s not always wrong. Sometimes the policies are written in blood, and you not knowing that doesn’t mean it’s not a good policy.

Which is why I said those procedures are worth reexamining, not just outright discarding. I tend to be against the DOGE chainsaw “just start hacking things off until it stops working” method. But asking “why” is a good litmus test for whether or not a procedure is worth spending time on.

It’s entirely possible that the “always done it this way” method is in use because that method works. The method was built using institutional knowledge that has since been lost. And those are worth examining for the exact inverse reason; To be able to reverse-engineer the institutional knowledge, and fucking write it down for the next person.

Yup, exactly! Sorry if anything I wrote sounded like criticism, I was agreeing and elaborating with my own experiences, that’s all.

Chesterton’s Fence

Nobara is likely the best candidate for you. https://nobaraproject.org/

Well, sucks for them, but why fedora should do it?

If it comes to that, rebase to Silverblue and use the Flatpak version of Steam.

A lot of apps and most games out there are 32 bit and need 32 bit support, trying to pull an Apple is naturally going to be unpopular and unproductive. This is one of those things about Linux and Linux development which is inherently problematic, which is the seemingly severe aversion to legacy support, despite the fact that Linux is often praised for running on older, less capable hardware, as well as taking better advantage of current gen hardware.

I don’t even know why this is even being discussed, it’s an awful idea and should never be implemented.

I’ll be gutted, bazzite feels like my forever distro and I really don’t want to give up atomic either!

Potentially the same problem since Nobara is also Fedora based.

Nobara’s not going anywhere regardless of how this goes down. At least on Nobara you won’t have to worry about your distro going tits up any time soon.

What’s even the argument for dropping 32-bit support? Just developer experience?

Many projects have already been officially dropping support for building and / or running on 32-bit architectures, requiring either adding back support for this architecture downstream in Fedora, or requiring packaging changes in a significant number of packages to adapt to this dropped support.

From the proposal, sounds like an overhead/maintenance issue. It’s ashame, I’ve been enjoying Fedora for the last 3 years since I made the complete switch to Linux from Wangblows

Maybe it’s about time I spend a week getting my Arch install just right