Monthly Archives: February 2008

aperture world tour: just like the world series ?

Posted by on 27Feb08 Comments Off

Update: 09mar08 Ok, fixed. Not sure when this changed, but each city now has its own registration link.

I had been going to let this pass, but seeing as there’s no change after three days I think it needs to be at least pointed out…

Apple have announced an Aperture World Tour to show off Aperture 2 worldwide. Excellent: they include London, so I’ll click on the Reserve Your Seat link and I’ll book one for myself…

Oh.

Hang on.

Check those dates.

Recheck the locations.

Recheck the reservations list.

Yup – only US cities are listed for reservations: there’s not even a hint that Milan, London, Moscow, Sydney, Hong Kong or Singapore even have events.

Yes, I can understand that the booking for those might be handled in a different fashion: there’s only one in each country so it’s not the same as the US set, but to not even have a list of what non-US users might have to do to get a place is a little rough. Maybe I should just switch to decaf and not take it personally, but it just smacks of the whole World Series attitude which is not what I would have expected of Apple.

Share

aperture 2 trial hack

Posted by on 15Feb08 47 comments

Update: 18feb08 My original hack required multiple edits in order to get the program to run, but Michal has found a far better method that just means a single change is required – I’ve reproduced it here from his comments and email so it’s easy to see what to do.

Update: 04mar08 At the request of hydr0, I’ve added screen shots of the application to demonstrate what zero-padding is – click on the image to view the whole application window grab if you require more context.

I’d sort of promised myself that by the time Aperture 2 came out I’d have managed to get a machine that was modern enough to be supported natively and be able to drop this script hackery rubbish… Needless to say, in light of certain other recent events a new Mac isn’t likely in the near future, and besides, if Aperture 2 is faster than 1.5.6 as all the early reviews indicate, maybe I don’t need to upgrade afterall.

Ok, this time I don’t have the original media, just the same trial package as everyone else so there will be two stages to this. The first is to allow the installer to run and ignore the minimum requirement checks – I skipped this last night on my PowerBook and didn’t install any of the helper packages and happily crashed my system when trying to quit the program. Not recommend.

In order to get the program installed on my MDD dual 867MHz G4 I had to fudge the speed test:

  1. Download the trial from Apple’s website
  2. Open the ApertureTrial.dmg disc image
  3. Create a new directory on your hard drive
  4. Drag the two items out of the .dmg and onto your local disc
  5. Right-click on the ApertureTrial.mpkg file and choose Show Package Contents
  6. Open the Contents directory
  7. Right-click on the ApertureTrial.dist file and choose Open With and then Other...
  8. Choose a text editor such as TextWrangler or TextEdit
  9. Scroll down until you find: function installationCheck()
  10. Change the next var regexp line to read: var regexp = /Power/;
  11. Change the next line to read: if (!checkCPUFrequency(600000000))
  12. Find the line below this that reads checkRAMRequirement and change the value inside the brackets if desired
  13. Save this file
  14. Double click on the ApertureTrial.mpkg icon and the installation should complete. Note you will need the trial licence key emailed to you by Apple

This will change the limit from a 1.25 GHz PowerBook to a 600MHz generic Power machine (ie: any G4 system). Note that you can drop the RAM requirement below 1GB and take the CPU limit down below 600MHz if you desire, but I would really, really question how usable this would make the final program.

After the installation has completed (don’t forget to rename your existing Aperture program – the trial will stop if you haven’t and ask you to do so) you will find that it fails to launch, complaining the the computer doesn’t meet requirements. Now it’s time for the hex editor (0xED.app is my favourite choice here) on the binary, just like before.

Michal’s new version:

  1. Open 0xED
  2. Choose File -> Open...
  3. Navigate to /Applications, then Aperture.app, then Contents, then MacOS, and finally choose the Aperture file and then click on Open
  4. Ensure the editor is set to Overwrite mode (Edit -> Write Mode)
  5. Enter 6d21b0 into the Offset box and hit Enter
  6. Check the ASCII side of things and you should see the string performRequirementsCheck starting under the cursor
  7. Replace the string with performLicenseCheck
  8. Switch to the hex view, and erase the extra five characters (the Check string) with zeros
  9. Save this file
  10. Launch Aperture as you normally would

That’s it: no more video card checks or RAM limits to edit.

The data before editing looks like this:

After editing, it should look like this:


My original method, purely for reference now:

  1. Open 0xED
  2. Choose File -> Open...
  3. Navigate to /Applications, then Aperture.app, then Contents, then MacOS, and finally choose the Aperture file and then click on Open
  4. Ensure the editor is set to Overwrite mode (Edit -> Write Mode)
  5. Enter 6D237C into the Offset box and hit Enter
  6. Check the ASCII side of things and you should see the string PowerBook starting under the cursor
  7. Open Terminal and type sysctl hw.model. On my MDD dual 867MHz system this returns: hw.model: PowerMac3,6
  8. Replace the Book part of the string in the 0xED window with the four characters after the word Power in the sysctl result. In my case, this means Mac3 so the string in the 0xED window now reads PowerMac3
  9. Save this file

This has changed the requirement for a G4 laptop to be a test for your exact system. Now it’s time to change the CPU requirements, as Aperture still expects a 1.25 GHz minimum G4, and now there are two options: the first is to open the Info.plist file and hand edit it, or you can type one command at the Terminal (the second way is faster, but changes the plist from ASCII to binary – not an issue for most people).

Option 1:

  1. Using either a Text Editor or the plist editor that comes with the Developer Tools, open the file /Applications/Aperture.app/Contents/Info.plist
  2. Look for the key called: RKG4LaptopMinimumCPUSpeedMHz and change the value that follows it from 1250 to something less than your system, eg: 600
  3. Save the file
  4. Launch Aperture as you normally would

Option 2:

  1. Open Terminal and type: defaults write /Applications/Aperture.app/Contents/Info RKG4LaptopMinimumCPUSpeedMHz -int 600
  2. Launch Aperture as you normally would

This does work, but I have had problems when quitting Aperture: the program does keep all of my changes but often crashes on termination. So far as this evaluation goes, I can live with that but maybe others out there can sort out a clean shutdown ?

Share

need a low-level software engineer ?

Posted by on 13Feb08 Comments Off

Are you in need of a low-level software engineer with over 12 years of commercial experience ? One that is happy to play around with JTAG probes and softcore CPU designs debugging unproven bitfiles ? One that can utilise logic analysers, oscilloscopes, multimeter’s, GPIO/LED’s and serial ports on first spin hardware when there’s no debug port available ? Has programmed in many types of assembly language (MIPS, SPARC, ARM, 6502, Z80), as well as the ‘usual’ Unix stuff (C/awk/sed/perl/sh) and has backend web programming (perl/PHP/MySQL) and performance tuning experience ? Also able to sysadmin, program/modify telephone exchanges (ISDN/POTS and with a smattering of VoIP too), read and debug board designs from circuit diagrams and translate software requirements into a language that hardware engineers can understand ?

If so, then drop me an email (cv@ this domain name), or take a look at my slightly more verbose CV – I’m happy to answer any questions by email or phone. My current employer is closing their office in this country at the end of March and so I’m looking for something close to Cambridge in the UK, preferably starting in early April.

Share

exim smtp time spamasassin based rejection

Posted by on 06Feb08 Comments Off

Exim and SpamAssassin can work very well together to screen incoming email during the SMTP receive phase and reject messages without them ever having to get close to a user. Although the borderline spam cases are the most annoying and give rise to false positives, there is another class of spam which is so totally bogus I wonder why they even bother to send it although it does give credence to the concept that spamming itself is no longer profitable – bot-herding and supplying delivery services to spammers is the new market, and the I-can-get-rich-quick-too spammers are themselves being ripped off.

To do this I wanted to use two methods – a clear and generous site-wide limit that will apply in all cases, and a per-user option to have a more aggressive approach to refusals. Using a recent (4.69) version of Exim my virus and spam checking is done in the acl_smtp_data ACL, so adding this snippet will implement a site-wide refusal for all email scoring more than 25:

  deny   message = This message scored $spam_score spam points and will not be delivered.
         spam = nobody:true
         condition = ${if >{$spam_score_int}{250}{1}{0}}

Note that Exim doesn’t do floats, and SA scores have one decimal place, so the limit is multiplied by ten to keep it an integer.

Next, I want to allow a per-recipient limit, but only if the message is addressed to one person. This comes after the bulk scoring in my configure file, but could just as easily come first:

  deny   message = This message scored $spam_score spam points and will not be delivered.
         spam = nobody:true
         condition = ${if and {{={$rcpt_count}{1}} \
                      {>{$spam_score_int}{${lookup{$recipients}lsearch{/etc/exim/sa_refusal}{$value}{250}}}}} \
                      {1}{0}}

You then have a nice and simple file (called /etc/exim/sa_refusal above) with a recipient on the left and the desired limit on the right, eg:

[email protected]:     500
[email protected]:   100
[email protected]:           152

A failed lookup will return 250 just as with the site wide limit, although you may wish to change the lsearch to a wildcard lookup and have the global limit for a single recipient email in the sa_resfual file too, but that is left as an exercise for the reader.

You may also wish to apply the site-wide filter as an else clause to the per-recipient rule – it’d certainly be cleaner programmatically but I fear that the current $if line is hard enough to read as-is and I don’t want any more { or } in there.

There are two things you may wish to change: 25 is not a magic number, but one that I found to be way above any email that had been subject to a false positive in SA (I’ve got a few years worth of data, so in theory no legit mail will ever score this highly), and the status reporting via eximstats reports lots of lines rather than an aggregate of offending spam:

         1   This message scored 18.6 spam points and will not be delivered.
         1   This message scored 18.8 spam points and will not be delivered.
         1   This message scored 21.3 spam points and will not be delivered.
         1   This message scored 21.6 spam points and will not be delivered.
         1   This message scored 24.5 spam points and will not be delivered.
         1   This message scored 25.1 spam points and will not be delivered.

Just change the message= lines to not refer to the $spam_score and things will be summarised more neatly.

Share
Page 1 of 11