Dear Apple, are you really forcing me to choose between buying new hardware and a Windows license?

We have an early 2008 MacBook “Blackbook” that is still working perfectly well and does everything we ask from it. It’s one of the reasons I love Apple hardware – it’s well engineered and works without a major fuss. Obviously we’re not playing games on it but it’s perfect for us to use for tasks that need a bit more power or typing than you’d want to do on a tablet. It’s also perfect for doing tasks that I want to use a separate computer for, like online banking.

Unfortunately it just stopped being perfect for those tasks because the last operating system that supports it is OS X 10.7 (aka “Lion”). It doesn’t meet the requirements for Mountain Lion and subsequent versions of OS X. I don’t need the latest and shiniest OS X on this machine but with the release of OS X 10.10, the security updates for Lion appear to have stopped. I write “appear to” because I couldn’t find an official announcement from Apple, just some references from the commentariat that Apple seems to be following the same procedures it has followed in the past when releasing a new version of OS X. There’s also no officially published end of life schedule, so it’s hard to guess those things.

Either way, this leaves me with a headache. I really like the 2008-2011 Apple hardware due to its robustness, but now I have to go look for an alternative OS. Nobody knows what undiscovered security issues lurk in Lion and I can’t get any security updates from the manufacturer anymore. So in effect if I care about security, I have an expensive doorstop with an Apple logo on it unless I install either Windows or Linux on it. Linux is out because my wife isn’t technical and I can’t really inflict even something like Linux Mint on her. That leaves me with Windows unless I want to spend at least $500 on new Apple hardware. Realistically I’d end up spending at least $700, because I don’t see the entry-level Mac Mini as good value for money, much like the entry-level really slow iMac isn’t either. Oh, and that one will probably end up being obsoleted by the same issue in another 4-5 years.

As a developer I’m obviously used to regularly replacing computers but in the last five years there wasn’t that much of an incentive to do so; my main hack-at-home machine is still a 2009 Mac Pro that’s been tweaked to pretend it’s an early 2010 one. It’s fast enough, it’s quiet and Just Works. It can also be easily extended with PCI cards, graphics cards and hold up to four HDDs. Yes, it has all the visual appeal of an overgrown toaster but it’s a professional workstation and clearly designed as one. I however take issue with obsoleting perfectly working and viable hardware.

So I guess this is a reason to give Microsoft more money for another Windows license and use it as an excuse to stick an SSD or a hybrid disk into the MacBook. Unfortunately this doesn’t help sway me in my decision that when the time comes to buy a new workstation for me. The next box I’ll buy or build will very likely be a dual-boot Windows/Linux box again instead of buying another Apple pro-level workstation.

Right now, it’s a good idea to check for FreeBSD bash port updates daily

If you haven’t heard about the bash “shellshock” bug yet, it may be time to peek out from underneath the rock you’ve been under ;). While bash isn’t installed as standard on FreeBSD, there’s a very good chance that someone either installed it because it’s their preferred shell or because one of the ports lists it as a dependency. Either way, now would be a really good time to check if your machine has bash installed if you haven’t done so already. Go on, I’ll wait.

Anyhow, right now you really need to check for updates on the bash port on a daily basis as the updates are coming in at a pretty furious rate. I’m guessing we’ll be back to normal pretty soon, but right now with exploits already in wild, your server will need some extra grooming.

Of course the other, simpler option is to uninstall bash, unless one of the ports you are using has it as a dependency…

Some Boost.Test notes

These are just a couple of notes for some neat tips and tricks I’ve discovered over the years when using Boost.Test. They may not be all that useful to everybody else but they’re the ones I tend to forget about and then end up rediscovering. I’m using most of these with recent versions of Boost and these were tested with 1.54.

  • You can nest test suites. I don’t use this feature and was surprised to discover it, but it makes a lot of sense if you’re dealing with large test suites that can be easily broken down into smaller logical chunks.
  • If you arrange the tests in test suites (which you should anyway), you can run a single test suite by using -run_test=TestSuite. You can also run a single test inside a test suit or a nested suit by giving the appropriate path to -run_test, like so -run_test=TestSuite/TestName
  • Fixtures are normal C++ structs/classes so you can derive from them to create more specialized fixtures. For example, in a set of test suite used to test a fairly large set of COM Apis, I use a single fixture to initialize COM, then derive fixtures to set up the tests for each interface. This cuts down a lot on duplicated initialization code.
  • Boost.Test supports fixtures. Make lots of use of them to set up the environment for each of your tests instead of dumping a lot of the initialization code into each test case, which makes the test cases smaller, easier to read and you can follow the “let the first call in your test be the function you’re testing” mantra.
  • Members of the fixtures can be used directly in your unit tests
  • You can use BOOST_CHECK/BOOST_REQUIRE macros in the fixtures as well, although I would advise to make fairly minimal use of that. It does help if you are trying to test what I call “flaky” pieces of code.

Make sure you’re using the right command processor when running Incredibuild

Quick hack/warning for those using an alternative command line processor like TCC and also use Xoreax’ Incredibuild for distributed builds. Incredibuild is awesome, by the way, and if you have a larger C++ project that takes a long time to build, you should use it. And no, I’m not getting paid or receive free stuff for writing that.

However, if you have to start your Visual Studio instance from the command line because you need to set some environment variables first, or because of your general awesomeness, make sure you’re starting it from a stock Windows shell. Either cmd.exe or Powershell will do nicely, thank you. If you start VS from TCC and have a couple of build tasks that spawn out to the shell, Incredibuild wants to shell out into TCC to run these tasks and the shelled out task don’t seem to return control to Incredibuild again. Yes, I was too lazy to investigate further as the method described above works.

Install your basic Emacs packages via a single function call

If you, like me tend to carry around or “cloud around” a single .emacs file so you end up with similar environments wherever you have an Emacs install, you know it’s a little painful to ensure that you have the same set of basic packages installed on each one of your Emacs installations. As I had mentioned before I don’t use that many third party packages so my Emacs configurations aren’t that complicated, but I always prefer to have the computer remember things so I don’t have to.

As I started using ELPA last year, I decided to investigate if I could use ELPA and a little custom code to download and install the packages that I know I want everywhere. One evening I got bored enough to write a function that tests for the presence of a bunch of basic packages that I want to have on every Emacs install. It’s not trying to be fancy and automate things to the n-th degree as I didn’t want to spend the time each time I start Emacs, so I just have to remember to invoke the function after a new install. Here is the function, in all its simple glory:

(defun install-required-packages ()
  (if (>= emacs-major-version 24)
      (progn
        (setq package-archives '(("ELPA" . "http://tromey.com/elpa/")
                                 ("gnu" . "http://elpa.gnu.org/packages/")
                                 ("marmalade" . "http://marmalade-repo.org/packages/")
                                 ("melpa" . "http://melpa.milkbox.net/packages/")
                                 ))
        (package-refresh-contents)

        (when (not (require 'bm nil t))
          (package-install 'bm))
        (when (not (require 'icicles nil t))
          (package-install 'icicles))
        (when (not (require 'smex nil t))
          (package-install 'smex))
        (when (not (require 'zenburn-theme nil t))
          (package-install 'zenburn-theme))
        )))

Unique buffer names in Emacs

A common annoyance with Emacs when working on a code base that has duplicate file names is that the mode line tends to display the buffer names as “one.py:<1>”, “one.py:<2>” etc etc. That doesn’t help much with telling them apart and I find it confusing.

I was introduced to the Uniquify library a while ago. This library allows you some control over how you want to display the buffer names of buffers that contain files with duplicate names. I use the following configuration in my .emacs:

(require 'uniquify)
(setq uniquify-buffer-name-style 'post-forward uniquify-separator ":")

The above code will display duplicate buffers as “one.py:left” and “one.py:right”, with “left” and “right” being the directories that contain the file. The screenshot below shows Emacs with two files with the same name opened from two different locations:

Screen Shot 2014-08-23 at 3.49.46 PM

Timo’s occasional link roundup, late July edition

A couple of interesting articles about debugging. Debugging doesn’t seem to get a lot of attention when people are taught about programming, I assume you’re supposed to acquire this skill by osmosis, but it is actually one of those skills that should receive much greater attention because it’s one of those that separates highly productive developers from, well, not so productive ones.

Why I’m Productive in Clojure. I’ve long been a fan of Lisp and Lisp-like languages, even though I wasn’t originally that happy with having Lisp inflicted on me when I was at university. Because it was weird and back then I didn’t much appreciate non-mainstream languages. These days I do because that’s where you usually find better expressiveness and ideas supposedly too strange for mainstream languages. I guess that makes me a language hipster.

And while we’re on the subject of lisp-like languages – I’ve never heard of Julia, but this blog post made me wonder if it should be on my list of languages to look at.

We have a Nest thermostat and I wasn’t too keen when I heard that Google bought them. Probably have to look into securing it (aka stopping the data leakage). While I understand the trade “your data for our free service” model from an economics perspective, I do take some issue with the “we’ll sell you a very expensive device and your data still leaks out to us” model. Nests aren’t exactly cheap to begin with.

Debugging on a live system that’s shouldn’t be live. Been there done that, on a trading system…

Netflix and network neutrality, as seen from the other side. I’m an advocate of regulating ISPs (especially the larger ones) as public utilities and essentially enforcing network neutrality that way. Netflix obviously has been going on about network neutrality for a while now but the linked article does make me wonder if those supposed “pay to play” payments were actually more like payments for the server hosting. You know, like the charges that us mere mortals also have to pay if we want to stick a server into someone’s data centre.