Recently I was adding a photo gallery page to a Drupal 9 site. When a photo was clicked/tapped, the link was supposed to take you to a larger version of the image. Instead, to my surprise, it gave a “page not found” error.
Unix has all kinds of pessimizations that seemed really cool in the 1970s when they were introduced. One of them is
When we last left off, we were able to cook up a service name of our choosing, and resolve it from a client. If we hooked up launchd stuff, we could also make it demand-launch (maybe that’s for another day). But we didn’t actually do anything with that resolution. There are several reasons for that, first, because actually crafting a message and sending/receiving it was covered by a prior article. But even more than that, there are actually a substantial number of design decisions around this task, and plowing ahead requires a lot of text.
I’ll start with the previous server/client, and flesh it out in small steps. In between the steps, I’ll outline design decisions, maybe some history, and pitfalls/sharp edges to be aware of.
Recently a friend and fellow programmer asked me how I learn a new language or platform. I answered that I do it with specific task in mind. Basically, I bumble along googling every little step until I complete my task. But I forgot to tell her about the pitfall of this method…
(This is a sort of simplified retelling of http://fdiv.net/2011/01/14/machportt-inter-process-communication with some added lore. You should probably start there.)
Much of the magic behind macOS and iOS (and all the derived xOSs - watch, appleTV, the stripped down versions in cables and touch bars and wherever else these things invariably end up) is performed with the assistance of other processes (including the kernel). Communicating between them is accomplished by various ways, but for macOS, the underlying mechanism is a client/server IPC mechanism powered by Mach, and the underlying currency is the mach port (
During my time at Apple, I dealt with a lot of rather low-level systems treachery. It’s poorly documented, even internally, and asking for help has roughly even odds on getting a passive aggressive non-answer.
The cool trick for today is creating a “memory object.” A memory object is one or more physical pages that are wrapped in a mach port. With this, you can pass the port to another process, who can map the pages, creating shared memory. Or you can map the pages again in your own address space, to create a mirror, or with different permissions so you can expose read-only pages at an interface boundary while still having the pages be writable at a different address.
Vienna in the 1840s was a scary time and place to give birth. From 1840 to 1846, 7% of women who gave birth at the Vienna General Hospital died of a postpartum infection called childbed fever. One doctor at the hospital, Ignaz Semmelweis, made it his mission to stop the disease. His work saved hundreds of lives, contributed to the development of medical hygiene — and can teach us a few things about debugging.
One day in 2010, I flipped through the latest issue of National Geographic and counted how many women and how many men were mentioned by name. It was actually an article about women in a particular country that sparked my curiosity. The unusually many women in that article (it turned out to be 8 women and 4 men) stood out in contrast with the rest of the magazine. The other feature articles (none of which were purportedly about men) mentioned in total 54 men and 12 women.
A couple weeks ago, Apple posted a note that says:
In an upcoming release of macOS, Gatekeeper will require Developer ID–signed software to be notarized by Apple.
Being a developer of Developer ID-signed (i.e., non-App-Store) software, I set out to vault Apple’s latest hurdle.
Xcode includes a command-line utility called
altool that manages the notarization process. That seems appropriate since my app isn’t built using Xcode’s build system.
Years ago I purchased a Synology NAS (a DS1812+, if you must know). I also purchased some hard drives for it, and a 2GB stick of RAM (bringing its total up to 3GB). Under the hood it’s a dual-core Cedarview Atom x86 CPU, and it runs a Linux distro wherein the owner of the device also has root access (i.e., you own what you own, like in the good old days). It’s also got dual GB NICs, some USB ports, etc.
In addition to storing substantial slabs of data, you can install services on these devices, so in effect they’re more like mini servers than the NAS name might imply. It’s busybox-based though, so a lot of the normal Linux commands act weird or don’t have useful aliases (
less, only a subset of
vi commands work, etc).
One of the services I opted to install was a DNS server, in the hopes that it would allow me to move some per-machine hosts file management stuff to it, and that our previously-rootless devices (read: iPads, iPhones, etc) would also be able to finally take advantage of a local caching name server with internal friendly names for devices that don’t participate in Bonjour.