10.6 Snow Leopard PowerPC Development

[barracuda156]

So what’s the progress on the project? I uploaded a video about it a few days ago, and it re-peaked some interest in the project. I’ve been experimenting with making it work better and testing a few things out and so far it’s still not been super successful, especially with networking… I did however, get a smaller version of the image made, which is on Macintosh Garden still the entire same image nothing’s been changed except you can actually put it on a smaller hard drive partition now. Would love to see the beta or at least an alpha 4 soon 😃👌

Re progress:

I'm on my MacBook at the moment which doesn't have those projects - @Jazzzny shared some toolchain files a while back on the other thread Here which included cctools and gcc if you're interested in those projects specifically.
On the system i'm running at this moment i have the following

Spoiler: projects

1. adv_cmds
2. amavisd
3. apache
4. apache_mod_bonjour
5. apache_mod_fastcgi
6. apache_mod_hfs_apple
7. apr
8. architecture
9. autoconf
10. automake
11. awk
12. bash
13. basic_cmds
14. bc
15. BerkeleyDB
16. bind9
17. bison
18. bison1
19. bootstrap_cmds
20. bsdmake
21. bzip2
22. CarbonHeaders
23. clang
24. CommonCrypto
25. CoreOSMakefiles
26. CPANInternal
27. CrackLib
28. crontabs
29. cscope
30. Csu
31. curl
32. cvs
33. cxxfilt
34. developer_cmds
35. disklabel
36. distcc
37. doc_cmds
38. efax
39. enscript
40. expat
41. FastCGI
42. fetchmail
43. file
44. files
45. flex
46. freeradius
47. gcc-5646
48. gcc_select
49. gdb
50. glibtool
51. gm4
52. gnudiff
53. gnumake
54. gnuserv
55. gnuzip
56. gperf
57. gpt
58. graphviz
59. grep
60. groff
61. headerdoc
62. ICU
63. IOACPIFamily
64. IOATAFamily
65. IOAudioFamily
66. IOBDStorageFamily
67. IOCDStorageFamily
68. iodbc
69. IODVDStorageFamily
70. IOGraphics
71. IOPCIFamily
72. IOStorageFamily
73. JavaScriptCore
74. ksh
75. less
76. libclosure
77. Libcpp_kext
78. libedit
79. libevent
80. libffi
81. libgcc
82. libiconv
83. libmd
84. libpcap
85. Libpcsvc
86. libtelnet
87. libutil
88. libxml2
89. libxslt
90. Liby
91. llvmCore
92. lsof
93. lukemftp
94. lukemftpd
95. mail_cmds
96. mailman
97. man
98. misc_cmds
99. modemccl
100. MySQL
101. nano
102. nasm
103. ncurses
104. neon
105. net_snmp
106. netcat
107. ntp
108. OpenBSM
109. OpenPAM
110. OpenSSL096
111. OpenSSL097
112. patch_cmds
113. pb_makefiles
114. pcre
115. pdisk
116. perl
117. portmap
118. procmail
119. pyOpenSSL
120. PyRSS2Gen
121. rcs
122. removefile
123. rsync
124. ruby
125. ruby_dnssd
126. ruby_libxml
127. RubyGems
128. RubyOnRails
129. SpamAssassin
130. srm
131. sudo
132. swig
133. SystemStubs
134. TargetConfig
135. tcl
136. tcp_wrappers
137. tcpdump
138. tcsh
139. texi2html
140. TimeZoneData
141. top
142. tsch
143. Twisted
144. UserNotification
145. uucp
146. vim
147. X11server
148. xar
149. xelf
150. xnu
151. zlib
152. zsh

built via darwinbuild and/or manually. I'm in the process of collecting anything else i have on the other machines and creating a table to put in the wikipost to collate all build progress and reports etc so we can all keep track of what we collectively have available.

Yes, I am aware of what @Jazzzny shared and I use some components from there (while other from darwinbuild and yet something just pulled over from 10a190/10a222), however the very problem is that everything is in pieces here and there, and everyone has slightly different toolchain, possibly not only with undocumented, but even unknown to oneself differences. This is fine as long as “this works for me”, but becomes a problem once someone asks why something fails for him and how to deal with that. One thing that MacPorts and similar package systems got right is that reproducible builds are important. This is what is lacking at the moment.

I think we need a completely standardized installer for the basic toolchain. There may be more than one of them, by the way, we have no obligation to install exactly same versions of everything which an archaic Xcode happened to have. Say, there may be a) Xcode 3.2.6 tools with restored ppc slices, otherwise identical to the release, b) updated Xcode tools, from some newer versions of Xcode (what MacPorts does, but can be different versions of course), c) different tools, aimed for developers (for example, Iain’s darwin-xtools). But in result it should be a) easy for any non-expert user to install a given toolchain from scratch, b) easy for any expert user to reproduce exactly identical set-up on another system without cloning and copying anything, c) easy to understand what a given user has on his machine, as long as he installed one of these toolchains, so that debugging is feasible based on logs.

I will test xtools moved into /usr/bin by the way. May not be a choice for everyone, but can be promising.

P. S. Did you build xnu via darwinbuild or manually?

 

[ChrisCharman]

Re progress:


Yes, I am aware of what @Jazzzny shared and I use some components from there (while other from darwinbuild and yet something just pulled over from 10a190/10a222), however the very problem is that everything is in pieces here and there, and everyone has slightly different toolchain, possibly not only with undocumented, but even unknown to oneself differences. This is fine as long as “this works for me”, but becomes a problem once someone asks why something fails for him and how to deal with that. One thing that MacPorts and similar package systems got right is that reproducible builds are important. This is what is lacking at the moment.

Agreed this is inconvenient for us working on the project and anyone wanting to build anything on 10.6.8.

For the normal user however it’s completely irrelevant.

The most important issue for the normal user/tester right now is internet access which requires fixing properly, as clearly the workarounds haven’t been made widely known.

I understand your point about MacPorts and other packaging systems but it’s not quite analogous to what we’re doing as we’re not trying to create a package manager - we just need to patch Xcode and then package that up. I do understand that you ARE working on a package manager so your points are directly relevant to that aim.

I think we need a completely standardized installer for the basic toolchain. There may be more than one of them, by the way, we have no obligation to install exactly same versions of everything which an archaic Xcode happened to have. Say, there may be a) Xcode 3.2.6 tools with restored ppc slices, otherwise identical to the release, b) updated Xcode tools, from some newer versions of Xcode (what MacPorts does, but can be different versions of course), c) different tools, aimed for developers (for example, Iain’s darwin-xtools). But in result it should be a) easy for any non-expert user to install a given toolchain from scratch, b) easy for any expert user to reproduce exactly identical set-up on another system without cloning and copying anything, c) easy to understand what a given user has on his machine, as long as he installed one of these toolchains, so that debugging is feasible based on logs.

A standard Xcode would be optimal for everyone - one that does not deviate from the release version aside from architecture.

Multiple other modifications or variations will be no more useful than our current situation as it wouldn’t be standardised. Anything additional can be installed to /usr/local and or /opt and avoid unnecessary installs when it is not needed and also not alter the shipped files. People are free to install more recent tools as they see fit outside of Xcode.

If people want to install self-compiled tools into /usr/local and or /opt via macports on top of the system themselves then that’s what your other threads have detailed and will simply require a functional Xcode which we will provide once it’s finalised either as a patched Xcode installer or as an update package.

I will test xtools moved into /usr/bin by the way. May not be a choice for everyone, but can be promising.

P. S. Did you build xnu via darwinbuild or manually?

I recommend using /usr/local/bin as the system should use that instead anyway.

XNU was built manually, though i’m not using it (the kernel) currently.

 

[barracuda156]

Agreed this is inconvenient for us working on the project and anyone wanting to build anything on 10.6.8.

For the normal user however it’s completely irrelevant.

It actually is relevant for end-users, and very much so, since without some working Unix tools nothing else can be used, including any package manager (be it my PPCPorts, official MacPorts, pkgsrc or even darwinbuild). Obviously, even if one prefers to avoid any ready-made build system or package manager, Unix tools are still required to build stuff manually. The point here is not a particular package manager at all; without the basic toolchain the OS is essentially unusable – if one wants something beyond TextEdit and Preview.

we’re not trying to create a package manager - we just need to patch Xcode and then package that up.

Yet another package manager is completely redundant, there is no point to re-invent a bicycle. However I hope we arrive to a reproducible procedure to build the tools rather than simply distributing some opaque binaries. Distributing pre-built stuff is super-helpful, but it is desirable that everything can be built from source if desired.
Reproducible procedure does not have to rely on MacPorts or darwinbuild (either is possible, but not necessary). It can be a text file with a step-wise instructions, that is sufficient, as long as anyone can follow that and get a strictly identical result.

A standard Xcode would be optimal for everyone - one that does not deviate from the release version aside from architecture.

I think this is too strong of a statement. First of all, the whole of Xcode is not really needed in most cases, and Apple itself moved to providing Developer Tools as a standalone install. I think for a normal user that will be optimal, it saves disk space, which matters on older machines, especially laptops.
It is also not clear whether tools from 3.2.6 are optimal for a developer in a sense of delivering superior results to any feasible alternative. One can argue they are preferable for “ideological” reasons (to retain whatever Apple had, including all possible bugs, as a heritage) or compatibility reasons, that is fine, but it does not mean everyone is necessarily better off using those.

 

[ChrisCharman]

It actually is relevant for end-users, and very much so, since without some working Unix tools nothing else can be used, including any package manager (be it my PPCPorts, official MacPorts, pkgsrc or even darwinbuild). Obviously, even if one prefers to avoid any ready-made build system or package manager, Unix tools are still required to build stuff manually. The point here is not a particular package manager at all; without the basic toolchain the OS is essentially unusable – if one wants something beyond TextEdit and Preview.

Most users install prebuilt packaged software. The fact that people like you continue to enable support for PowerPC via MacPorts is greatly appreciated by our small community, but most of that community would prefer not to touch anything on the commandline. Any unix level tools that are a part of the OS that we can ‘bake in’ and replace with powerpc versions, of course we are doing and will continue to do. You’re also considerably underestimating the primary use case for these systems for a lot of users, which is simply to run legacy software on real hardware, software that doesn’t exist anymore or is incompatible with newer versions of MacOS.

Yet another package manager is completely redundant, there is no point to re-invent a bicycle. However I hope we arrive to a reproducible procedure to build the tools rather than simply distributing some opaque binaries. Distributing pre-built stuff is super-helpful, but it is desirable that everything can be built from source if desired.
Reproducible procedure does not have to rely on MacPorts or darwinbuild (either is possible, but not necessary). It can be a text file with a step-wise instructions, that is sufficient, as long as anyone can follow that and get a strictly identical result.

This has always been one of @B S Magnets points and one i think we can all agree is the correct path - to provide step-by-step reproducible procedures. We’re not their yet for the reasons you stated which are that we haven’t established a single development environment or toolchain yet, so of course there isn’t a how to guide to replicate what doesn’t exist yet. You can use macports to build external tools, you can bootstrap the tools directly, you can cross-compile from Xcode on an intel machine etc. To do anything natively however the xcode build tools are fundamental as a foundation.

I think this is too strong of a statement. First of all, the whole of Xcode is not really needed in most cases, and Apple itself moved to providing Developer Tools as a standalone install. I think for a normal user that will be optimal, it saves disk space, which matters on older machines, especially laptops.
It is also not clear whether tools from 3.2.6 are optimal for a developer in a sense of delivering superior results to any feasible alternative. One can argue they are preferable for “ideological” reasons (to retain whatever Apple had, including all possible bugs, as a heritage) or compatibility reasons, that is fine, but it does not mean everyone is necessarily better off using those.

I think you’re misunderstanding what i’m saying, simply because you are focused on getting the most recent versions of everything running on PowerPC OS X. You view retaining what was included in the releases as holding on to ‘archaic’ versions. Don’t forget that the OS is just as ‘archaic’ as is the hardware we’re targeting and even some of us using them.

Replicating 10.6.8 and Xcode 3.2.x is fundamental to achieve anything further on the platform. Anybody can continue to modify and upgrade the system as they see fit after that but the people interested in this project want ‘Snow Leopard’ as it exists but for PowerPC to begin with and we have a lot of foundational work still to do on that front.

 

[ChrisCharman]

@ChrisCharman @Jazzzny @educovas Do we have a source for pkgbuild somewhere? Turned out it is Intel-only in our image. And 10a190 does not have it at all (?).

UPD. The question still stands, but if anyone bumps into the problem that MacPorts/PPCPorts cannot make a pkg because of that, just delete /usr/bin/pkgbuild, and it will fall back to PackageMaker. (Also need the same for productbuild and set package.flat no).

@barracuda156 pkgbuild was introduced with release 3.2 XCode so if sources exist they will be in that tree. Failing that, possibly 10A222 onwards worth checking. Will check my files when home later and report back on the development thread.

From comments to MacPorts code it follows that pkgbuild and productbuild are needed to build “flat” packages. So we can live without those (fixing it in MacPorts amounts to changing a fallback threshold), but it will likely pop up again elsewhere. So would be nice to have fixed.

I have not been able to find sources or binaries for pkgbuild. It doesn’t exist before some version of XCode 3.2.x at all and is not included in 10A096, 10A190 nor 10A222. I have not checked beyond 10A222 yet but chances are high that it was always intel which means we probably won’t be able to just swap it in from another build.

 

[ChrisCharman]

I know this is far fetched but I might ask

Is it possible to port the SSD TRIM support that was added in 10.6.8 intel?

Is TrimEnabler opensource?

 

[metallizer]

Is TrimEnabler opensource?

No, but TrimEnabler only removes the code apple placed so only apple branded ssds would work.

There is a good explanation here:

https://mackonsti.wordpress.com/2011/07/16/keeping-trim-on-10-6-8-update/

 

[barracuda156]

A minor thing to improve: I guess would want to disable Software Update, since it is meaningless at best and otherwise breaking, if someone accidentally installs those updates.

 

[barracuda156]

Most users install prebuilt packaged software. The fact that people like you continue to enable support for PowerPC via MacPorts is greatly appreciated by our small community, but most of that community would prefer not to touch anything on the commandline.

Well, good luck finding packaged software for 10.6 powerpc I would prefer that myself in some cases, but it just does not exist.
MacPorts / PPCPorts / pkgsrc are primarily used to install pre-built software by regular users. As you can see yourself from these forums, there is a demand for these, not for development, but for getting working software. And installation of these package managers requires some working toolchain to begin with.

You’re also considerably underestimating the primary use case for these systems for a lot of users, which is simply to run legacy software on real hardware, software that doesn’t exist anymore or is incompatible with newer versions of MacOS.

I am honestly not sure if that is the primary use-case or how it even can be possibly established. Say, if I am left with only powerpc machine right now, I am certainly not primarily interested to run 2008 versions of Safari and Aperture, since they do not serve their purpose anymore: Safari cannot browse the web, Aperture does not support my camera.
My software which I have from that time (I have purchased licenses for some) is largely dead: my favorite RSS reader does not work, chat apps are useless, downloader app is not working, some apps cannot even be activated, since servers do not exist. Archaic VLC or Quicktime do not support some modern formats, which I have music videos in.
Okay, CS4 works and old MS Office works, they are perfectly fine from that era. But a lot of stuff is simply defunct, and running it is impossible or meaningless.

 

[educovas]

I've been working on a different project and learned a bit more about the OpenGL framework. This could help me improve my current graphics acceleration patches so I'm planing to revisit that and take a look at tiff2icns.

Are there any new bugs I don't know? It would be very helpful not just for me to try to fix them but also for the people testing the OS if we had a list with the known bugs in the first post.

 

[barracuda156]

Are there any new bugs I don't know? It would be very helpful not just for me to try to fix them but also for the people testing the OS if we had a list with the known bugs in the first post.

Three issues I can mention:

1. If some software creates users/groups, OS does not recognize those without a reboot. AFAIK, it was not the case in 10a190 on PPC or 10.6.8 on Intel. It seems that the issue is not local but exists for our 10.6.8 generally. See an example of another user getting the same error: https://forums.macrumors.com/thread...ed.2433458/page-4?post=33676844#post-33676844

2. There is an issue with the OS `dyld` handling libstdc++ symbols. Example of what I talk about and Iain’s comments on it: https://github.com/iains/darwin-xtools/issues/11

3. AHCI kexts are broken. There are no sources, AFAIK, so not sure it can be fixed, but it would be great if it is possible (perhaps binary patching is required), since it will enable to use faster SSDs via PCIe.
P. S. Someone managed to do AHCI hacking here: https://carrot.dev/2021/03/10/2021-appleahci/

 

[ChrisCharman]

A minor thing to improve: I guess would want to disable Software Update, since it is meaningless at best and otherwise breaking, if someone accidentally installs those updates.

Agreed it should be disabled. Software update and app store related processes should be disabled. Perhaps down the line we can redirect Software Update and replace App Store with a GUI frontend to your prebuilt ports and macports overlay (much like linux app stores) but for now they are not useful.

 

[ChrisCharman]

I've been working on a different project and learned a bit more about the OpenGL framework. This could help me improve my current graphics acceleration patches so I'm planing to revisit that and take a look at tiff2icns.

Are there any new bugs I don't know? It would be very helpful not just for me to try to fix them but also for the people testing the OS if we had a list with the known bugs in the first post.

Networking is still the number one complaint from non-devs and after watching the latest video on YouTube it seems that information about GPU support isn’t clear.

 

[ChrisCharman]

Well, good luck finding packaged software for 10.6 powerpc I would prefer that myself in some cases, but it just does not exist.
MacPorts / PPCPorts / pkgsrc are primarily used to install pre-built software by regular users. As you can see yourself from these forums, there is a demand for these, not for development, but for getting working software. And installation of these package managers requires some working toolchain to begin with.

There are literally thousands of Mac PowerPC applications that work on systems up to Leopard and should run on 10.6.8 PowerPC when it’s finished - commercial software not open source.

My point is that i don’t know anybody that is using a PowerMac an eMac or an iBook as their daily driver in 2025 and running the latest software is secondary to running software that can only run on those machines.

The Web browser is the most notable exception to this but the developers kindly working on this problem release browsers for PowerPC users as application packages because most normal users are scared of the terminal. Users don’t live in the terminal like we do. Most are afraid of the terminal.

Don’t misunderstand me. It’s not unimportant at all to support new software and like i said previously, all of your work on MacPorts is appreciated and will be used by us tinkerers but unfortunately a lot of people do not want to spend (a lot) of time compiling and submitting bug tickets.

I wish more people were interested in the ‘behind the scenes’ and ‘under the hood’ workings but most people are not, they just want an app, that’s why app stores are so prevalent today.

We’re agreed that getting Xcode CLI Tools at a minimum working correctly on PowerPC is essential.

I am honestly not sure if that is the primary use-case or how it even can be possibly established. Say, if I am left with only powerpc machine right now, I am certainly not primarily interested to run 2008 versions of Safari and Aperture, since they do not serve their purpose anymore: Safari cannot browse the web, Aperture does not support my camera.
My software which I have from that time (I have purchased licenses for some) is largely dead: my favorite RSS reader does not work, chat apps are useless, downloader app is not working, some apps cannot even be activated, since servers do not exist. Archaic VLC or Quicktime do not support some modern formats, which I have music videos in.
Okay, CS4 works and old MS Office works, they are perfectly fine from that era. But a lot of stuff is simply defunct, and running it is impossible or meaningless.

I think it’s safe to assume that nobody is running ONLY a PowerPC Mac in 2025. Even those of us that have been using PowerPC systems for decades no longer view them as our primary devices and no amount of modern software will change that.

Meaning is subjective. Running old software is just as meaningful as using an old Mac to a lot of people. Running Snow Leopard which was denied to PowerPC users is meaningful to a lot of people. Doesn’t mean it will be the most useful, but as we are a hobby community predominantly, usefulness in of itself is relative.

We are doing this because we can, because it’s fun and because it makes people smile. That’s what motivates me anyway.

What is your interest @barracuda156? What drives you to spend so much of your time and effort battling upstream to support our old systems? What is the driving force behind your efforts with MacPorts for PowerPC and what is it about Snow Leopard on PowerPC that interests you? I remember you said you needed R for a project ages ago but otherwise i don’t know. Do you ‘daily drive’ PowerPC? Are old macs the predominant available platform where you live or work? I’m curious about your motivations because you seem to spend a lot of time working on PowerPC mac platform support (which is great for us) but i have no idea why. You also seem to have a lot of time to do this as well which is something i am extremely envious of 😂

 

[barracuda156]

Networking is still the number one complaint from non-devs and after watching the latest video on YouTube it seems that information about GPU support isn’t clear.

Well, I won’t argue against networking being arguably the most important issue (and not only for regular users), it just does not invalidate any other issues of considerable importance.
Just in case, I am not saying that someone capable and willing to fix UDP should rather spend time on rebuilding Unix tools After all, I certainly cannot fix UDP myself, but I am pretty sure I can handle the toolchain.

 

[ChrisCharman]

Well, I won’t argue against networking being arguably the most important issue (and not only for regular users), it just does not invalidate any other issues of considerable importance.
Just in case, I am not saying that someone capable and willing to fix UDP should rather spend time on rebuilding Unix tools After all, I certainly cannot fix UDP myself, but I am pretty sure I can handle the toolchain.

I’m putting a table in the WikiPost for all known issues.

 

[educovas]

Three issues I can mention:

1. If some software creates users/groups, OS does not recognize those without a reboot. AFAIK, it was not the case in 10a190 on PPC or 10.6.8 on Intel. It seems that the issue is not local but exists for our 10.6.8 generally. See an example of another user getting the same error: https://forums.macrumors.com/thread...ed.2433458/page-4?post=33676844#post-33676844

2. There is an issue with the OS `dyld` handling libstdc++ symbols. Example of what I talk about and Iain’s comments on it: https://github.com/iains/darwin-xtools/issues/11

3. AHCI kexts are broken. There are no sources, AFAIK, so not sure it can be fixed, but it would be great if it is possible (perhaps binary patching is required), since it will enable to use faster SSDs via PCIe.
P. S. Someone managed to do AHCI hacking here: https://carrot.dev/2021/03/10/2021-appleahci/

all 3 seems to be problems I can't fix but good to add to a bugs list.

Networking is still the number one complaint from non-devs and after watching the latest video on YouTube it seems that information about GPU support isn’t clear.

Unfortunately I can't fix networking so I'll work on what I still can lol

I think the information included in Macintosh Garden isn't clear because they added the Nvidia PCI image I created for @barracuda156 to test and couldn't even read my comments saying that the other build is for ATI and Nvidia. This is why it's good to make everything clear in the first post.

Well, I won’t argue against networking being arguably the most important issue (and not only for regular users), it just does not invalidate any other issues of considerable importance.
Just in case, I am not saying that someone capable and willing to fix UDP should rather spend time on rebuilding Unix tools After all, I certainly cannot fix UDP myself, but I am pretty sure I can handle the toolchain.

I also can't fix UDP so I'll try to fix what I can. It took me an insane amount of time to have this OS at this point, if something isn't fixed yet is because I didn't know about it or I couldn't fix after trying for a long time.

 

[educovas]

I've created a Launch Daemon to run utdns during boot and in the background, it works surprisingly well. Unsure if it would be a good idea to include the tool already configured in the image as an easy workaround... would probably need to ask the developer though. @barracuda156 what do you think?

 

[barracuda156]

I've created a Launch Daemon to run utdns during boot and in the background, it works surprisingly well. Unsure if it would be a good idea to include the tool already configured in the image as an easy workaround... would probably need to ask the developer though. @barracuda156 what do you think?

This is what I was implying above in fact. It would be convenient to have it already available upon installation.

 

[hrutkaymods]

@educovas
Coverflow or whatever they called it in SL doesn't work on my Mid 2005 iBook G4... Haven't tested it further on my other systems yet... Some windows duplicate window action buttons That's all I've noticed so far

(been awhile since I replied on Macrumors... hit the wrong button 🤦🏻‍♂️)

 

[ChrisCharman]

@educovas
Coverflow or whatever they called it in SL doesn't work on my Mid 2005 iBook G4... Haven't tested it further on my other systems yet... Some windows duplicate window action buttons That's all I've noticed so far

(been awhile since I replied on Macrumors... hit the wrong button 🤦🏻‍♂️)

Hi Gregg!

Thanks for the video. Hope you’re having fun with your PowerPC Challenge?

Can you confirm which .dmg restore image you’re using please? There are two but only one should be used for general users, the other was created for test purposes exclusively for @barracuda156 using 10A190 frameworks. The correct image supports all GPUs that are supported by 10.5.8 as it borrows the same frameworks.

Thanks so much for the feedback. Hopefully more people will jump on board to test after learning about the project and make us aware of any other bugs that need squashing.

Keep an eye out for a new image coming soon that @educovas is putting together that will include @barracuda156’s findings regarding internet access (using UTDNS to redirect from DNS to TCP) as a workaround to provide working network access until a more permanent fix is found.

 

[ChrisCharman]

I've created a Launch Daemon to run utdns during boot and in the background, it works surprisingly well. Unsure if it would be a good idea to include the tool already configured in the image as an easy workaround... would probably need to ask the developer though. @barracuda156 what do you think?

This is what I was implying above in fact. It would be convenient to have it already available upon installation.

I think to enable further testing and feedback from users this is probably wise as a working solution until we find a permanent fix, provided the open source license terms for UTDNS are acknowledged.

 

[educovas]

@educovas
Coverflow or whatever they called it in SL doesn't work on my Mid 2005 iBook G4... Haven't tested it further on my other systems yet... Some windows duplicate window action buttons That's all I've noticed so far

(been awhile since I replied on Macrumors... hit the wrong button 🤦🏻‍♂️)

CoverFlow is a know problem and it's a side effect of using Finder from 10.5.8. I noticed the duplicated window buttons on the Firefox based browsers and it also happened when I ran one of them on an Intel machine through rosetta so it's don't think it's a bug from 10.6.8 ppc.

I included a small bug list on my first post about 10.6.8: https://forums.macrumors.com/threads/snow-leopard-on-unsupported-powerpc-macs.2232031/post-33461479

 

[educovas]

I think to enable further testing and feedback from users this is probably wise as a working solution until we find a permanent fix, provided the open source license terms for UTDNS are acknowledged.

utdns seems to work very well, just would still have to insert the IPs manually since DHCP is still broken. I'll take a look at NTP and file sharing because both are not working. Hopefully I'll upload a new image in a couple days.

 

[ChrisCharman]

Spoiler: “Bugs, Fixes and Workarounds…”

I’ve created a table and added these issues to the wikipost.