8 ms·

EFI Sucks (2012)

101 points by turrini 9y ago

nikofeyn 9y ago
-
- colanderman 9y ago
  EDIT: Parent post was blaming Linus personally for sundry perceived issues with the greater Linux/Unix ecosystem. I've left my original reply below. ---- Linus had no part in any of those. Most of them existed long before Linux was a twinkle in his eye. Heck, some (two-letter commands) even existed before Linus was a twinkle in his parents' eyes [1] [2] [3]. (The exception being git, which is objectively one of the best DVCSes which exists. There is a reason it is so widely used.) [1] http://swenson.org/multics_wiki/index.php?title=Linux-to-Multics_Command_Mapping http://swenson.org/multics_wiki/index.php?title=Linux-to-Mul... [2] https://en.wikipedia.org/wiki/Multics#Project_history https://en.wikipedia.org/wiki/Multics#Project_history [3] https://en.wikipedia.org/wiki/Linus_Torvalds#Early_years https://en.wikipedia.org/wiki/Linus_Torvalds#Early_years
  - nikofeyn 9y ago
    i didn’t say he did create any of those. i only said he created git, which is true. i also didn’t blame linus like you say. i removed my response because, well, it was negative. i would just appreciate linus taking a less combative approach because his world hasn’t endowed the world of computing with as much nicety as he seems to think it has.
    - colanderman 9y ago
      Linus has endowed the world with what is possibly objectively one of the greatest, and most historically significant, pieces of software ever to exist. He's entitled to his opinion. To claim he isn't, because the greater open-source ecosystem is fragmented and not user-friendly, is kind of like saying John Lennon has no right to complain about disco, because hippies are smelly.
      - nikofeyn 9y ago
        i never claimed he wasn't entitled. i have simply stated i am tired of his complaints and rants. and my point is that the world he has helped nurture is not without its travesties, so maybe he should concentrate on that rather than constantly bitching about what other people have built. it would be nice if you stopped twisting my comments to say what you think they say. and i don’t even understand your retort anyway.
        RobertRoberts 9y ago
        >... constantly bitching about what other people have built." Exaggerating to the extreme implies you do not have a strong basis for your argument. If you actually count the number of times he's bitched about something, it's probably like 20 or 30 (can anyone provide a real number?). And even then only 2 are debatable in their value. (also a made up number to demonstrate the lack of solid data on this matter.) Therefore, I suspect you knew this, and just want to vent or make Linus look bad. I hope you have a better day tomorrow and make a decent follow up comment.
        nikofeyn 9y ago
        in my own personal experience, my primary source of linus news comes from articles being posted about him ranting or cursing about something. i didn’t post those. someone else did, and i read them. normally, i will follow these up with reading about various things about him and linux where he isn’t ranting, but those articles have been my portal to his world. why should i care to seek out more about one who i find is well known to throw e-mail tantrums, flip off cameras as a message to companies, etc.? please send your advice and condescending call for positivity to linus as well. :)
        RobertRoberts 9y ago
        The written form of communication lacks nuance. I genuinely hope you have a better day tomorrow.
        pdkl95 9y ago
tscs37 9y ago
A lot of the painpoints are gone, understandbly, but some still exist. The biggest suck on EFI is that it uses PE fileformats. I would have liked it more if it would have just loaded a raw PIC binary or ELF. And not used Windows Calling Conventions.
- AstralStorm 9y ago
  That is not important. The real bad part is that you still cannot easily load modules of your own to work around broken setup by mainboard manufacturer or Intel or boot rom in the device. This essentially causes lock in. Or even disable some broken modules. (Security has nothing to do with it, the module can be crypto signed by user installed key.) Plus the critical hardware setup documentation is not being released at all. Another is the use of SMI to communicate with the thing which just does not play well with a preemptible OS. Memory map handling is additional badness on top.
  - zaarn 9y ago
    That's more of an implementation problem of common EFI vendors, not EFI itself, sans SMI and mmaps.
ttflee 9y ago
> It's just sad how people always try to "improve" on old standard interfaces by then over-designing the improvements to the point where the new interface is just overwhelmed by complexity. Did Linus also criticize the complexity and untested nature of systemd?
- krylon 9y ago
  I vaguely remember Linus finding some strong words when the systemd developers wanted to integrate dbus into the kernel. (IIRC, they claimed it offered better performance, Linus ran some benchmarks and claimed the kernel-dbus implementation performed worse than the regular dbus daemon. My memory on the subject is fairly vague, though, so don't take my word on it.)
- craftyguy 9y ago
  How is systemd an 'interface'?
  - thomastjeffery 9y ago
    It's how you interact with daemons.
    - craftyguy 9y ago
      Ah, right. I suppose it could also be argued that the kernel is also unnecessarily complex as well?
      - ramenmeal 9y ago
        Eh its a little different. Your analogy would be more correct if we kept adding to the BIOS interface till it got large, rather than starting from scratch.
        JdeBP 9y ago
        Actually, that is what happened in the years before EFI. The API for old style PC/AT and PC98 firmware is a patchwork mess of oftentimes-conflicting subsystems that grew over the years.
kev009 9y ago
UEFI is a really unfortunate second system with all the markings of Intel's internal cultural issues imbued onto it that are hard to not see if you've worked with intel for any length of time. In the common case of an end user running an operating system, it's really hard to botch that without being kicked out of the market in ways that can't be worked around so it wont matter to most computer users. But UEFI is only a minor improvement over BIOS versus other industry standards for the people that could reap the benefits of an open and extensible bootloader in embedded, appliances, and hyperscale -- device manufacturers and operating system developers.
anfilt 9y ago
I remembering reading this a while ago. EFI just tries to do too much and thus is too complicated. Let alone the concerns that secure boot and other OSes.
deleted 9y ago
[deleted]
digi_owl 9y ago
So more of Torvalds on EFI: http://yarchive.net/comp/linux/efi.html http://yarchive.net/comp/linux/efi.html And here he is on ACPI: http://yarchive.net/comp/linux/acpi.html http://yarchive.net/comp/linux/acpi.html
- krylon 9y ago
  "There are two kinds of interfaces: the simple ones, and the broken ones." If only more people kept that in mind. ;-)
- raverbashing 9y ago
  Linus spent a lot of energy and Management by Perkele to make sure stuff worked and kept stable under ACPI. People would submit patches that fixed some things and broke others, and Linus put a stop to this I'm not so sure about the ACPI standard, it certainly has some warts but the main issue seems to be manufacturers who ship the thing once their hardware manages to boot Windows. Once. And note I said boot, not run.
pankajdoharey 9y ago
Unfortunately his statement is still valid even after 6 yrs, it is still a complicated disaster. And it uses Fat32 and PE. An abomination in my view.
- rkangel 9y ago
  FAT32 is a good choice IMO. It's the simplest of the "mainstream" filesystems.
  - xxs 9y ago
    correct me if I am wrong but it's still patented by Microsoft. Also time precision is up to even seconds (i.e. it can not store file stamp 'modified at 10:00:01')
    - zaarn 9y ago
      FAT is only patented if you want long filenames. If 8~3 filenames are long enough (and for EFI boot they are) then you can use FAT32 with short names. Additionally the specific EFI FAT32 implementation grants various patent rights which means you can implement EFI FAT32 (atleast, last time I checked by the situation) The other restrictions of the FS barely matter since 99.9% of the time it's used as /boot it will be read from and has barely any activity. The data integrity can be insured by setting up secureboot (MS or User/Setup mode) [0]: https://en.wikipedia.org/wiki/File_Allocation_Table#Patents https://en.wikipedia.org/wiki/File_Allocation_Table#Patents
    - chungy 9y ago
      > Also time precision is up to even seconds (i.e. it can not store file stamp 'modified at 10:00:01') In the pure form of the file system, yes, but with VFAT (which also adds long file names, creation time stamps, and access time stamps), the precision is exactly 1 second increments.
      - thriftwy 9y ago
        My main memory of VFAT comes from Windows 95 (or was it 98), I remember that when you saw this word anywhere, this meant your operating system is now borked beyond any repair.
snvzz 9y ago
There's a lot about it that's bad, but the worst is definitely that it allows the firmware to keep running after the OS boots, interfering with its normal operation. Thanks to SMI, the system is non-deterministic: No latency promises can be made.
- tinus_hn 9y ago
  The same happens with BIOS, that is how many of its settings work.
  - snvzz 9y ago
    Yes it does, but that's only of historical value by now. Sigh, they had one job, and they managed to screw it up, so we do still have to put up with this.
swiley 9y ago
The one thing I really love about EFI on non-macs is that you don't need a boot loader. You just compile your kernel with an EFI stub and whatever you want in the initrd and then select it with the firmware GUI. That's nice
- abhishekjha 9y ago
  I didn't understand a lot of what you said. Any sources?
  - kipari 9y ago
    The Arch Linux wiki has a good explanation: https://wiki.archlinux.org/index.php/EFISTUB https://wiki.archlinux.org/index.php/EFISTUB
  - zbentley 9y ago
    The Arch wiki in the sibling comment is a good resource for learning a lot. I'll try to (over)simplify the short version here: With the old BIOS-based boot process, the computer (the hardware/motherboard; not the operating system you ran on it) would, when it started up, look around for installed operating systems to boot. It wouldn't look too hard: on each hard disk, it would look in one (or, if you were lucky, four) places for a specially-prepared segment outside of the data installed by the operating system. This segment isn't a file or something that you can browse to normally on the drive (though some things shimmed it so it appeared thus); it's a non-file special segment outside of the OS's normal data/files. That segment (well, segments, but still) had to be set up just so otherwise the computer (BIOS) wouldn't find your OS to boot it. Doing this was often tricky, even more so when you needed multiple operating systems to be bootable. Doing this was also pretty inelegant, since if you wanted to stick an operating system on a sub-partition of a disk, as part of the installation process you had to mess with data that affected everything on that disk, not just what was in the sub-partition. It worked, and was simple, but it was the equivalent of being forced to modify a single central global variable in a software project every time one sub-part (file, function, whatever) of that project wanted to use a new library. For an excellent writeup of the gritty details of the BIOS/MBR startup process, see this document: https://neosmart.net/wiki/mbr-boot-process/ https://neosmart.net/wiki/mbr-boot-process/ UEFI, put most simply, looks around for installed operating systems a lot harder than the BIOS method did. It does a lot more than that, but the benefit GP was describing accrues from UEFI being much more capable in terms of discovery: instead of checking a single global prepared location for bootable OSes, UEFI can look in the files on the drive and do the intuitive thing: "looks like these files are part of an operating system; I'll give the user an option to boot from it". This doesn't always work perfectly, and there's a lot of complexity (and criticism) I'm hand-waving away here, but that's the gist of the difference. Sorry, turned out to be a not-so-short version.
tinus_hn 9y ago
Many of the issues are just that BIOS is old and stable while EFI and UEFI are new and immature. There should be a testing suite for UEFI like the CSS Acid test so there is a baseline of working functionality. But instead the test is ‘does it run Windows’ and that really is only a small part of it all.
majewsky 9y ago
I'll go against the grain here: I go out of my way to use UEFI over BIOS, because it Just Works for me. When I got my first UEFI-using notebook in 2012 (same year as the submission), things were a bit rough because the Arch wiki did not quite know what it was talking about, and the Arch ISO was not UEFI-bootable, so you had to use some trickery to install an UEFI bootloader, but even then, it only took me two hours to figure out partitioning and install the bootloader. Since then, stuff has gotten much better. Just recently, I switched my VirtualBox VMs to use UEFI emulation instead of BIOS emulation because it allows me to use the well-designed systemd-boot (previously known as gummiboot) instead of that absurd abomination called Grub 2.
- appleflaxen 9y ago
  > it only took me two hours to figure out partitioning and install the bootloader This doesn't read like a success story to me.
  - saghm 9y ago
    Immediately before, it mentions that this was 5-6 years ago and that there was no documentation available at the time, and immediately after it says that the situation is much better now.
- arghwhat 9y ago
  Now try to install arch to a bootable USB stick from your UEFI booted system, and see all hell break loose. I boot UEFI, but it's just so bloody cumbersome and fragile. The entire concept of having boot configuration in NVRAM is terrible.
  - digi_owl 9y ago
    Even more fun when OEMs put what should be read only ROM variables in NVRAM, and they get nuked...
  - jonnypickel 9y ago
    Not to turn this into a support thread but this weekend I tried to install Arch on a new, UEFI-enabled laptop and I've been stymied so far because I can't get the laptop to recognize my Live USB. I've built it with Rufus, dd for Windows, and Easy2Boot all with the same result (no bootable device) even though it works on another machine. Could it be because I created the USB on a PC using UEFI?
nszceta 9y ago
Arch Linux on VirtualBox using EFISTUB Super simple steps to install an Arch Linux guest on VirtualBox with pure EFISTUB. No bootloader! Fill in the blanks with https://wiki.archlinux.org/index.php/installation_guide https://wiki.archlinux.org/index.php/installation_guide timedatectl set-ntp true gdisk /dev/sda # 256 MB partition type EF00 mkfs.fat -F32 /dev/sda1 mkfs.btrfs /dev/sda2 mount -o discard,compress-force=lzo /dev/sda2 /mnt mkdir /mnt/boot mount /dev/sda1 /mnt/boot pacstrap /mnt base base-devel btrfs-progs vim openssh genfstab -U /mnt >> /mnt/etc/fstab arch-chroot /mnt ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime timedatectl set-ntp true vim /etc/locale.gen locale-gen vim /etc/hostname vim /etc/hosts systemctl enable dhcpcd systemctl enable sshd passwd root useradd -m user passwd user # /boot/startup.nsh fs0:\vmlinuz-linux rw root=/dev/sda2 initrd=\initramfs-linux.img exit umount -R /mnt poweroff
harijay 9y ago
Had the same experience with my plastic MacBook from 2007 and I could install Fedora 27 and Mint using a related program to iso master. Good to know about ISO master. Wrote about the process: “The 2007 plastic MacBook lives again with Mint-y Linux awesomeness” @harijay https://medium.com/@harijay/the-2007-plastic-macbook-lives-again-with-mint-y-linux-awesomeness-374469cc977e https://medium.com/@harijay/the-2007-plastic-macbook-lives-a...
dekhn 9y ago
Is EFI the system that my newer motherboards use when booting up? Is he talking about the system that has replaced grub on most of my machines with a more reliable one that's built into the hardware? In 2012, EFI/UEFI was pretty unreliable because the implementations were bad and the software support was terrible. Nowadays, I find it preferable.
Samis2001 9y ago
For this area, my ideal world is one where both the BIOS and UEFI are dead, replaced by something that is inspired both by OpenFirmware and coreboot.

EFI Sucks (2012)

101 points by turrini 9y ago

colanderman 9y ago
EDIT: Parent post was blaming Linus personally for sundry perceived issues with the greater Linux/Unix ecosystem. I've left my original reply below. ---- Linus had no part in any of those. Most of them existed long before Linux was a twinkle in his eye. Heck, some (two-letter commands) even existed before Linus was a twinkle in his parents' eyes [1] [2] [3]. (The exception being git, which is objectively one of the best DVCSes which exists. There is a reason it is so widely used.) [1] http://swenson.org/multics_wiki/index.php?title=Linux-to-Multics_Command_Mapping http://swenson.org/multics_wiki/index.php?title=Linux-to-Mul... [2] https://en.wikipedia.org/wiki/Multics#Project_history https://en.wikipedia.org/wiki/Multics#Project_history [3] https://en.wikipedia.org/wiki/Linus_Torvalds#Early_years https://en.wikipedia.org/wiki/Linus_Torvalds#Early_years
- nikofeyn 9y ago
  i didn’t say he did create any of those. i only said he created git, which is true. i also didn’t blame linus like you say. i removed my response because, well, it was negative. i would just appreciate linus taking a less combative approach because his world hasn’t endowed the world of computing with as much nicety as he seems to think it has.
  - colanderman 9y ago
    Linus has endowed the world with what is possibly objectively one of the greatest, and most historically significant, pieces of software ever to exist. He's entitled to his opinion. To claim he isn't, because the greater open-source ecosystem is fragmented and not user-friendly, is kind of like saying John Lennon has no right to complain about disco, because hippies are smelly.
    - nikofeyn 9y ago
      i never claimed he wasn't entitled. i have simply stated i am tired of his complaints and rants. and my point is that the world he has helped nurture is not without its travesties, so maybe he should concentrate on that rather than constantly bitching about what other people have built. it would be nice if you stopped twisting my comments to say what you think they say. and i don’t even understand your retort anyway.
      - RobertRoberts 9y ago
        >... constantly bitching about what other people have built." Exaggerating to the extreme implies you do not have a strong basis for your argument. If you actually count the number of times he's bitched about something, it's probably like 20 or 30 (can anyone provide a real number?). And even then only 2 are debatable in their value. (also a made up number to demonstrate the lack of solid data on this matter.) Therefore, I suspect you knew this, and just want to vent or make Linus look bad. I hope you have a better day tomorrow and make a decent follow up comment.
        nikofeyn 9y ago
        in my own personal experience, my primary source of linus news comes from articles being posted about him ranting or cursing about something. i didn’t post those. someone else did, and i read them. normally, i will follow these up with reading about various things about him and linux where he isn’t ranting, but those articles have been my portal to his world. why should i care to seek out more about one who i find is well known to throw e-mail tantrums, flip off cameras as a message to companies, etc.? please send your advice and condescending call for positivity to linus as well. :)
        RobertRoberts 9y ago
        The written form of communication lacks nuance. I genuinely hope you have a better day tomorrow.
        pdkl95 9y ago

A lot of the painpoints are gone, understandbly, but some still exist. The biggest suck on EFI is that it uses PE fileformats. I would have liked it more if it would have just loaded a raw PIC binary or ELF. And not used Windows Calling Conventions.

AstralStorm 9y ago
That is not important. The real bad part is that you still cannot easily load modules of your own to work around broken setup by mainboard manufacturer or Intel or boot rom in the device. This essentially causes lock in. Or even disable some broken modules. (Security has nothing to do with it, the module can be crypto signed by user installed key.) Plus the critical hardware setup documentation is not being released at all. Another is the use of SMI to communicate with the thing which just does not play well with a preemptible OS. Memory map handling is additional badness on top.
- zaarn 9y ago
  That's more of an implementation problem of common EFI vendors, not EFI itself, sans SMI and mmaps.

ttflee 9y ago

> It's just sad how people always try to "improve" on old standard interfaces by then over-designing the improvements to the point where the new interface is just overwhelmed by complexity. Did Linus also criticize the complexity and untested nature of systemd?

krylon 9y ago
I vaguely remember Linus finding some strong words when the systemd developers wanted to integrate dbus into the kernel. (IIRC, they claimed it offered better performance, Linus ran some benchmarks and claimed the kernel-dbus implementation performed worse than the regular dbus daemon. My memory on the subject is fairly vague, though, so don't take my word on it.)
craftyguy 9y ago
How is systemd an 'interface'?
- thomastjeffery 9y ago
  It's how you interact with daemons.
  - craftyguy 9y ago
    Ah, right. I suppose it could also be argued that the kernel is also unnecessarily complex as well?
    - ramenmeal 9y ago
      Eh its a little different. Your analogy would be more correct if we kept adding to the BIOS interface till it got large, rather than starting from scratch.
      - JdeBP 9y ago
        Actually, that is what happened in the years before EFI. The API for old style PC/AT and PC98 firmware is a patchwork mess of oftentimes-conflicting subsystems that grew over the years.

kev009 9y ago

UEFI is a really unfortunate second system with all the markings of Intel's internal cultural issues imbued onto it that are hard to not see if you've worked with intel for any length of time. In the common case of an end user running an operating system, it's really hard to botch that without being kicked out of the market in ways that can't be worked around so it wont matter to most computer users. But UEFI is only a minor improvement over BIOS versus other industry standards for the people that could reap the benefits of an open and extensible bootloader in embedded, appliances, and hyperscale -- device manufacturers and operating system developers.

anfilt 9y ago

I remembering reading this a while ago. EFI just tries to do too much and thus is too complicated. Let alone the concerns that secure boot and other OSes.

deleted 9y ago

[deleted]

digi_owl 9y ago

So more of Torvalds on EFI: http://yarchive.net/comp/linux/efi.html http://yarchive.net/comp/linux/efi.html And here he is on ACPI: http://yarchive.net/comp/linux/acpi.html http://yarchive.net/comp/linux/acpi.html

krylon 9y ago
"There are two kinds of interfaces: the simple ones, and the broken ones." If only more people kept that in mind. ;-)
raverbashing 9y ago
Linus spent a lot of energy and Management by Perkele to make sure stuff worked and kept stable under ACPI. People would submit patches that fixed some things and broke others, and Linus put a stop to this I'm not so sure about the ACPI standard, it certainly has some warts but the main issue seems to be manufacturers who ship the thing once their hardware manages to boot Windows. Once. And note I said boot, not run.

pankajdoharey 9y ago

Unfortunately his statement is still valid even after 6 yrs, it is still a complicated disaster. And it uses Fat32 and PE. An abomination in my view.

rkangel 9y ago
FAT32 is a good choice IMO. It's the simplest of the "mainstream" filesystems.
- xxs 9y ago
  correct me if I am wrong but it's still patented by Microsoft. Also time precision is up to even seconds (i.e. it can not store file stamp 'modified at 10:00:01')
  - zaarn 9y ago
    FAT is only patented if you want long filenames. If 8~3 filenames are long enough (and for EFI boot they are) then you can use FAT32 with short names. Additionally the specific EFI FAT32 implementation grants various patent rights which means you can implement EFI FAT32 (atleast, last time I checked by the situation) The other restrictions of the FS barely matter since 99.9% of the time it's used as /boot it will be read from and has barely any activity. The data integrity can be insured by setting up secureboot (MS or User/Setup mode) [0]: https://en.wikipedia.org/wiki/File_Allocation_Table#Patents https://en.wikipedia.org/wiki/File_Allocation_Table#Patents
  - chungy 9y ago
    > Also time precision is up to even seconds (i.e. it can not store file stamp 'modified at 10:00:01') In the pure form of the file system, yes, but with VFAT (which also adds long file names, creation time stamps, and access time stamps), the precision is exactly 1 second increments.
    - thriftwy 9y ago
      My main memory of VFAT comes from Windows 95 (or was it 98), I remember that when you saw this word anywhere, this meant your operating system is now borked beyond any repair.

snvzz 9y ago

There's a lot about it that's bad, but the worst is definitely that it allows the firmware to keep running after the OS boots, interfering with its normal operation. Thanks to SMI, the system is non-deterministic: No latency promises can be made.

tinus_hn 9y ago
The same happens with BIOS, that is how many of its settings work.
- snvzz 9y ago
  Yes it does, but that's only of historical value by now. Sigh, they had one job, and they managed to screw it up, so we do still have to put up with this.

swiley 9y ago

The one thing I really love about EFI on non-macs is that you don't need a boot loader. You just compile your kernel with an EFI stub and whatever you want in the initrd and then select it with the firmware GUI. That's nice

abhishekjha 9y ago
I didn't understand a lot of what you said. Any sources?
- kipari 9y ago
  The Arch Linux wiki has a good explanation: https://wiki.archlinux.org/index.php/EFISTUB https://wiki.archlinux.org/index.php/EFISTUB
- zbentley 9y ago
  The Arch wiki in the sibling comment is a good resource for learning a lot. I'll try to (over)simplify the short version here: With the old BIOS-based boot process, the computer (the hardware/motherboard; not the operating system you ran on it) would, when it started up, look around for installed operating systems to boot. It wouldn't look too hard: on each hard disk, it would look in one (or, if you were lucky, four) places for a specially-prepared segment outside of the data installed by the operating system. This segment isn't a file or something that you can browse to normally on the drive (though some things shimmed it so it appeared thus); it's a non-file special segment outside of the OS's normal data/files. That segment (well, segments, but still) had to be set up just so otherwise the computer (BIOS) wouldn't find your OS to boot it. Doing this was often tricky, even more so when you needed multiple operating systems to be bootable. Doing this was also pretty inelegant, since if you wanted to stick an operating system on a sub-partition of a disk, as part of the installation process you had to mess with data that affected everything on that disk, not just what was in the sub-partition. It worked, and was simple, but it was the equivalent of being forced to modify a single central global variable in a software project every time one sub-part (file, function, whatever) of that project wanted to use a new library. For an excellent writeup of the gritty details of the BIOS/MBR startup process, see this document: https://neosmart.net/wiki/mbr-boot-process/ https://neosmart.net/wiki/mbr-boot-process/ UEFI, put most simply, looks around for installed operating systems a lot harder than the BIOS method did. It does a lot more than that, but the benefit GP was describing accrues from UEFI being much more capable in terms of discovery: instead of checking a single global prepared location for bootable OSes, UEFI can look in the files on the drive and do the intuitive thing: "looks like these files are part of an operating system; I'll give the user an option to boot from it". This doesn't always work perfectly, and there's a lot of complexity (and criticism) I'm hand-waving away here, but that's the gist of the difference. Sorry, turned out to be a not-so-short version.

tinus_hn 9y ago

Many of the issues are just that BIOS is old and stable while EFI and UEFI are new and immature. There should be a testing suite for UEFI like the CSS Acid test so there is a baseline of working functionality. But instead the test is ‘does it run Windows’ and that really is only a small part of it all.

majewsky 9y ago

I'll go against the grain here: I go out of my way to use UEFI over BIOS, because it Just Works for me. When I got my first UEFI-using notebook in 2012 (same year as the submission), things were a bit rough because the Arch wiki did not quite know what it was talking about, and the Arch ISO was not UEFI-bootable, so you had to use some trickery to install an UEFI bootloader, but even then, it only took me two hours to figure out partitioning and install the bootloader. Since then, stuff has gotten much better. Just recently, I switched my VirtualBox VMs to use UEFI emulation instead of BIOS emulation because it allows me to use the well-designed systemd-boot (previously known as gummiboot) instead of that absurd abomination called Grub 2.

appleflaxen 9y ago
> it only took me two hours to figure out partitioning and install the bootloader This doesn't read like a success story to me.
- saghm 9y ago
  Immediately before, it mentions that this was 5-6 years ago and that there was no documentation available at the time, and immediately after it says that the situation is much better now.
arghwhat 9y ago
Now try to install arch to a bootable USB stick from your UEFI booted system, and see all hell break loose. I boot UEFI, but it's just so bloody cumbersome and fragile. The entire concept of having boot configuration in NVRAM is terrible.
- digi_owl 9y ago
  Even more fun when OEMs put what should be read only ROM variables in NVRAM, and they get nuked...
- jonnypickel 9y ago
  Not to turn this into a support thread but this weekend I tried to install Arch on a new, UEFI-enabled laptop and I've been stymied so far because I can't get the laptop to recognize my Live USB. I've built it with Rufus, dd for Windows, and Easy2Boot all with the same result (no bootable device) even though it works on another machine. Could it be because I created the USB on a PC using UEFI?

nszceta 9y ago

Arch Linux on VirtualBox using EFISTUB Super simple steps to install an Arch Linux guest on VirtualBox with pure EFISTUB. No bootloader! Fill in the blanks with https://wiki.archlinux.org/index.php/installation_guide https://wiki.archlinux.org/index.php/installation_guide timedatectl set-ntp true gdisk /dev/sda # 256 MB partition type EF00 mkfs.fat -F32 /dev/sda1 mkfs.btrfs /dev/sda2 mount -o discard,compress-force=lzo /dev/sda2 /mnt mkdir /mnt/boot mount /dev/sda1 /mnt/boot pacstrap /mnt base base-devel btrfs-progs vim openssh genfstab -U /mnt >> /mnt/etc/fstab arch-chroot /mnt ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime timedatectl set-ntp true vim /etc/locale.gen locale-gen vim /etc/hostname vim /etc/hosts systemctl enable dhcpcd systemctl enable sshd passwd root useradd -m user passwd user # /boot/startup.nsh fs0:\vmlinuz-linux rw root=/dev/sda2 initrd=\initramfs-linux.img exit umount -R /mnt poweroff

harijay 9y ago

Had the same experience with my plastic MacBook from 2007 and I could install Fedora 27 and Mint using a related program to iso master. Good to know about ISO master. Wrote about the process: “The 2007 plastic MacBook lives again with Mint-y Linux awesomeness” @harijay https://medium.com/@harijay/the-2007-plastic-macbook-lives-again-with-mint-y-linux-awesomeness-374469cc977e https://medium.com/@harijay/the-2007-plastic-macbook-lives-a...

dekhn 9y ago

Is EFI the system that my newer motherboards use when booting up? Is he talking about the system that has replaced grub on most of my machines with a more reliable one that's built into the hardware? In 2012, EFI/UEFI was pretty unreliable because the implementations were bad and the software support was terrible. Nowadays, I find it preferable.

Samis2001 9y ago

For this area, my ideal world is one where both the BIOS and UEFI are dead, replaced by something that is inspired both by OpenFirmware and coreboot.