Wandering Thoughts archives

2017-04-19

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 grub.cfg 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, your 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.

tech/PCBIOSBootingStages written at 23:19:51; Add Comment

For me Chrome clearly wins over Firefox on Javascript-heavy websites

For my sins, I periodically use a number of Javascript-heavy websites (some of them are sites where the Javascript is core to the experience). I have similar Javascript enabled environments in both Chrome (in incognito mode) and Firefox, with relatively similar sets of extensions (Firefox version and Chrome version). My consistent experience over the past while is that Chrome is clearly faster on these sites than Firefox, and in particular Firefox often feels actively laggy.

(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.)

Beyond that, possibly my core Firefox extensions are slowing down Firefox more than I expect. But if so, well, they're my core extensions for a good reason (and the obvious suspect of NoScript is not entirely the cause, since some of my Firefox usage is without it). What matters to me is the performance of the browsers I've created from Firefox and Chrome, not the performance of the stock versions in some platonic ideal state that I will never use them in. Given that I have one decently performing browser, that's what I'll wind up using for Javascript-heavy sites even if it's not Firefox.

(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.)

web/LinuxChromeFasterJavascript written at 00:05:29; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.