What would the Manhattan Project have done with an iPhone?

A coworker, Seph Coster, tweeted:

My first instinct was to respond with a joke. Something like “#oppenheimerselfie”.

I think what Seph was imagining, is the computing power an iPhone represents. In terms of raw capability, the devices we carry around in our pockets (and even on our wrists) definitely outclass the vacuum-tube based computers of that era. It would have been transformative.


I don’t know what the rules of this single device time travel scenario are, exactly– but I don’t think they could have put an iPhone to much use. The iPhone doesn’t support freedom 0, “The freedom to run the program as you wish, for any purpose“.

Even if the Project had the interest and resources to to compile their code into a form that would run on the iPhone, the iPhone will refuse to run any software that hasn’t been “signed” by Apple and distributed via the App Store. Yes, app developers can transfer their own code onto their own devices, but only if they’ve paid their yearly $100 to Apple.

Among myriad other things, both of those paths for getting code to the device require an internet connection (which doesn’t exist yet), and place a company (which doesn’t exist yet) in control of what software can run, or who is an authorized developer.

Could they have gotten around those restrictions? Maybe. Reverse engineering modern DRM systems (or figuring out how to jailbreak), with 1950’s technology, would be big undertaking. Perhaps as big as the rest of the Manhattan Project.

I haven’t brought up one particular very sweet solution yet– if they managed to reverse-engineer WiFI or other wireless protocols, and run a web server, they could theoretically run web apps. It’s a stretch, but perhaps more plausible than routing around the restrictions above.

That aside, almost any other common computing device, any mac, any PC, or phones and tablets running Android, would be more useful.


Previously, I wrote a bit about trying out Red Hat Enterprise Linux Workstation on my laptop: RHEL Notes, RHEL Notes II. I think, ultimately, I was taken in by a pretty simple critical thinking error (I’m sure there’s a fancy name for it):

  • Thing X costs money, under most circumstances
  • I can get thing X for free
  • Therefore, I should certainly use thing X

RHEL Workstation is a perfectly nice desktop, but there’s nothing that makes it a better choice for me, than Fedora, Debian, Ubuntu, Arch, Elementary (and on and on). I want software that’s more up-to-date, doesn’t require a license key, and doesn’t include arbitrary limits on what software I can use.

For now, I’m using Fedora 22.

Docker works, docker-compose fails

I ran into a funny issue yesterday. I was attempting to resurrect an old project (made with fig) using fig’s successor project, docker-compose. For reasons that will make sense in a minute, it’s worth noting that I’m on a mac, and all of the software under discussion was installed with homebrew. Running docker on a mac, means I’m also using boot2docker.

Plain old docker works fine:

$ docker run -it debian:latest bash
Unable to find image 'debian:latest' locally
latest: Pulling from debian
39bb80489af7: Pull complete 
df2a0347c9d0: Already exists 
debian:latest: The image you are pulling has been verified. Important: image verification is a tech preview feature and should not be relied on to provide security.
Digest: sha256:a25306f3850e1bd44541976aa7b5fd0a29beabc137f65acbac34d6918807fd6e
Status: Downloaded newer image for debian:latest

docker-compose, fails hard:

$ docker-compose up
SSL error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:581)

A certificate problem doesn’t make any sense– docker depends on the same certificate files.

Google produced a number of false leads, but I landed on a discussion thread on Github that suggested that there is something broken about OpenSSL 1.0.2.

The comment I linked to above, suggests that I can use Homebrew to switch back to OpenSSL 1.0.1.

brew switch openssl 1.0.1j_1

But,  that presumes that I had the version in question installed at some point. Homebrew doesn’t actually delete old versions until you tell it to, so you can always use ‘brew switch’ to restore a previously installed version.

How do you install an old version, though? Homebrew doesn’t make this obvious at all. To do that, you need to locate the relevant “recipe”  file in the homebrew git repository, and identify the moment in time (in the form of a commit hash) when the software  version you want was current.

Here is the file in question. It seems like the right commit to use is ‘b5cffc8d5fc41540a41ed4deba23afbb6431435e’.

Now what? You have to roll your entire homebrew install down to that commit. In my case, homebrew was installed in /usr/local/homebrew.

$ cd /usr/local/homebrew/
$ git checkout b5cffc8d5fc41540a41ed4deba23afbb6431435e
Note: checking out 'b5cffc8d5fc41540a41ed4deba23afbb6431435e'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at b5cffc8... openssl: update 1.0.1l bottle.

Then, you can ‘brew install openssl’, and you’ll get the correct version. After that, docker-compose will work.

$ docker-compose up
Creating solr_1...
Building solr...

RHEL Notes II: The least asinine way to get Docker on RHEL Workstation?

In the previous dispatch, I whined about Docker not being easily installable on RHEL Workstation. I also spent some time explaining the relationship between Fedora and RHEL.

The solution to my Docker problem comes from another interesting part of the Red Hat ecosystem: ‘rebuild’ distributions.

Just because Red Hat charges a bunch of money for RHEL licenses, it doesn’t stop being Free Software. All of the source code that makes up RHEL is available online. What stops anyone from using that code to compile and sell copies of RHEL? The surprising answer is “trademarks”. You are free to distribute an operating system built from the RHEL source code. You just can’t call it “Red Hat” or “RHEL”, or include any of their other trademarks.

So, several projects have sprung up to do that, most notably Scientific Linux and CentOS. These projects produce operating systems that are functionally identical to RHEL, but are available without licenses and subscriptions. One handy side effect of this, is that a package built for RHEL will work on these derivatives, and likewise, a package built for any of the RHEL-alikes will work just fine on RHEL.

Back to Docker. The CentOS folks have included Docker in their “extras” repository. I created a .repo file (stored in /etc/yum.repos.d) that instructs my system to include CentOS Extras when it searches for software.

name=CentOS-7 - Extras
includepkgs=docker* golang*

Then, it’s a simple matter of:

yum install docker docker-selinux

# if you want to run docker using a non-root account:
groupadd docker
usermod -a -G docker <account name>

# if you're logged into that account, log out and back in a again for the group change to become effective

Then you can docker all damn day.

Running Jenkins in Docker


updated 5/14 to include docker-selinux in the install instructions