When the third release of macOS High Sierra came out, I charted the pace of its updates compared to all prior Mac OS X/macOS releases. I said I planned to keep that chart current, so here it is now that the fifth High Sierra update (10.13.3) is out. (Note that 10.0 has vanished from the chart, because it had only four releases.)
Click the above image for an in-window larger version, or just view the full-size version directly.
As you can see, macOS 10.13 took just 120 days to reach its fifth update; that’s nearly half the time (229 days, macOS 10.11) as the next quickest release.
Is it better software updating, catching more bugs earlier and pushing releases faster, or is it just buggier software receiving multiple quick-release critical updates? I obviously don’t know, but my perception as a user is that it’s the latter.
There’s a lot of chatter out there that High Sierra is potentially the worst macOS release ever, in terms of bugs and broken or missing functionality. From the recent Month 13 is out of bounds log spewage problem to the root no password required issue (whoops!) to a variety of other glitches, High Sierra has presented many users, myself included, with a near-constant stream of issues.
But is it actually any worse than prior macOS/OS X1I’ll just call it macOS from here on. releases? There’s really not a lot of information to go on, given Apple’s very-private development process and non-public bug tracker.
However, the one data source I do have is a list of every macOS release date. With 10.13.2 having just been released, I thought it might be interesting to see how quickly the third update arrived on each version of macOS. If High Sierra is worse than usual, I’d expect that the time required to reach its third update would be notably less than that of other releases.
After some fiddling in Excel, the data proved—with some caveats and observations—my hypothesis…
And obviously, it would be, because there is no month 13. But if you’re unlucky enough to be a Mac user in the month of December, 2017, then you’ll probably be seeing a lot of “Month 13 is out of bounds” messages in your Console. And by ‘a lot,’ I mean an exceedingly excessive never-ending stream of spewage…
Thousands and thousands and thousands of them—I’m getting anywhere from two to 20 per second, continuously. Ugh.
This just started happening this morning, and it’s happening on all my Macs. I found one Apple developer forum thread that talks about the problem, and user Helge seems to point to a bug in mdworker…
As a recent somewhat-forced convert to Photos, I’m struggling with a number of things—more on that coming in a future post. But one of the tougher adjustments for me is that Photos uses a floating Info window, whereas iPhoto had an embedded info panel.
I keep the Info window open all the time, because I do a lot of work with keywords and location. (I also like to keep the Keywords window open, though this one was also floating in iPhoto.) I resize the iPhoto/Photos window quite often, depending on what I’m doing with other apps—sometimes I want my photos covering the screen, sometimes I don’t.
In iPhoto, this isn’t an issue (left GIF), as the info panel is attached to the main window. In Photos, though, resizing the main window leaves the Info window floating in space (right GIF).
I don’t like the big gap, either visually or operationally, so I wind up moving the Info window next to the newly-resized main window.
There are a few solutions to this problem, the best of which only Apple could provide. They could make the Info window a panel below the photos, or they could make it magnetic so that it would stick to the edge of the Photos window, even as it resizes. I don’t suspect we’ll see either solution coming from Apple, though.
Instead of waiting for Apple, I used one of Many Tricks’ own apps, Moom, which (among its other tricks) has the ability to save window layouts, either within an app or across many apps.
With the arrival of my iPhone 8 Plus and its A11 Bionic CPU, I thought it’d be interesting to compare its benchmark performance (for the CPU and GPU) with some of the other gear in our home—iOS devices, Macs, and even a PC and a Linux box. In total, I tested 15 devices.
How did I test? I turned to Geekbench, which you can run on MacOS, Windows, and Linux (anywhere from free to $99), as well as on iOS ($.99). It has tests for both the CPU (using single and multiple cores) as well as the GPU (OpenCL and Metal on iOS/macOS; OpenCL and CUDA on Windows; CUDA on Linux).
What follows is far from a scientific study; I was just curious how the CPU and GPU in the iPhone compared to other tech gear in our home. As such, I didn’t run the tests under “ideal lab conditions,” I just ran them—one time per machine, with no special setup other than some basic stuff…
Apple has announced that 32-bit apps have a limited future on the Mac: They’ll be fully supported in this fall’s High Sierra release; macOS’ 2018 release (“Really High Sierra”) will “aggressively warn” users about 32-bit apps, and I would assume, they won’t work at all in the 2019 version of macOS (“That Was My Skull!”).
But how do you know which apps on your Mac are 32-bit and which are 64-bit? MacObserver has an article that discusses the easy way, via the System Information app—just look in the Software > Applications section, and you’ll be able to see a list of apps and a 64-bit Yes/No column. But seeing the list is all you can do—you can’t easily save the list for future reference, for instance, nor can you copy/paste the info to another app.
So here’s a geekier solution to generate a list of your 32-bit apps, saved into a text file for easy future reference. Open Terminal, and paste this command:
system_profiler SPApplicationsDataType | grep -B 6 -A 2 "(Intel): No" > ~/Desktop/non64bit.txt
This does the same thing as the System Information app, but it dumps the data in text form; the greater-than sign redirects the output to a text file named non64bit.txt, saved to your desktop. The grep is used to show only the 32-bit applications (the full line reads 64-Bit (Intel): No), and the -B and -A options are added to capture the lines before and after that line in the output.
This is probably not overly useful to most people, but I wanted a way to capture the list of apps, as I have over 290 32-bit apps on my machine, and it takes a while to run the System Information report each time.
The continuing story of my homebuilt Mac, which I’ve named Frankenmac 2017. In the first installment, I covered resources, choosing parts, and ordering parts. Today, what do once the parts arrive, as mine did yesterday1Not shown: Keyboard, mouse, display, and the case.…
Everything in that shot came via Amazon, except for the CPU heatsink/fan at the back right. That required more driving around than I’d care to admit (one business gone, one out of stock, another unexpectedly closed for the day), but I finally found something I liked. And with that, I had everything I needed to build the machine.
Note: This page
contains an updated list (with links) of the parts I’m using in the project.
Now that I had the parts, it was time to try to turn them into a computer…
It’s been almost exactly nine years (wow!) since I last ventured into the land of Hackintoshes, or homebuilt PCs that can run macOS.
Back then, I built and used one, then wrote about the machine for Macworld, and they even lab tested it, where it held its own against real Macs costing much more.
Fast forward to 2017, and I’ve decided to tackle the project again. Why? Oddly, because there is a new Mac Pro coming, but it’s a ways away. I want something I can use in the interim, without spending a huge amount of money on. When the new Mac Pro ships—assuming it’s not an enhanced trash can design—I plan on upgrading, and the homebuilt Mac will become a gaming PC.
As I’m not writing about the project for Macworld this time around, I’m going to document things here on the blog as I go along. In today’s installment, I cover the first steps in the process: online resources and parts decisions.
I’ll admit it, last week’s news about the new Mac Pro got me excited about the future of the Mac for the first time in a long time.
Note that I am not in any of the target markets for a typical Mac Pro buyer—I don’t crunch huge scientific data sets, I don’t render massive 4K movies, and I’m not compiling huge programs on a daily basis. But I have always been a fan of the Mac Pro for one reason (up until the most recent one, at least): Customization. Having a customizable Mac means it can last longer, as you can make changes to keep up with technology. I have owned both the Motorola and Intel era Mac Pros, and they were truly excellent machines.
One Mac to rule them all
The older Mac Pro (and its predecessors) were—as I recently wrote—wonderful machines, because you, the user, could do so much to them. You could add RAM, of course, but you can do that to most any current Mac.
You could also choose up to four hard drives to put inside the case—no messy cables, no need to worry about a child or pet disconnecting your drive while it’s rendering a movie, etc. If you outgrew them, you could easily replace them. In my Mac Pro, I had an internal Time Machine drive (in addition to the external Time Machine drive.)