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

10.6 Snow Leopard PowerPC Development

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.

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?

  • Yes - The original thread is for the developer previews and all this dev jargon is derailing it!

    Votes: 1 6.7%

  • Yes - I would like to be able to follow and/or contribute to a 10.6.8/Xcode thread specifically

    Votes: 8 53.3%

  • Yes - I would like to be able to follow and/or contribute to a Developer Preview thread specifically

    Votes: 0 0.0%

  • Indifferent - I don't care either way i just appreciate the work that's being done

    Votes: 0 0.0%

  • No - The thread is already for Snow Leopard on PowerPC and all discussion is welcome and relevant

    Votes: 6 40.0%
  • Total voters
    15
  • Poll closed .
ChrisCharman

ChrisCharman

macrumors 6502a
Original poster
May 10, 2020
644
755
Bournemouth, UK
F1B7C31C-F3FC-435E-957D-D10E0EFBE18F.jpeg


Welcome to the Mac OS X 10.6 Snow Leopard on PowerPC - Development Thread​

The purpose of this thread is for the ongoing technical discussion, communication and collaborative efforts to develop and rebuild OS X 10.6.8 Snow Leopard and accompanying Xcode Development Tools for the PowerPC Mac Platform.

IMG_4093.jpeg


We have now reached a stage where a work in progress community created image (alpha testing version 5) of 10.6.8 is available, currently using 'donor parts' from Developer Build 10A190 and 10.5.8 Leopard, and system components built from the Apple Open Source Projects and Releases, which has been made available as an easy to restore disk image.

IMG_3071.png


…

MOST RECENT UPDATES TO 10.6.8 on PowerPC…​

educovas said:
There were some binaries I missed that didn't have ppc slices and exist in 10.5.8/10A190 or were outdated so I've updated the image once again to include the changes.

/usr/share/sandbox/krb5kdc.sb removed the allow system-socket line
Restored 10.6.8 SystemProfiler’s panes with ppc slice
Restored System Configuration bundles from 10.6.8

/Library/Application Support/iLifeMediaBrowser from 10.5.8
System/Library/PrivateFrameworks/BrowserKit.framework from 10.5.8
System/Library/PrivateFrameworks/ProKit.framework from 10A190
System/Library/PrivateFrameworks/Safari.framework from 10.5.8
System/Library/PrivateFrameworks/SystemMigration.framework/Frameworks/SlingShot+10_6.framework from 10.5.8
System/Library/PrivateFrameworks/XgridInterface.framework from 10A190
System/Library/PrivateFrameworks/MobileDevice.framework from iTunes 10.6.3
System/Library/PrivateFrameworks/AirTrafficHost.framework from iTunes 10.6.3
System/Library/PrivateFrameworks/DeviceLink.framework from iTunes 10.6.3
/System/Library/Extensions/AppleMobileDevice.kext from iTunes 10.6.3
/System/Library/Extensions/AppleUSBEthernetHost.kext from iTunes 10.6.3
Click to expand...
educovas said:
Changes in the new image:

- utdns already included and using google's DNS 8.8.8.8
- tiff2icns replaced with the one from 10.5.8
- fixed Core Text's cursor
- graphics acceleration wrappers have been rebuilt with the correct version

In order to get internet connection, the IP address, subnet mask and router have to be manually inserter since DHCP is still broken. The DNS server has to be set to 127.0.0.1.

Just to remind again: this image should work with all GPUs that were supported in 10.5.8, including Nvidia. To avoid confusion again, I won't be updating the image I built for @barracuda156.
Click to expand...
ChrisCharman said:
@educovas Quick update:

I have restored internet functionality without depending on an additional third party DNS to TCP application. As i suspected previously, there is an issue with Kerboros. If you update the system using MIT Kerboros Extras (and update the intel CUPS binaries) it fixes the issue that is blocking network connectivity.
Click to expand...
ChrisCharman said:
I have now downloaded, modified and updated the latest image (alpha 4) created by @educovas and replicated my previous fix (tested with alpha 3).
Click to expand...
ChrisCharman said:
I have also added a few other updates.

The latest alpha testing version 5 image has the following new changes:

  1. utDNS and the launchdaemon have been removed
  2. A number of missed cups binaries and other executables that were still intel only have been replaced with the ones from 10.5.8 in /usr, /sbin, /usr/bin, /usr/sbin, /usr/libexec and /usr/share
  3. /usr/include folder restored
  4. Various unix permissions errors in kexts and base system binaries corrected
  5. Kerboros Extras and configuration files pre-installed as default
  6. Intel Kerboros Apps replaced with 10.5.8 versions
  7. AppleScript Apps in CoreServices replaced with PowerPC versions
  8. System Image size reduced by removing all architectures other than PowerPC from system binaries
  9. TextEdit app updated
  10. Airport Utility app updated
  11. Front Row app updated
  12. ATi Radeon drivers updated to include ROM extender
  13. NTFS Kext replaced to rectify missing copyright string issue
  14. IOAHCIFamily and AppleAHCI kexts replaced with more recent versions from 10.5.8 further update can be obtained by installing PerformanceUpdateHardware.zip
I’ve also accidentally left interwebppc in the applications folder, and a few user preferences.

*DHCP should function correctly. In order to get internet connection, the IP address, subnet mask and router address might still need to be entered into network preferences on some systems, but otherwise should auto configure. Cloudflare 1.1.1.1, 1.0.0.1 and Google 8.8.8.8 DNS servers can also be added via the network prefpane in System Preferences if required.

This image should continue to work with all GPUs that were supported in 10.5.8, including Nvidia.

To avoid having too many different disk images floating around the web and reduce bandwidth usage for the end user, we will be moving to delta updates provided as packages soon, now that internet access is resolved in 10.6.8 PowerPC.

The restore image for 10.6.8_PPC Alpha Version 5 is linked in the ‘DOWNLOADS’ section of the wikipost.
Click to expand...
ChrisCharman said:
New image: 10.6.8_PPC_A5

If using an earlier image, a number of binaries and files must be replaced with PowerPC versions either built from source or directly from 10.5.8. It is recommended to use the latest restore image. It is better and easier to transfer user files and applications than to modify older images to bring them up-to-date.
Click to expand...
Click to expand...

​

! WARNING !​


The software discussed in this thread is experimental and may be unstable. Please be aware that you will not be able to revert back to your previous system if you erase your primary OS drive or partition - proceed with caution. Please install this software on a system you are prepared to erase if necessary.​

IMG_4299.png

​

DOWNLOADS​


FileHyperlinkDescriptionStatus
Mac OS X 10.6.8 Restore ImageMegaUpload
(Alpha 4)
Macintosh Garden
(Alpha 5)
Google Drive
(Alpha 5)		Full restore image of Mac OS X Snow Leopard 10.6.8 for PowerPCAlpha Testing: Version 5
XCode 3.2.6
(Intel)		Apple Developer DownloadsRelease 10M25XX 06/03/2011 Mac OS X 10.6.4+Release
XCode 3.2.6
(ppc)		WIP
DarwinBuildDarwinBuild GitHub
macos-powerpc.org		Darwinbuild is a collection of tools that assist compilation of the many projects contained in Darwin, the open source base of Apple's macOS operating system.Prebuilt port via @barracuda156
With various patches and broken sourceforge links redirected to allow Apple Open Source Projects to be built easily
UTdnsmacos-powerpc.org
UTdns GitHub		UTdns is a nifty tool which proxies all UDP-based DNS requests through TCP DNS. This is usefull if you have to tunnel DNS through TCP-only tunnelsPrebuilt port available via @barracuda156 to workaround current networking issues
IP address, subnet mask and router have to be manually inserted, since DHCP is still broken.
The DNS server has to be set to 127.0.0.1
MIT Kerboros ExtrasKerboros Extras.dmg**While Mac OS X ships with most parts of Kerberos for Macintosh, it does not include support for CFM-based Kerberos-using applications (such as Oracle Calendar), and the GUI Kerberos management application is in a hard-to-find location.
The Mac OS X Kerberos Extras installer will install the Kerberos CFM support library and make an alias to the GUI Kerberos Management application in /Applications/Utilities (the Kerberos application ships in /System/Library/CoreSevices ).
By default the installer will also install an MIT configuration file (edu.mit.Kerberos) if one does not already exist, or you can choose a custom install to force install a new (MIT-based) configuration file.
In addition the Mac OS X 10.6 (Snow Leopard) Kerberos Extras will also modify your ssh configuration to allow the use of Kerberos by default. Apple disabled Kerberized ssh in 10.4.9 (Tiger) by default to solve performance problems on networks without DNS.		Testing for inclusion in next build @ChrisCharman

INSTALLATION​

IMPORTANT: Always back-up your system before installing any operating system.


A. Install Snow Leopard using hard disk partitions:


REQUIREMENTS:

PowerPC G4 or G5 based system

Two hard disk partitions internal or external (or 2 separate drives)

Hard disk partitions setup:

Partition 1 - 10.5.8 System Containing the downloaded Snow Leopard disk image on the internal drive, or on a connected external USB/Firewire device. (Alternatively, 10a190 can also be used.)

Partition 2 - Restore the disk image onto this partition (IMPORTANT: All data on this partition will be erased!)

PROCEDURE:

1. Boot off partition 1 then, using Disk Utility, select ‘Scan image for restore’ and then restore the Snow Leopard Disk Image onto partition 2 using the ‘erase & restore’ and ‘block copy’ options.

2. Select partition 2 as the boot device and boot into Snow Leopard to complete the setup process.

Note: Use System Preferences > Startup Disk in 10.5.8 Leopard to pick startup volume or hold down the ‘Option (⌥) or Alt’ key when powering on the system to select a boot volume using the Boot picker.

TEST & DEBUG TOOLS​

​
ToolHyperlinkDescription
psx…An extended ps-like command which can display detailed information about processes and threads in OS X. The tool requires no special permissions if when viewing processes owned by the user, but will require root permissions otherwise. This tool is free and open source.
JtoolDownloadWhile for most binary functions one can use the OS X built-in otool, it leaves out useful information when
analysing the data section.
Jtool improves on otool, by addressing the
shortcomings of otool, and offers useful new features for static binary analysis. The tool has many useful features, like finding references in files and limited disassembly functionality. The tool is freeware but is closed source.
lsockDownloadThe functionality of netstat -o,
which shows the processes owning the system sockets is missing in OS X.
The tool uses an undocumented kernel control protocol called com.apple
.network.statistics to obtain real-time notifi cations of sockets as they are created.
This tool is
easy to incorporate into scripts, which makes it useful as a connection event handler.
BatchMod…BatchMod allows you full control over permissions within a simple and easy to use GUI.

​

GDB		…GDB, the GNU Project debugger, allows you to see what is going on `inside' another program while it executes -- or what another program was doing at the moment it crashed.

KNOWN ISSUES​

Issue DescriptionReported by UserFixed (Y/N)Workaround
AHCI kexts are broken for PowerPC@barracuda156NoAHCI Kexts from 10.5.8 are more recent. The 10A190 versions have been replaced in 10.6.8_A5. A further update can be obtained from by installing PerformanceUpdateHardware.zip
OS `dyld` handling libstdc++ symbols@barracuda156No
Software created users/groups not recognised by OS without reboot@barracuda156No
Networking - unable to access the internet (Ethernet and Wifi)
&
Self-assigned IP		@educovas
Known issue with all builds from 10A432 to current 10.6.8 testing builds
@ChrisCharman has identified a potential Kerboros issue which is blocking connections to port 80 and has tested Kerboros Extras package which restores full networking access without depending on an additional third party application. This fixes internet connectivity.		Yes@barracuda156 reported that after installing UTDNS they have internet working on 10.6.8 (UDP still broken as it was, and therefore no DHCP, but DNS is working over TCP, so browsing works, curl works etc.).
P. S. Pre-compiled utility: http://macos-powerpc.org/packages/utdns(you do not need MacPorts for this, it has 0 dependencies).
Or compile from source from: https://github.com/rahra/utdns
Graphics Acceleration Support for Ati & Nvidia
GPUs		@educovas
(Carried over from 10A190)		Yes@educovas has patched the image with 10.5.8 frameworks. All GPUs (ATi and Nvidia) that are compatible with Leopard should work on 10.6.8. Ensure you are using the correct .dmg and not the modified 10A190 compatible version created specifically for @barracuda156for testing purposes.
Sleep issues@educovasNoDisable Sleep
QuickLook partially broken@educovasNo
Bluetooth won’t find devices@educovasNo
Finder CoverFlow frozen/glitchy@educovasNo
Spotlight indexing doesn’t work@educovasNo
Microsoft NTFS Filesystem - no Read/Write access@jktwiceYesntfs.kext wasn't loading due to a missing copyright string. It should now work using the kext attached.
NTFS.kext (fixed)
Multiple third party apps are denied write access to files owned by root, even after being authorised with a root password@barracuda156No

APPLE OPEN SOURCE RELEASES 1068​



REFERENCE & DOCUMENTATION​

​

THIRD PARTY SOFTWARE SUPPORT​



For third party software support (software not integral to the OS or integrated apple tools) and MacPorts on 10.6 PowerPC please contact @barracuda156 on the appropriate threads.
C912134B-7399-456F-9894-3A51A1629EB1.jpeg

IMG_4433.png

IMG_4420.png

DISCLAIMER​

THE BETA SOFTWARE HEREUNDER IS KNOWN TO CONTAIN DEFECTS AND THE PRIMARY PURPOSE OF THIS BETA TESTING IS TO OBTAIN FEEDBACK ON SOFTWARE PERFORMANCE AND THE IDENTIFICATION OF FURTHER DEFECTS. USERS ARE ADVISED TO SAFEGUARD IMPORTANT DATA, TO USE CAUTION AND NOT TO RELY IN ANY WAY ON THE CORRECT FUNCTIONING OR PERFORMANCE OF THE SOFTWARE AND/OR ACCOMPANYING INFORMATION AND MATERIALS CONTAINED IN THIS THREAD .

ALL SOFTWARE MADE AVAILABLE FOR DOWNLOAD IS STILL IN THE TESTING PHASE AND IS PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS. ANY DAMAGES OR LOSSES INCURRED BY THE USER ARE THE SOLE RESPONSIBILITY OF THE USER. THE USER ACCEPTS NO WARRANTY OR GUARANTEE OF ANY KIND IS PROVIDED WITH THIS SOFTWARE.
 

Attachments

  • IMG_3069.jpeg
    IMG_3069.jpeg
    307.4 KB · Views: 345
  • IMG_3072.png
    IMG_3072.png
    1.1 MB · Views: 290
  • IMG_1345.jpeg
    IMG_1345.jpeg
    432.1 KB · Views: 299
  • IMG_2077.jpeg
    IMG_2077.jpeg
    995.3 KB · Views: 309
  • IMG_3084.png
    IMG_3084.png
    1.1 MB · Views: 281
  • IMG_3081.png
    IMG_3081.png
    849.2 KB · Views: 292
Last edited:
  • Love
  • Like
Reactions: SirGatez, NikolaPPC, Project Alice and 1 other person
BB281C6A-6F08-4033-B73C-C937C214B991.jpeg


About Snow Leopard on PowerPC …

In March of 2020, @Larsvonhier read a tweet by @system2048, who posted a screenshot of Snow Leopard running on a PowerPC Mac. It was one of the early 2008 Developer Previews of Mac OS X Snow Leopard.

IMG_4273.jpeg


On 21st April 2020 @Larsvonhier created the thread ‘Snow Leopard On Unsupported PowerPC Macs’.

Ever since that time, efforts to get Snow Leopard working on PowerPC systems have been ongoing and continued to be documented Here.

Special mention and thanks to Julian Fairfax and @parrotgeek1. 10.6 PPC.sh was a script shared by Julian Fairfax, based on an outline from @parrotgeek1 that allowed the first community members to begin tinkering with Snow Leopard on PowerPC.

IMG_4275.png


What started out as an effort to explore, document and update a number of the available Snow Leopard Developer Previews that, when patched, are able to boot on PowerPC systems has continued over the years. These modifications were initially relatively easy to follow in the beginning but have grown more complex as time has passed.

Further development requires a lot of 'developer talk' and low-level discussion that is less easy to comprehend and follow for the average user.

As this type of post has been objected to in the past, by a few users on the other thread, the question was asked of the community...

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?​


The poll results were divided, but the majority voted for a dedicated development thread.

On 26th April 2020 @vddrnnr began to test swapping components from Tiger and Leopard into 10A096. Following on from the step-by-step process outlined by @vddrnnr, this work was continued and rigorously tested and documented by @B S Magnet for build 10A096.

On 27th April 2020 @wicknix suggested that a restore image be created for the average user to be able to download and experience these early developer previews without having to perform modifications themselves.

@Larsvonhier created a table in the wikipost detailing kexts in 10.5.8 that reported as more recent than those found in 10A096 along with initial results of the testing of which could be transplanted.

On 29th April 2020 as further developer previews were being unearthed, in part due to @ASentientBot uploading them to the internet archive, @Larsvonhier requested that all found builds be shared on the thread, and would be added to the wikipost.

@jimjamyaha continued to report findings on kext versions and binary architectures across all discovered and shared builds.

@weckart confirmed that build 10A190 successfully installed on PowerPC using the same BootX and Kexts borrowed from Leopard for 10A096.

@vddrnnr identified that certain cups binaries copied from Leopard would fix some system issues.

On May 1st 2020 @Larsvonhier detailed the Kernel build numbers for 10A096-10A222 and attempted to get build 10A222 to boot on PowerPC using all 10A190 kexts.

It was here that it was first suggested that perhaps the right combination of components from different builds may be the way forward to getting 10A222, and later builds, functional on PowerPC.

On May 3rd 2020 @Larsvonhier provided
the first pre-installed image of Build 10A190. This disk image brought attention to the project and was featured on popular community forums, websites and YouTube channels such as Action Retro, with his ‘Impossible Cat’ videos.

It was at this time that @vddrnnr compiled the first project using the Xcode 3.2 beta, and demonstrated that some PowerPC functionality remained. This opened up the door for potentially bringing more recent third party software to PowerPC users that may not be possible if running Leopard.

May 13th 2020 @ChrisCharman joined the forum after following along, downloading all available images and ISOs and stated his intention to begin building system components from Apple Open Source Projects.

May 17th 2020 @ChrisCharman provided the developer preview seed notes for 10A190.

May 18th 2020 @vddrnnr discovered and shared a partial fix for graphics (no hardware acceleration but fixes ‘blocky images’ issue) using framework components from Leopard.

May 20th 2020 in response to a suggestion, that Snow Leopard on PowerPC be given a name, @Larsvonhier made the point that there was no need, that universal builds had always been named the same by Apple and that even classifying the builds as hybrid builds would be undesirable given that, as a community, we do not do this with Catalina/Mojave et al on unsupported machines simply because they borrow components from an earlier OS - Snow Leopard on PowerPC or SL_PPC should be enough to distinguish it from intel Snow Leopard.

May 21st 2020 @Larsvonhier predicts that at some point the project may split…one path ‘pimping’ 10A096 with components from Leopard and another upgrading 10A190/10A222 with updated ‘ingredients’.

View attachment 2438312

On May 22nd 2020 @ChrisCharman
confirmed that building a more up-to-date toolchain, by using the bundled Xcode command-line tools, it was possible to compile system components from Apple Open Source Projects and that those updates would successfully restore some functionality to build 10A190 and potentially to later builds. @ChrisCharman then continued to build on this hypothesis, working through AOSP one-by-one, with an aim to replace as much of the base system as possible to match the retail release of Snow Leopard, but this time with full PowerPC compatibility.

View attachment 2438344View attachment 2438345


On April 20th 2024 @educovas shared a hardware graphics acceleration patch using the @ASentientBot stubber tool which uses nm to compare the 10.6 and 10.5.8 binaries, identifies the missing newer functions and generates the stubs. These stubs were combined with components from 10.5.8 Leopard to fix the graphical issues on the early developer previews.


View attachment 2438337

On April 28th 2024 @educovas provided a modified version of Developer Build 10A222. This build was made possible using PowerPC components from 10A190 and compiling from some Apple Open Source Projects.

As the source code for build 10A222 is not publicly available, this disk image depended on the 10.6.0d3 included kernel and was incompatible with some PowerPC systems, particularly G5’s, including some G4 machines.

@ChrisCharman was able to confirm that replacing the kernel with the debug version would allow the system to function on a greater number of G4 models, indicating that something had become incompatible or stripped for PowerPC in the stock 10A222 kernel.

May 13th-15th 2024

@educovas shared that they had successfully managed to get to a functional desktop with a newly compiled 10A432 release kernel, which was built from AOSP Xnu along with:

file
notifyd
Securityd
kext_tools
DirectoryService
autofs
xnu

View attachment 2438590

The UI was mostly fixed, all apps were taken from older PowerPC compatible builds (mostly the same files taken from 10A190 and 10.5.8 to get 10A222 working) and what was compatible from the 10.6.1(10B504) update was also applied. This was a relatively small update provided by Apple originally and still very similar to GM(10A432). Of note; libSystem, some frameworks and IOSCSIArchitectureModelFamily kext were still compatible with PowerPC.

WiFi and Bluetooth were no longer functioning however. WiFi would connect but access to the internet was apparently not possible (Self-Assigned IP error). The same applied to a direct Ethernet connection.

View attachment 2438591

Without access to the internet @educovas felt that the wall had finally been hit.

@educovas shared a zipped folder with all replaced files and instructions on what needed to be changed in the XNU sources to build the 10A432 kernel.

Though an image was never shared of this build on the thread, @ChrisCharman later followed the XNU code changed and was able to confirm a successful build of the 10A432 kernel for PowerPC.

This thread is exclusively for discussing and sharing technical developments on Mac OS X 10.6 for the PowerPC G4 and G5 architectures i.e The OS itself, Xcode/Darwin toolchains, Apple Open Source Projects/Releases and for user feedback on bugs, fixes and hardware compatibility issues found when testing the builds provided here.

For information on third party software such as MacPorts, please follow the links in the WikiPost to the correct threads.
 
Last edited:
  • Like
Reactions: SirGatez
IMG_4486.jpeg

IMG_4538.jpeg

IMG_4421.jpeg

IMG_3924.jpeg

IMG_4422.png

508495D2-69F8-4729-9E23-5AB5282DFFC8.jpeg

Open Source Projects & Software included in Mac OS X​

The Mac OS operating system is built on a foundation of open source software and proprietary Apple components on top. There are over 400 Open Source projects implemented in the OS and Developer tools, some are used ‘as is’ from third party developers, others are modified with source changes released in line with the licensing terms of the package and others created and released by Apple themselves under the Apple Open Source License.

The source tree for OS X 10.6.8 can be found in the WikiPost.

Behind the spoiler below is a table of Open Source Projects included in OS X, including version numbers and a listing of where in the Operating System they are implemented:

ComponentProjectVersionUsed In
AddressBookMetakit2.4.9.2Mac OS X, Xcode Tools
AirPortFamilywpa_supplicant0.3.9Mac OS X
AKCmdsLibTIFF3.8.2Mac OS X, Xcode Tools
amavisdamavisd-newamavisd-new-2.5.1Mac OS X
apacheapache2.2.11Mac OS X, Xcode Tools
apache_mod_fastcgimod_fastcgi2.4.2Mac OS X
apache_mod_perlmod_perl2.0.4Mac OS X, Xcode Tools
apache_mod_phpphp5.3.0Mac OS X, Xcode Tools
libpng1.2.37-
libjpeg6b-
apache_mod_scgi_pubsubmod_scgi_pubsub1.11-pubsubMac OS X
Apple_Gutenprint_PrinterSupportgutenprint5.2.3Mac OS X, Printing
AppleShareClientLibopenssl0.9.1cMac OS X, Xcode Tools
aprapr1.3.5Mac OS X, Xcode Tools
apr-util1.3.7-
autoconfautoconf2.61Xcode Tools
automakeautomake1.10Xcode Tools
awkawkOctober 23, 2007Mac OS X
AxisAxis1.4Server
bashbash3.2Mac OS X
bcbc1.06Mac OS X
BerkeleyDBBerkeleyDB4.6.21Mac OS X, Server
bind9bind99.6.0-P1Mac OS X
bisonbison2.3Xcode Tools
bsdiffbsdiff4.3Mac OS X
bsdmakebsdmake2006-04-12Xcode Tools
bsdmake-mk2005-10-18-
bzip2bzip21.0.5Mac OS X, Xcode Tools
cctoolsgas1.38.1Mac OS X, Xcode Tools
ChatServergettext0.16.1Server
glib2.16.6-
Jabber2.1.24.1-
libidn0.6.14-
mu-conference0.8.0-
Proxy651.1.1-
Chesssjeng11.2Mac OS X
clamavclamavclamav 0.95.2Server
clangclang090120Xcode Tools
llvm090120-
CommonCryptoopensslopenssl-0.9.6Mac OS X, Xcode Tools
Gladman AESaes-src-26-08-05-
Gladman SHA2sha-26-08-05-
croncron2007-02-15Mac OS X
cupsCUPS1.4.0 (r8750)Mac OS X
curlcurl7.19.4Mac OS X, Xcode Tools
cvscvs1.12.13Xcode Tools
cxxfiltbinutils070207Mac OS X
CyrusIMAPCyrus IMAP Servercyrus_imap_2.3.8Server
DataDetectorsCoreInternational Components for Unicode3.6Mac OS X
diffstatdiffstat1.41Mac OS X
distccdistcc2.18.5Xcode Tools
doc_cmdschecknr2004-09-18Mac OS X
colcrt2004-09-18-
getNAME2004-09-18-
makewhatis2004-09-18-
DSPasswordServerFrameworkOpenSSH3.8.1p1Mac OS X
dtraceDTraceon-src-20060828Mac OS X, Xcode Tools
efaxefax0.9a-001114Mac OS X
emacsEmacs22.1Mac OS X
enscriptenscript1.6.4Mac OS X
expatexpat2.0.1Mac OS X, Xcode Tools
FastCGIfcgi2.4.0Mac OS X, Xcode Tools
ruby-fcgi0.8.7-
fetchmailfetchmail6.3.8Mac OS X
filefile5.00Mac OS X
FileSynclookup3n/aMac OS X
flexflex2.5.35Xcode Tools
freeradiusfreeradius2.1.3Server, Xcode Tools
FTPServerwu-ftpd2.4.2b17Server
gdbgdb6.3.50-20050815Xcode Tools
glibtoolglibtool2.2.4Mac OS X, Xcode Tools
gm4m41.4.6Xcode Tools
gnudiffdiffutils2.8.1Mac OS X
gnumakemake3.81Xcode Tools
gnuservgnuserv3.12.4Mac OS X
gnutartar1.17Mac OS X
gnuzipgzip1.3.12Mac OS X
gperfgperf3.0.3Xcode Tools
gptgptRELENG_6_2_0_RELEASEMac OS X
grepgrep2.5.1Mac OS X
groffgroff1.19.2Mac OS X
hunspellhunspell1.2.8Mac OS X
sjp.pl20080831-
ICUInternational Components for Unicode4.0Mac OS X
ImageIOgiflibgiflib-4.1.6Mac OS X, Xcode Tools
libJP2libJP2-5.1-
libjpeglibjpeg-6b-
libOpenEXR-1.4.0a-
libRadiance-
libtifflibTIFF-3.8.2-
InternetServicesSupportexpat1.95.5Mac OS X
iodbciodbc3.52.6Mac OS X, Xcode Tools
ipsecracoon0.6.7Mac OS X
libipsec0.6.5-
setkey0.6.5-
racoonctl0.6.5-
JavaToolsAnt1.7Mac OS X, Xcode Tools
JUnit4.1-
Maven2.0.5-
Derby10.4.2.0-
KerberosLibrariesKerberosKfM-6.5fc1Mac OS X, Xcode Tools
kshksh2007-11-05Mac OS X
ksh2007-11-05-
lessless418Mac OS X
libarchivelibarchive2.6.2Mac OS X
Libcpp_kextGCC4.2.1Xcode Tools
libeditlibedit2.11Mac OS X, Xcode Tools
libeventlibevent1.4.4Mac OS X
libiconvlibiconv1.11Mac OS X, Xcode Tools
libpcaplibpcap1.0.0Mac OS X, Xcode Tools
libstdcxxgcc4.2.1Mac OS X, Xcode Tools
libstdcxx_40gcc4.0.0Xcode Tools
libutillibutil2005-02-13Mac OS X
libutil1.3-
libxml2libxml22.7.3Mac OS X, Xcode Tools
libxsltlibxslt1.1.24Mac OS X, Xcode Tools
lsoflsof4.82Mac OS X
lukemftplukemftp20070806Mac OS X
lukemftpdtnftpd20080929Mac OS X
mailmanmailmanmailman 2.1.12rc1Server
manman1.6cMac OS X
MeCabMeCab0.95Mac OS X, Xcode Tools
memcachedmemcached1.2.8Mac OS X
MeshKitFCollada3.05BMac OS X
MySQLMySQL5.0.82Server
nanonano2.0.6Mac OS X
nasmnasm0.98.40Xcode Tools
ncursesncurses5.5Mac OS X, Xcode Tools
neonneon0.28.3Mac OS X
net_snmpnet-snmp5.4.1Mac OS X, Xcode Tools
netcatncHEADMac OS X
NotificationServeridavoll0.7.3Mac OS X
wokkel0.3.1-
ntpntp4.2.4p4Mac OS X
OpenALOpenAL1.1Mac OS X, Xcode Tools
OpenBSMopenbsm1.1Mac OS X, Xcode Tools
OpenLDAPOpenLDAP2.4.11Mac OS X
NetBSD-
NetBSD-
openmpiopenmpi1.2.8Mac OS X, Xcode Tools
OpenPAMOpenPAM20071221Mac OS X, Xcode Tools
OpenSSHOpenSSH5.2p1Mac OS X
OpenSSL096OpenSSL0960.9.6lMac OS X
OpenSSL097OpenSSL0.9.7lMac OS X
OpenSSL098OpenSSL0.9.8jMac OS X, Xcode Tools
passwordserver_saslpasswordserver_sasl2.1.22Mac OS X
patch_cmdspatch2.5.8Mac OS X
pcrepcre7.8Mac OS X
perlperl5.10.0Mac OS X, Xcode Tools
perl5.8.9-
PodcastProducerClientCFrameworks3.0.5Mac OS X
portmapportmap2001-04-25Mac OS X
postfixPostfixpostfix-2.4.3Mac OS X, Server
procmailprocmail3.22Mac OS X
pyobjcpyobjctrunk-20090623Mac OS X, Xcode Tools
pyOpenSSLpyOpenSSL0.7Mac OS X
PyRSS2GenPyRSS2Gen1.0.0Mac OS X
pythonpython2.6Mac OS X, Xcode Tools
python2.5.4-
python_dateutilpython_dateutil1.2Mac OS X
python_modulesaltgraph0.6.8Mac OS X, Xcode Tools
bdist_mpkg0.4.3-
bonjour-py0.3-
macholib1.2.1.dev-r432-
modulegraph0.7.2.dev-r439-
numpy1.2.1-
py2app0.4.2-
setuptools0.6c9-
xattr0.5-
Quartz2DLibTIFF3.8.2Mac OS X, Xcode Tools
rcsrcs5.7Xcode Tools
RemoteDesktopkeysymdef.h1.4Mac OS X
Brian Gladman's Rijndael Implementation1.0-
AGRegex0.3-
VNC Reflector1.2.4-
MAPKIT1.4-
PCRE4.0-
JPEG Library6b-
removefilesrm1.2.8Mac OS X, Xcode Tools
rsyncrsync2.6.9Mac OS X
rubyruby1.8.7-p72Mac OS X, Xcode Tools
ruby_dnssdruby_dnssd0.6.0Mac OS X
ruby_libxmllibxml-ruby1.1.2Mac OS X
RubyCocoaRubyCocoa0.13.1Mac OS X, Xcode Tools
RubyNode0.1.3-
RubyGemsRubyGems1.3.1Mac OS X
RubyOnRailsacts_as_ferret0.4.3Mac OS X
capistrano2.5.2-
cgi_multipart_eof_fix2.5.0-
daemons1.0.10-
fastthread1.0.1-
ferret0.11.6-
gem_plugin0.2.3-
highline1.5.0-
hpricot0.6.164-
mongrel1.1.5-
needle1.3.0-
net-scp1.0.1-
net-sftp1.1.1-
net-sftp2.0.1-
net-ssh1.1.4-
net-ssh2.0.4-
net-ssh-gateway1.0.0-
rake0.8.3-
RedCloth4.1.1-
ruby-openid2.1.2-
sqlite3-ruby1.2.4-
termios0.9.4-
xmpp4r0.4-
actionmailer1.3.6-
actionpack1.13.6-
actionwebservice1.2.6-
activerecord1.15.6-
activesupport1.4.4-
rails1.2.6-
actionmailer2.2.2-
actionpack2.2.2-
activerecord2.2.2-
activeresource2.2.2-
activesupport2.2.2-
rails2.2.2-
sambasamba3.0.28aMac OS X
Sandboxtinyscheme1.38Mac OS X
screenscreen4.0.3Mac OS X
ScreenSharingkeysymdef.h1.4Mac OS X
Brian Gladman's Rijndael Implementation1.0-
VNC Reflector1.2.4-
JPEG Library6b-
SmartcardCCIDccid1.3.8Mac OS X
smbsmbfs1.3.6Mac OS X
mlrpconnv_89-
SpotlightSQLite3.1.3Mac OS X, Xcode Tools
SQLiteSQLite3.6.12Mac OS X, Xcode Tools
SquirrelMailSquirrelMail1.4.17Server
srmsrm1.2.8Mac OS X
subversionsubversion1.6.2Mac OS X, Xcode Tools
sudosudo1.7.0Mac OS X
svkSVKv2.2.1Xcode Tools
SVN-Dump0.04-
SVN-Mirror0.75-
swigswig1.3.31Mac OS X, Xcode Tools
tcltcl8.5.7Mac OS X, Xcode Tools
tk8.5.7-
tcl848.4.19-
tk848.4.19-
bwidget1.8.0-
expect5.44.1.11-
incrtcl3.4-
iwidgets4.0.2-
memchan2.2.1-
mk4tcl2.4.9.7-
tcllib1.11.1-
tclsoap1.6.7-
tclvfs1.4-
tclx8.4-
tclxml2.6-
tcldom2.6-
tclxslt2.6-
tdom0.8.3-
thread2.6.5-
tkcon2.5-
tkimg1.4-
tklib0.4.1.0-
tktable2.10-
tktreectrl2.2.8-
tls1.6-
trf2.1.3-
xotcl1.6.2-
quicktimetcl3.2-
snack2.2.10-
tclresource1.1.2-
tclae2.0.3-
tclapplescript1.0-
tcp_wrapperstcp_wrappers7.6-ipv6.4Mac OS X, Xcode Tools
tcpdumptcpdump4.0.0Mac OS X
tcshtcsh6.15.00Mac OS X
texi2htmltexi2html1.70Mac OS X
texinfotexinfo4.8Mac OS X
text_cmdsbanner2005-09-16Mac OS X
cat2005-09-16-
cksum2005-09-16-
col2005-09-16-
colrm2005-09-16-
column2006-09-19-
comm2005-09-16-
csplit2005-09-16-
cut2005-09-16-
ed2005-09-16-
expand2005-09-16-
fmt2005-09-16-
fold2005-09-16-
head2005-09-16-
join2005-09-16-
lam2005-09-16-
look2005-09-16-
md52005-09-16-
nl2005-09-16-
paste2005-09-16-
pr2005-09-16-
rev2005-09-16-
rs2005-09-16-
sed2005-09-16-
coreutils/sortcoreutils-5.93-
split2005-09-16-
tail2005-09-16-
tr2005-09-16-
ul2005-09-16-
unexpand2005-09-16-
uniq2005-09-16-
unvis2005-09-16-
vis2005-09-16-
wc2005-09-16-
tidytidy2006.11.1Mac OS X, Xcode Tools
TomcatTomcat6.0.18Server
TwistedTwisted8.2.0Mac OS X, Xcode Tools
uucpuucp1.07Mac OS X
vimvim7.2.108Mac OS X
vim7.2-
WebServerAdditionsmod_bw0.8Server
mod_encoding220021209-
mod_jk1.2.28-
mod_python3.3.1-
mod_xsendfile0.9-
WikiServerelementtree1.2.6-20050316Server
zanshin0.6b1-
bonjour-py0.2-
WikiServerUIprototype1.5.0_rc0Server
script.aculo.us1.6.4-
xmlrpc.js1.0b1-
wokkelwokkel0.3.1Mac OS X
wxWidgetswxWidgets2.8Mac OS X, Xcode Tools
X11appsappres1.0.1X11
bdftopcf1.0.1-
bitmap1.0.3-
editres1.0.3-
fonttosfnt1.0.4-
fslsfonts1.0.2-
fstobdf1.0.3-
iceauth1.0.2-
ico1.0.2-
listres1.0.1-
luit1.0.3-
mkfontdir1.0.4-
mkfontscale1.0.6-
oclock1.0.1-
rgb1.0.3-
sessreg1.0.4-
showfont1.0.2-
setxkbmap1.0.4-
twm1.0.4-
viewres1.0.1-
x11perf1.5-
xauth1.0.3-
xbitmaps1.0.1-
xcalc1.0.2-
xclipboard1.0.1-
xclock1.0.3-
xconsole1.0.3-
xcursorgen1.0.2-
xditview1.0.1-
xdm1.1.8-
xdpyinfo1.0.3-
xedit1.1.2-
xev1.0.3-
xeyes1.0.1-
xfd1.0.1-
xfontsel1.0.2-
xfs1.0.8-
xfsinfo1.0.2-
xgc1.0.1-
xhost1.0.2-
xinput1.4.1-
xkbcomp1.0.5-
xkeyboard-config1.3-
xkbevd1.0.2-
xkbprint1.0.1-
xkbutils1.0.1-
xkill1.0.1-
xload1.0.2-
xlogo1.0.1-
xlsatoms1.0.1-
xlsclients1.0.1-
xlsfonts1.0.2-
xmag1.0.2-
xman1.0.3-
xmessage1.0.2-
xmh1.0.1-
xmodmap1.0.3-
xmore1.0.1-
xpr1.0.2-
xprop1.0.4-
xrandr1.3.0-
xrdb1.0.5-
xrefresh1.0.2-
xrx1.0.2-
xset1.0.4-
xsetmode1.0.0-
xsetpointer1.0.1-
xsetroot1.0.2-
xsm1.0.1-
xstdcmap1.0.1-
xterm243-
xtrap1.0.2-
xvinfo1.0.1-
xwd1.0.2-
xwininfo1.0.4-
xwud1.0.1-
X11fonts-encodings1.0.0X11
font-adobe-100dpi1.0.0-
font-adobe-75dpi1.0.0-
font-adobe-utopia-100dpi1.0.1-
font-adobe-utopia-75dpi1.0.1-
font-adobe-utopia-type11.0.1-
font-alias1.0.1-
font-arabic-misc1.0.0-
font-bh-100dpi1.0.0-
font-bh-75dpi1.0.0-
font-bh-lucidatypewriter-100dpi1.0.0-
font-bh-lucidatypewriter-75dpi1.0.0-
font-bh-ttf1.0.0-
font-bh-type11.0.0-
font-bitstream-100dpi1.0.0-
font-bitstream-75dpi1.0.0-
font-bitstream-speedo1.0.0-
font-bitstream-type11.0.0-
font-cronyx-cyrillic1.0.0-
font-cursor-misc1.0.0-
font-daewoo-misc1.0.0-
font-dec-misc1.0.0-
font-ibm-type11.0.0-
font-isas-misc1.0.0-
1.0.0-
font-1.0.0-
font-1.0.0-
font-misc-ethiopic1.0.0-
font-misc-meltho1.0.0-
font-misc-misc1.0.0-
font-mutt-misc1.0.0-
font-schumacher-misc1.0.0-
font-screen-cyrillic1.0.0-
font-sony-misc1.0.0-
font-sun-misc1.0.0-
font-util1.0.1-
font-winitzki-cyrillic1.0.0-
font-xfree86-type11.0.1-
ttf-bitstream-vera1.10-
X11libscairo1.8.6X11
libAppleWM1.3.0-
libdmx1.0.2-
libfontenc1.0.4-
libFS1.0.1-
libICE1.0.5-
liblbxutil1.0.1-
liboldX1.0.1-
libpng1.2.35-
libSM1.1.0-
libX111.2.1-
libXau1.0.4-
libXaw1.0.4-
libXaw1.0.5-
libXcomposite0.4-
libXcursor1.1.9-
libXdamage1.1.1-
libXdmcp1.0.2-
libXevie1.0.2-
libXext1.0.5-
libXfixes4.0.3-
libXfont1.4.0-
libXfontcache1.0.4-
libXft2.1.13-
libXi1.2.1-
libXinerama1.0.3-
libxcb1.2-
libxkbfile1.0.5-
libxkbui1.0.2-
libXmu1.0.4-
libXp1.0.0-
libXpm3.5.7-
libXprintAppUtil1.0.1-
libXprintUtil1.0.1-
libXrandr1.3.0-
libXrender0.9.4-
libXres1.0.3-
libXScrnSaver1.1.2-
libXt1.0.5-
libXTrap1.0.0-
libXtst1.0.3-
libXv1.0.4-
libXvMC1.0.4-
libXxf86dga1.0.2-
libXxf86misc1.0.1-
libXxf86vm1.0.2-
pixman0.14.0-
xcb-util0.3.3-
xpyb1.1-
xtrans1.2.3-
X11miscgccmakedep1.0.2X11
lndirgit-2007.12.06-
makedepend1.0.1-
xorg-docs1.4-
xorg-sgml-doctools1.1-
X11protoxcb-proto1.4Mac OS X, X11
fontconfig2.6.0-
freetype2.3.9-
pkg-config0.23-
applewmproto1.3.0-
bigreqsproto1.0.2-
compositeproto0.4-
damageproto1.1.0-
dmxproto2.2.2-
dri2proto1.99.3-
evieext1.0.2-
fixesproto4.0-
fontcacheproto0.1.2-
fontsproto2.0.2-
glproto1.4.9-
inputproto1.5.0-
kbproto1.0.3-
printproto1.0.4-
randrproto1.3.0-
recordproto1.13.2-
renderproto0.9.3-
resourceproto1.0.2-
scrnsaverproto1.1.0-
trapproto3.4.3-
util-macros1.2.1-
videoproto2.2.2-
xcmiscproto1.1.2-
xextproto7.0.5-
xf86bigfontproto1.1.2-
xf86dgaproto2.0.3-
xf86driproto2.0.4-
xf86miscproto0.9.2-
xf86rushproto1.1.2-
xf86vidmodeproto2.2.2-
xineramaproto1.1.2-
xproto7.0.15-
xproxymanagementprotocol1.0.2-
X11serverMesaLib7.0.4Mac OS X, X11
MesaLib7.2-
MesaDemos7.2-
MesaGLUT7.2-
AppleSGLX57-
xorg-server1.4.2-apple45-
xorg-server1.6.0-
xinit1.1.1-
xarxar1.4Mac OS X, Xcode Tools
zipzip3.0Mac OS X
unzip5.52-
ZopeInterfaceZope3.5.1Mac OS X
zshzsh4.3.9Mac OS X
9E74BF39-5921-49BD-B31D-15E6ED0000D2.jpeg

IMG_4215.jpeg

IMG_4499.jpeg


Xcode 3.2.X (PowerPC)​


WIP TABLE 1
 
Last edited:
The Snow Leopard thread, unlike other similarly sized threads, is borderline impossible to follow for someone that isn't involved.

I thought about the possibility of running SL on one of my Macs, but I don't even know what the state of it is, the OP is not a WikiPost, I just learned yesterday that there's two separate SL projects now? Not to mention the multiple pages per day of developing content.

Forget separate threads, it may be worth pushing for a subforum for it.
 
  • Like
  • Haha
Reactions: MarkSokolovsky, MarkSokolovsky, NikolaPPC and 4 others
I think it's a good idea to have separate threads mostly because the current one is mostly focused on the betas and everything related to 10.6.8 gets buried in all those pages.

Would be nice to have the first few posts describing the current state, what works and what doesn't, download links, tested machines, as simple as possible so people outside the project can read and understand.
 
  • Like
Reactions: NikolaPPC, Larsvonhier and ChrisCharman
educovas said:
I think it's a good idea to have separate threads mostly because the current one is mostly focused on the betas and everything related to 10.6.8 gets buried in all those pages.

Would be nice to have the first few posts describing the current state, what works and what doesn't, download links, tested machines, as simple as possible so people outside the project can read and understand.
Click to expand...

Yeah, I second this: while I don’t mind development stuff in the main thread, it is more convenient to have a dedicated thread, so we can focus on relevant things and messages do not get buried in generic discussions.
 
  • Like
Reactions: ChrisCharman
educovas said:
I think it's a good idea to have separate threads mostly because the current one is mostly focused on the betas and everything related to 10.6.8 gets buried in all those pages.

Would be nice to have the first few posts describing the current state, what works and what doesn't, download links, tested machines, as simple as possible so people outside the project can read and understand.
Click to expand...
I’ve left the first two posts intentionally blank on this thread for that potential eventuality.
 
  • Like
Reactions: repairedCheese
ChrisCharman said:
Since April 2020, efforts to get Snow Leopard working on PowerPC systems have been ongoing and documented in This thread. What started out initially as an effort to explore, document and update a number of the available Snow Leopard Developer Previews that, when patched, are able to boot on PowerPC systems has continued over the years. These modifications were relatively easy to follow.

We have now reached a stage where a working version of 10.6.8 is available, currently using 'donor parts' from Developer Build 10A190 and 10.5.8 Leopard. Further development requires a lot of 'developer talk' and low-level discussion that is less easy to comprehend and follow.

As this type of post has been objected to in the past, by some on the thread, the following question is being asked of the community...

Should continued work on 10.6.8 PowerPC and Xcode 3.2.X have its own dedicated thread?​

Click to expand...

I’ve been asking for this, explicitly, for only the last, like, three years.

I offer this thread ought to be upgraded to a wikipost for developer/development level stuff, particularly third-party ports, to be continued and expanded on over here.

The April 2020 thread came together for the getting the entire OS running (and stably). It was reconstructing what was being handled by Apple internally in 2008 and 2009, based on access to the earlier builds known to boot on PowerPC Macs. The goal for that thread was intended to address the end-user experience of testing and even using SL-PPC on their own PowerPC Macs. That thread must continue to be the place for exactly that and, where/as applicable, will refer to activity, fixes, and releases from collaborations and works from this specialized thread focussed on building elements from source and other lower-level, coding-level work. This work absolutely aids the entire OS, even as it isn’t the entirety of Snow Leopard as an OS.

I welcome the feedback.
 
  • Like
Reactions: lepidotós and repairedCheese
B S Magnet said:
I’ve been asking for this, explicitly, for only the last, like, three years.

I offer this thread ought to be upgraded to a wikipost for developer/development level stuff, particularly third-party ports, to be continued and expanded on over here.

The April 2020 thread came together for the getting the entire OS running (and stably). It was reconstructing what was being handled by Apple internally in 2008 and 2009, based on access to the earlier builds known to boot on PowerPC Macs. The goal for that thread was intended to address the end-user experience of testing and even using SL-PPC on their own PowerPC Macs. That thread must continue to be the place for exactly that and, where/as applicable, will refer to activity, fixes, and releases from collaborations and works from this specialized thread focussed on building elements from source and other lower-level, coding-level work. This work absolutely aids the entire OS, even as it isn’t the entirety of Snow Leopard as an OS.

I welcome the feedback.
Click to expand...
I already knew your vote before creating the poll @B S Magnet 😂
 
ChrisCharman said:
I already knew your vote before creating the poll @B S Magnet 😂
Click to expand...

My vote is beside the point, Chris.

From 2021, I was aware of how I’d be unable to successfully start another thread for development. (I urged others to go forward and do that, but I was dismissed.)

As with project drift/feature creep/whatever, it had strayed from the core remit of focussing, foremost, to get Snow Leopard running on as many PowerPC Macs, in the latest possible developer preview, as possible. Instead, it ended up becoming a place for third-party developer stuff which did little to, say, get a PowerPC Mac running a build stably enough to reach a Finder desktop. It always needed its own place.

So from that, I was aware it’d require another person, basically one of y’all, to do what you’ve done here with this new discussion wikipost thread for SL-PPC development. And now that day has arrived. It would have been better for it to have been struck into existence then, but better late than never.

Thank you for doing this.
 
Last edited:
Well the poll results demonstrate why i created the poll and this thread - we’re hovering around a 50/50 split of opinion on the matter @B S Magnet.

As for the original thread being derailed, that’s a subjective opinion. Even in the first month of the project we discussed that at some point paths would diverge into a 10A096 with Leopard components and a 10A190/10A222… with updated components. The original thread was never dedicated to either path in particular. It was a thread for SL_PPC as @Larsvonhier coined it.

Once you volunteered to be responsible for the WikiPost on that thread detailing all of the steps needed and which components from Leopard were required to tweak and improve 10A096, and then gave the project a nickname ‘Clouded Leopard’ it started to become clear that there was no longer space for both paths in one thread, particularly as your focus was solely on 10A096. This was compounded with MacPorts related posts entering the fray with @kencu followed by @barracuda156.

The three of us discussed divergence and agreed that MacPorts needed its own thread and that it wasn’t a fundamental part of the OS, even if third party software compatibility had been discussed from the get go, but also that the three of us, as the only active, consistent testers and contributors working on SL_PPC systems for a long period of time had become an ‘adhoc team’ and that sharing findings together remained the best course of action.

We then took a respite. I continued to quietly compile and tinker off thread when I found the time, @barracuda156 continued to share MacPorts on 10A190 progress in his own threads (admittedly sometimes in the wrong thread) and @educovas appeared with a 10A222 build and was working on a 10A432 build using components from 10A190.

Excitement ensued. People became active and vocal again, and then demands and disagreements emerged.

The consensus is not clear but the objections to technical posts being posted on that thread and its confusing nature for newcomers is clearly an issue, made clear by multiple users now. The fact that it has always been a technical thread is irrelevant at this point - it is no longer easy to follow for the whole of the community.

@educovas left that original thread and continued to work with a select group of people, testing and putting together a 10.6.8 build which was then shared on that thread for posterity. The build was apparently tested on multiple systems and by multiple people and was done outside of the scope of that project. This build has been volunteered to the community ‘as is’.

This brings us back to the poll and this thread.

I’m happy to go in either direction, but i will continue on the same path that was outlined in my first post in 2020 - building and testing system components from AOSP with a view to patching a build (now 10.6.8) to be as close to the retail version as possible.

If the community would like development in this thread only then we will encourage all development discussions related to the OS itself to be posted here and provide a comprehensive wiki, toolkit and references.

It is a community decision and the outcome will be respected.
 
ChrisCharman said:
Well the poll results demonstrate why i created the poll and this thread - we’re hovering around a 50/50 split of opinion on the matter @B S Magnet.
Click to expand...

What I can gather is this has been stewing out of sight, as I haven’t posted anything in many months about the direction and scope of the project — not since someone new came in, claimed they got a remarkable thing to work, but then declined to document how they did it. Yah, that didn’t sit right with me, I said as much, and I left it at that. I’ll expand on that a bit below.

After that, I went on to focus on other Mac (and life and work) things. That was several months ago, and this new thread is, well, new now.


ChrisCharman said:
As for the original thread being derailed, that’s a subjective opinion. Even in the first month of the project we discussed that at some point paths would diverge into a 10A096 with Leopard components and a 10A190/10A222… with updated components. The original thread was never dedicated to either path in particular. It was a thread for SL_PPC as @Larsvonhier coined it.

Once you volunteered to be responsible for the WikiPost on that thread detailing all of the steps needed and which components from Leopard were required to tweak and improve 10A096, and then gave the project a nickname ‘Clouded Leopard’ it started to become clear that there was no longer space for both paths in one thread, particularly as your focus was solely on 10A096. This was compounded with MacPorts related posts entering the fray with @kencu followed by @barracuda156.
Click to expand...

OK.

My focus being on 10A96 was not a distraction from folks testing and updating the wikipost for 10A190, and I repeated this regularly, noting I was the oddball working with 10A96 and wasn‘t offended by being alone with that. I wanted — hoped — folks would do the same with 10A190 as I had done with 10A96.

I continued adding new information related to 10A96, such as in Table 4, because that was what I was working on. I was not in a place or position to do the same for 10A190, but many others were.

I took up the voluntary mantle of maintaining the wikipost’s format and readability because no one else stepped up to do so. What was there back in 2020 was quickly devolving into a poorly edited wiki which so often undermines the utility of other, complex, lengthy wikiposts found elsewhere on MR (most notably, by folks whose professional backgrounds probably aren’t adjacent to or are in technical writing/documentation).

I didn’t fault anyone for not contributing to the testing of 10A190 and not updating the 10A190 column for verified functionality. It would have been nice for someone to be doing what I was doing on the 10A190 side, but that didn’t happen.

I don’t think it is OK to fault me on behalf of others who chose not to do that component/QA testing work on 10A190, to update folks in the ongoing discussion or in the wikipost on those component swaps.

Even as many others were trying out 10A190 on their gear (totally OK by me, always), I didn’t press others to step up to do the same for 10A190 or even later builds as I had been doing for 10A96. The column in Table 4 was already there, waiting for someone working on 10A190 to fill it in. The occasional post notwithstanding, particularly throughout 2020, that generally did not happen.


But — and this is key — I have always expected a level of quality, transparency, and clarity with communication to make sure documentation for what had been tested was available and accessible to all, and in a human-readable presentation/format. That no one took up that mantle with 10A190 or reported on swapped components which worked (or didn’t) is on those who worked on 10A190.

I’m sorry. Your grievance here is unfair. And a great deal of what you’ve brought up above isn’t even central to to the Snow Leopard itself.

That was the remit, after all: a PowerPC Mac owner who wants to install, try out, and even run Snow Leopard on their PowerPC Mac. They want it to work, and if it works, to find ways to make the OS work better (i.e., fewer crashes, bugs, getting AirPort to play nice, etc.).

Macports? Respectfully, that should have always been spun off to another thread about — wait for it — Macports on an unsupported OS back in late 2021. It originally came up in 2020 while folks were still trying out third-party software to see which ones worked and which did not.


ChrisCharman said:
The three of us discussed divergence and agreed that MacPorts needed its own thread and that it wasn’t a fundamental part of the OS, even if third party software compatibility had been discussed from the get go, but also that the three of us, as the only active, consistent testers and contributors working on SL_PPC systems for a long period of time had become an ‘adhoc team’ and that sharing findings together remained the best course of action.
Click to expand...

With candour, what wore me out — burnt me out — from continuing beyond mid-2022 was the steady abundance of Macports-related posts being nearly all of my alerts whenever a new post on SL-PPC came up.

It got to a point when I was, like, “What even is this anymore?”

From the remit of all the things central to making Snow Leopard run smoothly for the way most folks use OS X, each “Oh, this is about Macports again” became a distraction. Less wheat, more chaff. But by then, my expressed suggestion, to spin off non-Snow Leopard stuff over to another thread, was rebuffed by the very party generating the content which was ancillary to the remit of getting SL to run on PowerPC Macs. [!]

The work they did was and is laudable, and — this is key — it always belonged in its own topical place. I couldn’t twist their arm to go open a new thread on Macports in the Darwin 10.0.0dX environment. I found this frustrating, but really: what more could I do?

So… more drift away from the project’s central remit on the SL-PPC thread continued apace, and I reached a point, like around June 2022, when I was just, “OK, I can’t with this anymore.” Moreoever, few contributions to areas in the wikipost reserved for 10A190 had been added by anyone to in quite some time, despite most user activity on the thread being focussed on 10A190/10.0.0d2 matters. 🤷‍♀️


ChrisCharman said:
We then took a respite. I continued to quietly compile and tinker off thread when I found the time, @barracuda156 continued to share MacPorts on 10A190 progress in his own threads (admittedly sometimes in the wrong thread) and @educovas appeared with a 10A222 build and was working on a 10A432 build using components from 10A190.

Excitement ensued. People became active and vocal again, and then demands and disagreements emerged.

The consensus is not clear but the objections to technical posts being posted on that thread and its confusing nature for newcomers is clearly an issue, made clear by multiple users now. The fact that it has always been a technical thread is irrelevant at this point - it is no longer easy to follow for the whole of the community.
Click to expand...

It’s no longer easy to follow for the reason I just raised: the Macports stuff always belonged with another thread germane to the third-party Macports project, to keep the original remit of the SL-PPC thread focussed on Snow Leopard itself.

To newcomers, the thread, particularly from 2022, appeared preoccupied not so much with Snow Leopard, but with Macports. Feature creep? Project drift? Whatever. It happened.


ChrisCharman said:
@educovas left that original thread and continued to work with a select group of people, testing and putting together a 10.6.8 build which was then shared on that thread for posterity. The build was apparently tested on multiple systems and by multiple people and was done outside of the scope of that project. This build has been volunteered to the community ‘as is’.
Click to expand...

Good on him!

I was clear from the outset on the need for transparency and clear communication, in order for others to be able to repeat what he asserted he had accomplished. (I certainly wanted to repeat what he did, and for a minute, I thought I might get much more involved again.) This is the bedrock and cornerstone of good (scientific) method and peer review. Software engineering is still science.

He wasn‘t interested in that, and so he left.

Unlike others, I wasn’t so much dazzled by his breakthroughs as I was sceptical, so long as there wasn’t a way for anyone else to replicate, openly, what he was doing. This isn’t to argue any of it was fabiricated, but we needed (and, frankly, deserved) a way for other folks to walk through how he did it by having the ability to replicate it ourselves. A black box tack wasn’t it.

And yes, I’m kind of a stickler for openness over proprietary behaviour. As humans, we work at our very best when we share and collaborate together, not when we withhold and compete against one another.


ChrisCharman said:
This brings us back to the poll and this thread.

I’m happy to go in either direction, but i will continue on the same path that was outlined in my first post in 2020 - building and testing system components from AOSP with a view to patching a build (now 10.6.8) to be as close to the retail version as possible.
Click to expand...

Cool, and I’m glad you’re doing that and that that’s still your area of focus and interest. I hope I haven’t gotten in your way of that.

Also bear in mind, from the vantage of others, the AOSP work you were doing seemed to set about getting, say, something like Build 10A222 to boot fully and pull up a working Finder and WindowServer on a PowerPC box. Or, in the case of 10A190 elements, like frameworks or kexts, which were broken for PowerPC, compiling from the AOSP source might mend those broken bits.

And now, with some hindsight, I’m under the impression it wasn’t so much about that than it was to build AOSP elements for PowerPC operability in a Darwin 10.0.0dX environment, without specific attention to make a broken bits in particular build, like 10A190 or 10A222, to work better. Please correct me on that.


ChrisCharman said:
If the community would like development in this thread only then we will encourage all development discussions related to the OS itself to be posted here and provide a comprehensive wiki, toolkit and references.
Click to expand...

Here’s the thing:

"Snow Leopard on Unsupported PowerPC Macs”, per the original post before it became a wiki, didn’t set out to be a thread about software development or building toolchains. It certainly didn’t bring up a third-party repo. But that’s where it went nevertheless. It was about getting Snow Leopard to boot up and to run on a PowerPC Mac.

It seemed a clear remit: “10A190? Yes, mostly. 10A96? Yes, but very early. 10A222? WindowServer and Finder aren’t happy.”


ChrisCharman said:
It is a community decision and the outcome will be respected.
Click to expand...

I… I just find it curious how you’ve gone forward right now with this thread/poll/wikipost, unprompted, even as — by shared measures — you don’t favour creating a thread like this in the first place. It reads to me as slightly hostile, even if that isn’t the intent. This line alone comes across as very, “Sir, yes sir” as the only valid response, and it’s a line I couldn’t have said (something-something-about-gendered-allowances-etc.)

I also find it curious this is coming up right now and not, say, quite some time ago, back when I was still heavily involved with getting Snow Leopard running smoothly on PowerPC Macs. And although I’m not going to take this personally, I do gather the tenor of your comments here — including the lol emoji — feel awfully personal by nature. (Or maybe that’s a total misread, idk.) If you have had a grievance with me, there’s been nothing here which couldn’t have been brought up with direct, person-to-person communiction (i.e., pm).

Anyhow, I’m not actively involved in the main project and I haven’t been for a while. It’s never meant I lost interest, but I did grow tired for the aforementioned reasons of project drift/creep. I would like to return to it again (because I like using Snow Leopard as a “regular driver” on my fastest available PPC Mac). And when I do so, my focus will resume on the basic remit laid out in the original post by Lars and early replies by vddrnnr.

But if you take umbrage with me as a person, then this is not the place for it.

p.s., The poll’s data would be more effective with checkboxes, not radio buttons.
 
  • Like
Reactions: lepidotós, MarkSokolovsky and ChrisCharman
B S Magnet said:
What I can gather is this has been stewing out of sight, as I haven’t posted anything in many months about the direction and scope of the project — not since someone new came in, claimed they got a remarkable thing to work, but then declined to document how they did it. Yah, that didn’t sit right with me, I said as much, and I left it at that. I’ll expand on that a bit below.

After that, I went on to focus on other Mac (and life and work) things. That was several months ago, and this new thread is, well, new now.




OK.

My focus being on 10A96 was not a distraction from folks testing and updating the wikipost for 10A190, and I repeated this regularly, noting I was the oddball working with 10A96 and wasn‘t offended by being alone with that. I wanted — hoped — folks would do the same with 10A190 as I had done with 10A96.

I continued adding new information related to 10A96, such as in Table 4, because that was what I was working on. I was not in a place or position to do the same for 10A190, but many others were.

I took up the voluntary mantle of maintaining the wikipost’s format and readability because no one else stepped up to do so. What was there back in 2020 was quickly devolving into a poorly edited wiki which so often undermines the utility of other, complex, lengthy wikiposts found elsewhere on MR (most notably, by folks whose professional backgrounds probably aren’t adjacent to or are in technical writing/documentation).

I didn’t fault anyone for not contributing to the testing of 10A190 and not updating the 10A190 column for verified functionality. It would have been nice for someone to be doing what I was doing on the 10A190 side, but that didn’t happen.

I don’t think it is OK to fault me on behalf of others who chose not to do that component/QA testing work on 10A190, to update folks in the ongoing discussion or in the wikipost on those component swaps.

Even as many others were trying out 10A190 on their gear (totally OK by me, always), I didn’t press others to step up to do the same for 10A190 or even later builds as I had been doing for 10A96. The column in Table 4 was already there, waiting for someone working on 10A190 to fill it in. The occasional post notwithstanding, particularly throughout 2020, that generally did not happen.


But — and this is key — I have always expected a level of quality, transparency, and clarity with communication to make sure documentation for what had been tested was available and accessible to all, and in a human-readable presentation/format. That no one took up that mantle with 10A190 or reported on swapped components which worked (or didn’t) is on those who worked on 10A190.

I’m sorry. Your grievance here is unfair. And a great deal of what you’ve brought up above isn’t even central to to the Snow Leopard itself.

That was the remit, after all: a PowerPC Mac owner who wants to install, try out, and even run Snow Leopard on their PowerPC Mac. They want it to work, and if it works, to find ways to make the OS work better (i.e., fewer crashes, bugs, getting AirPort to play nice, etc.).

Macports? Respectfully, that should have always been spun off to another thread about — wait for it — Macports on an unsupported OS back in late 2021. It originally came up in 2020 while folks were still trying out third-party software to see which ones worked and which did not.




With candour, what wore me out — burnt me out — from continuing beyond mid-2022 was the steady abundance of Macports-related posts being nearly all of my alerts whenever a new post on SL-PPC came up.

It got to a point when I was, like, “What even is this anymore?”

From the remit of all the things central to making Snow Leopard run smoothly for the way most folks use OS X, each “Oh, this is about Macports again” became a distraction. Less wheat, more chaff. But by then, my expressed suggestion, to spin off non-Snow Leopard stuff over to another thread, was rebuffed by the very party generating the content which was ancillary to the remit of getting SL to run on PowerPC Macs. [!]

The work they did was and is laudable, and — this is key — it always belonged in its own topical place. I couldn’t twist their arm to go open a new thread on Macports in the Darwin 10.0.0dX environment. I found this frustrating, but really: what more could I do?

So… more drift away from the project’s central remit on the SL-PPC thread continued apace, and I reached a point, like around June 2022, when I was just, “OK, I can’t with this anymore.” Moreoever, few contributions to areas in the wikipost reserved for 10A190 had been added by anyone to in quite some time, despite most user activity on the thread being focussed on 10A190/10.0.0d2 matters. 🤷‍♀️




It’s no longer easy to follow for the reason I just raised: the Macports stuff always belonged with another thread germane to the third-party Macports project, to keep the original remit of the SL-PPC thread focussed on Snow Leopard itself.

To newcomers, the thread, particularly from 2022, appeared preoccupied not so much with Snow Leopard, but with Macports. Feature creep? Project drift? Whatever. It happened.




Good on him!

I was clear from the outset on the need for transparency and clear communication, in order for others to be able to repeat what he asserted he had accomplished. (I certainly wanted to repeat what he did, and for a minute, I thought I might get much more involved again.) This is the bedrock and cornerstone of good (scientific) method and peer review. Software engineering is still science.

He wasn‘t interested in that, and so he left.

Unlike others, I wasn’t so much dazzled by his breakthroughs as I was sceptical, so long as there wasn’t a way for anyone else to replicate, openly, what he was doing. This isn’t to argue any of it was fabiricated, but we needed (and, frankly, deserved) a way for other folks to walk through how he did it by having the ability to replicate it ourselves. A black box tack wasn’t it.

And yes, I’m kind of a stickler for openness over proprietary behaviour. As humans, we work at our very best when we share and collaborate together, not when we withhold and compete against one another.




Cool, and I’m glad you’re doing that and that that’s still your area of focus and interest. I hope I haven’t gotten in your way of that.

Also bear in mind, from the vantage of others, the AOSP work you were doing seemed to set about getting, say, something like Build 10A222 to boot fully and pull up a working Finder and WindowServer on a PowerPC box. Or, in the case of 10A190 elements, like frameworks or kexts, which were broken for PowerPC, compiling from the AOSP source might mend those broken bits.

And now, with some hindsight, I’m under the impression it wasn’t so much about that than it was to build AOSP elements for PowerPC operability in a Darwin 10.0.0dX environment, without specific attention to make a broken bits in particular build, like 10A190 or 10A222, to work better. Please correct me on that.




Here’s the thing:

"Snow Leopard on Unsupported PowerPC Macs”, per the original post before it became a wiki, didn’t set out to be a thread about software development or building toolchains. It certainly didn’t bring up a third-party repo. But that’s where it went nevertheless. It was about getting Snow Leopard to boot up and to run on a PowerPC Mac.

It seemed a clear remit: “10A190? Yes, mostly. 10A96? Yes, but very early. 10A222? WindowServer and Finder aren’t happy.”




I… I just find it curious how you’ve gone forward right now with this thread/poll/wikipost, unprompted, even as — by shared measures — you don’t favour creating a thread like this in the first place. It reads to me as slightly hostile, even if that isn’t the intent. This line alone comes across as very, “Sir, yes sir” as the only valid response, and it’s a line I couldn’t have said (something-something-about-gendered-allowances-etc.)

I also find it curious this is coming up right now and not, say, quite some time ago, back when I was still heavily involved with getting Snow Leopard running smoothly on PowerPC Macs. And although I’m not going to take this personally, I do gather the tenor of your comments here — including the lol emoji — feel awfully personal by nature. (Or maybe that’s a total misread, idk.) If you have had a grievance with me, there’s been nothing here which couldn’t have been brought up with direct, person-to-person communiction (i.e., pm).

Anyhow, I’m not actively involved in the main project and I haven’t been for a while. It’s never meant I lost interest, but I did grow tired for the aforementioned reasons of project drift/creep. I would like to return to it again (because I like using Snow Leopard as a “regular driver” on my fastest available PPC Mac). And when I do so, my focus will resume on the basic remit laid out in the original post by Lars and early replies by vddrnnr.

But if you take umbrage with me as a person, then this is not the place for it.

p.s., The poll’s data would be more effective with checkboxes, not radio buttons.
Click to expand...

Could we please keep at least some thread free from endless complaints that someone did something which has not matched with someone else’s expectations and views of what is “correct”?

MacPorts kept being brought up for a simple reason: there is no alternative. It would be awesome if someone did make a different and better build system. That did not happen so far, so MacPorts remains de facto the only way to make old macOS somewhat usable beyond booting it and running TenFourFox. (Potentially NetBSD’s pkgsrc can be a replacement, it will be very much welcome if someone works on it.)

This thread is not about MacPorts however, so why is this even being brought up? The only utility MacPorts may have for the OS development is setting up reproducible builds of system components. System components should not be built with MacPorts-supplied (or any third-party) Unix tools and should not depend on anything within MacPorts (or any other package management system). MacPorts has a great value for using SL PPC, but not for developing for the OS itself.
 
  • Like
Reactions: lepidotós and ChrisCharman
barracuda156 said:
Could we please keep at least some thread free from endless complaints that someone did something which has not matched with someone else’s expectations and views of what is “correct”?

MacPorts kept being brought up for a simple reason: there is no alternative. It would be awesome if someone did make a different and better build system. That did not happen so far, so MacPorts remains de facto the only way to make old macOS somewhat usable beyond booting it and running TenFourFox. (Potentially NetBSD’s pkgsrc can be a replacement, it will be very much welcome if someone works on it.)

This thread is not about MacPorts however, so why is this even being brought up? The only utility MacPorts may have for the OS development is setting up reproducible builds of system components. System components should not be built with MacPorts-supplied (or any third-party) Unix tools and should not depend on anything within MacPorts (or any other package management system). MacPorts has a great value for using SL PPC, but not for developing for the OS itself.
Click to expand...
In defence of @B S Magnet - they are simply responding honestly and fully to the points I’ve mentioned.
 
Last edited:
  • Like
Reactions: MarkSokolovsky
Larsvonhier said:
Having a ready-to-go image that takes up at the point of registering user(s) is imho a good idea. Thought about that from the beginning. Downside is that some people do not trust such a pre-install due to what might be included there.
And we´ll have to update it from time to time with updated components that we find...

I prepared a list with newer kexts that exist in 10.5.8 in comparison to 10A96 and that run here - as 10.5.8 was clearly more serviced and a bit more recent than the initial 10.6 release(s). Will put it in a table on page #1 and attach a zip archive with all of them. Care has to be taken to test all modifications on various machines - as I found i.e. that ATA kext families seemed to work at first and then on another machine failed to recognize drives.

Good news: At least the newer iTunes 8.2.1 runs out-of-the box while the latest 10.5.8 version seems to need some updated frameworks.

Also tbd: A table with PPC applications that have been tested on 10.6 PPC, also on the wiki page #1 for everybody to submit what you found! I can start it in the evening...

Speaking of frameworks: That will be my next focus (and due to gigantic combinations and dependencies I will need all help I can get there! ;-). So the task would be to find 10.5.8 frameworks and libraries that run on 10.6 and improve things (as a basis for newer applications that req. them).

Somewhere in the system is also the reason for the faulty jpg decoding (that TenFourFox and Preview show). Interesting that other browsers handle it differently.
Might also be some framework stuff.

Having XCode 3.2 is great news, perhaps even the last for SL (3.2.6) will run?
Click to expand...
Regarding the purpose of the thread and wiki including Xcode up to 3.2.6
Larsvonhier said:
Intel (apps) outside ;-)
(No they would not run).

But what can be done instead:
- run slightly more recent PPC apps (in comparison to 10.5.8)
- re-compile apps for 10.6 PPC with XCode 3.2.x (i.e. TenFourFox, atm without Altivec, but for G4/G5)
- and, as you said, use a more modern OS X
Click to expand...
Regarding the benefits of running Snow Leopard and Xcode on PowerPC
Larsvonhier said:
Some more findings:
10A190 (client) has Kernel 10.0.0d2 instead of earlier d1.
10A190 on my G5 has peculiar cyclic crash of dashboard after widgets called up one time. No problem if widgets are not summoned... that was never the case on any machine with 10A96 (server).

10A222 ! still partly boots into the installer with the BootX transplanted and the OSInstall.mpkg for clients. Finds some kexts, can´t find or load others, then stalls with "still waiting for root volume". Kernel is 10.0.0d3. But seems promising in comparison to later builds that cannot pre-load kexts into RAM before starting the kernel.

edit:
Brute-force copying all A190 kexts to the installer of A222 makes things worse, but still starts booting. Seems to be the game of finding the right match. Hopeful!
Click to expand...
Early attempts to get 10A222 functional on PowerPC
Larsvonhier said:
Depends on how you define the "final build". Most fundamental would imho be the kernel itself, so we´d either have it compiled from sources for PPC or find the "last" one with PPC support. Kexts are more or less explored now, but frameworks are to be checked. There are still some severe bugs in our 10A190 combo that might only be resolved by finding suitable frameworks from either later builds (again, PPC support needed) or from 10.5.8 wherever possible due to dependencies...
But it´s "just a lot of work", I guess.
Click to expand...
Discussion regarding compiling from source and sourcing at least some components from later builds or from Leopard
ChrisCharman said:
@Larsvonhier

I’ve been following this for a couple weeks now and decided to sign-up so i can more actively contribute. Currently running the dmg imaged onto a Powermac G5 Dual 2.3ghz with 4gb ram and the stock 6600. Experience is as expected and in line with previous PowerMac11,2 reports.

Thanks to all that have contributed thus far - this is an awesome project and one i never thought we would see come to life!

I Have downloaded iso’s for 10a096 server, 10a190, 10a222, 10a261 and 10a380. I also own a physical copy of retail server. I’m currently playing around with parts of each to see what if anything can be copied across to the more stable version of 10a190.

If i have the opportunity, assuming nobody more experienced has already started, i might try and compile from some open source files for 10.6-10.6.8 provided by Apple.

Testing thus far has consisted of attempting to implement suggestions from this thread, trying to install from my library of leopard apps for compatibility and attempting to ‘frankenmac’ using Pacifist, BatChmod and the various different installation iso’s.

Out of interest, has anybody managed to get software update working? I noticed after playing around with the LeopardWebkit instructions earlier in the thread that software update activated on one occasion - it may have been due to updating the security certificates or replacing some files. I haven’t installed anything from software update ti avoid x86 code overwriting my install.
Click to expand...
Me joining the thread having been following along since the beginning at home for the first couple of weeks as a non-forum participant and discussing my intentions
B S Magnet said:
Please do! Not sure how much of the OS build the open-source components for SL cover, but they could be helpful!
Click to expand...
Welcoming open-source components
Larsvonhier said:
I would not call it that for 1.5 reasons ;-)

1. There is a skin package tool that combines the look of Mountain Lion with Leopard, and that´s already called "Mountain Leopard" (also "Snow Leopard rebirth" would be ruled out for a similar reason ;-)

1.5 I do not really see a need for a new name. It´s still a Snow Leopard, running on PPC, or short SL_PPC.
In universal macOS times, we also did not differentiate between Tiger, PPC and Tiger, intel for example.

Classifying it as "hybrid" is imho not doing it a favour either. Do we call Catalina or Mojave on unsupported machines "hybrid" just because parts of earlier OS had to be taken and included to make them run...?
(Just my 2ct.)
Click to expand...

Regarding renaming the project

Larsvonhier said:
Ok, thanks. I thought so but wanted to be sure. As said, this effect of not pre-loading the kexts starts from a certain dev build on, not just from 10.6.0 (which means, if solved, we could get a 10.6.0 final release running). Not sure if it´s solely Kernel-related, perhaps our BootX needs a re-compile of some sort, too. Your Ryan-Rempel doc offers really a good insight there..
Click to expand...
Further discussion regarding getting the retail kernel working on PowerPC
Larsvonhier said:
…My gut feeling tells me that the road might split at some point: Pimping the A96 with older components (from 10.5.8) and finding/compiling newer ingredients for A190/A222 upwards.

Let´s see what we find out.
Click to expand...

Predicting a fork in the road

ChrisCharman said:
I can confirm that compiling from the Open-source Apple code does indeed add/restore functionality in these developer builds. I’ve just compiled and installed the version of cups from 10.6.0 on 10A190 and it’s working - my printer panel now gracefully opens instead of crashing system preferences! I’m optimistic moving forward.
Click to expand...

Me doing what I said i was going to do
 
Last edited:
  • Like
Reactions: Larsvonhier
B S Magnet said:
What I can gather is this has been stewing out of sight, as I haven’t posted anything in many months about the direction and scope of the project — not since someone new came in, claimed they got a remarkable thing to work, but then declined to document how they did it. Yah, that didn’t sit right with me, I said as much, and I left it at that. I’ll expand on that a bit below.

After that, I went on to focus on other Mac (and life and work) things. That was several months ago, and this new thread is, well, new now.
Click to expand...
Nothing has been 'stewing' on my end, this poll/thread is merely an appropriate response to a recent surge of 'developer' focused posts on the main thread, being cognisant that there were complaints the last time that happened.

Yes it was made clear that it didn't sit right with you, and you're perfectly entitled to that opinion but it is only one opinion on a community thread and others were not offended by the same. The poll is a means to find out how everybody else feels about it.

B S Magnet said:
OK.

My focus being on 10A96 was not a distraction from folks testing and updating the wikipost for 10A190, and I repeated this regularly, noting I was the oddball working with 10A96 and wasn‘t offended by being alone with that. I wanted — hoped — folks would do the same with 10A190 as I had done with 10A96.

I continued adding new information related to 10A96, such as in Table 4, because that was what I was working on. I was not in a place or position to do the same for 10A190, but many others were.
Click to expand...
Your 10A096 work has never been a distraction. If someone wants to test all Leopard components and update the table then they are more than welcome and able to do so, it is a wikipost after all, this isn't the approach i've been taking as my goal has always been to update the most 'current' working version of SL_PPC with AOSP components built from source and/or with PowerPC components from retail 10.6.X. Different approaches, both in line with the original intent of the thread.

B S Magnet said:
I took up the voluntary mantle of maintaining the wikipost’s format and readability because no one else stepped up to do so. What was there back in 2020 was quickly devolving into a poorly edited wiki which so often undermines the utility of other, complex, lengthy wikiposts found elsewhere on MR (most notably, by folks whose professional backgrounds probably aren’t adjacent to or are in technical writing/documentation).

I didn’t fault anyone for not contributing to the testing of 10A190 and not updating the 10A190 column for verified functionality. It would have been nice for someone to be doing what I was doing on the 10A190 side, but that didn’t happen.

I don’t think it is OK to fault me on behalf of others who chose not to do that component/QA testing work on 10A190, to update folks in the ongoing discussion or in the wikipost on those component swaps.

Even as many others were trying out 10A190 on their gear (totally OK by me, always), I didn’t press others to step up to do the same for 10A190 or even later builds as I had been doing for 10A96. The column in Table 4 was already there, waiting for someone working on 10A190 to fill it in. The occasional post notwithstanding, particularly throughout 2020, that generally did not happen.


But — and this is key — I have always expected a level of quality, transparency, and clarity with communication to make sure documentation for what had been tested was available and accessible to all, and in a human-readable presentation/format. That no one took up that mantle with 10A190 or reported on swapped components which worked (or didn’t) is on those who worked on 10A190.
Click to expand...
This i believe is the crux. The people working on 10A190/10A222 and beyond, were not following the same process of 'swap, test, report and record'. This is not because there is an agenda to keep the process opaque and mysterious but because the process of replacing unix level components is complex and the reporting of said changes is verbose with literally hundreds to thousands of files being swapped and changed in an ongoing manner, and no 'final conclusion' has been reached enough to record and document a 'step-by-step' for others to follow and repeat...yet. Marathon not a sprint, right? Instead there was an ongoing dialogue and discussion in the form of posts on the thread.

B S Magnet said:
I’m sorry. Your grievance here is unfair. And a great deal of what you’ve brought up above isn’t even central to to the Snow Leopard itself.
Click to expand...
I don't have a grievance, please explain what i've said that you feel is unfair and irrelevant as i'm not sure what you're referring to here? Certainly was not my intention to offend you.

B S Magnet said:
That was the remit, after all: a PowerPC Mac owner who wants to install, try out, and even run Snow Leopard on their PowerPC Mac. They want it to work, and if it works, to find ways to make the OS work better (i.e., fewer crashes, bugs, getting AirPort to play nice, etc.).
Click to expand...
I don't see the point of contention or divergence here? We are just approaching the problem from a different vantage. You have been focussed on 'perfecting' the 10A096 experience and documented for whomever else may wish to repeat those steps, others like myself and @educovas are trying to get more recent Snow Leopard components and systems to run. All are efforts to run Snow Leopard on PowerPC...I don't see how they can be interpreted as anything other.

B S Magnet said:
Macports? Respectfully, that should have always been spun off to another thread about — wait for it — Macports on an unsupported OS back in late 2021. It originally came up in 2020 while folks were still trying out third-party software to see which ones worked and which did not.

With candour, what wore me out — burnt me out — from continuing beyond mid-2022 was the steady abundance of Macports-related posts being nearly all of my alerts whenever a new post on SL-PPC came up.

It got to a point when I was, like, “What even is this anymore?”

From the remit of all the things central to making Snow Leopard run smoothly for the way most folks use OS X, each “Oh, this is about Macports again” became a distraction. Less wheat, more chaff. But by then, my expressed suggestion, to spin off non-Snow Leopard stuff over to another thread, was rebuffed by the very party generating the content which was ancillary to the remit of getting SL to run on PowerPC Macs. [!]

The work they did was and is laudable, and — this is key — it always belonged in its own topical place. I couldn’t twist their arm to go open a new thread on Macports in the Darwin 10.0.0dX environment. I found this frustrating, but really: what more could I do?

So… more drift away from the project’s central remit on the SL-PPC thread continued apace, and I reached a point, like around June 2022, when I was just, “OK, I can’t with this anymore.” Moreoever, few contributions to areas in the wikipost reserved for 10A190 had been added by anyone to in quite some time, despite most user activity on the thread being focussed on 10A190/10.0.0d2 matters. 🤷‍♀️

It’s no longer easy to follow for the reason I just raised: the Macports stuff always belonged with another thread germane to the third-party Macports project, to keep the original remit of the SL-PPC thread focussed on Snow Leopard itself.

To newcomers, the thread, particularly from 2022, appeared preoccupied not so much with Snow Leopard, but with Macports. Feature creep? Project drift? Whatever. It happened.

We did discuss this between us on that thread and i believe that the majority of MacPorts related discussion now lives on the appropriate threads. I do feel however that had other SL_PPC users, myself included, been more active on the thread when these posts were forming a chain of notifications, that they would have been 'diluted'. It's also fair to point out that as @barracuda156 continued to work on MacPorts for 10A190 and Rosetta 10.6.8, that they were becoming intimately familiar with those systems under the hood and were sharing useful findings as well that are relevant to SL_PPC. There are many examples of third party software discussion on that thread including MacPorts and Xcode discussion from very early in the timeline, so to chastise somebody for continuing this trend and not sticking to the main topic isn't really fair. We did agree, collectively, that moving forward only relevant posts would be made and as far as i'm aware that has been the case.
B S Magnet said:
Good on him!

I was clear from the outset on the need for transparency and clear communication, in order for others to be able to repeat what he asserted he had accomplished. (I certainly wanted to repeat what he did, and for a minute, I thought I might get much more involved again.) This is the bedrock and cornerstone of good (scientific) method and peer review. Software engineering is still science.

He wasn‘t interested in that, and so he left.

Unlike others, I wasn’t so much dazzled by his breakthroughs as I was sceptical, so long as there wasn’t a way for anyone else to replicate, openly, what he was doing. This isn’t to argue any of it was fabiricated, but we needed (and, frankly, deserved) a way for other folks to walk through how he did it by having the ability to replicate it ourselves. A black box tack wasn’t it.

And yes, I’m kind of a stickler for openness over proprietary behaviour. As humans, we work at our very best when we share and collaborate together, not when we withhold and compete against one another.
Click to expand...

Yes. You have been very clear. I think you may wish to consider this from another perspective; not all followers of the thread want to get their hands dirty and do it themselves, or spend hours writing or reading documentation, many simply want to be provided with a way to install Snow Leopard on their beloved PowerPC systems. @educovas has provided the community with working 10A222 and 10.6.8 images so that this is possible. I would like to know exactly what was done to accomplish both but I also understand that i'm not owed that explanation and that the task was completed without thorough note-taking. There is nothing to stop another person from taking the images apart, and analysing them much as has been done with the developer previews, and maybe someone might do that someday.

I don't see anybody competing, with the exception only exception being 'who gets to post what on the thread'.

B S Magnet said:
Cool, and I’m glad you’re doing that and that that’s still your area of focus and interest. I hope I haven’t gotten in your way of that.

Also bear in mind, from the vantage of others, the AOSP work you were doing seemed to set about getting, say, something like Build 10A222 to boot fully and pull up a working Finder and WindowServer on a PowerPC box. Or, in the case of 10A190 elements, like frameworks or kexts, which were broken for PowerPC, compiling from the AOSP source might mend those broken bits.

And now, with some hindsight, I’m under the impression it wasn’t so much about that than it was to build AOSP elements for PowerPC operability in a Darwin 10.0.0dX environment, without specific attention to make a broken bits in particular build, like 10A190 or 10A222, to work better. Please correct me on that.
Click to expand...
That's good because from my perspective, all Xcode/command line/unix level/technobabble is being shunned from the other thread because it is difficult to read and follow, but no you haven't gotten in my way.

Your impression is incorrect, I continue to work on 10A190 and intend to upload a final version when one exists just as i'd hope you will do for 10A096, so others can 'play' with them. My main focus however is to take whichever is the most recent bootable Snow Leopard image (was 10A190 then 10A222 and now 10.6.8) and apply the same AOSP component replacements with a view to help create the most up-to-date, as close as possible to retail version of Snow Leopard for us all to enjoy.

With my time being as limited as it is i can see why that might be unclear so i hope that this illuminates my position. I have no interest in building AOSP for the sake or building them not creating my own Darwin based OS...though that might be fun in the future.

B S Magnet said:
Here’s the thing:

"Snow Leopard on Unsupported PowerPC Macs”, per the original post before it became a wiki, didn’t set out to be a thread about software development or building toolchains. It certainly didn’t bring up a third-party repo. But that’s where it went nevertheless. It was about getting Snow Leopard to boot up and to run on a PowerPC Mac.

It seemed a clear remit: “10A190? Yes, mostly. 10A96? Yes, but very early. 10A222? WindowServer and Finder aren’t happy.”
Click to expand...
Click to expand...
The title and aim of that thread is 'Snow Leopard on Unsupported Macs'. Not Developer previews only on PowerPC macs. It was a thread started with the discovery that some DPs with tweaks could be booted and progressed to a community effort to explore how far we could go with 'Snow Leopard' on PowerPC. I see no major deviance from that remit, apart from what we have already discussed and addressed. Please correct me if i'm missing something?

B S Magnet said:
I… I just find it curious how you’ve gone forward right now with this thread/poll/wikipost, unprompted, even as — by shared measures — you don’t favour creating a thread like this in the first place. It reads to me as slightly hostile, even if that isn’t the intent. This line alone comes across as very, “Sir, yes sir” as the only valid response, and it’s a line I couldn’t have said (something-something-about-gendered-allowances-etc.)
Click to expand...
It is not hostile in the least, if anything it is actually an anxiety driven move to prevent conflict on the other thread as there has been a flurry of 'technobabble' recently and I intend to be more active again in a short time and do not want a backlash of complaints directed at myself or anyone else. I respect all viewpoints shared here and on that thread but some are mutually-exclusive and thus if the community wants a separate thread then we will have a separate thread, then everyone can be happy. It's really that simple.

B S Magnet said:
I also find it curious this is coming up right now and not, say, quite some time ago, back when I was still heavily involved with getting Snow Leopard running smoothly on PowerPC Macs. And although I’m not going to take this personally, I do gather the tenor of your comments here — including the lol emoji — feel awfully personal by nature. (Or maybe that’s a total misread, idk.) If you have had a grievance with me, there’s been nothing here which couldn’t have been brought up with direct, person-to-person communiction (i.e., pm).
Click to expand...
It is a total misread. I have nothing but respect for you @B S Magnet and have enjoyed our interactions over the last 4 years. It 'tickled me' because I feel like I knew what your vote would be and was correct that's all.

B S Magnet said:
Anyhow, I’m not actively involved in the main project and I haven’t been for a while. It’s never meant I lost interest, but I did grow tired for the aforementioned reasons of project drift/creep. I would like to return to it again (because I like using Snow Leopard as a “regular driver” on my fastest available PPC Mac). And when I do so, my focus will resume on the basic remit laid out in the original post by Lars and early replies by vddrnnr.
Click to expand...
Please do, i look forward to it.

B S Magnet said:
But if you take umbrage with me as a person, then this is not the place for it.
Click to expand...
I do not and it certainly is not. If I had a problem with you as a person you would know it as i can be very blunt and forward when the situation calls for it, and you would be greeted with a pm. Please don't read that as threatening at all, or hostile because it isn't intended to be. I hope that clears up any misunderstanding.

B S Magnet said:
p.s., The poll’s data would be more effective with checkboxes, not radio buttons.
Click to expand...
This is the first poll i've posted on MacRumors and i'm unfamiliar with the options.
 
Last edited:
  • Like
Reactions: MarkSokolovsky
Doq said:
Post #2 is not widely editable as part of a WikiPost.
Click to expand...
This is true. Current link for the 10.6.8 dmg also included in the wikipost.

A problem that arose with the other thread was the word count limit for posts. @B S Magnet managed to convince the mods to increase it for that thread, a number of times, and also finely tuned the formatting of that wiki. There is a limit however and so this thread will have information spread across posts 1-3.

I’m still figuring out which content will be best suited for posts #2 and #3 - will most likely end up being static information that will not need to be changed i.e instructions and useful references perhaps. All WIP.
 
  • Like
Reactions: Project Alice
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom
Back