Fedora's CPU Proposal Is Way Better Than Ubuntu

21 thoughts on “Fedora's CPU Proposal Is Way Better Than Ubuntu”

• I hope this change will also straighten out the /usr/lib{,32,64} split. Supporting different sub-architectures and supporting 32-bit x86 on an x86_64 system is essentially the same thing.

• I don't know how flatpak works but if they don't do it now I hope they will borrow this idea.
  Overall idea feels like macos apps that are essentially archives/folders
  only here there are fixed folders and apps share them
  not sure I like it as cleaning up is more messy – you need to take care of many folders. I am surprised they don't put different archs im different segments of ELF file

• This is such a good idea that it almost makes me wonder if Ubuntu is partially doing their implementation out of malice.

• 6:30 I have an Ivy Bridge computer right next to me that's running Windows 10, and that would be moved to Fedora as soon as Win10 hits EOL.

• Guys what's this new crocus driver that doesn't even work in the daily builds of ubuntu ?
  It can't even run the ubuntu installer application because it misses something.
  Is it any good ?

• Which cpus are in which set is a mess created by cpu manufacturers. Sometimes, manufacturers choose to release new chips with old instruction sets and without the new features. This grouping is just done to help simplify the existing mess.

• I like the dynamic approach. Could be used to provide transparent transition times before dropping old hardware support, while also allowing those transitions to take place over a couple decades.

• It would be good to have a meta-package which would download only supported by the current hardware executables.

• I can say that I currently still run a home server on a Westmere (Nehalem die shrink) processor, so this is relevant to my interests. Any baseline above v2 would screw me over.

  That being said, this whole concern seems kind of dumb. The performance improvements are marginal in almost all cases, and if any application actually meaningfully benefits from the newer optimizations, there's already a mechanism to conditionally enable the newer instructions with just a bit of extra effort on the part of a given application's developers.

  The only purpose of this feature is to slightly improve performance for lazy developers of not performance-focused applications, but at least the Fedora implementation won't lock any users on older processors out.

• see but even then, id argue the cuttoffs are kinda stupid. avx1 is on sandy and ivy bridge, and outside of avx2 work specifically, haswell has very little other than (iirc) single digit IPC improvements over ivy bridge, theyre even the same process node.

• My 5950x is detected as a v2 CPU, so that's fun

• And this is where fat binaries might have helped.

  I like that Apple did add an x86_64h (h for Haswell) slice for their universal binaries. Kinda sad that I can't compile x86_64h for Swift.

• Using 7700X over B650, bring on the v4!

• 13900K, 13600K, 1370p

• zen 3 isnt v4 but skylake is??

• Compatibility aside, I have to say that I ran ALHP repos (optimized all possible packages up to v3) and recently CachyOS repos (here, even their v4 repo is growing) and it works really well. I haven't noticed any issues whatsoever. I'd say my systems that use these repos feel a bit faster, but that may just be subjective.

• Unlike some of folks here less than half my age having pro-euthanize-old-cpu opinions, I've used pre and post 386 hardware before.

  Also, back then, not when it was bleeding edge, but a few years after. The 386 was, in practical terms, out in the late 80s, and it was scrubbed from having linux kernel support THIRTY SIX YEARS after Intel announced the introduction of that silicon.

  15 y.o. hardware isn't the actual get-out-and-push kinda slow that 3-4 decade old hardware was.

  So, keeping the same timescale… no need to bring out the pitchforks and torches for the first parts of AMD-x64 architecture until AFTER the 32bit-ctime problem will have everyone all abuzz like Y2K in the late 90s.

  Not everyone on this planet is running linux on old hardware for nostalgia. Not everyone has first world funds to keep up with the bleeding edge. Slightly old computer hardware isn't the same as eating 8 year old expired canned food you found in a dumpster.

  15 year old hardware (at least, desktops) have peripheral upgrades that keep them more current than 386 hardware did even when it was relevant. In the few years before, and after the 386, peripheral slots changed several times, each to incompatible physical/pinout form factors. My Core2 motherboard can still run a SSD, or a more modern GPU. I will concede, not to the full capacity new hardware could. But, far more usable than a 386 trying to continue to work 1, 2, or 3 decades later.

  Let's keep the snobbery about hardware support limited to the far less free commercial OSes like Windows or MacOS, please and thank you.

• man i need to upgrade my i-7 920

• This is, if I understand correctly, basically the same solution as setting flags in Gentoo. Done differently, but same end result.

• wouldn't it be simpler to just not install versions of the libraries that will never be touched anyway? less bandwidth overhead, less disk space overhead, and you only have to evaluate at system install time, rather than every time you load a program into memory

• Ryzen 9 7900X with 64G DDR5-6600

Comments are closed.