Some things on how PCs boot the old fashioned BIOS way
A while back I wrote on how PCs boot and hard disk partitioning, which gave a quick description of the original BIOS MBR-based method of booting a PC (in contrast to UEFI booting). It's worth talking about BIOS booting in slightly more detail so that we can understand some constraints on it.
In practice, BIOS MBR booting goes through at least two and often three stages. The first stage loader is started by the BIOS when the BIOS loads the first 512-byte sector from an appropriate hard disk (which gets complicated these days) and then transfers control to it. Generally all that the first stage does is load more code and data from disk, in other words load the second stage. Because the first stage has only a few hundred bytes to work with, most first-stage loaders hard code the disk block locations where they find the second stage, and basically all first stage loaders use BIOS services to read data from disk.
The second stage boot code contains at least the core of the
bootloader, and is often fairly comprehensive. For GRUB, I believe the second stage
image contains the GRUB shell and menu system, various software
RAID and filesystem modules (such as the one that understands ext4),
and some other things. For GRUB, the second stage can't boot your
system by itself; instead it will proceed onwards to read your
grub.cfg, possibly load additional GRUB modules that your
tells it to, and then for Linux hopefully finish by loading your
selected kernel and initramfs into memory and starting them.
I believe that most second stage bootloaders continue to use BIOS
services to read any additional data they need from disk (for GRUB,
grub.cfg, any additional GRUB modules, and then finally the
kernel and initramfs). This means that BIOS MBR based bootloaders
are subject to the whims and limitations of those BIOS services,
which in some situations may be significant.
It's common for bootloaders to read data directly out of your
filesystem. This obviously means that they need to be able to
understand your filesystem and anything it sits on top of (such as
software RAID, btrfs, LUKS, and so
on). Since bootloader filesystem and so on support can lag behind
kernel support, this can leave you wanting (or needing) a separate
/boot that your bootloader can understand.
A certain amount of this is a lot simpler with UEFI booting. UEFI has a concept of files in a (simple) filesystem, real NVRAM variables, and a reasonably rich collection of UEFI services. This means that bootloaders don't have to hardcode disk block locations or have complicated ways of hunting for additional files; instead they can do relatively normal IO. Since UEFI will load an entire UEFI executable for you, it also eliminates the first stage bootloading.
Since UEFI booting is better in a number of ways than BIOS booting, you might imagine that an increasing number of machines are set up to boot that way. Perhaps they are for name-brand desktops that are preinstalled with Windows, but at least for Linux servers I don't believe that that's the case. Part of this is sheer pragmatics; the people putting together installers for Linux distributions and so on know that BIOS MBR booting works on basically everything while UEFI may or may not be supported and may or may not work well. Maybe in five years, server installs will default to UEFI unless you tell them to use BIOS MBR.
(Years ago I sort of had the same experience on Flickr, but I believe that more or less went away later for a while. It returned a couple of years ago, and I quietly switched from using Firefox on Flickr to mostly using Chrome.)
This result sort of surprises and depresses me (partly because using Chrome has its pains). My understanding is that in theory Firefox and Chrome are usually relatively neck and neck as far as performance goes, with Firefox at least competitive, and that especially on common sites Firefox should not be laggy. There are a number of things that could be causing this for me and not for other people, especially general users. For a start I'm on Linux and using Fedora's build of Firefox instead of the Mozilla build, while I think most performance comparisons are made on Windows or MacOS and use the official Mozilla builds.
(I'm also using a relatively odd Linux environment with relatively modest OpenGL and compositing support, which might hurt Firefox more than Chrome.)
(And I'm using some extensions in Chrome's incognito mode that I would expect to be sort of heavyweight, like uBlock Origin and a mouse gestures extension.)
PS: I care about this partly because I dislike some things Google does with Chrome and partly because I care about Firefox being competitive and good in general. The overall web ecology benefits when we have a real choice in browsers, and part of having a real choice is good performance.
(I also think that Mozilla fundamentally cares more about Linux for Firefox than Google does for Chrome. As a non-Windows, non-Mac user, I remember the days when I was a second class citizen on the web and I would rather like to not go too far back to them.)