thedailyjaws referenced the “Jaws” movie crew having nicknamed the prop sharks “Bruce”. Upon reading that, it suddenly hit me that it must be the reason that the great white shark in Pixar’s Finding Nemo was named “Bruce.” Or another reason, anyway. I had always assumed that it was just because it’s a stereotypically Australian name.
Many thanks to David Pierini over at Cult of Mac for interviewing me for this piece regarding those of us who have been helping preserve what bits of Apple’s Newton platform we can. I am honored to have helped carry the torch—from all those who came before, including Victor Rehorst—and be counted with the likes of Grant Hutchinson. Definitely worth the read and a gander at Grant’s amazing photos.
My advice on which browsers to run on which versions of iOS and OS X, from Small Dog Electronics’ Barkings! blog:
Third, and most important, is to run the most modern & secure web browser you can. Apple’s own Safari browser (which is included with OS X and iOS) is fast, efficient, and has excellent integration features, but it is only kept up-to-date for the current & previous version of OS X and the current version of iOS. Fortunately, there are other good alternatives which you can run on older, and current, versions of OS X (listed below by OS X version):
OS X 10.9 Mavericks – OS X 10.11 El Capitan (Intel):
OS X 10.7 Lion – OS X 10.8 Mountain Lion (Intel):
Mac OS X 10.6 Snow Leopard (Intel):
Mac OS X Tiger 10.4 – Mac OS X 10.5 Leopard (PowerPC G3/G4/G5):
As you probably now know, Google is shutting down Google Code in less than a year and are encouraging users to switch to other open source hosting platforms such as GitHub. They have a handy Export to GitHub tool, which is easy, if a bit slow. I had a couple stale projects on Google Code that I hadn’t moved to GitHub yet, so I gave the tool a shot.
It appears to do a good job on the source code side of things, but has a few issues for project wikis (despite automatically converting to Markdown):
1. It doesn’t preserve history or images.
2. It exports the wiki data into a separate ‘wiki’ branch, not the GitHub project wiki.
There’s nothing I can do about the former, but I was able to easily automate resolution of the latter since GitHub allows you to clone project wikis to local repositories for advanced editing.
bash script which—given a Google Code project exported to GitHub—takes the
ProjectHome.md wiki page and makes it into the project’s
README.md file, plus moves all the wiki pages over to the GitHub project’s wiki, fixing page links as it goes. I don’t know why Google couldn’t have included that functionality in their tool since you have to give it access to your GitHub account anyway.
You can find
finishGoogleCodeGitHubWikiMigration on GitHub at (see the README for usage instructions) and feel free to submit pull requests for improvements:
NOTE: While it works on fresh clones of the project repositories, it does modify the repositories. If you don’t like the changes it makes, DO NOT push the changes back to GitHub!
One final comment on the Google Code project export process: you can also set the ‘project moved’ flag on the Google Code project if you want it to permanently redirect to the GitHub project, but I’ve found you cannot revert the change, so only do so when you’re really sure you’re happy with the migration.
My introduction to the Bash “Shellshock” vulnerabilities, from Small Dog Electronics’ Barkings! blog:
OS X is a descendant of a long lineage of UNIX operating systems, from which it inherits its incredible stability and enhanced security. However, the past two weeks have uncovered numerous bugs in a core piece of software relied on by many UNIX operating systems, OS X included: bash (Bourne-again shell). It turns out that these bugs have been very long standing and can be exploited in numerous ways to provide unchecked access to a computer (in some cases remotely) with an afflicted version of bash installed. Due to the surprise and scope of this vulnerability, many have dubbed it “Shellshock”, in reference to the combat fatigue experienced by soldiers, but it’s really not a fair comparison to the effects of war.
Read the full piece for my advice on applying patches to limit your risk.
The Twitter Statuses Badge was an interesting project for me, but was in dire need of some modernization which I had not had the time to give it. While I understand the want for consistency, I’m still disappointed in Twitter for their restriction of artistic freedom with the Developer Display Requirements, the other death knell for my badge.
So, today I officially lie my Twitter Statuses Badge to rest and suggest the use of the official Embedded Timelines instead.
Back when I first started its development in 2007, there was no official, versioned API and it’s managed to continue working this entire time. Clearly, Twitter decided that with v1.0 of the API deprecated, that anything using older calls than that would no longer need to be supported. So, I’ve updated to the v1.0 API calls and all is working again… for now (more on that in a sec).
To the following (replacing “morgant” with the appropriate Twitter username for your use, of course):
A Few Words on the Future