Sorbet Leopard - Your Power Mac Unleashed

[barracuda156]

Nothing, really. It was just an idea to save time. I agree building natively is ideal.

While on the topic, I would actually prefer to contribute to the Snow Leopard project instead, but performing the necessary trial-and-error of importing / exporting kexts / frameworks around to fix issues, setting up a build environment and compiling new binaries, troubleshooting no-boot errors, and testing different configurations is going to require a certain regular time investment and prioritization I frankly cannot afford at least for the foreseeable future.

Meanwhile, a linear series of mostly predetermined steps to compile an update for Sorbet carries a much lower price tag in comparison, will at least resolve any remaining bugs, and the fact that I now daily a G4 and G5 again is just the excuse I needed to justify proceeding.

@z970 If the aim is to update the system itself, Snow Leopard is a much better start, and will require less time & effort (this does not mean it gonna be quick & easy, but still). Getting 10.5 at least to the level of 10.6 is already non-trivial at best and likely impossible without hacking the kernel (and definitely Libc and the system compiler).

If the aim is to make minimal fixes to a few specific issues without much involvement, and have a usable result, Leopard is easier, of course, since the only constrain with it is not to break what works: there is a lot to improve but not much to fix.

In a case you decide to work on SL later, ping me. While I am not an expert in the OS, I can deal with building components.

 

[srp]

Snow Leopard is a much better start, and will require less time & effort

I have put a substantial amount of effort into trying to make Snow Leopard work and I just can't agree with this statement. Every system I have tested it on is way too unstable. I would assume that either your hardware is an outlier and somehow you don't get the same issues I do, or you are just dealing with multiple panics a day like I am - neither is good considering the OS needs to be stable on more than just one person's machine.

I cannot use my PowerBook with it because it doesn't sleep and ends up cooking itself. Using it with my G5s causes a kernel panic when sleeping or sometimes even when the screensaver triggers. Neither device can stay running for more than ~8 hours without panicking.

I will be in the middle of writing code or testing something and it panics. Software that works on Leopard doesn't work on Snow Leopard. USB drives randomly decide not to mount, Firewire drives cause panics, USB game controllers and other devices cause panics, the networking stack is broken... the list goes on.

In my opinion this is not a reliable starting point for making a definitive OS tweak set geared around improved usability for hobbyists. When I use my Macs, it is typically for a couple hours at a time and then I step away to do something else, I can't justify the stress I'm putting on the PSU and VRMs through a full power cycle every few hours.

If we could actually fix some of these issues then it would be a different story, but I have no idea how to fix crashes with closed source ACPI kexts or debugging weird sleep state issues that show up differently depending on the device you're using. Is anyone maintaining a list of known issues and affected components? Have we done an inventory of what we can rebuild from source vs what we will likely need to reverse engineer or port from Leopard? I think these are probably reasonable next steps to understand the scope of work involved.

 

[barracuda156]

I have put a substantial amount of effort into trying to make Snow Leopard work and I just can't agree with this statement.

Well, try getting libdispatch compile on 10.5 to begin with 🙂 Then rebuild CoreAudio with 10.6 APIs added. Then rebuild CoreFoundation, libobjc and whats not to support ObjC APIs which work in 10.6 out-of-the-box.
I bet it gonna take longer than fixing sleep and DHCP in 10.6.

(Edit: I never said 10.6 does not require work, but getting 10.5 to have what 10.6 already has is nearly impossible and will need rewriting core system components from kernel and compiler to multiple frameworks.)

Every system I have tested it on is way too unstable. I would assume that either your hardware is an outlier and somehow you don't get the same issues I do, or you are just dealing with multiple panics a day like I am - neither is good considering the OS needs to be stable on more than just one person's machine.

The system is stable, if hardware is fine. I get panics on the Quad now, but regardless of the OS, since there is something very wrong with the hardware, sadly. Otherwise there are no panics and no freezes (ok, maybe once in a blue moon). I run SL daily for hours, with intensive CPU load.

What is broken is local networking (connecting machines require manual setup, while in 10.5 it works out of the box) and sleep (I don’t need it on a PowerMac and can live without it on a laptop). I think DHCP is also kinda broken, so if you are behind a firewall, you need another system to get the correct IP. This sucks, admittedly. However upsides are way too many.

 

[barracuda156]

Is anyone maintaining a list of known issues and affected components? Have we done an inventory of what we can rebuild from source vs what we will likely need to reverse engineer or port from Leopard?

I advocated for that in https://forums.macrumors.com/threads/10-6-snow-leopard-powerpc-development.2439769 but not sure at what stage it is.

Unfortunately, I do not know what breaks DHCP. That is arguably No. 1 issue which I find annoying in 10.6.
AHCI kexts are broken in 10.6, which prevents usage of some, perhaps rather uncommon, PCIe hardware.
OpenGL in A5 is borrowed from 10.5.8, and it is older than what even 10a190 has. However, 10a190 had some issues, so neither alternative is great. Here we are on par with 10.5 but not 10.6 on Intel.
Broken sleep and Finder not reflecting disks unmounting are known issues.
A bunch of Unix tools lack ppc slices in Xcode 3.2.6, so those must either be rebuilt or substituted. For someone not using ports it will be a substantial list.

 

[srp]

Then rebuild CoreFoundation, libobjc and whats not to support ObjC APIs which work in 10.6 out-of-the-box.
I bet it gonna take longer than fixing sleep and DHCP in 10.6.

I think that the issues affecting Snow Leopard are much deeper than just those two problems. It's honestly hard to tell when so many of the issues could just be stemming from permissions.

Unfortunately, I do not know what breaks DHCP.

I believe that the whole network stack is affected in ways we don't fully understand yet. It's worth mentioning that in AquaCenter, AirPlay streaming via Shairport and Spotify Connect are basically broken - no device is ever broadcast to the AirPlay sender/Spotify client despite those functions working well in Leopard and even my experimental Tiger build. I have no hypothesis for why this happens other than a permissions issue - same with SMB/NFS and USB drive mounting issues.

Here we are on par with 10.5 but not 10.6 on Intel.

This is the kind of assertion that should be rooted in tests and evidence. I had to patch my SDL2 build for Snow Leopard because it couldn't enumerate any of my monitors. I had to make an additional patch for it to properly recognize my external display. I'm seeing frame pacing and performance problems, especially in multithreaded contexts. The GPU drivers are fickle as they are - have we actually gone through each individual driver or built a hardware compatibility chart yet? Do we know an FX5200 boots but an X1900 doesn't, for example?

AHCI kexts are broken in 10.6, which prevents usage of some, perhaps rather uncommon, PCIe hardware.

I don't think this is to blame for my panic issues. I will admit that I need to dig deeper into why these panics are happening and provide some logs so that we can figure out a solution.

I also agree with you in principle that it's nice to have ARC, grand central dispatch, all of the benefits that Snow Leopard brings but I can't think of one HARD limitation where software that will build for 10.6 on PPC simply *could not* be ported to 10.5. Using mrustc as an example, I have it building `proc_macro` on Leopard and it's capable of compiling simple programs. There's still more work needed and it's not ready to go into a Portfile, but it's clearly workable.

I want Snow Leopard to work. But I think you will agree with me that if this OS is only stable on 50% of the devices that users run it on, we should work to make it better. When I get the chance this weekend, I will try to do some more testing on my end - maybe you can take a look at these panics, and we can figure them out together.

edit: I might have found something related to the network issues: https://arstechnica.com/gadgets/2010/11/apple-fixes-broken-ipv6-by-breaking-it-some-more/

 

[barracuda156]

I think that the issues affecting Snow Leopard are much deeper than just those two problems. It's honestly hard to tell when so many of the issues could just be stemming from permissions.

Permissions issues exist but are problems with specific image(s), not with the OS itself. You could assemble 10.5 image, using wrong permissions here and there, and get the same issues arise.
While for an end-user at a given moment of time it does not effectively matter if a bug is in the code or in a dmg he uses for install, it makes a big difference for us. Fixing permissions is just a matter of mechanical work done. No one so far found enough time/motivation to do that, that’s all.

This is the kind of assertion that should be rooted in tests and evidence.

The assertion about CG and GL is based on a fact that components were literally borrowed from 10.5.

I had to patch my SDL2 build for Snow Leopard because it couldn't enumerate any of my monitors. I had to make an additional patch for it to properly recognize my external display.

Because 10.6.8 on ppc used some components from 10.5.8, some codepaths assuming standard 10.6 may not work, and 10.5 ones should be used, or 10.6 ones need to be patched accordingly.

I'm seeing frame pacing and performance problems, especially in multithreaded contexts.

If you mean that something works consistently better on 10.5 than on 10.6 with SDL, that is SDL (or our) bug, which is totally fixable.

The GPU drivers are fickle as they are - have we actually gone through each individual driver or built a hardware compatibility chart yet?

Not properly so, I believe.

Do we know an FX5200 boots but an X1900 doesn't, for example?

X1900 does not break booting or running the OS. However ATI cards have inferior support for GL (I think this holds for 10.5.8 too), and were one of the reasons to borrow older components from 10.5 into A5 image, otherwise no hardware accel was available for them.

I don't think this is to blame for my panic issues.

In my experience AHCI kexts were just breaking the boot if loaded (i.e. if OF detected PCIe card I had). So I had to either remove the card, or disable that PCIe device in OF, or trash the broken kext (I settled on the latter eventually).

I also agree with you in principle that it's nice to have ARC, grand central dispatch, all of the benefits that Snow Leopard brings but I can't think of one HARD limitation where software that will build for 10.6 on PPC simply *could not* be ported to 10.5.

Maybe I miss your point. Why so? In general case it can; in some cases not, but that is expected: newer SDKs have APIs unavailable in older ones, and we cannot port Swift apps to powerpc, for example. Why is this a hard limitation? I won’t run 10.5 on x86 because some Catalina apps may not be ported to it.

Using mrustc as an example, I have it building `proc_macro` on Leopard and it's capable of compiling simple programs. There's still more work needed and it's not ready to go into a Portfile, but it's clearly workable.

If you have sorted out libunwind linking, it is worth adding into the portfile. (I think on 32-bit 10.5 that was the stopper?)

 

[z970]

I have put a substantial amount of effort into trying to make Snow Leopard work and I just can't agree with this statement. Every system I have tested it on is way too unstable. I would assume that either your hardware is an outlier and somehow you don't get the same issues I do, or you are just dealing with multiple panics a day like I am - neither is good considering the OS needs to be stable on more than just one person's machine.

I cannot use my PowerBook with it because it doesn't sleep and ends up cooking itself. Using it with my G5s causes a kernel panic when sleeping or sometimes even when the screensaver triggers. Neither device can stay running for more than ~8 hours without panicking.

I will be in the middle of writing code or testing something and it panics. Software that works on Leopard doesn't work on Snow Leopard. USB drives randomly decide not to mount, Firewire drives cause panics, USB game controllers and other devices cause panics, the networking stack is broken... the list goes on.

In my opinion this is not a reliable starting point for making a definitive OS tweak set geared around improved usability for hobbyists. When I use my Macs, it is typically for a couple hours at a time and then I step away to do something else, I can't justify the stress I'm putting on the PSU and VRMs through a full power cycle every few hours.

If we could actually fix some of these issues then it would be a different story, but I have no idea how to fix crashes with closed source ACPI kexts or debugging weird sleep state issues that show up differently depending on the device you're using. Is anyone maintaining a list of known issues and affected components? Have we done an inventory of what we can rebuild from source vs what we will likely need to reverse engineer or port from Leopard? I think these are probably reasonable next steps to understand the scope of work involved.

Not to interject, but I’m curious if you’ve seen any of these issues with the 10.6.8 A5 image present on the first 10A096 build, as 10A190 was overall more broken than either and likely isn't worth pursuing.

Of course I am mostly speaking as an observer (and from memory as it’s been 6+ years since the project began), but in practice since there is only so much manpower and volunteered time available that can be dumped into this, perhaps it would be a wiser choice to build from the platform with less inherent issues provided that it still offers the same basic advantages as A5, for example in software ports.

Regarding a GPU compatibility chart, one (and several others) was assembled in the original thread in “table 3”. A basic machine compatibility chart was likewise provided in “table 2”. I can't imagine how much more useful information must have been discovered over the years across all 114 pages but never added to the WikiPost due to lack of space.

 

[srp]

Trying to take a closer look at this today. This build here is not the original 10A96 build, unfortunately. It has timestamps in 2021, .Trashes etc which indicate this has been modified.

This would ideally be the client you'd want to start patching things into - but we need a clean mirror first.

 

[barracuda156]

Not to interject, but I’m curious if you’ve seen any of these issues on the previous 10A096 build rather than the 10A190 build the A5 image was based on.

A5 is not based on 10a190. It is based on 10.6.8 release with some proprietary components taken from 10.5.8 (Finder, OpenGL, something in CoreGraphics, perhaps AirPort module, some GPU drivers).
A different image which was labelled as “Nvidia” here has OpenGL from 10a190.

I do not remember if anything at all was taken from 10a190 into A5. Perhaps something was, but it not even remotely “based on” 10a190.

There are a few things which work better in 10a190 than in A5: DHCP, previews in Finder, GL stack (at least it is newer). In general, however, A5 is substantially better.

From what I recall, B S Magnet reported that the stability difference between the two was substantial.

Of course I am mostly speaking as an observer (and from memory as it’s been 6+ years since the project began), but in practice since there is only so much manpower and volunteered time available that can be dumped into this, perhaps it would be a wiser choice to build from the platform with less inherent issues provided that it still offers the same basic advantages as 10A190, for example in software ports.

I don’t think 10a96 has any utility at all. 10a190 as such has little relevance either, only GL and some Xcode components can be useful, I guess.

 

[barracuda156]

Trying to take a closer look at this today. This build here is not the original 10A96 build, unfortunately. It has timestamps in 2021, .Trashes etc which indicate this has been modified.

This would ideally be the client you'd want to start patching things into - but we need a clean mirror first.

Why on earth use 10a96? It was basically useless from the get-go and completely obsolete by now. It makes little to no sense to start from 10a190 either, since core components of the system are way below what 10.6.8 has (kernel to begin with, libSystem etc.).

 

[barracuda156]

I wonder if this can replace broken AHCI kexts: https://github.com/PureDarwin/IOAHCIProject

 

[joevt]

I wonder if this can replace broken AHCI kexts: https://github.com/PureDarwin/IOAHCIProject

Doesn't look like there's anything there.

 

[srp]

Why on earth use 10a96? It was basically useless from the get-go and completely obsolete by now. It makes little to no sense to start from 10a190 either, since core components of the system are way below what 10.6.8 has (kernel to begin with, libSystem etc.).

Because going the route of starting with 10.6.8 and patching PPC binaries back into it clearly has its own set of problems. This is what the A5 build does.

By starting with 10a96 you’re starting with the most compatible PPC surface. I’m still just gathering information and collecting differences between versions.

 

[z970]

A5 is not based on 10a190. It is based on 10.6.8 release with some proprietary components taken from 10.5.8 (Finder, OpenGL, something in CoreGraphics, perhaps AirPort module, some GPU drivers).

My apologies, thanks for the correction.

On second thought (and I am just thinking out loud at this point), perhaps it doesn't make sense to use anything besides 10.6.8 / A5. Earlier builds may or may not offer comparatively better stability, but if you consider the respective strengths of the different OS versions, any build of 10.6 is likely not going to achieve better overall stability on most systems than what is already offered in retail 10.5. Likewise, if the user's main priority is extracting the fastest performance possible, then neither 10.6 or 10.5 is going to outpace 10.4 when running on such limited hardware anyway, certainly when equipped with non-CI graphics.

And then regarding the question of what exactly constitutes "usability", perhaps that depends on their intended usage. Between Leopard WebKit, PowerFox, Basilisk, TenFiveTube, QT 7.7 (and others I'm certainly forgetting), 10.5 currently offers the overall best modern web / workflow compatibility, albeit by a small margin admittedly.

But then (with some exceptions), given that many final versions of apps compatible with PPC support both 10.4 and 10.5, 10.4 may provide a better offline experience all else being equal given the OS itself has a significantly lighter footprint, allowing comparatively more CPU cycles to be allocated to foreground applications rather than background services / kernel threads; and furthermore reducing baseline GPU load since Core Image wasn't as resource-intensive in 10.4.

Meanwhile for development uses, seemingly you can attest that 10.6 is more "usable" than either of its predecessors in terms of flexibility when backporting software to PPC. As @srp alluded, is this mainly a convenience factor making porting generally just easier, or rather an absolute in regards to enabling certain important software that would be impossible on 10.5? Are there any noteworthy examples you can think of? Is this mostly a benefit of Xcode 3.2, or newer libraries, or perhaps both?

So just zooming out for a moment, if 10.6 isn't going to be able to compete in end-user stability or foreground application performance, does it have any other inherent advantages perceivable besides offering newer binary / library / toolchain versions enabling better development interoperability? With the Darwin 10.8 kernel recompiled from 10.6.8 AOSP, have any tangible performance differences yet been recorded and compared over version 9.8? Perhaps in network throughput?

Correct me if I'm wrong but as I understand it, other factors to consider are: the software built from 10.6.8 is only several years newer than 10.5.8 and still more than 15 years old so security improvements are negligible, no Open Firmware-compatible GPUs actually support OpenCL, the effects of Grand Central Dispatch are probably canceled out when half the systems are single core and the other half have more cycles available on an optimized 10.4 anyway, XProtect is closed-source and Intel-only, Cocoa Finder w/ Exposé is closed-source and Intel-only, QuickTime X is closed-source and Intel-only, the Mac App Store is Intel-only and irrelevant, and for that matter it is likely reasonable to assume that (with some exceptions again) most contemporary software moved to Intel-only binaries after requiring 10.6 as the minimum since the system was only available for Intel platforms, so it is hard to imagine that general software compatibility could be much improved either.

All that is to say I still think it would be ideal for 10.6 to (somehow) eventually get to a point where it can supplant 10.5 on PPC as it already has on Intel, because it would at the very least presumably open up easier backporting for modern software. So, I'm asking only to gain a better understanding of its total offered value in any other use cases and figure out where we will be able to realistically take it in comparison to 10.4 / 10.5 since in practice a considerable portion of the retail product was closed off and never released.