Haswell Refresh

You may have read all kind of news about the new Haswell processors – the so called Haswell refresh – but it seems like most people have missed the Geekbench results.

Ok. Here is the first one of the Intel i5-4690 on a ASRock Z97X Killer (Windows 32-bit) and here is the first one of the Intel i7-4790 on a Gigabyte Z97X-SOC Force setup as iMac14,2 (Mac OS X 10.9.2 Build 13C64).

Good news. One of the processors survived 7.2 GHz, for a short while, but the Geekbench results are skewed. Anyway. Nothing really spectacular, with a 100 MHz speed bump, but I thought that you may want to see this 😉

The new Haswell processors can be used on motherboards with a LGA 1150 socket (current motherboards) but only with a UEFI BIOS upgrade to support the processor. No idea if all vendors will add support for the Haswell refresh processors, I guess so, but it doesn’t look good for unlocked (K-series) models. Seems like we need a new motherboard with X97 chipset for them. The problem is that I am still waiting for my unlocked SKU’s so I can’t tell you what to expect. And with a baby coming next week… I don’t even know if I will have the time and energy to blog about it.

OS X Beta Seed Program

Good news. Apple recently launched a new OS X Beta Seed Program. A huge change in Apple’s policy, because now everyone can sign up, for free, and start testing Developer Previews. Start helping Apple to improve our beloved operating system used on Macs and Hacks. More about the latter later on.

A first step towards this change was first made public when Apple added the Feedback Assistant to build 13D33. Something that was previously only used by people who were invited by Apple with this invitation:

OS X Lion Software Update Invitation
Apple invites you to participate in a software seeding project. Our program, Apple Software Customer Seeding, provides customers with access to pre-release software so that they may explore new features, perform early compatibility testing, and submit feedback to Apple engineers. We have selected you, based on a referral and/or prior participation in our program, to assist us in testing an upcoming release of an OS X Lion Software Update. You must have OS X Lion 10.7, build 11A511 or 10.7.1, build 11B26. Please follow the directions below to complete the invitation process.

Remember it? That was back in 2011 when Apple was about to release Lion and iCloud. And remnants of the past can still be found on the faq page:

How can I sign up for this program?
We are not seeking new participants. You must have an invitation in order to log in.

A page that I guess will soon be changed. Let’s see what we get when we want to give some feedback. I mean someone at Apple HQ surely love to learn about this ‘error’ so why don’t we give it them right away.

Not exactly to “make OS X even better” but to fix a simple content error. And that’s as far as it goes… because then I decided to check what this Feedback Assistant does. Especially what photostream-diagnose-ext.sh does. A shell script called by the feedback executable to collect data, which Apple states is “not personally identifiable data”. And to show you that this is not correct, I hereby present you their script in plaintext:

#!/bin/sh

DUMPFILENAME="$1"/photostream-diagnose-ext-$(date +%Y%m%d-%H%M%S).txt
AGENT_DEBUG_LOG_LINE_COUNT=$(syslog -k Facility com.apple.photostream-agent -k Level 6 | wc -l)

COLOR=$'\x1b[34m'
CLEAR=$'\x1b[m'

COMMANDS=(
"echo $0 report version 6"
# added in report version 5
"codesign -vv /Applications/iPhoto.app/Contents/Library/LoginItems/PhotoStreamAgent.app"
"codesign -dvv /Applications/iPhoto.app/Contents/Library/LoginItems/PhotoStreamAgent.app"
"codesign -vv /Applications/iPhoto.app"
"codesign -dvv /Applications/iPhoto.app"
# added in report version 4
"profiles -c"
# added in report version 3
"find $HOME/Library/Application*Support/iLifeAssetManagement -ls"
"sqlite3 $HOME/Library/Application*Support/iLifeAssetManagement/ILifeAssetManagement.db .dump"
"sqlite3 $HOME/Library/Application*Support/iLifeAssetManagement/state/albumshare/*/Model.sqlite .dump"
# added in report version < 3
"sw_vers"
"/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -dump"
"launchctl list"
"defaults read com.apple.iPhoto"
"defaults read com.apple.iLifePhotoStream"
"defaults read com.apple.Aperture"
"defaults read MobileMeAccounts"
"defaults read com.apple.iLifePhotoStream.importstatus"
"cat $HOME/Library/Containers/com.apple.iPhoto/Data/Library/Preferences/com.apple.iPhoto.rejectedPhotoStreamImports $HOME/Library/Preferences/com.apple.iPhoto.rejectedPhotoStreamImports"
"ps aux"
"mdutil -s -a"
"echo $UID $USER"
"touch /var/db/launchd.db/com.apple.launchd.peruser.$UID/overrides.plist"
"cat /var/db/launchd.db/com.apple.launchd.peruser.$UID/overrides.plist"
"ls -ln /var/db/launchd.db/com.apple.launchd.peruser.$UID/overrides.plist"
"ls -lnd /var/db/launchd.db/com.apple.launchd.peruser.$UID"
"ls -lnd /var/db/launchd.db"
"cat /var/log/system.log"
)

for command in "${COMMANDS[@]}"; do
echo "===========================================" >> "$DUMPFILENAME"
echo "#### $command" >> "$DUMPFILENAME"
echo "" >> "$DUMPFILENAME"
$command 2>&1 | iconv -f utf-8 -t utf-8 --byte-subst='<%u>' >> "$DUMPFILENAME"
echo "" >> "$DUMPFILENAME"
echo "" >> "$DUMPFILENAME"
done

# added in report version 6
echo "===========================================" >> "$DUMPFILENAME"
echo "#### UUIDs" >> "$DUMPFILENAME"
echo "" >> "$DUMPFILENAME"

for binary in /Applications/iPhoto.app/Contents/Library/LoginItems/PhotoStreamAgent.app/Contents/MacOS/PhotoStreamAgent /Applications/iPhoto.app/Contents/MacOS/iPhoto; do
echo $binary >> "$DUMPFILENAME"
python - $binary 2>&1 >> "$DUMPFILENAME" <<EOF
import macholib.MachO, uuid, sys
binary = macholib.MachO.MachO(sys.argv[1])
uuid_command, = [c[1] for c in binary.headers[0].commands if type(c[1]) == macholib.mach_o.uuid_command]
print uuid.UUID(bytes=uuid_command.uuid)
EOF
md5 $binary >> "$DUMPFILENAME"
echo "" >> "$DUMPFILENAME"
done
echo "" >> "$DUMPFILENAME"

echo "===========================================" >> "$DUMPFILENAME"
echo "#### Crash Logs" >> "$DUMPFILENAME"

if test -n "$(find ~/Library/Logs/DiagnosticReports -maxdepth 1 -name 'PhotoStreamAgent_*.crash' -print -quit)"; then
for crashlog in ~/Library/Logs/DiagnosticReports/PhotoStreamAgent_*.crash; do
echo "------------------------------------------" >> "$DUMPFILENAME"
echo "#### Crash log $crashlog" >> "$DUMPFILENAME"
cat $crashlog >> "$DUMPFILENAME"
done
else
echo "No crash logs" >> "$DUMPFILENAME"
fi

cd "$(dirname "$DUMPFILENAME")"
zip -q "$DUMPFILENAME".zip $(basename "$DUMPFILENAME")
rm "$DUMPFILENAME"

Note: I actually found this script, a long time ago, on a dump site, where people dump all kind of information. My blog article only gave it a more “public” spot.

Right. That is not exactly “not personally identifiable data” what it collect. In fact. It goes far beyond anything that Apple should need from us, as Beta testers, and some of it has absolutely nothing to do with iPhoto or whatever (photo) application(s) you can come up with related to Apple (software) and/or Apple operating systems. And even if I would accept something like this, on a voluntary basis, then I want to know what they collect and what they do with it. So what is this BS?

This is also why I would like to suggest that you change this script so that it won’t include anything that you find unacceptable.

Edit:

Yes. You may accept their agreement and hand over the data they collect, because you don’t care about what Apple collects, which is fine by me, but I will not accept agreements that have not been transparent from the get-go. I tell you. It could have been so much better. So much more transparent, with a list of checkboxes (example) allowing you to opt-in to what you may want to include with your feedback.

The URL of the OS X Beta Seed Program is slightly different than the one used by registered developers. Look here:

/usr/sbin/softwareupdate --set-catalog "https://swscan.apple.com/content/catalogs/others/index-10.9publicseed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz"

The word “public” is new here. It now also adds a symbolic link to the Feedback Assistant like so:

ln -sF "/System/Library/CoreServices/Feedback Assistant.app" "/Applications/Utilities/Feedback Assistant.app"

No need to dig up the Feedback Assistant anymore. Which is a good change. Next thing it does is that it launches a new daemon with:

/System/Library/CoreServices/Feedback Assistant.app/Contents/Library/LaunchServices/seedusaged

But what this daemon does is TBD at a later time. No time now. I don’t even know if I want to discuss it in public.

OS X Mavericks 10.9.3 (Build 13D43) Seeded

Apple seeded a sixth test build of OS X 10.9.3 (13D43) to registered Mac developers, available through their Software Update mechanism in the Mac App Store, as well as through the Mac Dev Center.

Focus Areas

– Graphics Drivers
– Audio
– Safari
– Contacts and Calendar sync over USB in iTunes
– Mail

Everyone else who is interested in testing OS X 10.9.3 (13D43) without being a registered Mac software developer can change their App Store URL by entering the following terminal command (all on one line):

sudo /usr/sbin/softwareupdate –set-catalog https://swscan.apple.com/content/catalogs/others/index-10.9seed-10.9-mountainlion-lion-snowleopard-leopard.merged-1.sucatalog.gz

Tip: You can also open the App Store from a terminal window with:

open macappstore://showUpdatesPage

Edit

You can restore to the original Apple catalog by resetting the override URL with help of the following terminal command:

sudo /usr/sbin/softwareupdate --clear-catalog

After that the CatalogURL property will be removed from /Library/Preferences/com.apple.SoftwareUpdate.plist and when everything went fine, you’ll see this text: softwareupdate: Changed catalog to Apple production
Back to the factory original (production) catalog.

Legal Notices

Use of this confidential, pre-release software is subject to the Software License Agreement for Apple Confidential OS X Pre-Release Seed Updates presented upon installation of the OS X Software Update Seed Configuration Utility. The original Software License Agreement that accompanied commercially-available versions of the software being updated does not apply to these pre-release seed updates.

Warning

This update won’t show up under Updates in the App Store when you are still using the 10.9.2 Golden Master (build 13A598) or already have OS X 10.9.3 (Build 13D28) installed. There’s an additional check for build 13C64, which was first released to Apple employees and a day later to the public.

Changes

In this build AGDC (Apple Graphics Device Policy) has improved, and as a result my DVI monitor (with my IGPU only setup) works without any modifications to AppleIntelFramebuffer.kext whatsoever, though I had to change:

/S*/L*/E*/AppleGraphicsControl.kext/C*/P*/AppleGraphicsDevicePolicy.kext/C*/Info.plist

<key>ConfigMap</key>
<dict>
	<key>Mac-F60DEB81FF30ACF6</key>
	<string>none</string>
</dict>

What I did was that I changed the factory “Config1” to “none” (Config1 unloads GFX1) like all other models under ConfigMap (iMac14,1/MacBookPro11,1/iMac14,2/MacBookAir6,1/MacBookPro9,1/iMac14,3/MacBookAir6,2/Mac-81E3E92DD6088272/MacBookPro10,1/MacPro4,1/MacPro5,1/MacPro3,1/MacPro6,1/iMac13,3) Without this mod only the DisplayPort monitor connector worked.

Did you catch the Mac-81E3E92DD6088272 in that list? That is a new board-id (for OS X 10.9.3, not this specific DP) and thus Apple could be planning to release a new Mac with OS X 10.9.3 installed on it. What I can tell you is that this specific board-id is not another Mac Pro, and the most likely candidate is a brand new Mac mini. Or is that just my imagination. Hoping for a new Mac mini?

Edit: We know now that this board-id (Mac-81E3E92DD6088272) is for the 21-inch mid-2014 iMac (iMac14,4).

Also. A quick look at /S*/L*/E*/IOPlatformPluginFamily.kext/C*/P*/X86PlatformPlugin.kext/C*/Resources revealed that all plist are unchanged.

Well. This has to be it for now folks as I need to go – sanding a 30 meter wall and paint the darn thing for a second time. Have fun!

Update:
I forgot to mention that I found a new GUID. One used to store/retrieve the DisplayBackgroundColor (options/):

“FA4CE28D-B62F-4C99-9CC3-6815686E30F9:DisplayBackgroundColor”

There might be more. Will keep searching for new stuff.

Update 2:
Worked around a stupid wordpress.com code block issue.

ssdtPRGen.sh v13.1 with long Scope (_SB) support

A new version of ssdtPRGen (v13.1) is now available from my Github repository. It should just work, and combat the dreaded “Warning: No ACPI Processor declarations found in the DSDT!” but since I don’t have any time to conduct testing myself – this is where you come in handy – and I also don’t have all sorts of different configurations to test the script with so you are warned.

Changelog

– enhanced _debugPrint with argument support.
– Haswell refresh (desktop) processor data added.
– triple/quad byte package length support added.
– typo in help text (-turbo) fixed.
– opcode error (‘Name’ instead of ‘Device’) fixed.

Please report bugs and other oddities over at: https://github.com/Piker-Alpha/ssdtPRGen.sh/issues

Thank you for testing this update!

ssdtPRGen.sh v13.0 with improved multi-processor support

A new version of ssdtPRGen (v13.0) with improved multi-processor support, and other bug fixed, is now available from my Github repository. It should just work, but you are warned: Didn’t have a lot of time to work on it and I also don’t have all sorts of different configurations to test the script on. I guess that is where you come in handy.

Changelog

– removed unused variable ‘checkGlobalProcessorScope’
– missing deviceName in two calls to _debugPrint fixed
– fixed a typo in help text for -d and now -d 2 also works again
– made -help work
– stop overwriting the ACPI processor scope name with the last one, by using $scopeIndex
– debug data fixed/running processor was missing when the -p argument was used
– more text hidden/only shown when -d [2/3] argument is used
– improved multi-processor support

Please report bugs and other oddities over at: https://github.com/Piker-Alpha/ssdtPRGen.sh/issues

Thank you for testing this update!