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 on the previous 10A096 build rather than the 10A190 build the A5 image was based on. 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.

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.