This is not going to be an easy post to write, and I really hope I do it justice.
The Apple/Mac community lost one of it’s finest podcasters today. Tim Verpoorten wasn’t the first Apple/Mac podcaster, but he was one of the very earliest generation. I think it would be fair to call him a father figure to many of us who followed. I know he was one of the podcasters who inspired me to pick up the microphone myself, and I doubt I’m alone in that.
Tim had been unwell for some time, and hung up his microphone to concentrate on his health a while ago, but we all hoped it would just be a temporary hiatus. I don’t think any of us in the community wanted to believe we’d heard the last of Tim’s distinctive and friendly voice.
Every good Apple/Mac podcast brings something unique to the table, and Tim’s Mac Review Cast brought fantastic reviews week after week after week for years and years. Tim had a knack for finding great apps, particularly free ones, and he was able to find and review them at a truly impressive rate. Most people can mange either quantity or quality, but Tim could do both at the same time. Although he reviewed many many apps, you could always tell when an app really appealed to him. Those apps were almost never large apps with lots of features, but small apps that did just one thing, but did it really well. It’s fair to say Tim had a bit of a thing for menubar apps.
Because I learned about so many great apps on the Mac Review Cast, I regularly look up at my menu bar, or into my dock, and think of Tim. One app in particular that I’ll always associate with him is the light-weight Mac-like text editor Smultron. I’d almost given up on finding an editor like this for the Mac, when I heard Tim review Smultron, and gave it a go. It was love at first sight, and that cute red strawberry icon will always bring back fond memories of Tim.
Tim was one of the founders of the Mac Round Table Podcast (MRT), and it was through that podcast that I was fortunate enough to get to ‘work’ (play more like) with Tim. One of the great things about the MRT is how different all the contributors are, and how that opens up some great conversations. We often agreed on things, but when it comes to temperament, I think myself and Tim were polar opposites – I’m know for being the cranky Irishman (sorta) who’s prone to impassioned (and hopefully entertaining) rants, while Tim was always as cool as a cucumber – I can’t remember him ever getting flapped, and I can’t remember him ever having a bad word to say about anyone. I think it’s much easier to go on a rant than it is to remain calm and collected, and I greatly admired Tim’s coolness.
I never met Tim in the real world, yet I feel I’ve lost a friend. The Mac community has certainly lost one of it’s finest ambassadors, but my thoughts are with the Verpoorten family tonight – their loss is so much greater than ours.
This is the third instalment of an on-going series. These blog posts are only part of the series, they are actually the side-show, being effectively just my show notes for discussions with Allison Sheridan on my bi-weekly Chit Chat Across the Pond segment on her show, the NosillaCast Mac Podcast. This instalment will be featured in NosillaCast episode 418 (scheduled for release late on Sunday the 12th of May 2013).
In the first installment we started with the 40,000ft view, looking at what command shells are, and why they’re still relevant in today’s GUI-dominated world. In the second instalment we looked at OS X’s Terminal.app, the anatomy of the Bash command prompt, and the anatomy of a Unix/Linux command. This time we’ll be looking at the anatomy of file systems in general, and the Unix/Linux file system in particular, and how it differs from the Windows/DOS file system many of us grew up using.
This is the second instalment of an on-going series. In the first instalment I tried to give you a sort of 40,000ft view of command shells – some context, some history, a very general description of what command shells do, and a little bit on why they are still very useful in the modern GUI age. The most important points to remember from last time are that command shells execute commands, that there are lots of different command shells on lots of different OSes, but that we will be focusing on Bash on Linux/Unix in general, and Bash on OS X in particular. The vast majority of topics I plan to discuss in these segments will be applicable on any system that runs Bash, but, the screen shots I use will be from OS X, and some of the cooler stuff will be OS X only. This segment, like all the others will be used as part of my bi-weekly Chit Chat Across The Pond (CCATP) segment with Allison Sheridan on the NosillaCast Mac Podcast.
Last time I focused on the shell, and avoided getting in any way specific about the actual commands that we will be executing within the Bash shell. I thought it was very important to make as clear a distinction between command shells and commands as possible, so I split the two concepts into two separate segments. Having focused on command shells last time, this instalment will focus on the anatomy of a command, but will start with a quick intro to the Terminal app in OS X first.
I have no idea whether or not this idea is going to work out, but on this week’s Chit Chat Across the Pond segment on the NosillaCast Mac Podcast (to be released Sunday evening PST) I’m going to try start what will hopefully be an on-going series of short un-intimidating segments to gently introduce Mac users to the power contained within the OS X Terminal app. I’m on with Allison every second week, and I’ll have other topics to talk about, so the most frequent the instalments in this series could be would be bi-weekly, but I think they’ll turn out to be closer to monthly on average. While the focus will be on OS X, the majority of the content will be equally applicable to any other Unix or Linux operating system.
In the last CCATP we did a very detailed segment on email security, and despite the fact that with the benefit of hind-sight I realise it was too much to do at once and should have been split into two segments, it received the strongest listener response of anything of any of my many contributions to the NosillaCast in the last 5 or more years. I hope I’m right in interpreting that as evidence that there are a lot of NosillaCast listeners who want to get a little more technical, and get their hands dirty with some good old-fashioned nerdery!
Something that’s exercised me over the last few years is what I sometimes call “the tyranny of free”, because the instance that everything must be free is actually very costly to us all. But, that’s only part of a bigger picture, and this week’s announcement from Google that they will be killing a number of services people have come to rely on, including Google Reader, got me thinking about this again.
I’ve blogged about the tyranny of free before, so I don’t want to focus on that today, instead I want to take a step back and talk about the importance of following the money.
Back in 2011 I wrote a blog post explaining how to create an OS X Service for stripping keywords from image files. In this post we’ll use the same technique to create a Service for stripping geotags from JPEG images.
As with the keyword stripping service, there are two prerequisites for this action, one is required, one is optional. You absolutely MUST have install EXIFTool installed, and it would be good if you also had Growl installed, but it’s not essential.
This week’s Insgragram TOS kerfuffle is nothing new. Instagram is not the problem, it’s just the latest symptom of a sick business model that has been allowed to become so dominant as to be almost un-challengeable – services on the web MUST be free, so you MUST give up your privacy and/or your intellectual property rights to enable the service providers profits. If you dare stand up for privacy then you are a greedy idiot who wants something for nothing, and you need to grow up and let the companies make money.
My problem is not that companies want to make profits, it’s their instance on selling our data to do it that I have a problem with. How about this for an idea – why not let people pay for services rather than insisting we all whore out our privacy and intellectual property?
- It is now possible not to use any separator between the words that form the basis of your randomly generated password
- The padding character can now be set to be randomly chosen, independently of the separator character. This is now the default setting, and provides more entropy by default.
- An additional care transform has been added, you can now choose to have the capitalisation alternate on each subsequent word.
- When the
custom_separatoroption was left blank, no separator was used, rather than the expected random separator.
- When the
custom_separatoroption was left blank or set to
RANDOM, and the
SEPARATOR, the results were un-expected, different random character was used for each, rather than the same random character.
For documentation and detailed release notes on version 2 of the module, see the release notes for version 2.0.
A few weeks ago on the Chit Chat Across the Pond segment of the Nosillacast, I mentioned that I had an OS X service set up to generate a random password using my XKpasswd Perl module and copy it to the clipboard. Listeners enquired as to how they would go about doing that, so as promised, here’s a quick tutorial.
Obviously this tutorial is for Mac OS X users only, because OS-wide Services and Automator are OS X features. The screenshots are taken on 10.8 Mountain Lion, but this same technique definitely also works on OSX 10.7 Lion, and probably even on 10.6 Snow Leopard. This tutorial also assumes that you have downloaded the
XKpasswd module, and saved it somewhere on your computer, along with either the sample dictionary file included with the module or one of your own making, and that you know where on your computer those files have been saved. In other words, you need to have
XKpasswd.pm and a text file with one word per line somewhere on your hard drive. In my sample code I’m going to assume you’ve installed the Perl module to the suggested location,
/usr/local/xkpasswd/XKpasswd.pm, and that you have customised the sample dictionary a little (more secure that way), and saved it to