I did a clean install of the Mac OS X “El Capitan” beta on my machine this weekend forgetting two things:
- Permissions on my Time Machine backups
- Exporting my Hazel rules before I wiped my old OS install
Trying to solve #2 above had me run into #1. Even with a matching user name and password Time Machine won’t work because the UID of my user isn’t the same as the one on my Time Machine backups.
Trying to use the “Star Wars” interface to Time Machine results in error messages about not having the proper permissions. Viewing the backups folder in Finder shows each folder with a red circle with dash icon indicating I don’t have permissions either so that also wasn’t a way to go about solving my problem.
This website had the cure for my problems. More specifically entering this command:
sudo vsdbutil -d /Volumes/My\ Passport
This turns off ACL security checking on the volume you pass to it. Very handy!
Before I found that I ran this command on the backed up copy of my user Library folder:
sudo chmod -RN /Volumes/My\ Passport/Backups.backupdb/Jason’s\ MacBook\ Pro/2015-08-07-191128/Macintosh\ HD/Users/jkratz/Library
The removes the ACLs from the folder permanently and recursively. It also took a long time since there many files there. Had I run it on the root level backups folder it would have taken forever. The vsdbutil command was much handier.
From Baldur Bjarnason’s blog via Gruber:
For a developer work machine, 16GB is the uncomfortable minimumrequirement. It does not cover the needs of a developer’s average workday without us making some compromises in our workflow and productivity.
I don’t know what kind of heavy development Bjarnason does for a living but I do Java development professionally on a Windows 7 laptop with 8GB of RAM. Daily I run IBM WebSphere and IntelliJ IDEA with no issues in that 8GB of RAM. The Macbook Pro I own and use for personal development projects also has 8GB of RAM and I don’t ever run into problems there either. Would I prefer more? Of course. But to say that 16GB is the uncomfortable minimum for any developer machine is just a bunch of nonsense.
I just upgraded to macOS Sierra (10.12) and have been finding some odd things happening with the search path that is being used to find installed libraries. Unfortunately there isn’t a very good solution at this time but I’m sharing what I’ve found in case it helps someone else.
Apple includes Python 2.7 with macOS and it is used by the system for various things. The general wisdom is to not mess with the system-provided install (and whatever you do don’t remove it unless you like reinstalling the operating system). Because I need to install other libraries that aren’t provided with the operating system I’ve installed the Python 2.7 distribution (at this writing version 2.7.12) from python.org and use that for my development work. That is where the problems start to show up.
There are two ways to install new libraries (called packages) using the pip install tool:
1. The global (global for the Python install) site-packages folder.
2. The user’s own site-packages folder.
Since I’m the only user on my system I prefer to just put everything I need into the global site-packages folder since in my case it is equivalent to the user-specific one.
When the Python interpreter starts up it, through various means, creates a search path that it uses to find other packages that you’ve installed when you try to use them with the “import” statement. You can see this yourself by opening up a Python shell and typing:
1. import sys
You should see something like:
Notice the paths with prefixed with “/System”? There is our problem. Through the standard path extension system our supposed-to-be-standalone Python environment is now seeing one Apple-provided library we might not be interested in using (PyObjC) and a folder where other libraries might be installed.1
The thing to note here is that those paths are at the end of the full sys.path so they will be searched last. If there is a version of the same library (PyObjC) for instance in one of those earlier paths it will be used instead of the system one. So theoretically I shouldn’t have to do anything but I use PyCharm from JetBrains for my Python development and I don’t like seeing this in my projects:
This can be fixed however and here is how to do it:
1. Ignore the problem. If I wanted to do that I wouldn’t be writing this article.
2. Modify a file called site.py that is responsible for generating the Python sys.path
3. Update the file Apple put in place to add those folders to sys.path.
Let’s look at #2 first because that’s the solution I’ve chosen. site.py is installed here by default:
and can be easily edited. The key is to filter out any lines that start with “/System” once the path has been built. sys.path is just a list and can be easily modified by any Python script. I’ve created a gist here with the code. The change was made at line 548 to remove the system paths from sys.path.
One thing to note about doing this is that this file can be overwritten by another Python install and these changes might need to be made again.
What about #3 above? I don’t recommend doing it because it’s an Apple provided file but it’s an easy change to make as well. The file itself is called Extras.pth and just contains two lines: the two paths we want to remove. It lives here:
The only thing required is to comment out those two lines.
I hope at some point there is a better way to address this problem but for now there is an easy solution for it. If you’re not like me and don’t care about having the system-provided stuff viewable by your other Python install none of this is an issue. As noted earlier if you have the same version of a library in one of the folders that’s earlier in sys.path it will be used instead.
Here is a list of some other reading on the subject I came across while looking into this issue. Some very interesting background information here.
- I have to assume that Apple did this to enable people to add packages to the system-provided Python without breaking anything but I don’t like that it’s there polluting my own Python install. ↩
I’ve always been a sucker for the stories of Arctic and Antarctic exploration in the 1800’s and the story of the HMS Erebus and HMS Terror is one I’ve followed for quite awhile. Erebus was found in 2014. Now, they’ve found HMS Terror and in fantastic condition (so great glass windows are still in place). This is a great story.
macOS Sierra Tip # 2: Show hidden files when opening a file
This isn’t as much of a Sierra tip vs. a general macOS tip since this existed prior to Sierra but it’s a useful thing to know.
When opening a file via the standard Mac open file dialog:
press Cmd-Shift-. on the keyboard which will cause hidden files to appear:
Tip # 1: Select the audio output
Back in the old days (in other words, the last release of macOS, El Capitan) it wasn’t quite straightforward how to direct the audio on the Mac to somewhere other than the built-in speakers. In that release, assuming you set the preference to show the volume control in the menu bar, you could option-click and get a menu of choices such as AirPlay-compatible speakers.
No More! With the release of Sierra, Apple has decided to unhide the destination menu and bring it front and center. If you don’t have the volume control icon in your menu bar see the instructions below. If you do simply click on it and choose your destination.
If you don’t have the volume icon in your menu bar…
If you want to display the volume icon in your menu bar it’s easy to find. Open System Preferences and click on the Sound icon:
There is a checkbox at the bottom of that preferences panel to show the volume control in the menu bar. Click that and you’re good to go:
I seem to have a problem: I can’t seem to make up my mind if I should blog or where the blog I can’t make up my mind to maintain should live. I started on WordPress. Then I switched to Squarespace. I got tired of the limitations in Squarespace then went back to WordPress.com. Then I got tired of the limits of WordPress.com and did a self-hosted install of WordPress running on a Digital Ocean droplet. Then at some point I got tired of having to maintain that myself and gave Squarespace a spin again and was thrilled with it. It had come a long way since the last time I had tried. But inevitably I got tired of the limits of Squarespace again and now I’m back on WordPress.com.
Don’t get me wrong, Squarespace is an amazing platform to keep a personal website and the pricing is phenomenally cheap for what they give you but I had three major issues with it:
- Their Markdown editor sucks.
- They no longer have an API for external publishing tools.
- Their idea of image handling is ridiculous.
It’s hard to describe just how poor of a Markdown implementation they have implemented. The editor is buggy beyond belief and it only handles bare bones Markdown. I was not the first one to request a more advanced flavor of Markdown, and I’m sure I won’t be the last, but the requests seem to have fallen on deaf ears because there has been no movement on that part of the tool in a long time. I write everything in Markdown and my preferred flavor is GFM (GitHub Help, or something similar like PHP Markdown Extra because I frequently use the extra items provided by those implementations like footnotes and tables.
Lack of API for publishing tools
I can see the reasoning behind ditching their old posting API because of the way Squarespace pages are built. Every page is usually made up of multiple blocks so that would make creating an external API pretty difficult. It wouldn’t be impossible of course…they could easily limit the API to publishing simple posts (as they seem to do with their own iOS tools) but they obviously think it isn’t worth the cost. I need the ability to post from other tools though and I want the ability to use automation tools like IFTTT with my website. That just isn’t an option with Squarespace right now and from the looks of it won’t be an option anytime soon.
Squarespace can certainly afford to take a look at how WordPress (either self-hosted or on WordPress.com) handles a media library. Every image uploaded to WordPress is easily managed using their media library tools. Squarespace, by contrast, offers no such tools. When you attach images to a page or post they are essentially tied to that page and there is no central place to manage them. Want to get a list of every image asset on your site? Good luck with Squarespace because they don’t have a way to see that type of information.
If Squarespace fixes these things I might consider switching back again. Their pricing and feature set for most people is superior but they just have lousy support for the items that are the most important to me. I might have to dump more money into WordPress to get what I want but at least it is an open environment that has far more advanced management tools.
I have a confession to make: I’m an iOS app addict. More specifically I’m a productivity app addict (well, photography/graphics too but that would be another post). Todo list apps, calendar apps, writing apps, “glue apps” (like Workflow) – if a productivity app gets good reviews from sources I trust I’m all over it to see how it would fit into my workflows.
Over the last several months I’ve read a lot about Ulysses, yet another writing app. Almost every day I came upon someone extolling the virtues of the new universal version of Ulysses for iOS. A fancy text editor that uses Markdown? It was hard not to hit the buy button but at $20 it isn’t exactly an impulse purchase. I then read that Federico Viticci of MacStories had started using it for his writing.1 I bought a subscription to Club MacStories just to read his impressions and after reading that article I gave in and spent the $20 dollars to buy Ulysses.
As always Federico is thorough but the one part of his article that really struck me though was this:
Drafts, too, is a solid app, and I’m happy that I got to know it better, but, inside me, I wasn’t sure about it either. I could get my writing done in the app, but I wasn’t feeling it. I don’t know if this makes sense to other writers, or if I have a problem, or if it’s a combination of both, and all of us who want to get some writing done on iOS have a bit of a problem with the App Store and abundance of choice. Maybe we are all slightly obsessive about this software thing and we just like to create problems for ourselves.
I think Federico hit on something important here: the feeling of using something. I’ve also found that “feeling it” when using a piece of software is important. I’m sure it’s not important to everyone, but I’d bet a good portion of the people who buy apps like Drafts or Ulysses want to feel engaged with the software they are using. Many crave good design in software; some applications have it, some don’t. I love journaling in Day One on the Mac and iOS. I tried using MacJournal, which is also a fine app in it’s own right, but I just never felt inspired when I sat down to write. Something about Day One inspires me and makes me feel like writing in it. I’d say the same thing about my iOS text editor of choice Editorial. It just inspires me in a way that other text apps have not.
In Federico’s example of Drafts (which I also own and use) he talks about not being inspired. That isn’t a knock against Drafts, it is a very well thought-out application with tons of functionality. It was the first text app on iOS to bring a lot of automation to the table to let it interact with other applications. It doesn’t inspire me to write either.
Look at the byline on the website: “where text starts”. Drafts is designed to take notes and small bits of text and send them on their way elsewhere using the automation features. Yes you can write as much text as you want there and it will work but it isn’t designed for long form writing. That’s where apps like Editorial and Ulysses come in.
Federico is wrong though when he says we are creating problems for ourselves. The guy is an app fanatic to be sure. He works around a lot of shortcomings in iOS using apps like Workflow to accomplish things that, in all honesty, could be done easier on a Mac. But he doesn’t feel inspired on the Mac, he feels inspired on iOS. It’s the platform that works for him and he’s done some amazing things with the scriptability of apps like Editorial or gluing apps together using Workflow and Pythonista. Is there anything wrong with that? Absolutely not. Has he spent a lot of time not writing to accomplish these things? Sure but he’s also learned, and taught, a lot as well. There is a lot of value in those things, just as much as in the writing itself.
I’ve read in the recent past that we should all just settle on a set of tools and stop tinkering with our productivity workflows and to a certain extent I believe that. But I am, and have always been, a tinkerer and I derive a lot of pleasure out of it. Maybe it’s time we stop beating ourselves up over it and just have fun. Maybe we won’t be quite as productive as we could be if we just stuck to a set of tools and got to work but it wouldn’t be as fun. There is a lot to be said about having fun.
- If you don’t know of Federico he’s written a fantastic amount about writing on the iPad, including an ebook about Editorial. ↩︎