El Capitan

So I finally took the plunge a couple weeks ago and upgraded my hackintosh to OS X 10.11 El Capitan. This is just some preliminary notes on how my upgrade went, and some guidelines you may want to follow if you’re similarly upgrading your machine.

Because this is a major version upgrade, and El Capitan is adding stricter SIP, I recommend being a bit more methodical/paranoid than normal with the upgrade:

  • copy existing clover config/installation to a USB key for backup/emergency use
    1. a full bootable clone of your 10.10 install is best, but a 10.10 USB installer with a known good clover config is good enough in most cases
  • find any/all updated kext patches for your hardware (e.g. cloveralc, handoff/BT, 5Ghz wifi)
  • copy all kexts that you plan to inject via clover to the 10.11 folder
    1. alternatively, you can copy your kexts to /Library/Extensions after your installation is finished. I chose this route so I could use a stricter SIP setting than most people are using.
  • add necessary ‘BooterConfig’ and ‘CsrActiveConfig’ values to config.plist to configure or disable SIP
    1. most people are using CsrActiveConfig 0x67 or 0x77; this is basically entirely disabled, and ultimately turns off all of the security that SIP offers.
    2. if you just want to turn off kext signing (ala kext-dev-mode=1 from yosemite) you want to use 0x11
    3. you can find a list of the various Csr options over at insanelymac.
  • update any kext patches to their 10.11 versions
  • If you have an unsupported Nvidia card…
    1. manually turn off the web drivers from the preference pane prior to running the installer.
    2. On the final reboot after installing, manually add the nv_disable=1 boot flag just to be safe
    3. install Nvidia web drivers & reboot without nv_disable
  • If you use CloverALC, make sure to run the script again to re-insert the layout/zml files
  • rebuild kernel cache one last time and reboot

For Nvidia users using any SMBIOS other than Mac Pro, you don’t need to change your SMBIOS for the install. Use a tool like pacifist to force install the drivers, then manually run the installer package. The Nvidia installer script does a check for existing driver components (specifically NVDAResmanWeb.kext), and if it finds them, it bypasses the hardware/SMBIOS check and allows the installation on any system with compatible OS version.

Goodbye Photos.app

So after living with the new Photos.app for two week now, I’m astounded by how much disk space it’s using for previews, thumbnails, and caches.

To recap, I have a library of roughly 9200 photos that I store on a second drive, since my OS drive is an SSD. These are mostly RAW files (e.g. NEF, RW2, etc.) The initial import to Photos.app created a library of 12.18GB. This is just previews and thumbnails.

I have not added or edited a single photo inside Photos.app since the initial import; I’ve only used it as a browser.

And the photos library has now grown to 16.68GB, plus it’s keeping a separate/secondary cache over 8GB inside the app sandbox storage. (e.g. ~/Library/containers/com.apple.photos)

This is just absurd.

For comparison, I just updated to lightroom 6, and generated smart previews for my entire library.

The catalog itself (e.g. lrcat file) is 85MB
The Smart Previews lrdat file is 9.11GB
The main Previews lrdat file is 3.66GB
And the cache folder? 2.8MB

So Photos.app, with no edits whatsoever, is using around 25GB of disk space.
Lightroom 6, with quite a lot of edits; flagged files, tags, collections, etc. is using 12.5GB; half as much space as Photos.app

At this point, until Apple reigns in the disk-space bloat with Photos, I’m swapping my lightroom library back onto my SSD, and moving the Photos.app library to the slower HDD; the app just isn’t worth losing 12.5GB of space on my SSD compared to lightroom and all that it offers.

no more need for an SSDT?

Well, the title might be misleading, but it’s true for a few niche cases at least.

So I don’t know when they fixed this, but thanks to a comment on /r/hackintosh, I took a loot at clover automatic c-state/p-state generation for the first time in a year, and it seems to be fixed, at least for Haswell on Yosemite using XCPM. I’ve been running my system without an SSDT for a few days now, and can verify that speed-step, sleep, etc. are all still working great.

Why should you care? Well, it means you don’t need to worry about generating an SSDT or configuring drop-tables anymore to get native speed-step using XCPM mode with Yosemite. This also means that overclocking should be more user-friendly now if you use Clover; just adjust your max turbo speed in the bios, and clover should update automatically, no more generating a new SSDT for every clock-speed bump/test. You will still see a P-State Table MisMatch message in your system log, but in my quick testing, the overclock works fine.

Of course, if you’re using an SSDT for anything other than power management, this is all moot; keep using your SSDT.