LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-17-2019, 09:54 PM   #46
garpu
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 802

Rep: Reputation: 389Reputation: 389Reputation: 389Reputation: 389

UEFI is a lot faster. In my completely unscientific observations, on my old computer (legacy), I'd have time to use the washroom and grab a cup of coffee while it booted. On the new one, I can't make it to the kitchen, and it's already up.
 
Old 06-17-2019, 11:29 PM   #47
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 3,546

Rep: Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424
Be that as it may garpu, it is not because of UEFI. If you look at the boot process it still reaches a point where everything is handed off to the kernel of any OpSys. This is one of the reasons that while it is possible to access drives like CDROM/DVD/USB from the CMOS and even run apps and boot from them, once an OpSys begins to load a driver is required to do the very same thing. FWIW my mobo supports UEFI and I've tried it, then opted for Legacy mode though I do have a 4TB HDD that is GPT. I can no longer boot from it but that isn't a problem since I have 2 other smaller drives in this box. It is fine as a large storage drive. The point is that not only is the theory against any increased boot speed due to UEFI (other than for the Windows Fast Boot option) but also is the practice. Boot speed is entirely about the read speed of the drive, RAM, and the complexity of the kernel and init system. BIOS and UEFI are simply a recipe and set of rules for how hardware "talks" to each other. It is somewhat analogous to our human autonomic system like heartbeat and breathing that can be taken over by a conscious imperative.
 
3 members found this post helpful.
Old 06-18-2019, 01:01 AM   #48
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 8,057

Rep: Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608Reputation: 5608
Quote:
Originally Posted by enorbet View Post
Be that as it may garpu, it is not because of UEFI.
The initialization of hardware can be faster on UEFI (basically the POST until the handoff to the OS). BIOS is limited to 16bit processor mode and has 1MB of addressable memory space that it can run in, where UEFI can be 32bit or 64bit with a much larger memory space to work in. This is what allows "advanced" graphics and mouse support in UEFI. This also means it can initialize more hardware quicker than BIOS can, which could lead to a faster handoff to the OS.

There's no guarantee it will be faster, and on some systems, it could be minuscule, but theoretically, it can be faster using UEFI (and it has been demonstrated by users that UEFI can be faster than CSM/Legacy boot). But I've never been a proponent of something just because it increases your boot time unless you're constantly booting your system (I only reboot when necessary, otherwise, my machine is accessible 24/7). Don't take this to mean I'm encouraging everyone to switch to UEFI to shave off a handful of seconds from your system.

But once it gets to the OS, you're correct that speed will be based of your hardware and how your init system brings up the system.
 
2 members found this post helpful.
Old 06-18-2019, 11:50 AM   #49
enorbet
Senior Member
 
Registered: Jun 2003
Location: Virginia
Distribution: Slackware = Main OpSys
Posts: 3,546

Rep: Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424Reputation: 3424
Although I've grown exceeding rusty with Assembly from lack of use (and maybe because I was never much better than "See the dog. The dog can run fast" ) there was a time when I played extensively with hacking firmware and intimately aware of the steps in POST. I swapped CMOS chips while the system was running to try out modded images, reprogram chips, enable and disable features and add some new ones. As long as the I/O chips are similar even different manufacturer and model mobo bios images could be used, sometimes to substantial effect for what settings and how much control was possible.

As long as early PCs could retain ISA peripheral slots only that simplicity allowed early BIOS chips to have sufficient memory space to handle any hardware that could be optionally plugged in but soon the progression began and the number of Interrupts and size of memory had to be nearly doubled. It was inevitable that continued progress could not be handled by simply adding more BIOS hardware. UEFI wasn't just a lark. It is needed at the hardware level.

So maybe it can be seen that I'm not quite a Luddite and respect and concur with the move to something like UEFI. I do take some small issue with what has been done with it however, which has been largely cosmetics, convenience and a few agenda-ridden (largely from Wintel) "features" that have little to do with what is needed before handing off to Int 19h. The time required for POST is quite variable based on what and how many settings are employed in Setup and since UEFI has massively more horsepower and resources it can be faster than BIOS but since it also has more settings and more hardware variables possible, it can also be slower. That's why I focused on Boot as being the time after POST since once the image is loaded into RAM, and even though that image is constantly "consulted", it is all up to the OpSys and it's init system.

From my POV UEFI could, and likely will, become far more important and useful in the future, but as of 2019 it's largely just a bauble and has but little gain in boot time or any other function beyond hardware compatibility. I sincerely hope Legacy support will continue for at least another decade. It is worthy of note that although Moore's Law is still advancing, so is software bloat and complexity. Just consider how much was accomplished with so few resources with the Apollo Moon Project computers.

--- Software Apocalypse ---
 
Old 06-18-2019, 02:05 PM   #50
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 9,831

Rep: Reputation: Disabled
Quote:
Originally Posted by enorbet View Post
I sincerely hope Legacy support will continue for at least another decade.
Intel provide this with the CSM, as you know. However, Intel is removing legacy BIOS support from client & data center platforms by 2020. And I assume that other providers will follow suite. So, unless you don't plan to buy new computers...

Last edited by Didier Spaier; 06-18-2019 at 02:06 PM.
 
Old 06-19-2019, 03:31 PM   #51
SCerovec
Senior Member
 
Registered: Oct 2006
Location: Cp6uja
Distribution: Slackware on x86 and arm
Posts: 1,924
Blog Entries: 2

Rep: Reputation: 612Reputation: 612Reputation: 612Reputation: 612Reputation: 612Reputation: 612
Since I've found refind i'm UEFI-ng and never looked back.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
About Slackware 9.1 boot disk?? ftp://ftp.kpn.be/pub/linux/slackware/slackware-9.1-is AL3OMDAH Slackware 4 04-18-2007 09:54 AM
Slackware Slackware Slackware!!!!! monkeymartin Slackware 5 03-28-2003 10:41 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 04:38 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration