Shut it

I got a Raspberry Pi 3 Model B for Christmas and finally started using it. If “finally” seems like the wrong word, I will clarify: I’m not talking about the Christmas a month ago, I’m talking about the Christmas 13 months ago.

I bought a power supply, case, and microSD card for the Pi right away, but I never got it up and running. I dithered so long because I couldn’t decide what to do with it. My first thought was to set it up to run the Wolfram Language, which can be installed and run for free (for non-commercial use) on the Pi. That’s still kind of appealing, but I’m more interested in learning R and ggplot (to that end, Kieran Healy’s Data Visualization was recent Christmas gift to myself).

Then I thought about using the Pi as a Homebridge server, but that would mean committing to a bunch of smart devices in my house, and although I’m kind of interested in hearing other people’s experiences in home automation, I’m not sure I want to do it myself. I’ve never felt it burdensome to flip a light switch.

I could always set up the Pi as a general-purpose server to do command-line things from my iPad via Prompt. I already have that, though, because both of my iMacs (home and office) run continuously and have the tools I like already installed. Rosemary Orchard has an interesting variation on this: a Pi she travels with as a portable server for times when she doesn’t have good internet access. But for that I’d need a Pi Zero W; mine doesn’t have WiFi.

Update Feb 2, 2019 4:01 PM  Apparently my Pi does have WiFi, even though most of the setup guides I’ve seen for it discuss Ethernet connections only. Even so, if I were going to travel with a Pi, it’d be the tiny Zero W.

A couple of weeks ago, Nathan Alderman was on a Slack channel I visit, talking about installing an internet ad-blocking service called Pi-hole on his Mac mini. He was having some trouble with its configuration because Pi-hole is more easily installed in its native environment, a Raspberry Pi. I’d never heard of Pi-hole before, but it seemed like a perfect fit for my dust-gathering Model B. Last weekend, I spent about an hour and a half setting it up on my home network, and it’s been successfully blocking crap from my devices ever since.

There is an ethical issue to using an ad blocker. People who want to make a living creating things on the internet should be paid for their work, and advertising is the most common way to get paid. And I’m not offended by the presence of advertising on other media. Newspapers, magazines, radio, and TV have always had ads, and I don’t go out of my way to block them. But when I’m looking at a newspaper while eating breakfast, the newspaper doesn’t look back at me, taking note of the cereal I’m eating, the clothes I’m wearing, and whether it looks like I’ve put on a few pounds recently. Internet ads do, and it’s that—along with the invisible trackers on so many sites—that offends me. So I’ve used ad blockers despite my qualms.

Pi-hole differs from browser-based ad blockers in that it works at the network level. It acts as a local DNS server that simply doesn’t serve content from sites on its block list. So the voluminous cruft associated with so many modern websites doesn’t even get to your browser to be sifted through. And a single configuration works for all the devices on your network.

I followed these instructions, which start at ground zero and take you through the entire configuration of both the Raspbian OS and Pi-hole itself. There are a few places in process where you’ll have to do a small bit of thinking on your own:

After configuring Pi-hole, reboot the Pi; you should have a functioning ad blocker.

To test it, I changed the DNS settings on my iMac to point to the IP number of the Pi and tried out several pages. It worked for a while and then I did something I’m still not sure of that killed the WiFi connection. It wasn’t a problem with the Eero, as all my other devices were still connected. I rebooted the iMac, its WiFi connection came back, and I haven’t had any trouble with it since.

With a successful test under my belt, I took the big plunge: changing the DNS settings in my router to point to the IP address of the Pi. That required a reboot of the Eero. When it came back, ads were blocked from all of my devices. And my wife’s, too, which led to some difficulties.

First, she couldn’t follow links from Twitter on either her iPhone or iPad. I assumed this had something to do with the t.co domain that Twitter uses for links in tweets. That turned out to be correct, but what was weird was that I could follow those links from all of my devices. I looked in her settings and mine but couldn’t find any reason for this. Going to the Pi-hole admin page and adding t.co to its whitelist solved the problem.

But that got me thinking that other services she uses might be blocked. The people who set up blocklists for Pi-hole, I figured, are probably very militant and will block more than a normal person will want blocked. I was particularly concerned with Instagram and Facebook; Pi-hole could make them unusable.

So we started with Instagram. My wife went to her timeline and started clicking links to see what worked and what didn’t. Most links worked, but a couple didn’t. I looked at the ones that didn’t and they were definitely the kinds of quasi-advertisements that Pi-hole adherents would want to block. “Yeah,” said my wife, “but my friends post these and I like to see them.”

I realized right then that Pi-hole wasn’t going to work network-wide. We didn’t bother checking links in Facebook or, god forbid, Pinterest. I reset the Eero to go back to using my ISP’s DNS servers, and then set the DNS on all of my devices to point to the Pi. This isn’t what the Pi-hole folks intended, but it works perfectly for us. I get the blocking I want, and my wife doesn’t get the blocking she doesn’t want.

In the week since setting up Pi-hole, I’ve had to add only one other domain to the whitelist: bit.ly. I guess I understand why a service that hides what you’re clicking on could seem nefarious, but that’s too severe even for me.

Here’s what the Pi-hole admin dashboard looks like:

Pi-hole admin page

Early on, I added a recommended set of blocklists, thinking it would overwrite the defaults. Instead, it added to them, and I think there are a bunch of duplicates in that 1.6 million figure in the red box. Now that I understand the system a little better, I’ll probably delete all the blocklists and start over with a fresh set.

Overall, I’m pleased with Pi-hole. It was easy to get started and has given me no trouble since I finalized its setup. I’m not sure I’d buy a Pi specifically for it, but it’s a nice service to add if you already have one.


New Apple graphs

It’s a month after the end of a fiscal quarter and time for another round of graphs showing Apple’s performance. As always, you can get a full meal of graphs from Six Colors and MacStories. Here, you’ll be served an amuse-bouche.

The big difference this quarter is that Apple’s report no longer contains unit sales for its devices. As it’s unit sales that I’ve been graphing for the past few years, I had to either give up or figure out a new set of graphs to produce. I chose the latter, but I’m not sure if I’ll keep doing this every quarter. Generally speaking, I don’t find the money Apple makes as interesting as the devices it has out in circulation. It’s the devices that change the world, not Apple’s bottom line. On the other hand, revenue is certainly related to device sales, and moving from unit sales to revenue allows me to talk about services, which are becoming a larger part of the Apple story.

Whatever I decide to do in the future, here’s how I looked at the data for Apple’s holiday quarter. The first thing to know is that Apple breaks down its revenue into five product categories:

The first three are our old friends, the fourth is a lumping together of all the other hardware Apple sells—Watches, AirPods, HomePods, and so on—and the fourth is the category Tim Cook flogs every chance he gets.

It doesn’t take much analysis to realize that none of the latter four categories comes anywhere close to the iPhone as a revenue generator.1 The iPhone accounts for about 60% of Apple’s income, so I decided the best way to start the presentation of the quarterly results was to aggregate the latter four categories and display that alongside the iPhone.

Apple revenue

There’s a lot in here, so let’s go through it piece by piece.

First, Apple’s fiscal year starts at the end of September of the previous calendar year, and I think it’s easier—especially if you want to compare Apple’s performance with the release of products or the introduction of new services—to deal with dates in the regular calendar we all use. So I plot things by calendar year.

Second, I got into this Apple graphing business because I found it difficult to interpret graphs of raw quarterly data. Most of Apple’s sales are so strongly seasonal that it’s hard to see trends unless the data are smoothed. I chose a simple moving average smoother; the smoothed data are calculated by adding the current quarter’s revenue and those of the previous three quarters and dividing that sum by four. The thick solid lines shown in the graph are these moving averages.

Next, the raw revenue figures are plotted as points. In the graph, these are smaller and somewhat muted in color so they don’t detract from the moving averages. I’ve plotted them as dots at the middle of the quarter to which they apply and have connected the dots of the most recent quarter in previous years with a light dashed line. This gives a sense of the year-over-year change.

Finally, Apple just made a change to the way it assigns revenue to the five categories, and it’s published an explanation that also recalculates the revenue in those categories for the four previous quarters.2 Here’s what Apple says:

Starting in 2019, in connection with the adoption of the new revenue accounting standard, Apple will classify the amortization of the deferred value of Maps, Siri and free iCloud services, which are bundled in the sales price of iPhone, iPad, Mac and certain other products, in Services net sales. Historically, Apple classified the amortization of these amounts in Product net sales consistent with its management reporting framework. As a result, the 2018 net sales information has been reclassified to conform to the 2019 presentation.

In a nutshell, by reclassifying some portion of the sale price of its devices as going toward Maps, Siri, and iCloud, Apple has boosted its services revenue by about $640 million per quarter. As a consequence, it has reduced the quarterly revenues for the iPhone ($450 million), the Mac ($70 million), the iPad ($110 million), and the other devices ($10 million).

Thus, comparing revenue figures before the 2017 holiday quarter to figures after that quarter is not an apt3 comparison. The Six Colors crew have done their best to account for this change by estimating how Apple would have presented its revenue figures using the new system for all of the previous quarters, not just the most recent year’s. I decided to avoid the perils of estimation by using shading to partition the graph into two sections, one for the old accounting method and one for the new. The reader is alerted to the change and can make their own judgments about comparisons across the section boundary.

On the scale of the graph above, the adjustment from the old method to the new would be barely noticeable. $450 million is less than one-quarter of the distance between the minor tick marks on the vertical axis, or about the diameter of one of the raw revenue dots. No big deal.

What is a big deal is the downward kink in iPhone revenue caused by the most recent quarter. It’s not just that Apple missed the estimate it made three months ago; it’s not just that iPhone revenue is down from the year-ago holiday quarter; it’s that iPhone revenue is down from the holiday quarter of two years ago. Unsurprisingly, Apple has been focusing on its overall revenue, which although down, is buoyed by the continuing upward trend of the non-iPhone revenue.

And speaking of non-iPhone revenue, let’s split that out into its four components. This makes for a nice graph, because they are all of comparable scale.

Non-iPhone revenue

On this scale, the $640 million that Apple has robbed from Peter to pay Paul is not insignificant. The Services revenue in the unshaded area would be noticeably below what I’ve plotted if we were still using Apple’s old accounting method. Still, Services is rightly considered Apple’s biggest growth category, even though it is growing at a slower rate than it was a few quarters ago.

Down further on the graph, we see that the iPad is about to be overtaken by Other, an ignominious position for what used to be the top dog of the non-iPhones. In fact, if we were to look at the raw revenue figures instead of the moving averages, we’d see that the iPad has come in below Other for the past two quarters.

But we can’t look at the raw figures because I didn’t plot them. Why not? Because doing so makes a mess.

Non-iPhone revenue mess

It’s not impossible to interpret this graph, but who’d want to? Plotting two aspects of four data sets that intersect one another is just too much at once. If we want to look at the raw data of these, it’s best to plot no more than two on the same graph.

You certainly can’t explain Apple in two graphs, but I think these do a good job of presenting an overview of the company’s progressions and regressions from the product side. One unaddressed problem with them is that they don’t account for inflation—something I didn’t have to worry about when I was plotting unit sales. Apple doesn’t account for inflation either, of course, but that doesn’t mean I shouldn’t. If I’m going to keep doing this, I’ll have to decide on an inflation index and a basis year.


  1. The same was true with unit sales, which is why I typically broke out the Mac and iPad sales into their own graphs. 

  2. Big thanks to Jason Snell for pointing me to this document. I could see in the consolidated financial statement that the previous year’s revenue figures had changed from the values reported last year, but I didn’t understand the changes until I saw the recalculations. 

  3. I will not use the phrase “apples to apples.” Even I have some dignity. 


My FileBrowser setup

At the end of my last post, I said that after giving up on trying to use a Luna Display to view local Mac files on my iPad, I hit upon a way to use FileBrowser instead. It wasn’t a particularly profound discovery, but it’s made my setup at work run much more smoothly.

To summarize the last post, I often find myself in the lab at work wanting to look at photos or drawings stored on the iMac in my office. I bought a Luna Display, thinking it would be a good way to do this, but I found running Mac programs on my iPad a frustrating experience. The Mac way of doing things doesn’t work well without a mouse/trackpad and keyboard, and the iPad way of doing things isn’t supported by Mac software.

Enter FileBrowser. Or I should say “Re-enter FileBrowser.” I tried to use FileBrowser a couple of years ago for a similar task—I wanted access to photos on my iMac while in our conference room so I could display them on a TV via my iPad—but didn’t like the long delays and occasional disconnections that kept occurring. So FileBrowser sat on my iPad unused for a long time.

Then about a year ago, I read Federico Viticci’s article about potential replacements for Transmit, the file transfer app. Panic had just announced that they were halting development of the iOS version of Transmit because of low sales, and Transmit users (like me) would have to prepare for a time when an update to iOS would cause Transmit to stop working.1 To my surprise, FileBrowser was Federico’s top choice.

So I found the folder where I had tucked FileBrowser and gave it another chance, this time connecting via SFTP to a couple of servers, including the one that runs this blog. And it worked… fine. It wasn’t nearly as easy to set up or as cleanly designed or as pleasant to use as Transmit, but it was serviceable. The disconnections and delays I’d seen earlier when connected to my iMac over a local network didn’t seem to happen when connected to a remote server. Good to know, I thought, and went back to using Transmit.

It was only after my disappointment with working through a Luna Display that I thought again about FileBrowser. Maybe I should give it another chance.

So I did, but this time I used a different network connection type. When you create a new connection in FileBrowser, you’re presented with a list of connection types to choose from:

FileBrowser choice of connection types

When I first tried FileBrowser, I had selected the Computer/Network Drive, which led to another set of choices:

FileBrowser choice of computer types

From here I chose Mac, and FileBrowser then searched the local network for Macs. I selected my office iMac, entered my user name and password, and then had a connection that I could turn on and off with a tap. A connection that turned out to be frustratingly unreliable.

This time, after my success with SFTP connections to outside servers, I decided to choose the FTP option from the second list. That led me to this setup screen:

FileBrowser SFTP configuration

As I had learned when making the server connections in FileBrowser last year, this configuration system is not much different from starting an SFTP connection at the command line. Fortunately, I have some experience at the command line, so I knew the address field had to include a colon and a port number2 after the IP number and then the path to my home directory after that.

The user name and password fields are straightforward unless you use SSH keys to connect. If that’s the case, the password field should be the passphrase for your SSH key. The file with your private key must then be saved to FileBrowser’s private file area with a special name of the form

username.server.port.sftp

So for this connection (which is fake), the filename is

drdrang.192.168.1.1.2222.sftp

If you’re a Transmit user, you’re probably looking at this with shock and dismay. Panic makes all of this so much easier. FileBrowser’s way of setting up an SFTP connection is very much like editing a Unix configuration file. Inevitably, you will make some small, hard-to-find mistake the first couple of times you try it. Luckily, once you have a connection configured properly, you never have to do it again.

With the connection to my local iMac made, scrolling through a folder of photos is not unlike scrolling through the Photos app.

FileBrowser with grid view of photos in folder

You can use pinching to make the thumbnails bigger or smaller. Tapping on an individual photo brings it up in full-screen mode.

FileBrowser viewing one photo

Pinching also works here to zoom in on a particular area.

FileBrowser after zooming via pinch

Although these examples are JPEG files, all of this works with PDFs, PNGs, Numbers spreadsheets, Word documents, etc. Whatever can be displayed in iOS’s QuickLook will be viewable in FileBrowser.

The obvious question is why is FileBrowser working so well for me now when it didn’t before? That’s easy: I don’t know. But I can think of two possibilities.

  1. Two years of development made FileBrowser better since I first used it.
  2. The SFTP connection I’m using now is simply more reliable than the SMB connection I was using before. SMB is a Microsoft protocol that isn’t always reliable even when connecting a Mac to a Windows computer.

These are not mutually exclusive.

I suppose I should try again with the connection I used two years ago to see if it still gives me problems. Don’t hold your breath. When I’m working in the lab, I need to concentrate on the hardware on the table in front of me, not the software in the air around me.


  1. So far, this hasn’t happened, and I’m still happily using Transmit. 

  2. The standard port for an SSH connection (which is what SFTP runs over) is 22, but many people, including me, configure their SSH server to use a different port number in hopes of cutting down slightly on the number of outside attacks. This is no substitute for real security, but it doesn’t hurt. 


A few days with the Luna Display

A couple of weeks ago, I bought a Luna Display. It worked fine, but it didn’t feel comfortable doing what I’d bought it for, and I returned it after a few days. I learned in those few days that I don’t like running Mac software on an iPad, especially an iPad without a hardware keyboard.

If you know about Squarespace web hosting, Away luggage, and Casper mattresses, you’re familiar with the Luna Display. It’s been a ubiquitous sponsor of Apple-centric podcasts for months, so you know it’s a little plug that pops into the USB-C or Mini DisplayPort on your Mac and allows you to use your iPad as a sort of controllable monitor.

Luna Display dongles

If you want to supplement what you’ve heard on podcasts and what you can read on the Luna site, T.J. Luoma has an excellent writeup on his Luna Display configuration, including some practical tips he’s picked up as he’s gained more experience with it.

When I bought my Luna, I had a very particular use in mind, and it’s that use that informed my ultimate decision that the Luna wasn’t for me. I have an iMac in my office at work on which all my project-related files reside. Each project gets a folder (in Dropbox so I can also get them easily on my home iMac) and a bunch of subfolders for drawings, plans, specifications, and photographs of the machinery or building that the project is about. While I do most of my work in my office, inspections and testing of equipment are done in my company’s laboratory space, some 75–100 feet from my office. What I wanted from the Luna display was a quick and convenient way to refer to drawings and (especially) photographs from my iPad while I was looking at parts back in the lab.

With the photos on Dropbox, I could access them from the lab through either the Dropbox or Files apps, but latency was often a problem, as the iPad had to download each photo from the cloud before it could be displayed. I figured a local network solution, like the Luna Display, would solve the latency problem.

And it did. Photos viewed through the Luna software popped up on the iPad screen quickly because they were coming through a fast internal network instead of through a sometimes sluggish outside connection. Overall, I’d say the Luna Display worked exactly as advertised. But…

Because my iPad was acting as a Mac display, I was viewing the photos through Mac software, and none of the software I tried—while perfectly fine when run directly on the Mac itself—felt right when run indirectly on the iPad.

When I’m working on my Mac and I need to flip through a bunch of photos, I typically open up the folder in which the photos are stored and do one of two things:

This system doesn’t work well on the iPad because its efficiency depends on keyboard shortcuts—the space bar to go in and out of QuickLook and the arrow keys to flip from photo to photo—and I don’t want to bring a keyboard with me into the lab. The value of the iPad in this situation is its compactness, the ability to set it up in a small space that doesn’t intrude on the inspection or test. You might think a keyboard wouldn’t take up enough space to get in the way, but it does.

There are other software options for viewing photos. Xee was the photo viewer I used to use a lot in the pre-QuickLook days. It’s a nice piece of software, and using it again during my Luna Display tryout has made me think I should go back to it (its ability to quickly show EXIF data very useful). But like the Finder/QuickLook system described above, it isn’t efficient without a keyboard and wasn’t a good fit with the Luna.

I also tried out Phiewer, which can give you both an overview of the photos in a folder like Icon View and a detailed view of an individual image like QuickLook. It has onscreen buttons for navigation—which is a waste of screen space for a Mac app, but a godsend if you’re running that Mac app on a keyboardless iPad—but it doesn’t allow zooming via pinching, and that just seems wrong when working on an iPad.

In fact, everything felt wrong when I was running Mac apps through my iPad. Buttons were too small, even when I tried tapping on them with the Pencil. Resizing windows was a chore; dragging felt off. I confess I didn’t spend time examining why the behavior just didn’t feel right, but it didn’t.

I use both my Macs and my iPad a lot, and while I don’t have any trouble switching between the two, I found it very annoying to be forced into using Mac-like actions on an iPad. This was surprising to me, as I have nearly 35 years of Mac use under my belt and only 2½ years of iPad use.1 But my immediate sense—a sense that didn’t change over the 4–5 days I used the Luna—was one of unease.

Would I have felt this unease had I been using the Luna Display in a more keyboard-centric manner? Maybe not. And I can see where people who are iPad-first users would find the Luna very convenient if they only occasionally need to be hands-on with their Mac mini server. But for my use, the neither-fish-nor-fowl behavior that the Luna forced me into was very inconvenient. It made me have to think about what I was doing instead of just doing it, and that got in the way of my real work.

The good thing that came out of my Luna Display tryout was that it made me think harder about a software-only solution to my problem. I finally learned of a way to use FileBrowser on my local network that was pleasant instead of teeth-grittingly frustrating, which was my previous FileBrowser experience. I’ll describe that in a later post.


  1. The 11 years of iPhone are probably a confounding factor in this comparison.