Archive: 2016

  1. Installing Windows 10 on a late 2008 MacBook Pro running El Capitan

    It can’t be done.

    Update: It seems that it really can’t be done now, if you’re running a later version of macOS. I’ve had reports of Boot Camp crashing if you try to amend the Boot Camp Assistant software as outlined in Step 2 below.

    Well, not if you take Apple’s Boot Camp software at face value. It suggests that only Windows 7 can be installed, and (by implication) anything newer should be left to newer Macs. But having seen the specifications of some modern Windows PCs I was fairly confident that it would run. Possibly even quite well. So I persevered.

    There is a lot of advice about how to get later versions of Windows running on older Macs. Much of it is very complicated and quite possibly works if you know exactly what you are doing and the wind is behind you.

    I tried some of these more complicated solutions without any success. I spent several hours over a number of days disabling system integrity protection (which doesn’t sound like a good idea), manually blessing disks (really), and creating special versions of the Windows 10 installer DVDs, which ultimately told me to press any key and then proceeded to ignore that key press and do nothing.

    The wind has been very swirly recently.

    In the end I decided to adopt a more basic approach: I simply overrode the Boot Camp setting that said it couldn’t be done.

    And it was simple – changing one number in the appropriate info.plist file.

    Then I ran Boot Camp again and was told that of course my 2008 MacBook Pro was more than capable of running any version of Windows and when would I like to begin? I’m paraphrasing slightly. So I put in my Windows DVD and ran through the process of selecting a partition size and installing the operating system – all without any issues.

    Then, when Windows 10 was successfully installed, I ran the Windows Boot Camp support software – and was told that it wasn’t compatible. Having heard that before, I ignored it and instead of running the main setup executable, installed the drivers via the Windows driver package that was also available with the support software (BootCamp.msi). Once that had crashed (oh) and I’d rebooted the computer I found that nearly everything was working as expected, with a crisp looking display and basic touchpad support.

    There are one or two issues that I still need to look at – such as getting two finger scrolling working – but nothing that you don’t get with most new PCs (don’t ask my girlfriend about her oversensitive ASUS touchpad if you value your life). And the whole process was a lot simpler and quicker than trying to install Windows manually.

    Now I have to remember why I started this process in the first place.

    Steps for installing Windows 10 on your old MacBook Pro

    If you follow these steps you do so at your own risk and with no guarantee that things will work out. I used a late-2008 MacBook Pro. Others of a similar vintage might well work.

    Step 1

    Get a copy of Windows 10. Fairly obvious but worth mentioning. You can download a copy of the Windows installer DVD in iso format from here:

    You will need the 64 bit version.

    To keep things simple you will need to create an actual DVD from this file, but in El Capitan that is very easy. Once the file is downloaded, insert a blank DVD (we all have those still lying around don’t we?), right-click on the iso file and select Burn to Disc.

    Step 2

    This is the important bit. Find the Boot Camp Assistant software in the Applications > Utilities folder on your Mac, right-click and select ’Show Package Contents’. That should open up the software package to show a Contents folder. Open that and you’ll see a list of files including one called info.plist, which is the main configuration file for the Boot Camp Assistant software.

    Open that file in a text editor (I use the excellent TextWrangler) and look for this block of text:


    We are interested in the MacBookPro entry. This part of this configuration file says that anything before the MacBook Pro 5,5 should only have Windows 7 installed. You can find out the version of your MacBook Pro in El Capitan by selecting ‘About This Mac’ from the Apple menu and then System Report. All you need to do is make sure that the number in the info.plist file is earlier than the MacBook Pro you are attempting to install the Windows operating system on. I changed it to MacBookPro4,5 to be on the safe side.


    Save the file.

    Step 3

    Run the Boot Camp Assistant software, tick both boxes when prompted to do so and follow the on screen instructions.

    Screenshot: Boot Camp Assistant

    Boot Camp Assistant

    You will need a USB flash drive to install the Apple support software for Windows (this includes all of the drivers required to get the screen, keyboard, trackpad etc working).

    Step 4

    When the whole process is over and Windows has installed, make sure the USB flash drive is attached.

    Unfortunately the main setup.exe file on the USB flash drive won’t run properly. It will tell you that you can’t install the drivers for this Mac. Fortunately, you can ignore this and install the drivers manually by navigating to BootCamp > Drivers > Apple on the USB flash drive and running BootCamp.msi by double-clicking on it. This process may hang – it did for me when attempting to install some audio drivers.

    Whether it does or not, once it has finished you should reboot. Windows should restart with most of the relevant drivers in place. Or you might end up with no sound like me. Fortunately I was able to resolve that by diving back into the BootCamp > Drivers folder and then into the RealTek folder to install the audio drivers by running RealtekSetup.exe. After another reboot the audio was fine.

    So far, I haven’t come across any major problems other than the audio. I’ve installed Visual Studio and tried a few other things and it has all worked as expected. Obviously your mileage may vary and there are no guarantees, but it certainly works well enough for what I need.

    It can be done.

  2. How to keep your linux server secure – unattended security upgrades

    There are many steps to securing a server, but one of the most fundamental is to make sure that all of the core software running on it has all of the latest security patches implemented. Yet most linux installations, including the numerous virtual servers that can be deployed almost instantly, don’t have any automatic mechanism for updating the installed software packages enabled by default. That’s primarily because of the flexibility that linux offers – there is no assumption that one solution will suit every deployment.

    However, there is a minimum that is recommended for most situations – and that is to run all of the security updates for the installed linux distribution on a daily basis. Although you wouldn’t likely stumble on the solution as to how to do this by accident, it is relatively painless to set up using the unattended-upgrades package.

    First, you have to install the package itself, along with some mail software so that the system can email you the results of the process. Then it’s just a question of making a few configuration changes. After that, the update process should be picked up by the cron.daily script and run every day.

    Step 1

    Install the unattended-upgrades package and bsd-mailx (which will be used to send you email notifications of the success or otherwise of an update):

    apt-get install unattended-upgrades bsd-mailx

    As part of the bsd-mailx installation you will need to configure Postfix, if you haven’t already done so. Assuming your server has a fully qualified domain name (FQDN) and is connected to the internet, it is likely that you will be able to use the default options.

    Step 2

    The main configuration file for the unattended-upgrades updates will be located here:


    To edit it, it’s probably easiest to use one of the built in command line editors like vi, although you’ll need to remember to type ‘i’ to insert text and then ‘:wq’ to save afterwards:

    vi /etc/apt/apt.conf.d/50unattended-upgrades

    There are a lot of lines in that file, most of which are already commented out. The default configuration should have the following section uncommented – which is all that you need to get the security updates to work:

    // Automatically upgrade packages from these 
    // (origin:archive) pairs
    Unattended-Upgrade::Allowed-Origins {

    The other lines in that section of the file which are commented out deal with running other, non-security updates automatically. You can ignore those for now. But you will need to uncomment the Unattended-Upgrade::Mail line further down in the file if you want the system to report progress to you:

    // Send email to this address for problems or packages upgrades
    Unattended-Upgrade::Mail “root@localhost”;
    You can change the email address here to your own. However, I prefer to leave it to send email notifications to root and to set up an alias to forward all email sent to root to me. You can do this by adding a line to the /etc/aliases file: `root:`. Remember to run `newaliases` afterwards to rebuild the aliases database.

    Step 3

    Finally, edit the file that runs the upgrades on a periodic basis:

    vi /etc/apt/apt.conf.d/10periodic

    When you’re finished it should contain the following:

    APT::Periodic::Enable "1"; 
    APT::Periodic::Update-Package-Lists "1"; 
    APT::Periodic::Download-Upgradeable-Packages "1"; 
    APT::Periodic::Unattended-Upgrade "1"; 
    APT::Periodic::AutocleanInterval "7";

    That’s it! You should start receiving daily emails about any packages that have been upgraded on your server. You really should read these because there may be problems with the process, and there definitely will be occasions when a reboot is required to finish the upgrade.

    This solution only deals with security updates. There will be lots of other updates to the software packages you use on your server – such as new features or other non-security related changes. If you want, you can enable those in the 50unattended-upgrades file as well, by uncommenting the other files in the main configuration section. However, I prefer to handle those changes manually in case an upgrade impacts other parts of the system.

  3. Responsive Images – native browser support and WordPress 4.4

    Using responsive images means ensuring that the right type and size of image is sent to the browser requesting it. That means not sending a massive image file to a mobile browser that is only going to display it in a tiny window. It also means ensuring that if the user is viewing your site on a big, high resolution display that they don’t end up with something blurry and hard to make out.

    Browsers have begun gradually to support [responsive images] natively

    It is some time since I last looked at responsive images in detail, during which time browsers have begun gradually to support them natively – without the need for the various javascript workarounds that were required before.

    There remain two approaches to the use of responsive images: a new <picture> element (which this site used to use), and new srcset and sizes attributes to extend <img> and <source> elements. A full explanation of the difference, and how they can be used together, can be found on the Responsive Images Community Group site; with more information about use cases in an excellent A List Apart article: Using Responsive Images (Now).

    In short, the <picture> element allows for art direction-based selection – you can specify entirely different images to display at different browser sizes and have complete control over the process; the srcset attribute (and associated sizes attribute) lists the pool of source images from which the browser can pick to load depending on the browser environment. They are complimentary technologies – both can be used to ensure that, typically, a mobile browser is sent a smaller file than a desktop browser – and both are being drafted into the HTML 5.1 specification.

    All of the leading browsers (and by leading browsers, I mean leading modern browsers, not Internet Explorer) now support the new srcset and sizes attributes, including:

    • Blink / Chrome / Opera
    • WebKit / Safari
    • Mozilla Firefox

    One other, Microsoft Edge, has the attribute extensions in development.

    The <picture> element is also supported by:

    • Blink / Chrome / Opera
    • Mozilla Firefox

    As of iOS 9.3 and OS X 10.11.4 (both currently in beta), it will also be supported by WebKit / Safari. It is currently under consideration by Microsoft Edge.

    This site used to use a plugin for converting images to use the <picture> element, but it’s no longer required because the latest edition of WordPress (4.4 at the time of writing) now includes native support for srcset and sizes attributes. This is a distinct improvement: along with the wider browser support it means that there is no longer a requirement to use javascript to deliver the right image or plugins to generate the necessary responsive image code. It also means that it is easy to add other classes (and other markup) to an image without it being lost in any plugin conversion.

    So, if you are viewing this page in a relatively modern browser, the image below should vary in file size depending on the width of your browser and resolution of your screen. But it should always look good – as all Sinclair products should.

    Photo - Sinclair Spectrum

    You’ll get a different version of this image of a Sinclair Spectrum depending on your browser width and screen resolution