Fedora Plans To Drop Support For Legacy BIOS Systems (linuxiac.com) 122
The Fedora 37 development team is considering dropping support for non-UEFI BIOS. Linuxiac reports: The Unified Extensible Firmware Interface, or UEFI, is a modern method of handling the boot process. UEFI is similar to Legacy; however, the boot data is stored in a .efi file rather than the firmware. In the case of Fedora, while the change may take some time, the new Fedora x86_64 installations will no longer work on non-UEFI platforms. On x86_64 architectures, Fedora 37 will mark legacy BIOS installation as deprecated in favor of UEFI. While systems already using Legacy BIOS to boot will continue to be supported, new Legacy BIOS installations on these architectures will be impossible.
EUFI (Score:2)
If only there were a way... (Score:2)
If only there were a way [rodsbooks.com] for BIOS-only PCs to support UEFI.
FWIW, the link is almost 10 years old. No clue if this tool will work with Fedora 17 and beyond.
Bullet points (Score:5, Informative)
Just to place some things down about BIOS. Pros and cons about it always welcomed in replies.
BIOS, or at least the one we are so accustomed to, hails from the original IBM PC in 1981. The reason IBM's BIOS came to be known simply as BIOS is because of successful reverse engineering and the whole PC Clone stuff from days of hairspray and hostile take overs. Basically, everyone had a BIOS that was pretty much IBM BIOS that we all just started calling it BIOS.
The B in BIOS stands for Basic, and boy is that an understatement. When your system powers on and begins to run the code in BIOS to bootstrap the OS, it's running in 16-bit mode. So BIOS only gets about 1MB of RAM to do literally everything it might need to get that OS up and running. Hence a lot of hardware needs a kind of fallback that BIOS can talk to. Not getting into the details here as I'm sure other's would be more than happy to expand upon, but basically, your system knows very little about itself by the time the OS is getting loaded. Again, there's arguments on why that's not BIOS' job and what not, but just a point to make here.
BIOS needs to use the Master Boot Record (MBR) system for identifying how to boot the OS. However, MBR is limited to 32-bit for identifying the size of the boot drive (and of course it's signed, so really 31 bits). Which some of you might have ran into this, maybe not. But if you have an OS on a drive bigger than 2.1TB MBR will just straight up refuse to boot with that device, no matter when the actual boot partition is.
BIOS also (subjective warning here!!) hasn't aged very well in the decades we've had it.(Okay, subjective off, but I'm going to justify that, just give me a second). ACPI is an addition to BIOS to add in all the power stuff and the hacky way vendors have had to "add" ACPI has lead to very interesting results, depending on what incantations your OS issues to work with ACPI. And ACPI is just one example of things we've bolted on along the way to BIOS. Now there's arguments for "clean slate" and "not BIOS' job to ensure it works". Again I'm sure everyone will have opinions on it.
Intel came up EFI in 1998 to replace BIOS and Apple picked it up, but literally nobody else did. That spurred AMD, Intel, Microsoft, and a lot of PC (and Apple) makers to come together to build something that everyone agreed to. Which in 2007 that was UEFI.
UEFI can now boot from a drive as large as 9.4ZB using the GPT system. Additionally, UEFI can run in either 32-bit or 64-bit mode granting way more space than BIOS had, meaning much faster bootstrapping. Additionally, there are EFI binaries that can preemptively load all kinds of drivers in so that your OS has more information about the system it is booting into. In fact UEFI adds in a lot of features on power management, network capabilities, graphic abilities, and so on. That you can have keyboard+mouse GUI with the ability to netboot from the UEFI (no longer do we need the PXE boot disk, it's baked into the hardware in a standard way).
Now of course, the negative that I hear plenty bemoan. UEFI brings with it SecureBoot (insert gasps). I'm sure everyone could write a small book about this. So I'll just leave it at that.
The thing to remember about Fedora's call is this. Systems already under legacy BIOS are still supported and as of F37, if you have a system that is BIOS only, you will still be able to install. What is being slightly curtailed by being marked deprecated is new install on Legacy BIOS on systems able to do UEFI. As of 2020, quite a few motherboard makers are no longer shipping legacy BIOS support in their boards. The Fedora people feel we've crossed the threshold ("debatable but you know whatever") of motherboards on market that no longer have BIOS to warrant this change.
Ah but what of "older" computers. The thing is that there were a sizable number of mobos shipping UEFI in 2007 and 2009 would be a year you'd be hard pressed (not impossible) to find a mobo without UEFI. Now I'm sure that gives no comfort for those of you out there with your Intel Pentium III that's still chugging as a file server or whatever. But do note that Fedora is recommended on a system with 2GHz or better, to which you're P3 is distinctly not going to run. For you all still clinging to these systems, alas, the end of the road has come for any ideas about running the latest Fedora and it may be time to reconsider your Fedora 28 (2018 if you're wondering) install (Fedora 29 distinctly pushed the requirements past the 1GHz point) and where you go from here.
I get we all lament the dropping of older hardware by one of the big kids in the operating system pool. But do remember, the pool is large and there's plenty of other kids in it. And if you're Apple, you're the kid peeing in the pool but for some reason everyone loves swimming next to you.
Okay that's all, I think the Fedora people are giving plenty fair warning about what they expect to do, which I would say is way better than one day them going "SURPRISE BITCH!" I know we all hate it, but we're at least being giving a heads up about it. I mean it could be worse, it could be Apple and them being SURPRISE BITCH! YOU DO NOT NEED USB-A ANYMORE!! Oh wait, that's exactly what they did.. Hmmm, curious.
Re: (Score:2)
After a while, when Microsoft came out of the dark ages, the BIOS wasn't needed as much and became nothing more than a bootloader. Doing BIOS, or UEFI calls, in a modern OS is ridiculous. Especially Linux because it really doesn't use the BIOS much at all once you've started booting.
Part of the problem is that the PC architecture is such a terrible ad-hoc mess that the BIOS/UEFI are really there just to hide all the creaky details.
Linux syscall analogous to DOS BIOS calls (Score:2)
Doing BIOS, or UEFI calls, in a modern OS is ridiculous.
Linux syscall are pretty much analogous to PC BIOS calls, the concept lives on under a different name, nothing more.
Re: (Score:2)
Re: (Score:2)
No, they're not even remotely similar. Indeed, they're polar opposites.
They both represent an API offering low-level functionality where you pass parameters and returns in registers and invoke functions via interrupts.
syscalls are how you communicate with the Linux kernel.
You are confusing what they call with how they are called. Even with the former there is some similarity, BIOS was providing OS-like functionality.
BIOS calls started off as how the operating system would access the hardware back when hardware was less standardized ...
Absolutely wrong. BIOS started out absolutely standardized, one target, the IBM PC. The programmer's reference manual for BIOS calls was literally the IBM assembly language source code listing of BIOS. IBM would sell t
Re:Bullet points (Score:4, Informative)
The BIOS is composed of many different pieces and parts. There's the bootstrap part of it which is the bit that performs basic power on tests, configures hardware and then does the necessary bits to load the OS - either via legacy 16-bit mode, or modern UEFI 32-bit mode.
But there are other parts and those parts are important to operating systems. The bootstrap mode also produces a series of tables in RAM that tells the OS the hardware configuration - where chunks of memory are, what the PCI bus (including PCIe) configuration is, peripherals and other things. Sure the OS can probe and reconfigure things like this itself, but you'll find a good chunk of the OS needs to be loaded and running before you can do that. As such, knowing how to access deices "early" can be a great help in getting the system up and running.
Example - in Linux, you don't see Tux or the console messages until after the console hardware is initialized - in the meantime, boot messages, including the Linux signon message, are buffered in the printk buffer until console initialization. Console initialization happens near the end of the kernel startup sequence when the kernel is probing for hardware and discovers what would be the console device which is either a physical console, a framebuffer, serial port, etc. Once the console is initialized, the printk buffer is emptied
But during this initial startup, the peripherals are usable to the operating system. Linux has "Early printk" that can use these pre-initialized devices to output printk messages basically from the get-go, and once the kernel has initialized itself tot he point it can run the console itself, it disables early printk and finishes the console initialization by dumping the printk buffer.
I wouldn't doubt Windows is also using the pre-initialized peripherals for things like the kernel debugger to the splash screen shown on boot.
Another module is ACPI. These started as a basic table for power management - power management on PC was a finicky affair since laptops existed long before any form of OS managed power, so the early revisions of PC power management was done by the BIOS. But by 1995 this was unworkable, so as part of the Plug and Play specification came Advanced Power Management where the OS itself would manage the system power states. This later evolved into ACPI which is a bytecode system that basically are OS independent drivers to allow various parts of the PC to be controlled - from things like switches (e.g.., lid closed on a laptop) to batteries, to even things like sleep, suspend, hibernate and even power off.
It's the primary reason why BIOS updates can lead to improved system stability - it's not that suddenly they load the OS better makes the system more stable, but core critical functions the OS needs to do often have bug fixes in the OS independent driver and make the system more stable by fixing bugs in the way the driver works.
So while the old legacy unctions of a BIOS no longer are used (they were useful in the 80s and lead to a rise in non-IBM clones that could run MS-DOS software, called MS-DOS clones. These were often not IBM PC compatible at all but were capable of running most major applications like Lotus 123 and Word Perfect at the time. But to say it's completely useless after the OS boots is also incorrect
Re: (Score:2)
AFAIK you can boot from a GPT drive with BIOS (or in legacy mode), just that you need to create a "bios-grub" partition as the first partition on the drive.
Re: (Score:2)
Yes, but this "GPT drive" contains an actual MBR, per GPT specification, so to a GPT-unaware software the GPT drive mimics a familiar MBR drive.
Re: (Score:2)
Sure. It still means you can boot from a large drive using BIOS, either "real" BIOS or "legacy mode" of a newer device.
"BIOS" know due to source code ... (Score:4, Informative)
The reason IBM's BIOS came to be known simply as BIOS is because of successful reverse engineering and the whole PC Clone stuff from days of hairspray and hostile take overs. Basically, everyone had a BIOS that was pretty much IBM BIOS that we all just started calling it BIOS.
It was simply BIOS before the clones. The IBM source code listing to BIOS was the official API documentation. You could buy the BIOS listing from IBM in a little maroon (?) three ring binder. You needed the assembly language BIOS listing to find out what registers held and returned what parameters for calls to BIOS. PC software rarely made calls to DOS only, many times you needed to call BIOS. PC apps were generally a combination of DOS and BIOS calls.
That's why the cloning that came later was so important. Much of the software running on the PC was coding to an API defined by a single assembly language source code example, "the BIOS".
Re: (Score:2)
I don't get the hate for Secure Boot, I use it extensively to protect my systems from malware and from tampering.
Re: (Score:2)
BIOS needs to use the Master Boot Record (MBR) system for identifying how to boot the OS. However, MBR is limited to 32-bit for identifying the size of the boot drive (and of course it's signed, so really 31 bits). Which some of you might have ran into this, maybe not. But if you have an OS on a drive bigger than 2.1TB MBR will just straight up refuse to boot with that device, no matter when the actual boot partition is.
BIOS does NOT need MBR to boot an OS, and has never needed it. The MBR is not a part of the BIOS specification, but a convention and an industry standard, created by IBM for their IBM PC/XT computer, and faithfully followed by all clone makers and OS makers and diagnostic software makers since then. BIOS only needs to be told the disk location of a boot sector, which then gets loaded in memory and jumped to, and while MBR can be used for this purpose, its use is not mandatory.
About the large disks - the "in
UEFI sucks sometimes (Score:5, Informative)
Given a Dell server:
BIOS will boot the 1st device in the list then the next ones in order. The "Hard Disk Failover" mode will try booting from subsequent HDDs if the 1st fails - excellent when RAID disasters happen.
UEFI needs to have the OS registered with the UEFI device map and if that's ever disturbed you get a server waiting in the UEFI shell requiring manual intervention.
BIOS defaults the console to 80x25 text mode. UEFI will try to detect the maximum resolution on a monitor and might leave you in a very high resolution framebuffer mode - the last thing you need when you have to fumble on the console in the middle of the night from a tiny iDRAC remote window or on the datacenter floor with crash cart with a LCD that will proudly say: "Resolution out of range"
Yes, you can switch even the newest Gen 15 servers to BIOS boot mode.
Re: (Score:2)
There was a time where you'd have a default RS232 9600BPS-8N1 console for servers, both at BIOS level, but also in LILO and system console if you choosed to.
It was very handy to just plug a terminal and look at the output, with bonus you could have it grouped into a console server and remote telnet/ssh to it, so you didi not need to enter the noisy cold DC, but handle it remotely even at home if you were on an astreint (call-out duty).
Re: (Score:2)
Terminal MUX in every rack + serial cables for every server = unhappy datacenter people (more cables) and unhappy beancounters (extra cost) and unhappy windows admins (windows server without GUI ? Blasphemy !)
There's IPMI SoL (Serial-over-Lan) but security people say IPMI connections are not encrypted enough to their liking for a root password.
Re: (Score:1)
UEFI needs to have the OS registered with the UEFI device map
No it doesn't, but it *can* be setup that way. If this is an issue for you then you should select only CMS options in your boot order.
UEFI will try to detect the maximum resolution on a monitor and might leave you in a very high resolution framebuffer mode
It'll match the resolution of the display attached. If your display doesn't support detecting the resolution maybe you should fix that.
Honestly it sounds like you're battling with a) crap hardware, b) a singular crap example of UEFI implementation, c) user error and somehow blaming that all on the existence of UEFI.
Don't do that. It's not helpful.
Re: (Score:2)
No monitor attached. It's a server in the datacenter. Yes, some other hardware and implementations might be better, that's why I put "sometimes" in the title.
Which other (non-Dell) servers have you seen with better UEFI implementations ?
Thanks !
Re: (Score:2)
What you missed is with UEFI boot time are massively slower. It was bad enough booting a server in BIOS mode. In UEFI mode boot time are just terrible.
Other distros that support legacy? (Score:2)
I can't get the latest Ubuntu to boot on non-UEFI hardware. This is for a kid's computer to keep an old, yet decent system out of the landfill.
Any suggestions for other distros?
Re: (Score:2)
I too have set up Linux machines for kids to get extra use out of old hardware. Depe
Re: (Score:2)
Have no idea about Ubuntu, but Debian still works on BIOS systems. And Slackware will surely support these for a few decades to come :)
Re: (Score:2)
I use PCLinuxOS with KDE desktop. Runs well on any x64 (I have it on a 15 year old laptop). On an i7-3xxx, it boots to the desktop in 5 seconds flat.
-- Caveat: something in the current kernel does not like some older ATI GPUs, and won't install on 'em. Wasn't just us affected, but be aware.
uefi means 'dd to copy' no longer works (Score:2)
unless something changed, having your system setup to boot uefi means that I now cannot (easily) just take a dd of a full /dev/sda and then move it to another system and boot from it.
I always turn off uefi so that I CAN do this and clone systems at work for labs.
odd that systems that are installed fresh with uefi seem to have faster disk i/o than the same init'd disk but with old style geom and setup. all using aligned sectors, of course.
I dont use redhat crap anyway. my last good redhat experience was 4.
UEFI is IFFY in 2022 (Score:3)
Really bad decision (Score:2)
Wrong move. Bad decision. Stupidity.
OpenSSL 1.2 FTP requires 1.2 TLS to download ??? (Score:1)
Re:I don't get it (Score:5, Informative)
It reduces the code maintenance burden.
As older hardware is phased out it becomes increasingly difficult to both find hardware with working legacy BIOS and people familiar enough with these systems to actively maintain them. At some point, the pain of maintaining legacy just becomes too much. Ergo, drop legacy support!
To be fair though, UEFI has been around since 2006, let's say 2010 to be generous with how soon it became available everywhere. If you are still running a Pentium 4 or Athlon 64 machine in any kind of modern setting it is time to reconsider.
Re:I don't get it (Score:5, Informative)
I have systems here that are newer than 2010 without UEFI support. It took quite a bit longer for it to not only get rolled out, but also be stable. These are perfectly capable multi-core systems with plenty of RAM comparable to what is still sold today, and SSD drives.
And to answer the GP, yes, RedHat makes hardware, its called IBM :)
Re: (Score:1, Insightful)
I hate to be the one to break this to you, but 2010 was 12 years ago. That hardware is fucking ancient.
re: ancient hardware (Score:5, Insightful)
I'd argue that especially for server class machines, an "ancient" one from the 2010 era is still pretty viable in quite a few scenarios. We've got a few still in our workplace because we have lots of smaller sites we manage, and one location, for example, runs as a "sister company" to our main one. It has its own domain for the Windows machines so it serves as their on-site domain controller. If it dies? Cool, we'll replace it. But it's been rock solid reliable all this time, doing what's needed.
Especially when you get into using Linux, it's often implemented where you're fine with "slower, older" hardware but simply need reliability.
Re: (Score:2)
Re: (Score:2)
Which sane company would not make that calculation? I also run almost 10 year old hw in datacentre and for me it's still not worth it to do a forklift upgrade. If DC charged me per every single Amp and every single rack (instead of a room full of racks), then maybe. Cooling also isn't a cost that reflects my racks' heat output.
Re: (Score:2)
Re: (Score:2)
By the time the replacement server pays for itself in power/cooling savings, it's going to be long obsolete. Hardware from 10-12 years ago isn't that inefficient, so if it works and does the job you might as well keep using it.
Re: (Score:2)
Re: (Score:2)
Hell no. Server machines from 2010 aren't even Sandy Bridge. Enjoy your Smeltdown. I know a lot of people that obsessed over those old Westmere Xeons since they're overclockable, but those things just don't hold up anymore. Seriously get a 5950X or 12900K on an ECC system and be done with it. Much better perf/watt and fewer hardware vulnerabilities.
Most PCs from 2010 are now hot garbage begging to be pwned by exploits you can't even patch out because Intel doesn't give a fuck. And frankly AMD doesn't
Re: (Score:2)
an "ancient" one from the 2010 era is still pretty viable in quite a few scenarios
Sure, they make for some great inefficient space heaters in the winter.
Re: (Score:2)
They also work great for homelabs. I have a dell 510 and r710. I'd probably save a lot of money energy wise upgrading them with a home built machine with lots of harddrive bays, but the initial cost factor versus long term savings makes this a difficult transition.
Re: (Score:2)
I'd argue that especially for server class machines...
Except this article is about Fedora.
Re:I don't get it (Score:5, Insightful)
With that logic that would seem to make you ancient also.
Computers compute. From creation until the magic smoke comes out, which makes them quite useful for many peoples other than you. My truck is from 2004. It is ancient too. But it runs fine so I still drive it. It still does the speed limit so it is useful. It still hauls my friends' furniture. I could go on. Your argument is weak to say the least.
Re: (Score:2)
From creation until the magic smoke comes out
No. Most computers do not get used until smoke comes out. They get used until they get replaced with something that is objectively better in relevant metrics, e.g. Speed for games, hardware compatibility for home PCs, energy efficiency for servers.
My truck is from 2004. It is ancient too.
Indeed, and if you lived in my city you'd not be allowed to drive it at all anymore due to emissions regulations much less drive at the speed limit. Which begs the question, would you still have it if you could no longer drive it? Would you still have it if you we
Re: (Score:1)
It's a Hemi.. It actually produces extra oil!
Re: (Score:3)
I hate to be the one to break this to you, but 2010 was 12 years ago.
So?
That hardware is fucking ancient.
It used to be in the 90s "fucking ancient" was a year or two ago. Today it's a meaningless term. There is nothing wrong with decades old hardware and no reason to throw it away. New is not going to get the job done any differently or better especially for most Linux servers that sit idle 99% of the time.
Re: (Score:2)
If your hardware is old enough that it actually really does need BIOS functions instead of just working under the lazy assumption that they're there without ever actually using them, then your hardware was almost certainly made in the 90s. Most likely the hardware that you have that "requires" it just uses a tiny portion of it, maybe like a single interrupt hook or something, and the rest of it is just fucking ignored. Your OS uses basically none of it unless its either DOS, Win9x, or OS/2, in which case, y
Re: (Score:3)
OS/2 here boots up and runs fine on UEFI systems, at that it is required if you want to boot from a GPT disk. Only problem with the newest hardware is sometimes the video frame buffer is above 4 GB memory, so OS/2 can't use it and so won't run.
Re: I don't get it (Score:2)
Does it run without the CSM enabled?
Re: (Score:2)
Yes, it is actually a beta of ArcaOS, an OEM version of OS/2. In the ESP partition,
[U:\EFI\OS2]dir
The volume label in drive U is EFI_SYSTEM.
The Volume Serial Number is 1B20:1618.
Directory of U:\EFI\OS2
1-25-22 8:07p
1-25-22 8:07p
1-23-22 5:28p 780,676 0 ---- os2ldr.bin
1-25-22 8:07p
1-22-22 9:34a 104,736 0 ---- os2ldr.efi
5 file(s) 885,412 bytes used
62,780,928 bytes free
Re: (Score:3)
OS/2 here boots up and runs fine on UEFI systems
Is that with or without calling on the services of a necromancer?
Re: (Score:2)
OS/2 isn't dead yet, https://www.arcanoae.com/uefi-... [arcanoae.com]
Re:I don't get it (Score:4)
It maybe "fucking ancient" but some of it is still good hardware. I know some people that are still gaming on Amd 8350's. Not as many frame rates as current hardware but still high enough to game on.
An those AMD dinosaurs are still way over kill for normal office work.
Re: (Score:3)
It also may be very difficult to replace due to legacy data or software that is no longer available, or whose availability is quite uncertain. Many mortgages last 30 years: the records of payment for those are vital data involving billions of dollars of property.
Re: (Score:2)
Re: (Score:2)
Not as many frame rates as current hardware but still high enough to game on.
Define "game". I'm sure it plays Candy Crush, but goddamn modern games are way too amazing to play on potato mode to cram them onto ancient hardware.
Hate to gatekeep, but if you think a 10year old computer can be "gamed on", then you're not at all a gamer.
Re: (Score:2)
Dude, newer mods for the original DOOM can bring modern systems to their fucking knees.
You don't know what 'gaming' is.
Re: (Score:2)
Hate to gatekeep, but if you think a 10year old computer can be "gamed on", then you're not at all a gamer.
The reality is just slap in a modern GPU and you are good to go. A higher end 9-10 year old PC will play all the modern games even in VR just fine.
Re: (Score:2)
Very much so, my son uses my previous desktop to VR often, not sure which gen Core it is, but it is more than 10 years old at this point. It has a more modern video card, a 2060 I think, so it has the graphics horsepower, and seems to be good enough framerates and lack of stutter that he plays beat saber at a much higher ability level than I do, so I assume it is still working fine for the purpose.
My modern desktop has some kind of issue, and it won't even get to boot if UEFI is enabled, so I have it runni
Re: (Score:3)
My modern desktop has some kind of issue, and it won't even get to boot if UEFI is enabled
BIOS and UEFI OS installs are not compatible. You can not switch to UEFI if your OS was installed under at BIOS enabled system. There are ways to change a BIOS installed OS over to a UEFI but I look at them with a skeptics eye. If you are happy with Windows 10 on a BIOS install, I wouldn't' worry about. But just know some where down your road there is a complete system reinstall or some hanky back door OS tricks to switch to UEFI boot.
Re: (Score:2)
I know. Fixing that issue I reinstalled a dozen times before I tracked down why it wouldn't boot after the initial installation.
Re: (Score:3)
We long ago passed a plateau in computers with need vs want. There once was a time when I swapped out CPU"s twice a year, and did complete system rebuilds every two to get more noticeable power. This hasn't been a issue for at least the last 10 years. Current systems are more powerful than those of 10 years ago, but most people won't notice it in every day use, or even when gaming.
I believe we are reaching such a plateau in GPUs too. I'm still running on a couple of crusty 1080Ti's. While I long for
Re: (Score:3)
Hate to gatekeep, but if you think a 10year old computer can be "gamed on", then you're not at all a gamer.
You're really going to pick this hill to die on? :)
Yes, a 10 year old computer can be "gamed on." Hell, a 30 year old computer can be gamed on based on all the retro gaming videos that keep showing up in my YouTube feed. Not every one out there cares about frame rate. Most people care that the action is smooth, with min lag and tearing as possible. That AMD 8350 that I talked about has a RTX 3080 in it.
Yeah, that was my thoughts on that too....
But anyway, he is perfectly happy on that system.
Re: (Score:1)
Re: I don't get it (Score:2)
My dual xeon 96gb ram t5500 is not ancient, it works just fine thankyouverymuch
Re: I don't get it (Score:2)
Re: (Score:2)
Yes, but they have made so few improvements in 12 years, that a 12 yo computer can perform like a brand new one. Put a 1080 on a 12 yo middle of the road processor and you are modern gaming.
Re: (Score:2)
Not really. Even today, a GPU might stall a lot of the CPU can't keep up. Point in case, ran an i5-6600 with a RTX2080 for a while as a stop-gap measure. Then I swapped for a Ryzen 3800. Boom, even the mostly GPU-bound games suddenly ran faster, especially as you increased graphics details and resolution.
Re: (Score:1)
Re: (Score:2)
Read the post I responded to, as well as some of the others. They all stated that the CPU doesn't matter any more, only the GPU.
Re: (Score:2)
Shorter lead time too. Building one of these things takes 4-5 years from drawing board to it rolling down the slipway.
Re: (Score:2)
The computer I'm typing this on is from 2012, and it's a BIOS system. A long time ago Gigabyte released a "beta" update with UEFI support for this board, but it was crap so I went back to the plain BIOS. Sure, it's a 10-year old system, but it's also a quad-core i7 with 16 GB of RAM, and it more or less benchmarks similarly to the new Core i3 systems we're getting at work. It wasn't until a couple of years after I built this PC that UEFI support was more or less universal amongst new hardware.
Now "fuckin
Re: (Score:1)
I have a 667Mhz G4 Mac with a SSD ...
The fact that your bragging about a SSD in 2022 kind of puts you in the curmudgeon territory. Yes I have patched up old core 2 machines for buddies and actually a couple charity's during the peak of the pandemic, and with 8 gigs of DDR2 and a SSD they run fine as basic windows 10 office / internet boxes (yea you could use less ram and be ok on linux but really, who wants to use linux)
I would not call them capable or comparable to what is sold today unless your comparing
Re: (Score:2)
I have a 667Mhz G4 Mac with a SSD ...
The fact that your bragging about a SSD in 2022 kind of puts you in the curmudgeon territory.
And at the time that you bought that g4 mac you were absolutely convinced that it was the fastest consumer CPU ever made. And then Apple crushed your pride by switching to x86 a few years later.
Re: (Score:2)
And at the time that you bought that g4 mac you were absolutely convinced that it was the fastest consumer CPU ever made.
I dunno if I'd go that far but those G4s certainly ran rings around the pentium 4s, especially if you used something that could take advantage of Altivec
And then Apple crushed your pride by switching to x86 a few years later.
Those core solos were warmed over Pentium Ms which were in turn warmed over Pentium 3s. It wasn't until the Core 2 duo that you could reasonably say that apple had surpassed their previous flagship offerings. The intel switch was about getting something newer than a G4 in a laptop and I can't blame Apple for doing that, but to say Intel were making "better"
Re: I don't get it (Score:1)
I got it 2 years agi at a yard sale asshole
Re: (Score:2)
That's the same for me - fully working well performing hardware that now hits the 10 year mark.
That has been one of the primary advantages with Linux - you can use old hardware without problems.
So now it's time to shop for another Linux distro.
Re:I don't get it (Score:4, Informative)
I have systems here that are newer than 2010 without UEFI support. It took quite a bit longer for it to not only get rolled out, but also be stable.
Rolled out by whom? UEFI has been a thing since 2002, though at that time called EFI. UEFI is a specification, not an implementation. When and whether the implementation becomes stable depends on your vendor. The only reason you wouldn't have it is because your vendor simply chose not to implement it at that time and/or didn't have an implementation available at that time that they considered stable. You could have added UEFI as a requirement in your purchasing decision; plenty of implementations were available and stable at the time. Apple's first Intel based macs were all EFI based and switched to UEFI as soon as it became available in 2007, which is around the same time that many vendors already had stable implementations available. The only ones who didn't were just being cheap, basically putting it off until newer chipsets came around that wouldn't even work without it, and even then they often chose to do things half-assed and make the CSM mandatory to support newly built hardware based on old designs, because said hardware still had option ROMs written in 16-bit x86 that had to hook into BIOS functions.
EFI/UEFI omits a lot of crap present in BIOS that stopped being relevant by the time of the 386, and it became almost entirely irrelevant by the mid 90s when basically everybody was using protected mode OS. I don't know why people insist on keeping that shit around. It would have actually taken off faster if Microsoft had gotten off their asses and supported it earlier, especially given the NT versions of Windows (which EVERYBODY was using at that point) had basically no use at all for BIOS. They still won't support it on 32-bit, which contributes to the reason a bunch of morons out there (including here on slashdot, who also stupidly believe UEFI requires secure boot, that it requires a GUI or has anything at all to do with a GUI, and other nonsense) think UEFI is a 64-bit only specification. In fact UEFI doesn't make any kind of stipulations at all for CPU architecture; it doesn't even have to be x86. BIOS does though, in fact it was built around the idea that you had a 16-bit intel CPU, and provides a bunch of helper functions (in 16-bit x86) specifically intended for DOS as well as option ROMs that you almost certainly don't even use anymore.
Re: (Score:2)
Fedora is the alpha test version of RHEL. If it doesn't support the redhat bottom line, it's not going into Fedora... or it's coming out. This has always been true. It has never made sense for anyone to run Fedora. But people do it anyway, because they want to test RHEL for free. I personally prefer to avoid unpaid labor.
Re: (Score:2)
I was just fighting with a bunch of 2012 Nexcomm machines recently, trying to get them to boot UEFI, and despite a few references to UEFI and EFI in the BIOS, it does not seem possible. Guess somebody is going to have to upgrade a bunch of machines soon.
Fedora has limited usefulness itself (Score:5, Insightful)
I'm sorry, but this is a bullshit argument. Or at least, it should be. How often do you need to revamp the boot-up logic? Like hardware drivers, once you have working drivers for hardware, which doesn't change, any breakage comes from elsewhere in the system. Certainly not from new "legacy BIOS" machines that need quirks addressed because they're not being made any longer. IOW, the "maintenance costs" are induced by your own inability to provide a stable internal API or otherwise insulate parts of the system from each other. Dropping hardware support because "maintenance burden" is therefore a sign of your incompetence.
Now, fedora's use case as the little free-as-in-beer brother to RHEL makes it itself a legacy maintenance burden on the commercial company red hat. So it makes middle management sense for them to sabotage it for older hardware.
But for linux as a community thing, it makes as much sense as dropping x86 (ie, 32bit) support. There's still quite a lot of hardware Out There in use and working fine, TYVM, that would NOT be served by forcing to switch to UEFI even if it was possible.
Besides, UEFI is a bad idea done badly. We'd be better served with a functioning coreboot that could be easily installed on just about every modern machine you would care to buy, and with that get something with the flexibility of OpenBOOT and geared toward booting FOSS OSes under full operator control. But of course, that's not something red hat would ever work toward. Instead, they would rather work toward windows-ification through the works of poettering and his toady crew.
As to me, I'm typing this on an athlon 64, running 32bit tiny core linux for xterms and a browser, and that's the newest currently in use. The real work happens on a VIA C7. Both are on 24/7 and in use whenever I'm not doing something else. The only real problem is chasing ever newer browsers because ever more websites "upgrade" to be incompatible with my browser for... no gain. Most sites I tend to visit (or used to visit) would be just as well served with HTML4, since text and maybe some pictures are all I'm interested in.
So here too, we see a tendency to run forward, move fast, break things... and manage to lose in the process, but not gain. Thanks, webshits.
I think that the longer computing is with us, the more we're going to have to own up that replacing the entire infrastructure, hardware and software, every few years just so we can keep tinkering with the software because we cannot be arsed to get it right the first time, is unsustainable in the long run. And that means much longer hardware support than your theoretical 16 years. My mobile phone is older than that, and it still works fine, as it should. My landline phone is close to that much older than I am, and also still works fine. Computers for most people don't need to double in speed every 18 months, haven't for a long time actually. If not for the GUI bullshit, the daily stuff of writing emails and letters could be done on an 8-bit computer with multi-tasking to boot. Yes, faster computers are more convenient, but convenient to whom? Currently to people not even there, so they can write ever more sloppier code and call their polished turd a webbrowser. And they expect me to chase after them with constant software updates and regular hardware replacements? If they'd be less lazy I wouldn't have to expend the effort or the money.
So no, for "the linux community" it's not remotely "time to reconsider". Well, whether you'd want to keep on using fedora, maybe. I certainly wouldn't, but I definitely stopped with all things red had around the time of the split, anyway.
Re: (Score:2)
Fedora can't bring us functioning coreboot for all because functioning coreboot requires either vendor support or a lot of trial and error per-motherboard hackery.
Re: (Score:2)
I'm sorry, but this is a bullshit argument. Or at least, it should be. How often do you need to revamp the boot-up logic? Like hardware drivers, once you have working drivers for hardware, which doesn't change, any breakage comes from elsewhere in the system.
You do realize that any call into BIOS requires 16-bit real-mode addressing right? It's not just boot code that has to do that, hardware drivers require it too if you happen to be using old hardware, which means it has to be done in the kernel. And the
Re: (Score:2)
That's only if your hardware drivers use BIOS, which to my knowledge no-one does. Unless they absolutely have to.
Some hardware has to be initialized via option ROM by BIOS. Take basically every VESA implementation for example. If it's not, you'd have to write a shim to call into it the same way BIOS normally would as part of your driver.
Maybe this betrays my ignorance but I can't off-hand think of anything that really needs to. The drivers will just talk to the hardware directly.
https://man7.org/linux/man-pag... [man7.org]
See also:
https://github.com/mqudsi/lrmi [github.com]
Basically this is how userland code can make BIOS calls.
Idiot things like requiring FAT in the kernel just so you can boot. That sort of thing not only shows a specific focus on a certain vendor, it also is a potential IP liability.
The kernel doesn't have to support FAT at all, rather the boot files and any extensions for UEFI need to be stored in it. Here's a minimal UEFI bootstrap, ba
Re: (Score:2)
How often do you need to revamp the boot-up logic?
Is that a trick question? Because the answer is on the release of every new CPU architecture. Or did you not realise bios updates to support newly released CPUs have been a thing since the days of the 386?
But hey since you're so passionate why not volunteer to Fedora to maintain said codebase? I'm sure they could use your support.
We'd be better served with a functioning coreboot that could be easily installed on just about every modern machine you would care to buy,
If ever someone could mistake you for someone who had a clue you just removed all doubt.
Re: (Score:2)
Besides, UEFI is a bad idea done badly.
I always assumed that the real reason why UEFI was introduced, was to preserve Microsoft's monopoly by attempting to destroy the ability to dual boot operating systems on PC hardware, while also giving it just enough superficial flashing lights, that excuses would be made for it as "innovation," by the same group of treasonous idiots who think that systemd deserves to exist.
Re: (Score:2)
Linux, AND Fedora, support more than just PC architectures. It saves some small work only for part of the team.
i call bull shit... what about VMs (Score:2)
And running a VM in legacy bios mode is so hard is it?
Lazy people, the 1990s coders were more gung ho better.
Re: (Score:1)
AFAIK yes, they do still have that big enterprise server rack joint-venture with Dell.
Re:I don't get it (Score:4, Insightful)
> Does Red Hat sell computers? What interest do they have in getting people to throw away their old hardware?
I'll try to steelman it:
1) only advanced users use Fedora and they're the ones who use RHEL at work. Their company will ensure they have a modern PC.
2) RHEL9 may or may not follow suit. Fedora is where Redhat breaks stuff to see how it goes.
3) IBM doesn't have community concerns like Fedora did back in the day.
4) So few people use it anymore that they have to pick and choose what they're going to put limited resources into.
5) Secure Boot is theoretically really good to have and requires UEFI. If you're not side-saddled with an Intel Management Engine it might even be secure.
6) People with diverse hardware are running Debian anyway.
7) One less reason to run Fedora in place of CentOS.
To counter 6), the new RISC-V dev boards are very interesting and come with Fedora. I hope they switch that to Debian soon.
I began leaving the Redhat community after 23 years when 4) became shockingly apparent and they were willing to break popular EL configurations mid-release and wouldn't even accept a patch when somebody else did the work for them.
Re: (Score:3)
CentOS is going to die when CentOS 7 reaches EOL. The reason for the existence of CentOS died with the move to the "Stream" versions.
Re: (Score:1)
And the move done in secret without any community discussion or planning, announced that their owner IBM is treating Red Hat they way they treat MySQL. They're keeping it barely alive to fulfill outstanding contracts, and the customers are not moving to other IBM products.
RHEL 8 had other issues befere they pulled the CentOS "swallow my stream, baby! Keep swallowing keep swallowing, I will *tell* you when you can come up, baby!" move with CentOS 8.
Re: (Score:2)
I presume to mitigate having to answer 'why isn't it booting right on XX' when people go to try and hit some limitation or another.
A lot of systems are way more complicated than anyone ever intended BIOS to go. Many storage adapters and network adapters playing a game of 'will *my* option rom fit in the tiny sliver of memory that's allowed to try. Further, among disks, will the disk you like get selected as device 80? Installer uses EDD to figure out which drive should get boot loader and people get frus
Re: (Score:2)
There's probably some neck-beard out there right now figuring out how to chain-load an EFI boot system off legacy BIOS with $DEITY-knows how many hacks and shims, just because SecureBoot is MICROSOFT EVIL!!! or some other rot.
Re: (Score:3)
Probably more work to induce the installer to work despite not seeing efi runtime services (either a patched anaconda or pre-empting by a faux /sys/firmware/efi facility). Depending on how much they remove/implement the efi-only facet.
Once a efi style installation is complete, all you'd have to do is overwrite the protective boot sector with a real boot sector to have grub load the content from /boot. Not a lot of hacks and shims for the actual boot sequence, since the kernel rapidly gets to the same spot e
Re: I don't get it (Score:3)
"A lot of systems are way more complicated than anyone ever intended BIOS to go. Many storage adapters and network adapters playing a game of 'will *my* option rom"
If the Trash-80 line was continually bolted on to try to bring it through the 2020s and beyond, people would say that Tandy is batshit crazy.
Yet we don't hear much bruhaha about this when it comes to the IBM PC clone.
Re: (Score:3)
If the Trash-80 line was continually bolted on to try to bring it through the 2020s and beyond, people would say that Tandy is batshit crazy.
Yet we don't hear much bruhaha about this when it comes to the IBM PC clone.
That's because we gradually replaced almost all of the really bad parts of it. You generally don't have to worry about the remaining bad stuff unless you're writing a boot loader. Basically the first second after powering on is ugly, then all the legacy stuff is disabled and you're running a modern design.
Re: I don't get it (Score:2)
Maybe the top brass got a nice big Christmas "gift"?
Re: (Score:2)
Red Hat makes good money selling support for legacy systems. RHEL 8 is supported until at least 2029.
The RHEL 9 beta was forked from Fedora 34 and the release notes imply that legacy BIOS is supported. It RHEL 9 is released this year it will probably be supported until at least 2032.
Doublethink (Score:2)
"More shorted sited crap from a generation that can't stand having anything other than the latest and greatest. Like money is water."
The same people who moans and groans whenever something drops into a landfill.
You would think that they would do everything to keep a working machine out of one, but New Happy Shiny Uber Alles. :-\
Re: (Score:1)
"More shorted sited crap from a generation that can't stand having anything other than the latest and greatest. Like money is water."
The same people who moans and groans whenever something drops into a landfill.
You would think that they would do everything to keep a working machine out of one, but New Happy Shiny Uber Alles. :-\
So you really think they should continue to support bios, something that is 40 years old and crap by today's standards?
At some point someone has to say enough's enough.