Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

mac57mac57

macrumors 6502
Original poster
Aug 2, 2024
272
135
Myrtle Beach, SC
I came upon AuroraTrimcelerator in these forums and it sounds wonderful... but I wonder if it is already included in Sorbet Leopard? Is it additive to Sorbet Leopard or already there? Thanks.
 
@ChrisCharman's first response is correct, AuroraTrimcelerator is the ancestor of Sorbet. If I recall, some tweaks from Aurora were omitted in Sorbet because they were found to actually decrease performance in certain situations, while several new ones were also added onto the tweaks originally packed into Aurora, and then built into the disk image. On top of all the more arbitrary cosmetic addons in Sorbet like themes, screen savers, some app updates, etc. Plus the app store frontend.

But on a more abstract note, with respect to Aurora being the main component ... while my focus these days has largely moved on from Sorbet and the other projects, even as personal interests, I do regret that there was always some misinformation and / or animosity surrounding it (namely that it was literally just 10% tweaks and 90% hype, because Aurora didn't contain that many tweaks), in hindsight probably due to insufficient transparency and an overdose of the marketing -- because hey, marketing is fun and it's fun to wear a costume and pretend to be Apple; there's little reason to do anything that you're sacrificing so much free time for if it wasn't in some capacity fun, at least in my opinion.

Regardless, I hope the first paragraph contributed to Chris' response in answering your question, @mac57mac57. I'm happy to provide detail on anything else to the best of my ability, if you'd like.
 
Thanks @z970.

Regarding your offer to provide more details, I do have one question:

My PowerMac G5 DP 2.3 GHz runs Sorbet and provides a vintage Mac software repository Gopher server to the internet. It records about a dozen hits a day, so it is not heavily used; after all, Gopher is not a mainstream protocol anymore.

For a machine running this type of load, are there any additional tweaks that might have been in Aurora Trimcelerator but that were left out of Sorbet that might further improve the machine's performance?

For example, I have read more than once that I should enable QuartzGL, which would have the impact of improving performance. I am not sure if that is enabled already or not in Sorbet, but if not, might it help? Might there be other things that would help, but were left out because they are not perhaps perfect for all work load scenarios?

Thanks!
 
@mac57mac57 I can't remember at this point what exactly Aurora did, so I went back to take another look at its contents one by one:

1. It removes AudioIPCDriver.kext, AppleI2SModemFamily.kext, and IOSerialFamily.kext, and then clears the kernel cache. Removing AudioIPCDriver does reduce idle CPU usage, but removing the rest pretty much only increases available disk space, and also reduces the time to poll all of the kernel extensions in the system -- which is only run, like, once during first boot. Either way, this was included in Sorbet.

2. It removes all instances of 'designable.nib', which I guess is leftover debug code that Apple left in the released system instead of being cleaned out prior to release. Again, this should only save space. Maybe it reduces application launch times by a small amount, but that's a stretch. This was also included in Sorbet.

3. It disables BeamSync, which is essentially Apple's custom implementation of V-Sync. Doing this will result in smoother 2D animations, in most cases. This was disabled by default in Sorbet.

And then it repairs disk permissions and runs the BSD periodic maintenance scripts. That's the main script.

4. The 'Disable Spotlight' script used a cruder and less refined method by actually taking out Spotlight from the system ... without addressing launchctl, so the console would just fill with constant errors of mdutil wondering where the files are because the responsible daemon processes weren't shut off. A more correct implementation of this was included in Sorbet, where the files weren't touched, in favor of just the daemons being properly switched on / off via launchctl.

5. 'Optimize Network Speeds' used a more primitive configuration of various sysctl parameters to modify the behavior of the kernel network stack to get higher performance, regarding how it transmit and received data. I believe a more finely tuned version specifically for the version of Darwin shipped with Leopard was included in Sorbet by default. Or something like that.

6. The 'Enable QuartzGL and Quartz 2D Extreme' script was mostly a misunderstanding. Quartz 2D Extreme was just QuartzGL's moniker during the Tiger era, and this script actually enables both of them, so it would theoretically 'work' across both Tiger and Leopard. It was believed at the time that enabling it (QuartzGL) system-wide would enhance graphical performance and was planned for Sorbet, but it was found during final testing that in the majority of cases, applications running with QuartzGL enabled would present around the same performance as otherwise, but with higher resource consumption, so it was just disabled for everything. I think the one exception was the System Preferences app, which would display preference pane transitions noticeably choppier when QuartzGL was disabled.

7. Monolingual was used to strip non-PPC architectures from the Sorbet image, and a generic alternative to ShadowKiller was also included in Sorbet (somewhere in the Scripts folder) but not enabled by default. Enabling this should moderately improve 2D graphics performance even further.

And then the contents of 'AuroraTips' were tweaked / added to and then rebranded as 'Sorbet Tips' and plastered onto the Mac Garden page. And that's pretty much everything between them.

I was still learning, so I didn't fully understand at the time that making the system itself consume less disk space didn't really make it faster, rather instead it usually just breaks things. In a nutshell -- and with some exceptions, what has been proven to generally make software faster (relative to the hardware it's running on; you won't feel the difference if the hardware is overpowered for the software in question) is how many CPU threads it consumes, how much memory it consumes, and how much it leverages vs. strains the GPU.

I hope that was helpful.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.