I just upgraded a mid-2011 iMac (iMac12,1 for you Apple nerds) to High Sierra. I thought I would wait until all the bugs were ironed out. Hah. That worked out really well. ;-)
I’m not here to talk about bugs in the software, but about bugs in the “documentation”. In particular about APFS (the new Apple File System) and its vaunted encryption feature. There is no – or contradictory – information available about how to use it, and, in particular, how to do a clean install onto an APFS encrypted disk.
“Help” on the machine itself is notoriously useless. But finding authoritative information about APFS from Apple – through any channel – is nearly impossible.
I did find a post on Reddit that claimed that FileVault and APFS encryption were the same thing, and also claimed that Apple suggests that in order to achieve an encrypted APFS install, that we install to an un-encrypted disk and turn on FileVault after the fact. This didn’t sound right.
People are talking about this, and everyone is confused:
- Is APFS (Encrypted) and FileVault on the same volume redundant?
- Apple APFS Encryption Question
- Understanding the difference between APFS encryption and FileVault
Then I found this post on discussions.apple.com which seemed to highlight everything that was bothering me about the APFS encryption story – especially the confusing
System Preferences >> Security & Privacy UI about turning on FileVault. What does this do? Is it the same thing as somehow turning on APFS encryption using Disk Utility or the
diskutil apfs command? Who knows!
This support topic about institutional recovery keys sheds some light on the subject. It suggests that Apple wants us to think that “FileVault” and “encrypted disk” are basically the same thing – even though the mechanisms for achieving that encryption are different among CoreStorage, HFS+, and APFS. Conflating related but distinct notions usually leads to people having an erroneous (aka false) mental model of a system, and this often leads to frustration or worse – maybe even to catastrophic data loss. This isn’t a good place to cut corners on clarity.
diskutil man page can be an exercise in frustration as well. There is some discussion of “crypto users” and “crypto keys” but no good definitions of these. Also, what does
-role do? What do the B, R, and V flags mean? There is no explanation.
Is APFS ready for production use on spinning disks? I installed it on the iMac’s 2011-vintage 500GB Seagate drive. (It even has 512 byte sectors! How totally passé!) Was this a mistake? The machine isn’t sluggish exactly, but it’s not screaming along either. Is APFS slowing it down? Or just the fact that it’s memory-limited (I need to upgrade it beyond its current 4GB of RAM)?
Dear Apple: APFS is a great idea, and long overdue, but it’s kind of a mess! The lack of user data integrity checking – instead depending on the drives and their firmware to do this! – is a huge mistake. Brian Cantrill has ranted publicly about ZFS’s checksumming (of everything) turning up all kinds of disk firmware bugs that would otherwise have led to data corruption.
Also, please publish better man pages, some clear manuals, security white papers, and “best practices” deployment notes, for APFS.
As I sat down to write this – I have only just finished getting my working environment set up again on this machine – I found a bug. In Vim. I had to build my own version of Vim because the version that ships with High Sierra – 8.0.something – seemed to be ignoring my
~/.vim/after/ftplugin/ files. Rather than debug this I just built a recent 8.1 and it seems to work fine. While this isn’t Apple’s fault exactly, the bug was in the version of Vim that they ship. Oh well.
I wish you and your loved ones all the best in 2019!
For my part, I’m going to start the year off with a bit of good news for software developers, and two somewhat curious discoveries.
First, the good news. GitHub have recently announced that their free tier will include unlimited private repositories, each with up to three collaborators.
I’ve been using GitHub for public projects and Bitbucket for private ones precisely because Bitbucket has for years offered the option of unlimited private repositories in their free tier. However, Bitbucket limits you to five collaborators across all repositories, whereas GitHub will now allow up to three collaborators for each repository. I like both platforms, so I doubt I’ll move everything over, but this change should put some pressure on Bitbucket.
Now for the curious bits.
A few days ago, while down a rabbit hole related to IPv6, I discovered that broadband internet in Latvia costs a fraction of what it costs here in the USA, thanks largely to monopolies granted many years ago by the FCC.
I’m paying Comcast $82 per month for 150 Mbps cable internet service. In Latvia I could get 100 Mbps for €12 or 300 Mbps for €15.
Comcast have been “advertising” on NPR that they are helping families get connected to the internet. I think this claim would ring truer if decently-fast Comcast broadband cost $15/month rather than $80 or more.
Lastly, having decided to change my site generator to generate HTML instead of XHTML, I had to figure what was going on in the world of “HTML5” – which I have blissfully ignored for the past few years. I was surprised to discover that the HTML standard has actually forked. There are now two standards bodies – the W3C and WHATWG – both working on and publishing HTML standards. W3C – who had abandoned HTML in favor of XHTML and other XML-based technologies – have jumped back onto the HTML bandwagon; but whereas the WHATWG (an organization of browser vendors) want HTML to be a “living standard”, the W3C want it to be, as it has been in the past, a versioned standard.
The WHATWG has this to say about the difference in approaches (from the HTML spec introduction):
For a number of years, both groups [W3C and WHATWG] then worked together. In 2011, however, the groups came to the conclusion that they had different goals: the W3C wanted to publish a “finished” version of “HTML5”, while the WHATWG wanted to continue working on a Living Standard for HTML, continuously maintaining the specification rather than freezing it in a state with known problems, and adding new features as needed to evolve the platform.
Since then, the WHATWG has been working on this specification (amongst others), and the W3C has been copying fixes made by the WHATWG into their fork of the document (which also has other changes).
You can choose to follow either standard, but since your HTML will be, in all likelihood, consumed by a web browser (or a web browser engine such as Electron), the WHATWG standard is more likely to be accurate and useful.
Read the 2018 journal.