Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Status
The first post of this thread is a WikiPost and can be edited by anyone with the appropiate permissions. Your edits will be public.
Some extremely minor findings:

I still don’t know why the login window for 10A96 (and for all I know, 10A190 as well) displays a plain blue default background, even when directing loginwindow.app to open a background picture is included in its preferences plist. But what I did learn was the loginwindow.app from 10.5.8, version 5.6 (a later version than the 5.3 version bundled with 10A96), works just fine with 10A96. This doesn’t affect the background at all, but it still functions — making it one of the few applications from 10.5.8 to work in the 10.6 PPC environment (along with TextEdit and Keychains).

Interestingly, loginwindow from 10.6.8 is a different major version from 10A96 (it’s version 6.1.2), but it shows as a Universal Binary in 10.6.8. For fun, I opened its Info.plist to check the minimum version it was meant to run (10.6, it turns out), then tried it in 10A96, with low expectations. The crash, as expected, pointed to a dynamic library not present in 10A96:

Dyld Error Message: Library not loaded: /usr/lib/libbsm.0.dylib Referenced from: /System/Library/CoreServices/loginwindow.app/Contents/MacOS/loginwindow Reason: image not found

I still haven’t set up a successful, working build environment within 10A96 to begin compiling dynamic libraries whose source code on AOSP is available, and offhand I don’t remember whether libbsm was one of the libraries available in source code.

Anyway, I’ll be updating my findings for loginwindow.app to Table 4 shortly.
Hi @B S Magnet

LoginWindow from 10A190 is more recent than the version included in 10A096, as are some of the dependencies.

10A222->10A432 continue to add changes to the app that break compatibility without replacing the dependencies, even though the app is universal. I have found that later versions of LoginWindow can run with these dependencies replaced on the system and it is possible to reach the login screen with a proper desktop image as the background, once reaching the desktop there are still further libraries and frameworks that need to be identified and replaced as the desktop is unusable for a number of reasons.

The Basic Security Module (BSM) Audit API can be compiled (I have done this) and is available as an AOSP. I believe the other security subsystems also need to be replaced moving forward, as well as resolving issues with CoreUI, ImageKit etc.

Regarding your build environment on 10A096, what are the compilation errors you are experiencing? MacPorts aside are you able to share the command line output from using the command line tools from Xcode 3.2 beta (10A096 server version) when attempting to build from source at all?
 
  • Like
Reactions: B S Magnet
Hi @B S Magnet

LoginWindow from 10A190 is more recent than the version included in 10A096, as are some of the dependencies.

I’ve yet to try anything else from 10A190 in the 10A96 environment other than Finder.app (finding: it did not take well). I may try other applications and binaries from 10A190, but this will probably be more of a curiosity exploration than one of necessity (that is: a necessity to better improve 10A96 system performance) — unless I realize some of the components from 10A190 actually help 10A96’s overall stability and performance. I still have to finish sorting through all of 10.5.8’s components in 10A96 first.

10A222->10A432 continue to add changes to the app that break compatibility without replacing the dependencies, even though the app is universal. I have found that later versions of LoginWindow can run with these dependencies replaced on the system and it is possible to reach the login screen with a proper desktop image as the background, once reaching the desktop there are still further libraries and frameworks that need to be identified and replaced as the desktop is unusable for a number of reasons.

OK. This makes sense, though finding later dependencies compiled as universal binaries is the standing challenge.

The Basic Security Module (BSM) Audit API can be compiled (I have done this) and is available as an AOSP. I believe the other security subsystems also need to be replaced moving forward, as well as resolving issues with CoreUI, ImageKit etc.

I’m not sure how to do this successfully for PowerPC when the source code for 10.6(.0) on AOSP omits architecture calls for ppc entirely. I’m not a developer, so anything more complicated than comprehending that is just beyond my knowledge set.

Regarding your build environment on 10A096, what are the compilation errors you are experiencing? MacPorts aside are you able to share the command line output from using the command line tools from Xcode 3.2 beta (10A096 server version) when attempting to build from source at all?

As noted, building for any aspect of ppc architecture from AOSP source (for the most part, with Xcode 3.2) throws a long list of errors for missing, expected components. My hope was some of these AOSP tarballs might be compiled with a command-line sh configure && make && make install, but I haven’t run into much of that. Again, this is close to the limit of what I understand.

This is not atypical for what kind of stuff I’m seeing:

1626073205415.png
 
  • Like
Reactions: ChrisCharman
Here’s a useful little workaround on SL-PPC (and Snow Leopard more broadly) to get around lack of native emoji support, pre-Lion:

  1. Download the freeware TrueType font called Symbola
  2. Unzip and move the symbola directory to /Library/Fonts
  3. If need be, restart the application with emoji call-outs.

The workaround is possible because this font (and another called Quivira) specifically features an abundance of mapped glyphs (relative to most text- or dingbat-based fonts), and those glyphs are mapped to many of the same basic Unicode locations where modern emojis would be located.

The downsides: none of these backmojis will be in colour; they’ll tend to be pretty small relative to default text size; some emoji groups (like flags) won’t render; and emoji modifiers (like skin tone) became compatible only with much later emoji support versions.

I have verified that this workaround does indeed work with 10A96 (and also 10.6.8). 👍

1626599837298.png
 
Last edited:
OK, so I feel like a dork for not having figured this out sooner.

Up until a few minutes ago, I thought streaming audio from within iTunes on Build 10A96 was not going to be feasible. I thought a nubango patch for the last verified version of iTunes 10 to work in 10A96 was going to be needed. Unfortunately, I found that the nubango-patched iTunes 10.4.1 aborts during launch.

What I hadn’t given much thought to until, well, now, was the possibility the reason I wasn’t seeing a list of streaming radio in iTunes may have had something to do with, of all things, Little Snitch.

My test environment is running 2.5.3 — which is amongst the final versions written as a universal binary. While I confirmed last year Little Snitch mostly works in 10A96, one of its glitches is it doesn’t pop up an interaction window to allow/disallow a connection. That glitch is most likely a glitch of 10A96 itself — probably related to the same bug which won’t open an “Open File…” window from within an application (such as using a web browser to try attaching an image using the “Attach files” button when making a post on here).

What this means for Little Snitch 2.5.x in 10A96 is approval for network connections must be made into a rule manually and proactively.

For the iTunes radio issue, this dawned on me… today. Not last week, last month, or last year, but today.

So I made a rule for iTunes to access the internet, aaaand…

🎉

1626611044084.png



[EDIT TO ADD: I also managed to fix the crash-on-quit issue with 10.4.1 in Build 10A96 by changing permissions for com.apple.iTunes.plist and com.apple.iTunes.eq.plist from 700 to 777. It’s a bit brute-force, but it did the trick. Selecting the checkbox in preferences to share your library will crash iTunes immediately, hinting at a missing/incompatible framework.]
 
Last edited:
OK, so I feel like a dork for not having figured this out sooner.

Up until a few minutes ago, I thought streaming audio from within iTunes on Build 10A96 was not going to be feasible. I thought a nubango patch for the last verified version of iTunes 10 to work in 10A96 was going to be needed. Unfortunately, I found that the nubango-patched iTunes 10.4.1 aborts during launch.

What I hadn’t given much thought to until, well, now, was the possibility the reason I wasn’t seeing a list of streaming radio in iTunes may have had something to do with, of all things, Little Snitch.

My test environment is running 2.5.3 — which is amongst the final versions written as a universal binary. While I confirmed last year Little Snitch mostly works in 10A96, one of its glitches is it doesn’t pop up an interaction window to allow/disallow a connection. That glitch is most likely a glitch of 10A96 itself — probably related to the same bug which won’t open an “Open File…” window from within an application (such as using a web browser to try attaching an image using the “Attach files” button when making a post on here).

What this means for Little Snitch 2.5.x in 10A96 is approval for network connections must be made into a rule manually and proactively.

For the iTunes radio issue, this dawned on me… today. Not last week, last month, or last year, but today.

So I made a rule for iTunes to access the internet, aaaand…



View attachment 1807899


[EDIT TO ADD: I also managed to fix the crash-on-quit issue with 10.4.1 in Build 10A96 by changing permissions for com.apple.iTunes.plist and com.apple.iTunes.eq.plist from 700 to 777. It’s a bit brute-force, but it did the trick. Selecting the checkbox in preferences to share your library will crash iTunes immediately, hinting at a missing/incompatible framework.]

I wonder if this’ll fix 10.2.2 on 10A96…
 
  • Like
Reactions: ChrisCharman
I’ve yet to try anything else from 10A190 in the 10A96 environment other than Finder.app (finding: it did not take well). I may try other applications and binaries from 10A190, but this will probably be more of a curiosity exploration than one of necessity (that is: a necessity to better improve 10A96 system performance) — unless I realize some of the components from 10A190 actually help 10A96’s overall stability and performance. I still have to finish sorting through all of 10.5.8’s components in 10A96 first.



OK. This makes sense, though finding later dependencies compiled as universal binaries is the standing challenge.



I’m not sure how to do this successfully for PowerPC when the source code for 10.6(.0) on AOSP omits architecture calls for ppc entirely. I’m not a developer, so anything more complicated than comprehending that is just beyond my knowledge set.



As noted, building for any aspect of ppc architecture from AOSP source (for the most part, with Xcode 3.2) throws a long list of errors for missing, expected components. My hope was some of these AOSP tarballs might be compiled with a command-line sh configure && make && make install, but I haven’t run into much of that. Again, this is close to the limit of what I understand.

This is not atypical for what kind of stuff I’m seeing:

View attachment 1805087

Hi @B S Magnet

Yes, I wouldn’t recommend trying to use LoginWindow from 10A190 in 10A096 without first backing up and even then only as a curiosity to investigate the changes between the builds. I imagine most if not all components ported from the later builds will decrease stability, which is something 10A096 has going for it. 10.5.8 sources are a safe bet.

Indeed, finding later versions of dependencies pre-compiled as universal that remain compatible is a challenge. This is why i’ve decided to focus on building as many from source as i’m able, and learning along the way what works, what doesn’t and why etc. I’m definitely having more success doing this than moving files across from later builds directly to 10A190 and i find the errors during compilation tend to light the way forward, with a little research and problem solving.

A large number of the AOSP for 10.6 are able to be compiled for PowerPC, many without modification, they just require a few of the build tools to be updated to more recent versions and the correct configure and compile flags to be passed on the command line. Others do require some minor modifications either to the makefile or the code itself which is to be expected.

I’ve avoided using Xcode directly, for the most part, and instead use the terminal with the command line tools as this has a much higher success rate when compared to the Beta Xcode 3.2 Development Environment from 10A096 Server - as you stated the Xcode Project files are mostly designed for x86_64 but the source code itself in many cases isn’t. The downside to building projects this way is that, unlike MacPorts which notifies you of the dependencies required for each project, there’s no easy way to identify what the dependencies are until the build fails unless it’s included in the readme and sometimes on the original developers website. Another problem is not knowing the correct order to build dependencies for each project leading to multiple build attempts across multiple projects until something works, as well as many searches on google. This is very time consuming, and i feel I’m learning a lot as i do this which is part of the attraction for me if i’m honest.

In the last year since starting to work on this, i’ve purchased multiple developer DVDs, 10.6 retail and 10.6 Server, a PowerBook 5,6 (advertised as 5,8 but an honest mistake by the seller) and a 2008 Aluminium Macbook to aid in testing and comparing builds. This is in addition to the Powermac G5, Powermac G4 and iBook G4 that i already owned and have installed either 10A096 or 10A190 on. I think it’s safe to say that i’m heavily invested in this project at this point and i’m still excited to see what can be achieved over the next year and beyond!
 
In the last year since starting to work on this, i’ve purchased multiple developer DVDs, 10.6 retail and 10.6 Server, a PowerBook 5,6 (advertised as 5,8 but an honest mistake by the seller) and a 2008 Aluminium Macbook to aid in testing and comparing builds. This is in addition to the Powermac G5, Powermac G4 and iBook G4 that i already owned and have installed either 10A096 or 10A190 on. I think it’s safe to say that i’m heavily invested in this project at this point and i’m still excited to see what can be achieved over the next year and beyond!

Wow. This ¶ right here made my jaw drop open with awe. I am duly impressed.

Comparatively speaking, I’ve only been using the one PowerBook5,8 (which I found in 2019 on a domestic eBay sale, assumed by the seller as broken, dead, and CAD$25… and while it does have its wealth of problems I can’t readily fix, it does run) and downloading whatever’s come available since @Larsvonhier kick-started this project into gear. So yes, total respect for your commitment. I’m inspired by it. :)

As for using Xcode command-line build tools, I’d never considered that path — again, because I lack developer experience. I had been mapping out a plan to old-school it as if this was simply a generic posix system without port services (i.e., homebrew, macports, rpm, etc.). At this point, I haven’t put myself into the head space to begin doing that just yet, as I’m still trying to eke out what remains from the front-end, before beginning work in earnest on the foundation of the system itself (i.e., building optimized binaries and libraries specifically for 10A96 or 10A190 or any other aspect of this project).
 
Not yet... and actually I think I moved 7.6.4?

If you plan to do more testing with 10A96, I would highly recommend manually moving into place QuickTime 7.7.0’s components.

I discussed this in earnest on post #926, followed a couple of days later in post #928 the installation of iTunes 10.4.1 — in that order. (I’ve also referenced post #926 in the WikiPost appendix for fixes and workarounds, in case you need to refer back to it.)

I have found that doing this not only improved stuff related to QT media stability, but it also restored QuickLook functionality in Finder. The 7.7.0 installation components include several updated frameworks and private frameworks which tie into Core services (like CoreMedia), as well as QTkit stuff. My manual moving of iTunes 10.4.1 into place occurred just after I had moved QuickTime 7.7.0’s components into place.
 
  • Like
Reactions: ChrisCharman
If you plan to do more testing with 10A96, I would highly recommend manually moving into place QuickTime 7.7.0’s components.

I discussed this in earnest on post #926, followed a couple of days later in post #928 the installation of iTunes 10.4.1 — in that order. (I’ve also referenced post #926 in the WikiPost appendix for fixes and workarounds, in case you need to refer back to it.)

I have found that doing this not only improved stuff related to QT media stability, but it also restored QuickLook functionality in Finder. The 7.7.0 installation components include several updated frameworks and private frameworks which tie into Core services (like CoreMedia), as well as QTkit stuff. My manual moving of iTunes 10.4.1 into place occurred just after I had moved QuickTime 7.7.0’s components into place.

I recall doing something similar with 10a190… with iTunes 10.6.3 and QuickTime 7.6.4….
 
I recall doing something similar with 10a190… with iTunes 10.6.3 and QuickTime 7.6.4….

10A190, as this project has been revealing, is a different creature from 10A96. A lot happened in four months of system development between the two.

For 10A96: QT 7.7.0 first, then iTunes 10.4.1 second, and this will complete the QT/iTunes portion of your testing setup, allowing you to concentrate on other areas.
 
  • Like
Reactions: ChrisCharman
10A190, as this project has been revealing, is a different creature from 10A96. A lot happened in four months of system development between the two.

For 10A96: QT 7.7.0 first, then iTunes 10.4.1 second, and this will complete the QT/iTunes portion of your testing setup, allowing you to concentrate on other areas.

The problem I had was when I did it for a second time (10a190) iTunes broke my install when manually installing QuickTime. The first time I did it, it worked perfectly fine.
 
The problem I had was when I did it for a second time (10a190) iTunes broke my install when manually installing QuickTime. The first time I did it, it worked perfectly fine.

I can’t say, sorry.

At present, 10A190 quirks remain outside of my domain, and I defer to @ChrisCharman ’s experience with it. I can more definitively speak to what 10A96 is capable of doing.
 
I can’t say, sorry.

At present, 10A190 quirks remain outside of my domain, and I defer to @ChrisCharman ’s experience with it. I can more definitively speak to what 10A96 is capable of doing.

Yeah… I mean I’m running 10a96 client on my G5 right now so I’m in the same camp as you (after my frustration with 10a190 being more sensitive).
 
Last edited:
For your Monday flex:

Running the 10A96 build of 10.6 on a PowerBook, compiling a particular version of gcc for a project I’m trying, as iTunes 10.4.1 streams a radio feed from Holland, and I’m doing basic browsing with InterwebPPC (and using backmojis in my post) — yet the CPU hums along at 52°C and the fans are humming along at around 40 per cent of their top speed.

Awwwyeah this is the good stuff. 💪
 
The latest, small bit of interesting news:

I was looking at the left bar of a Finder window and furrowing my brow at how the one unibody iMac and one unibody MacBook Pro I had on the network were represented by icons of much older models (the white iMac and the 15-inch aluminium MBP, respectively). Right next to my 10A96 box with these outdated icons, I had another laptop open with 10.6.8 and was noticing how those icons for the networked Macs were correct.

So I found this semi-old article to locate where system .icns live (this isn’t something I think about much, so I needed a refresher). These .icns live inside the /System/Library/CoreServices/CoreTypes.bundle.

This intrigued me because a few months ago, when I began working on SL-PPC stuff again, I tried bringing over the CoreTypes.bundle from 10.5.8 and quickly learnt that it choked Finder. So at the time, I reverted it and forgot about it.

This time, the article gave me the idea to inspect within the bundle to find the Contents/Resources sub-directory (where the .icns live). For one thing, I found there are roughly twenty more .icns in 10.6.8 than in 10A96. Most of those were for models which, in June 2008, didn’t exist yet (not even the late 2008 15-inch unibody MBP or unibody MB were known publicly then).

I got the idea to move all the .icns to a holding directory I simply called “10A96”, then copied over all the .icns from the CoreTypes.bundle in 10.6.8. (There is one file on that level simply called “System”, and I left it alone for now, along with the language support .lproj directories.)

Next, I moved up one level to Contents/ because the Info.plist there gives definition to the parameters for when those .icns are to be used. I appended the Info.plist and version.plist with a .10A96, and then copied over the same from the 10.6.8 source.

Then I rebooted.

Guess what? IT WORKED.


1626920190184.png

[Before: “sonologia” is the late-2013 iMac and “morfologia” is the unibody MBP]


1626920330210.png

[After: HEY LOOK AT THAT :D ]


So I guess this is one tiny UX thing which brings some currency to the look and feel of these early builds. :)


[2021.07.23, EDIT TO ADD: In addition to the above cosmetics, there are also three prefPanes in 10.6.8 whose .icns appearances vary from Build 10A96 — Desktop & Screen Saver; Energy Saver; and Keyboard & Mouse. For the last one, Keyboard & Mouse, in 10A96 and 10A190 it was still an all-in-one prefPane (covering keyboards, mice, and tracpads), as it had been for Leopard and Tiger; by 10A222, Trackpad was split from Keyboard & Mouse; and by the Golden Master 10.6.0, Keyboard & Mouse was split again to separate Keyboard from Mouse (and also Trackpad). With these splits, new .icns were made, and in the case of splitting Mouse from Keyboard, a new Keyboard .icns and new Mouse .icns were created.]
 
Last edited:
I found another thing in Builds 10A96 and 10A190 which changed for both 10.5.8 and 10.6.0–10.6.8:

The Keyboard.prefPane in 10A96/10A190 is set up much the same way as what’s found in 10.5.3 (and probably 10.5.4, given the window of when those updates went public). This means Keyboard.prefPane in 10A96/10A190 handles not only the keyboard configuration, but also mouse configuration and trackpad configuration.

By 10.5.8, the Keyboard.prefPane had changed, with trackpad configuration removed and spun off to its own prefPane called Trackpad.prefPane. The configuration options in Trackpad.prefPane are no different than the Trackpad tab in the old Keyboard.prefPane.

By 10.6.8, the Keyboard prefPane was split again, with Keyboard.prefPane handling keyboard configuration; Trackpad.prefPane handling trackpad configuration; and Mouse.prefPane appearing whenever a mouse is connected. This was probably easier than having one prefPane playing musical tabs depending on system configuration, as plenty of Macs lacked a trackpad by default, while others lacked a mouse. Plus, added features with the forthcoming wireless peripherals might have made an all-in-one Keyboard.prefPane pretty unwieldy.

So, for the sake of it, I went ahead and brought over both the Keyboard.prefPane and Trackpad.prefPane from 10.5.8 into Build 10A96, and disabled the 10A96 Keyboard.prefPane. If one looks at the version.plist files within these prefPanes, all of them show “version 4.5”, but the SourceVersion tag for these are different. For the 10.5.8 prefPanes, they are SourceVersion 1021000; for Builds 10A96 and 10A190 prefPane, it is SourceVersion 1050000.

For this new, split-prefPane setup to work properly, one more item requires backporting to the 10.5.8 version.

In 10A96/10A190, you will need to disable /System/Library/PrivateFrameworks/MachineSettings.framework in Build 10A96/10A190. Then, copy over the same private framework from 10.5.8. Once this version is moved into place, Trackpad.prefPane should work, as should Keyboard.prefPane (with Keyboard & Mouse tabs no longer showing an option for Trackpad).

But there’s one more thing:

If you’ve done all of the above and everything loads, you may notice that Trackpad.prefPane isn’t located under the Hardware section, but under the Other section. System Preferences.app needs to know about the Trackpad.prefPane in order to categorize it correctly.

To do this, open package contents of System Preferences.app/Contents/Resources and locate the NSPrefPaneGroups.xml file. Look for the section titled <string>hardware</string>. Insert a line in that list which reads “<string>com.apple.preference.trackpad</string>”. Save that xml file, and this will relocate Trackpad to the proper location.

With these tweaks, along with the appended UI tweaks in post #1092 (the one right before this post), my test Mac running Build 10A96 now appears with the following:

1627049151918.png


In short, this is making the system look and feel more like a finished build of Snow Leopard. It’s superficial, but nevertheless refreshing.
 
Yeah… I mean I’m running 10a96 client on my G5 right now so I’m in the same camp as you (after my frustration with 10a190 being more sensitive).
Hi @B S Magnet and @MacPro2006VBox

Though i have spent many hours working on 10A190, i have been focused on low level binaries and libraries so cannot shed too much light on iTunes at this point i’m afraid. That being said, i do remember that QuickLookUI is different in 10A190 than 10A096 which probably means other incompatibilities exist with Leopard versions of iTunes as well - 10A096 being closer to 10.5 is much more forgiving.
 
  • Like
Reactions: B S Magnet
Hi @B S Magnet and @MacPro2006VBox

Though i have spent many hours working on 10A190, i have been focused on low level binaries and libraries so cannot shed too much light on iTunes at this point i’m afraid. That being said, i do remember that QuickLookUI is different in 10A190 than 10A096 which probably means other incompatibilities exist with Leopard versions of iTunes as well - 10A096 being closer to 10.5 is much more forgiving.

Yah, I think @MacPro2006VBox was wanting to know more about iTunes and 10A190 compatibility. The 10A96/iTunes combination appears to be solved at this point.
 
An editorial note to the WikiPost:

I’ve updated and clarified the timeline and relationship of Builds 10A96 and 10A190 to their Leopard counterparts.

This is noteworthy because up until recently, the folks who’ve been involved with the Clouded Leopard project have generally likened 10A96 as a closer spiritual successor of 10.5.8, and 10A190 a closer successor of 10.6.0.

This isn’t quite true.

Rather, given how Build 10A96 was released to developers only one week after the 10.5.3 update, whilst Build 10A190 was released to developers just a few weeks after the 10.5.5 update (with a slightly longer span of time between 10A190 and the subsequent 10.5.6 update), it is probbly more precise to relate these DP builds to their temporal Leopard counterparts, in terms of overall system development and any crossover of newly added functions — especially when considering how 10.5.8 came out 14 months after 10A96 and 10.6.0 went on sale out almost 10 months after 10A190.

Although this should have been evident from the outset, this temporal relationship between the 10.5 updates and the 10A96 and 10A190 builds didn’t become clear to me until this week, when I noticed how the appearance of the Trackpad.prefPane in 10.5.8 and 10.6.0 was not present with either 10A96 or 10A190.

In short: There may be other features like this which aren’t immediately apparent at first glance, but are absent in the DP builds and which could stand to benefit by grabbing stuff from the 10.5.8 “parts bin”, as it were.
 
In short: There may be other features like this which aren’t immediately apparent at first glance, but are absent in the DP builds and which could stand to benefit by grabbing stuff from the 10.5.8 “parts bin”, as it were.

Takes me back to this: https://forums.macrumors.com/threads/snow-leopard-on-unsupported-ppc-machines.2232031/post-29628664

I don't have time to contribute but I really feel like the above is the way to go in order to actually build a real roadmap to 10.6 PPC.
 
  • Like
Reactions: B S Magnet
Can't code and probably can't do anything that would be helpful to project but geekbench score is good and close to the leopard lol
 

Attachments

  • 20210726_003133.jpg
    20210726_003133.jpg
    184.3 KB · Views: 110
  • 20210726_003111.jpg
    20210726_003111.jpg
    287.7 KB · Views: 110
  • Like
Reactions: B S Magnet
Can't code and probably can't do anything that would be helpful to project but geekbench score is good and close to the leopard lol

Nice!

You need not know how to code in order to test things on your setup. (After all, I can’t code to save my life.)

One area where checking into things might help to improve your Geekbench score is by opening Console.app in Utilities and opening the system.log to see what, if anything, if sending a lot of messages to the log. Also, the left panel with all the logs can show, if there are any, which background applications or services might be crashing and restarting a lot. By seeing that those don’t keep reopening, this should help to improve your score. Also, check your Users prefPane under Login Items and make sure you don’t have anything which was put in there. After anything has been removed from that list, do a restart.

Lastly, grab a copy of OnyX 2.2.5 (the last Snow Leopard version known to run on the PowerPC 10A96 and 10A190 builds), and under Finder, activate the “Quit Finder” option so that you can Cmd-Q on Finder when running just Geekbench. This should also help with your score. :)
 
  • Like
Reactions: PowerfulEra
Rather, given how Build 10A96 was released to developers only one week after the 10.5.3 update, whilst Build 10A190 was released to developers just a few weeks after the 10.5.5 update (with a slightly longer span of time between 10A190 and the subsequent 10.5.6 update), it is probbly more precise to relate these DP builds to their temporal Leopard counterparts, in terms of overall system development and any crossover of newly added functions — especially when considering how 10.5.8 came out 14 months after 10A96 and 10.6.0 went on sale out almost 10 months after 10A190.

Although this should have been evident from the outset, this temporal relationship between the 10.5 updates and the 10A96 and 10A190 builds didn’t become clear to me until this week, when I noticed how the appearance of the Trackpad.prefPane in 10.5.8 and 10.6.0 was not present with either 10A96 or 10A190.

In short: There may be other features like this which aren’t immediately apparent at first glance, but are absent in the DP builds and which could stand to benefit by grabbing stuff from the 10.5.8 “parts bin”, as it were.
Then we should take care of 10.5.3 .5 and .6 kext sets/kernel instead of focusing using 10.5.8 set to replace in 10A96
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.