Journal OSX

Homebrew on macOS 10.12 Sierra

Apple introduced a few changes with the directory structure and permissions in macOS Sierra 10.12 which in the beginning broke Homebrew on macOS without some CLI magic to manually fix things. However, this has been fixed and Homebrew now full supports macOS 10.12. One of the issues was around a change in permissions on the directory /usr/local which on a new installation either doesn’t exist or wasn’t writeable.

Therefore Homebrew changed their installation routine and migrated the installation folder to /usr/local/homebrew in order to circumvent the whole permissions issues.

Install Homebrew

The following Terminal command will download and install Homebrew. Ruby comes pre-installed with macOS and therefore just copy and paste the following command in your Terminal:

ruby -e "$(curl -fsSL"

Homebrew requires the command line tools which ship with Xcode. If you don’t have Xcode or the command line tools installed, macOS will automatically prompt you to install them. You can get away with the command line tools by clicking install.

However, you can also get Xcode by downloading it free of charge from the AppStore. Here, I will simply install the command line tools.

To check for any issues after the installation, run:

brew doctor

To search for an application:

brew search <application_name>

To install an application:

brew install <application_name>

To list all applications installed by Homebrew:

brew list

To remove an installation application:

brew remove <application_name>

To update Homebrew:

brew update

Fixing brew after upgrade to macOS 10.12

If you had brew installed before upgrading to macOS 10.12 you will notice that the upgrade broke brew. The following instructions will fix the broken install and will let you upgrade brew to the latest and greatest which supports 10.12

Accept the license agreement of the command line tools shipped with Xcode

sudo xcodebuild -license

Change ownership of /usr/local to yourself:

sudo chown -R $(whoami) /usr/local

Run brew doctor and brew update. The installer of the update will inform you that it will migrate the brew repository to a new directory:

brew doctor && brew update

=> Migrating HOMEBREW_REPOSITORY (please wait)...
==> Migrated HOMEBREW_REPOSITORY to /usr/local/Homebrew!
Homebrew no longer needs to have ownership of /usr/local. If you wish you can return /usr/local to its default ownership with:
sudo chown root:wheel /usr/local

Change the owner back to the defaults with:

sudo chown root:wheel /usr/local

Journal OSX

Homebrew on OSX 10.11 El Capitan

Homebrew is a great package manager for OSX and one of the easiest ways to install Unix tools and open source software (Homebrew most certainly isn’t the only package manager out there: other popular choices: Macports and Fink but Homebrew is my personal favorite).

In order to install Homebrew you need XCode and the respective command lines tools. Xcode is available in the AppStore Screenshot 2016-01-01 13.53.40

Download and Install Xcode. You have to run it once and agree to the license. It will automatically start installing the components. Grab a cup of coffee/tea it will take a few minutes even on a fast machine with a SSD.

Screenshot 2016-01-01 13.54.45

Open up a Terminal and issue the following command to install the command line tools

xcode-select --install

Before you can download and run the script to install Homebrew you have to temporarily disable the System Integrity Protection of OSX in order to write to the /usr folder and create the installation root directory /usr/local.

If you encounter any permissions issues the following article provides instructions to fix the permissions problem. In case you upgraded an existing installation to El Capitan the /usr/local folder will most probably exist already and you will only have to issue the following command to fix the permission problem:

sudo chown -R $(whoami):admin /usr/local

If it’s a fresh installation (wiped the hard drive or simply bought a new Mac) /usr/local will not exist and you have to manually create the folder.

  • Reboot into recovery mode (Hold CMD + R on boot) → Utilities → Terminal
  • Temporarily disable SIP: csrutil disable
  • Reboot back into OSX
  • Open the Terminal application and issue the following command:

sudo mkdir /usr/local && sudo chflags norestricted /usr/local && sudo chown -R $(whoami):admin /usr/local

The command creates the installation directory for Homebrew and removes the directory flags that restrict access to it when SIP is re-enabled.

Reboot back into recovery mode and issue the following command to reenable SIP protection:

csrutil enable

Reboot back into OSX and now you will be able to write to /usr/local and install Homebrew by starting the following script in a Terminal:

ruby -e "$(curl -fsSL"


After completion of the installation check for any outstanding issues as suggested at the end of the setup by issuing the following command:

brew doctor

A short list of commands for Homebrew, refer to the man page for more information:

To search for an application: brew search <search_keyword>

To install an application: brew install <application_name>

To list all applications installed by homebrew: brew list

To remove an installed application: brew remove <application_name>

To update Homebrew: brew update

Homebrew’s default installation directory: /usr/local/Cellar
This ensures that Homebrew doesn’t interfere with Unix utilities shipped by OSX (e.g. if you install python3 via Homebrew it will not interfere with the Version shipped with OSX)

Journal OSX

System Integrity Protection in OSX 10.11 EL Capitan

System Integrity Protection is a security technology introduced with OSX 10.11 that helps to inhibit potentially malicious software of modifying essential system files and folders on the Mac which can prevent your Mac from booting or compromise its security.

In previous OSX Versions the “root” user account had no permission restrictions and had access to any system files and applications. Software gained root-level access when a user entered an administrator name and password to install or run an application which then was able to modify or overwrite any system file or application.

System Integrity Protection (SIP) uses sandboxing technology to restrict the root account and limit actions that it can perform on the protected system parts of OSX.

Paths and applications protected by System Integration Protection include:

  • /System
  • /usr
  • /bin
  • /sbin
  • Applications that are shipped with OSX

Paths and applications that are exempt from SIP and third-party software can write to include:

  • /Applications
  • /Library
  • /usr/local

The protected parts of OSX can only be modified by processes that are signed by Apple which are granted special permissions to write to system files such as Apple software updates and Apple installers.

Third-party applications downloaded from the Mac App Store already work with SIP. Other third-party software might conflict with SIP and might require an update to make it compatible with OSX EL Capitan.

In addition, SIP also prevents software from automatically changing your startup volume. To start up the Mac from a different volume, press down the Option key while the Mac is restarted or use the Startup Disk Pane in System Preferences and select a Volume from the list.

[Disclaimer – I take no responsibility for any damage to you or your system inflicted by following any of the presented instructions]

Certain applications or abandoned old software that is no longer supported might require you to disable SIP in order to make them work on OSX El Capitan. Follow this steps to disable SIP:

  1. Reboot the Mac into Recovery Mode by restarting the Computer and holding down Command + R until the Apple Logo appears on the screen
  2. Select Utilities → Terminal to open up a shell
  3. Enter: csrutil disable
  4. Reboot the Mac

You can verify if a file or folder is is restricted by issuing the ls command with the -O (capital “O” not zero) to modify the long listing flag

root folder listing

Journal OSX

Swift Programming Language is open source!

Apple finally adhered to their promise from WWDC 2015 of open sourcing their new programming language, Swift. In addition to the source code to the compiler, Apple also released the very first implementation in Swift of the “Foundation” library that serves as the standard library for all OS X and iOS application. All the source – code and everything else was released under the Apache 2.0 license which grants the user of the software the freedom to use the software for any purpose, to distribute it, modify it, and distribute modified versions of it, under the same terms of the license without concern for any royalties. The great advantage of the Apache License is that it’s a permissive license, so software derived or which makes us of the software does not necessarily need to be licensed under the same license which leaves ample room for commercial closed-source software to use Swift.

So far Swift’s application was fairly limited to Apple’s own platform since no compiler or runtime library was available for other platforms. As fantastic as these platforms are to develop for, heck even I use a Mac as my main desktop machine, they only make up for a fraction of a much larger universe (my servers all run CentOS Linux). Making Swift publicly available provides access to this interesting language to a much larger developer community.

Why is the Open Sourcing for Swift so interesting?

First of all, if you’re interested in or currently are developing for one or more of Apple’s platform and are using Objective-C, then you will need to learn Swift, as soon as you can. In case you are not developing for one Apple’s platforms, which include OS X, iOS, tvOS, watchOS, and who-knows-what in the future, then currently, the applications of Swift are fairly limited to a few proof-of-concepts implementations on non-Apple platforms like Linux.

Still, why is Swift so interesting to me? It’s an extremely modern language with clever design elements, a very elegant syntax, strong safety features and, thanks to being derived from the LLVM compiler project, is extremely fast. A few of the especially interesting features for developers are: a cool error handling / exception system and Swift’s  adherence to a protocol-oriented architecture.

In Swift, no values are allowed to be null. If you declare a value as
Int, you have to assign an integer value; if you declare a
String value, it can’t ever be nil.

var exampleString : String
exampleString = nil                   // error !

Trying to set a variable to nil will result in a compiler error. Variables in Swift are only allowed to be nil, if they’re optional variables which are declared with a question mark after its type:

var exampleOptionalString : String
exampleOptionalString = nil           // allowed

The question mark indicates that a value may be assigned to the variable and it equals to X or there isn’t a value at all. Optionals are similar to using nil with pointers in Objective-C, but they work for any type, not just classes. Optionals are safer and more expressive than nil pointers in Objective-C and are at the heart of many of Swift’s most powerful features. Because a variable’s “nullability” can be determined at compile time, a large number of null checks can be avoided. Swift helps you to be clear about the types of values your code can work with. If part of your code expects a String, type safety prevents you from passing it an Int by mistake. This enables you to catch and fix errors as early as possible in the development process.

Swift also provides an interesting error-handling system which, in my personal opinion, improves the readability of the code. The system is derived from the older NSError system used in Objective-C APIs. It separates the idea of exceptions into two concepts: errors which are the fault of the programmer, and errors that result from user input or the environment. This distinction is important, because it’s not the user’s fault if the developer failed to check the bounds of an array before attempting to access a value, however the user should be notified if the app failed to save a file because the disk is full.

Based on this, Swift distinguishes between exceptions and errors. Exceptions are thrown by the system and always result in your program exiting with an error. Errors are triggered by problems that the user can at least attempt to deal with. Swift’s syntax requires the developer to be especially cautious about functions that can possibly cause issues.

Consider the following Java-snippet:

try {
            String data = getData();
} catch (Exception e) {
            System.out.println("Exception: " + e.getMessage());

It’s not obvious from the code which of the three lines in the try section may possibly result in an exception being thrown. However, the equivalent code in Swift makes it clear which lines can throw an error:

do {
            try openFile()
            let data = getData()
            try writeToFile(data)
} catch let error {
            println("Error: \(error)")

In Swift, any function that can throw an error is required to be wrapped in a do block, or else their calling method must be marked as throws. In a similar fashion, methods in Java must either be wrapped in a try block or have their calling function list the possible exception that they can re-throw in the signature.
The interesting difference here is that each individual line that can throw an error must be prefixed with try. Anyone reading the code can quickly grasp which line or method might fail; in the given example, openFile and writeToFile are the problematic lines which can cause issues.

Lastly, in Swift, along with many other languages, there is this idea of a data type that contains a list of possible methods that a type respectively a class can implement. Java and C# refer to this as an interface, while C++ refers to it as an abstract base class. In Swift, this is called a protocol.

The following example shows a protocol that defines methods for processing some data:

protocol IntegerProcessing {
                 func processNumber(number : Int) -> Int

Any class can then choose to conform to the protocol like this

class MyNumberProcessor : IntegerProcessing {
                  func processNumber(number : Int) -> Int {
                           return number * 2

Even for a novice developer this might look like very benign stuff. However, the real strength and flexibility comes from the fact that the majority of the Swift standard library and the Swift language itself is largely implemented through protocols. Let’s consider the following simple example of comparing two values. In almost all programming languages, it’s possible to compare to integers to each other using the == operator:

2 == 2    // true

In slightly fewer languages this ability to compare values is extended to Strings (including Swift, but for example not in Java):

"foo" == "bar"  // false

The Equatable protocol in Swift requires that any class that conforms to it (“implements”, in Java/C# parlance) implements a version of the == operator which allows two objects of the same type to be compared against each other.

This philosophy of protocols defining the behaviour of objects, rather than their inheritance tree shapes a larger number of aspects in Swift. It’s an interesting approach to development and I’m eager to see this applied elsewhere.

I believe that these features any most definitely many more are responsible for Swift living up to its designers’ goals of being “fast, modern, safe, and interactive”.