Archives For MacOS

powershell on macos

July 4, 2017

I wrote in an earlier post about easily installing multiple applications on macOS. One of those applications interestingly enough is Microsoft’s PowerShell. Microsoft has open sourced PowerShell and made it available on GitHub ( From GitHub you can either grab the source and build it yourself, download and install a pre-built binary, or both. I chose to just grab the binary and run with it as I have enough projects to keep me occupied as it is. The current PSVersion is 6.0.0-beta, and it’s shown running on macOS 10.12.5.

I start PowerShell for Mac from the ITerm2 command line, and from there I can look about PowerShell all I want. While the shell appears feature complete as far as syntax is concerned, PowerShell for Mac is missing considerable core .Net functionality when compared to the versions that run on Windows. As one small example shows below, Get-PSProvider doesn’t show the provider for the registry, as there is no equivalent (at all) on macOS. While it’s nice to have the same shell running across multiple platforms, as bash does, PowerShell for Mac and Linux isn’t going to be nearly as useful as it is on Windows if you want full Windows functionality on another OS. Any PowerShell scripts that are developed to take heavy advantage of Windows OS functionality are going to fail pretty hard on both the Mac and Linux, just to give you fair warning.

By the way, two comments on PowerShell help:

  1. If you decide to update PowerShell’s help, then run PowerShell as sudo before running Update-Help, or the updates will fail.
  2. The graphical view of help (via -ShowWindow) isn’t implemented and won’t work.

One tool not provided by the PowerShell project is the PowerShell ISE (Integrated Scripting Environment). The ISE is bundled with every copy of Windows these days, and is a powerful way to write and debug PowerShell scripts of any complexity on Windows. For the Mac the next best tool to use is Visual Studio Code with the PowerShell v1.4.1 extension (see below). You get full syntax highlighting and support as well as a split screen with code at the top and a PowerShell prompt at the bottom. The only major feature missing in this setup is the help section that is displayed to the right (by default) in the native ISE.

PowerShell for Mac and Visual Studio Code for Mac are an interesting counterpoint to Windows Subsystem for Linux on Windows 10. For those folk who like to “swim” in the lower regions of coding and operating systems, we’re living in a golden era.

my opinion on macos

July 2, 2017

In the last post about iOS, reader Wolfgang Lonien asked:

Would be interesting to hear your opinions about MacOS vs. Linux and BSD. How much of it is open like in BSD, how much is the proverbial “walled garden”?

The answer is complicated, and I’ll answer it in two parts.

Open vs Closed

The commercial version is closed. It’s not open like Linux or BSD. macOS as it’s now known (and was known as Mac OS X in previous incarnations) is closed, along with the many support frameworks and applications that come bundled with it. It’s shipped pre-installed on every Mac that Apple sells, ready to run as soon as the new Mac is powered up. This simplifies things greatly. The problem with this pat answer is that while the official binary version as shipped is closed, Apple has released the source code in a limited form for an open version known as Darwin.

Darwin is the source to an operating system composed from NeXTSTEP (later OPENSTEP), elements from BSD, and the Mach microkernel. NeXTSTEP was the underlying OS for Steve Job’s NeXT computer, the computer he developed when he left Apple in 1987. When Steve was re-hired by Apple in 1997, one of the stipulations placed upon Apple upon re-hiring Steve was that Apple would buy NeXT. Apple then announced that the next official Apple OS for the Mac would be derived from NeXTSTEP/OPENSTEP. It was finally released as a public beta in 2000 as Mac OS X. At the same time in 2000, the core elements were released as open source as Darwin under the Apple Public Source License. The Cocoa and Carbon frameworks in particular, as well as many higher-level tools, remained closed.

Here’s what uname -v shows in ITerm2:

Darwin Kernel Version 16.6.0: Fri Apr 14 16:21:16 PDT 2017; root:xnu-3789.60.24~6/RELEASE_X86_64

In the first ten years of Darwin, up to 2010 and Darwin 8.0.1, Apple released a binary ISO to help install Darwin. After 2010 it has only been released as source code. Apple has never released the iOS variant for ARM.

I’m sure this sounds terrible to the purists, but I personally don’t care. The OS works, it’s solid, and I love the desktop. After over 30 years working with graphical desktop operating systems from Windows 1 through AT&T System 3, IRIX, UnixWare, Solaris, and on through Windows 10, I find macOS to be the most refined of them all. It’s notable that macOS is the first, and only, BSD variant I work with. I’ve tried many times in the past to install Free BSD and Net BSD on hardware and virtual machines, and I’ve given up every time due to one stupid glitch after another with the installation. I have no love for any other BSD except Apple’s macOS.

Walled Garden vs Open Installation

Apple’s macOS has its own App Store where you can purchase thousands of applications. It’s not ideal, and many have complained against it since its introduction in 2011. My biggest complaint is that I can’t update apps purchased outside of the app store within the app store. Biggest example of this is my purchase of OmniGraffle. While the App Store shows I have it installed, I have to go to the Omni Group’s website to pick up (and pay for) major upgrades. Free minor updates come via the application itself. It’s an annoyance, to be sure, but it points to a key positive point: You can install any software you want without having to use the App Store.

I have, for example, HomeBrew, through which I have the latest releases of gcc, python, and R; Google’s Go language, Mozilla Research’s Rust, Oracle Java (version 8 update 131 for now), NetBeans 8.2, JetBrains Toolbox with four of their IDEs, Xcode, Visual Studio Code, Android Studio, PowerShell for macOS, Sublime Text, Iterm2 (because I absolutely cannot stand Terminal), VirtualBox (with several Linux VMs), Office 365, GitHub’s desktop, Unity, Blender, Lightroom, and on and on and on. In short the system is wide open to serious development tools and just about anything that can be installed and/or compiled to work on macOS.

As for the App Store, it’s good about delivering updates/upgrades to macOS and all the Apple tools that came pre-installed. The only thing I’ve installed from the App Store are “minor” applications like Bear (in fact I think that’s the only thing I’ve installed from the macOS App Store). macOS isn’t locked down the way iOS is, and I appreciate that, the same way I appreciate that iOS is as locked down as it is. My iPhone has become a vital part of my personal and work life, and if it wasn’t as locked down as it is now, I’d lock it down hard myself. It’s one of many reasons I switched from Android (Samsung Galaxy) to an iPhone back in 2015. Android is far more easily hackable and rootable than iOS; way too easy.

One More Thing

macOS is UNIX Certified, specifically The Open Group UNIX® 03 standard. I tend to pay attention to standards in my line of work, and the fact that macOS conforms to the UNIX standard, instead of calling itself UNIX-like, adds to the value of the overall computer system I use for my personal and professional work. Neither Linux nor the free BSDs are there, and probably never will be. That doesn’t mean I won’t use them, but then again, it also means I won’t walk away from macOS nor the hardware on which it runs. I depend on all my tools, and I want them to be the best quality tools I can possibly afford. macOS definitely fits in the quality tool category.

There has been talk for some time about how Apple devices running iOS are contenders for replacing standard Intel architecture computers, such as MacBook Pros. Since I have a number of Apple devices, I thought I’d install Geekbench 4 (version 4.1) and run it across three of my Apple devices. I’ve put the results in a simple table below, with the results in the first three rows.

MBP mid-2015 iPhone 7 Plus iPad Pro 2016
CPU Single-Core 4462 3457 3017
CPU Multi-Core 16005 5872 5082
Compute 38117 12296 14764
Processor Intel Core i7 Apple A10 Fusion Apple A9x
Max Frequency 2.8 GHz 2.34 GHz 2.26 GHz
OS macOS 10.12.5 iOS 10.3.2 iOS 10.3.2

The MBP I own is a 15″ Retina MBP with 16GB of memory and the 2.8GHz quad-core i7. I wasn’t surprised to see the MBP be the leader across the board, particularly in multi-core scoring. The MBP is certainly the brawniest of the three with its Intel processor and eight times the memory over both the iPhone and iPad. Keep in mind that the MBP is the oldest of the three devices.

What I found rather interesting is the GPU-based Compute score. The iOS version of Geekbench uses Metal, the graphical framework that’s a part of iOS. Geekbench on the MBP uses OpenCL and because I’m too cheap to buy a copy, the built-in Iris Pro on the i7 processor was used instead of the beefier AMD Radeon R9 M370X. So even though I’m using the “lesser” graphics processor and “poorer” graphics software framework, the MBP still scored a solid two to three times faster than either iOS device. Of further note is the sizable performance lead of the iPad over the iPhone, even though the iPhone’s CPU is clocked faster and it’s using a more current Apple SoC.

So, am I ready to trade in the MBP for either iOS device? It all depends on the use case.

For general uses involving reading content and typing, I could easily switch to the iPad Pro. I use it with a Logitech keyboard-and-cover in landscape mode, which, when attached to the iPad using the Smart Connector gives me a decent keyboard with back-lit keys. It’s not as efficient and comfortable as the MBP keyboard, but it’s more than serviceable especially over a period of hours. I can do writing and other types of textual creation, as well as fairly sophisticated graphical content creation and photo/video post processing. There are, however, limits to the iPad Pro.

For the ultimate web experience I prefer the MBP and my selection of browsers, which includes Chrome, Firefox, and Vivaldi. I am not a fan of Safari on either iOS or macOS, and I don’t think I ever will be. What makes web browsing on iOS truly annoying is Apple’s insistence of forcing every other browser to use the Apple web engine used by iOS Safari; it is buggy and poorly performant.

When I need to develop software I much prefer the MBP. When I need to do light code editing on the iPad Pro I use Textastic with Working Copy. I have iOS Terminus that allows me to ssh into machines around my home running Linux and macOS (nothing like that for Windows, unfortunately). Under ssh I tend to use vim with extensive vim customizations and colorizations. And I can use scp and git to move things around that need moving. So the iPad Pro makes a pretty decent work platform when I don’t want to fire up the MBP, especially when I need to put it down due to interruptions.

I haven’t even mentioned the iPhone, but it’s decent enough that it can fill in for the iPad when all I can carry with me is just the iPhone. I use a Microsoft Folding Bluetooth keyboard to type on, and I have an SDHC to Lightening card reader for reading JPEG and RAW files produced by my Olympus cameras. The same apps I would use on my iPad to post process work just fine on the iPhone 7 Plus. And when I don’t want to, or can’t have, my Olympus camera, then the iPhone 7 Plus camera is just fine.

Finally, there’s the truly heavy lifting that the MBP is called upon to do. For example, I have a number of Linux virtual machines I power up to perform testing and development in parallel with work on the MBP. I use Xcode to develop iOS applications, as well as Android Studio to develop Android applications. If I want to develop using a full Javascript stack starting with node.js, then the MBP is the only way to go. If I want to develop in Java or Python or Go or Rust, only the MBP allows me to do that.

And the 15″ screen on the MBP is the easiest of all the screens to read, which is important due to my poor eyesight (20/700 and near sighted).

There is no easy answer to the original question, except to say it all depends. As long as I can choose which to use for which task, I will choose all three based on the work at hand that needs to be done.

But I am impressed with what the Apple SoCs can accomplish. While the MBP rules them all, for single core scoring all three devices are fairly close together, compared to multi-core and compute. This bodes well for Apple’s continued evolution of its ARM-based processors, and if I were Intel, I really would be looking over my shoulder at ARM in general and Apple in particular.

Visual Studio Code in PowerShell Git Repository

Visual Studio Code in PowerShell Git Repository

While taking breaks during the day (and later this evening) I pulled the PowerShell source from Github. I got it to build, after a fashion, but the build process wants to run a series of tests, and the tests are failing a bit. Considering this is alpha code, I’m not that concerned, and consider this to be a learning opportunity.

I will clarify this about the build directions on OS X;

  1. install a PowerShell pre-built binary as Microsoft recommends and start that up;
  2. go down into the PowerShell top Git directory (in my case it was ~/Git/PowerShell);
  3. execute ‘Import-Module ./build.psm1’ within PowerShell.

That will define the PowerShell function Start-PSBootstrap that you need to execute in order to set up the PowerShell build environment. That little detail about sourcing build.psm1 is missing in the OS X directions, although it’s there in the Linux directions. Good thing I read around a bit…

GitHub Desktop with PowerShell Repository

GitHub Desktop with PowerShell Repository

I am pleased with the tools I have installed on the MBP. Visual Studio Code seems to be a rather decent editor (and debugger with the right extensions installed). I’m using it so far for Rust, Go and Python, and tonight I got it set up for C# editing. It comes with the ability to navigate a local Git repository copy out-of-the-box. All on a MBP under Mac OS X 10.11.6. I’m also pleased with GitHub Desktop. I can browse the repository metadata and the diff tool is again pretty decent. My only problem is I couldn’t use the Desktop to do the pull; I had to use the command line tool. I’m no git expert, and my understanding of the Desktop is even more limited. But again, it’s an opportunity to learn.

I’m something of a tool packrat, having installed a fair number of editors and IDEs over the years. For example I’ve purchased a license for Sublime Text, I’ve got Komodo Edit 9 installed, and I even have a copy of Atom installed. About the only editor I don’t have on OS X is Notepad++ (unfortunately, only available on Windows), an editor I use on Windows when I need to get serious about text and code editing without the bloat of a full-up IDE.

So, new tools, new code, a new(ish) shell to spark some interest. I’m looking for a full-up replacement for Java, so maybe I need to give C# another look. PowerShell is written in C#, so there’s that. I know that the cool kids look askance at C#, and I know that Java is still considered the #1 language for making a living. But Oracle has made using Java hellish, and I have no desire to use the language any more. C++, C#, Python, Rust, Go, Javascript; there are so many other good alternatives and what I listed doesn’t scratch the surface of computer languages. It’s such a rich development environment these days.


tl;dr: It was permissions issues that kept Django from executing properly on Arch ARM and the Raspberry Pi 3. Read on for the details.

Well, looks like I have to walk back that snide comment about Arch running on a Raspberry Pi 3. While I’m certainly no hero, I was irritated considerably by Django’s flagrant failure, enough to find out why. But first, some background.

  1. Django, along with a lot of other Python packages, is located in the system’s site-packages directory. On the RPi 3 running Arch ARM it’s /usr/lib/python3.5/site-packages. The site-packages directory is owned by root (root:root) with permissions 755. Permissions 755 means root can read/write, while group and the world can only read and execute from that directory.
  2. With that kind of ownership I had to install Django with ‘sudo pip install django’ (without the quotes, obviously). After installation every directory had 750 permissions, and every file had 640 permissions, with root:root ownership. That means, using the non-root account alarm, I had no permissions to read anything in the django installation.
  3. And thus any attempt to use django-admin was bound to fail

I don’t have copious amounts of time to work on these kinds of issues. So while I was out working on my honey-do list, while at Trader Joes in the organic produce section, the light went on as to what the probable problem and solution was. Sure enough, when I got home and found a minute to look, that’s when I found the permission settings all wrong. A quick ‘sudo find . -type d -exec chmod 755 {} \+’ and ‘sudo find . -type f -exec chmod 644{}\+’ fixed things up, and I was able to get a quick and dirty Django web server up and running. In fact, to test a capability I’ll need, I tarred up the sample I built on the MBP, secure copied it over to the RPi 3, untarred it there, and got it up and running. Here’s a couple of screen shots of it in action on the RPi 3:

Screen Shot 2016-08-14 at 2.46.50 PMScreen Shot 2016-08-14 at 2.48.01 PMLooks like I’m back in business. The only thing I edited on the RPi 3 was the polls/ with vi to change the text output by Other than that, I simply started it up.

This is the first time I’ve ever had a problem with permissions using pip and Python. In the future I’m going to have to be careful with Arch ARM. It’s a small issue, considering everything else works just fine.