10.6 Snow Leopard PowerPC Development

[ChrisCharman]

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.

We have now reached a stage where a work in progress community created image (alpha testing version 4) 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 courtesy of @educovas.

…

MOST RECENT UPDATES TO 10.6.8 on PowerPC…​

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

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.

10.6.8 image: https://mega.nz/file/AApSABha#W83ywkVUXAeemZGjz4Prdzy0_yBsLuVG8rWjvqAc98M

​

! 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.

DOWNLOADS​

File	Hyperlink	Description	Status
Mac OS X 10.6.8 Restore Image	MegaUpload (Macintosh Garden Uploads are outdated)	Full restore image of Mac OS X Snow Leopard 10.6.8 for PowerPC	Alpha Testing: Version 4
XCode 3.2.6 (Intel)	Apple Developer Downloads Internet Archive	Release 10M25XX 06/03/2011 Mac OS X 10.6.4+	Release
XCode 3.2.6 (ppc)			WIP
DarwinBuild	DarwinBuild 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
UTdns	macos-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 tunnels	Prebuilt 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

INSTALLATION​

Spoiler: “Installation Instructions”

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​

Spoiler: “Tool Table”

Tool	Hyperlink	Description
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.
Jtool	Download	While 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.
lsock	Download	The 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​

Spoiler: “Bugs, Fixes and Workarounds…”

Issue Description	Reported by User	Fixed (Y/N)	Workaround
AHCI kexts are broken for PowerPC	@barracuda156	No	Remove AHCI kexts
OS `dyld` handling libstdc++ symbols	@barracuda156	No
Software created users/groups not recognised by OS without reboot	@barracuda156	No
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	No	@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	@educovas	No	Disable Sleep
QuickLook partially broken	@educovas	No
Bluetooth won’t find devices	@educovas	No
Finder CoverFlow frozen/glitchy	@educovas	No
Spotlight indexing doesn’t work	@educovas	No
Microsoft NTFS Filesystem - no Read/Write access	@jktwice	Yes	ntfs.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	@barracuda156	No

REFERENCE & DOCUMENTATION​

• Welcome to Snow Leopard Documentation
• Mac OS X & iOS Internals Free book by Johnathon Levin
• Apple Developer Documentation Archive
• Mac OS X Internals A Systems Approach A book by Amit Singh
• Apple Open Source Releases
• Apple OSS GitHub
• What’s New in 10.6 Snow Leopard
• Siracusa/ArsTechnica comprehensive review of Snow Leopard retail edition, Aug. 2009
• SSEN’S BLOG - Building XNU from Source
• Snow Leopard on Unsupported PowerPC Macs

​

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:

Open Source Software Currently Supported macOS PowerPC

MacPorts for 10.6 PowerPC With Pre-Built Ports Unofficial Testing Welcomed

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.

 

[ChrisCharman]

Further information …

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.

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.

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 some 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.

Spoiler: WIP Project Timeline & History

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.

 

[ChrisCharman]

Spoiler

WIP TABLE

DESCRIPTION	PROJECT NAME	PRODUCTS	10.6.8 UNIVERSAL	BUILDS FOR PPC	PATCH REQUIRED	DEPENDENCIES	BUILD TOOLS	BINARY PACKAGE
	Apple16X50Serial-24
	AppleAPIC-13
	AppleFileSystemDriver-13
	AppleHWSensor-193
	AppleIntelPIIXATA-251.0.1
	AppleKeyswitch-105.3.4
	AppleRAID-4.0.6
	AppleRTL8139Ethernet-153
•	AppleSMBIOS-42
	AppleTalk-95
	AppleUSBCDCDriver-4005.4.2
	AppleUSBIrDA-145.2.4
	BerkeleyDB-18
•	BootCache-64.2
•	CF-550.43
	CPAN-27
	CPANInternal-62
	CarbonHeaders-18.1
	ChatServer-326.5
	Chess-110.0.6
	CommonCrypto-36064
	CoreOSMakefiles-63
	CrackLib-36064
	Csu-79
	CyrusIMAP-188
	DSPasswordServerPlugin-281.1
	DSTools-134
•	DirectoryService-621.12
	DiskArbitration-213.1
	FastCGI-4
•	ICU-400.42
	IOACPIFamily-8
	IOATAFamily-251.0.1
	IOATAPIProtocolTransport-251.0.1
•	IOAudioFamily-183.4.2
	IOBDStorageFamily-10
•	IOCDStorageFamily-47.1
	IODVDStorageFamily-30
	IOFWDVComponents-199.4.1
	IOFireWireAVC-406.4.0
	IOFireWireFamily-426.4.1
	IOFireWireIP-203.4.0
	IOFireWireSBP2-406.4.1
•	IOFireWireSerialBusProtocolTransport-210.0.0
•	IOGraphics-392.1
•	IOHIDFamily-315.7.16
	IOKitTools-78
•	IOKitUser-514.16.50
•	IONetworkingFamily-65.2.1
•	IOPCIFamily-144
•	IOSCSIParallelFamily-211.0.0
	IOSerialFamily-56
•	IOStorageFamily-116.1.41
•	IOUSBFamily-424.4.1
•	IOUSBMassStorageClass-267.0.1
	JavaScriptCore-7533.20.20
	JavaScriptGlue-7533.19.1
	KerberosHelper-62.1
	KerberosLibraries-81.46.4
•	Libc-594.9.5
	Libcpp_kext-8
•	Libinfo-330.10
	Libm-315
	Libnotify-54.3
	Librpcsvc-18
•	Libsystem-125.2.11
	Liby-16
	LinkOrder-90 (coming soon!)	-
•	MySQL-55
	NFS-42.1
	OpenAL-37.2 (coming soon!)	-
	OpenBSM-21
	OpenDirectory-57.1
	OpenLDAP-143.4
	OpenPAM-11.1
	OpenSSH-142
	OpenSSL096-15
	OpenSSL097-105
•	OpenSSL098-35.1
•	PowerManagement-211.14
	PyRSS2Gen-5
	RubyCocoa-67.1
	RubyGems-17.1
	RubyOnRails-28.1
	SQLite-74.11 (coming soon!)	-
•	Security-55002
	SecurityTokend-36808
	SecurityTool-40596
	SmartCardServices-36160
	SpamAssassin-144.2
	SquirrelMail-36
	SystemStubs-6
	TargetConfig-12.1
•	TimeZoneData-35
	Tokend-40596
	Twisted-9
	UserNotification-22
•	WebCore-7533.21.1
•	WebKit-7533.21.1
	X11apps-30.1
	X11fonts-10.2
	X11libs-40.3
	X11misc-10.1
	X11proto-40.5
	X11server-85.3
	adv_cmds-138.1
	amavisd-114.1
	apache-747.3
	apache_mod_bonjour-12
	apache_mod_fastcgi-4
	apache_mod_hfs_apple-9
	apache_mod_perl-104
	apache_mod_php-53.4
	apr-24
	architecture-258
	autoconf-15
	autofs-154
	automake-8
	autozone-141.2 (coming soon!)	-
	awk-15
	bash-80
	basic_cmds-49
	bc-21
	bind9-31
	bison-13
	bison1-1
•	bless-71.3
	bootp-198.2
	bootstrap_cmds-72
	bsdmake-24
	bzip2-21.1
	cctools-750
	cddafs-243.0.2
	clamav-125.8
	clang-23
•	configd-293.8
	copyfile-66.1
	cron-35
	crontabs-43
	cscope-15
•	cups-218.30
	curl-57.2
	cvs-42
	cvs_wrapped-15
	cxxfilt-9
	developer_cmds-53.1
	diffstat-5
•	diskdev_cmds-491.6
	disklabel-2
	distcc-1607
	doc_cmds-47
	dovecot-166.13 (coming soon!)	-
	dtrace-78
	dyld-132.13
	eap8021x-100.1
	efax-35
	emacs-78.2
	enscript-15
	expat-9
	fetchmail-31
	file-39
	file_cmds-202.2
	files-556.3
	flex-24.1
	freeradius-25.1
	gcc-5646
	gcc_select-70
	gdb-1344
	glibtool-14
	gm4-13
	gnudiff-15
	gnumake-126.2
	gnuserv-7
	gnutar-450
	gnuzip-30
	gperf-6
	gpt-7
	graphviz-1009
	grep-28
	groff-32
	gssd-31
	headerdoc-8.7.15
	hfs-183.1
	hunspell-4
	iodbc-37
•	ipsec-93.15
•	ipv6configuration-31.3
	kext_tools-180.2.1
	keymgr-22
	ksh-16.1
	launchd-329.3.3
	ld64-95.2.12
	less-22
	libarchive-14
	libclosure-38
	libdispatch-84.5.5
	libedit-13
	libevent-1
	libffi-15
	libfs-9
	libgcc-13
	libiconv-30
	libmd-3
	libpcap-23.1
	libresolv-41
	libsecurity_agent-36399
	libsecurity_apple_csp-36859
	libsecurity_apple_cspdl-36064
	libsecurity_apple_file_dl-36064
	libsecurity_apple_x509_cl-36064
•	libsecurity_apple_x509_tp-55006
	libsecurity_asn1-36064
	libsecurity_authorization-36329
	libsecurity_cdsa_client-36213
	libsecurity_cdsa_plugin-36327
	libsecurity_cdsa_utilities-36658
	libsecurity_cdsa_utils-36064
	libsecurity_checkpw-36064
	libsecurity_cms-36064
•	libsecurity_codesigning-55005
	libsecurity_cssm-40418
	libsecurity_dotmacdl-36606
	libsecurity_filedb-36725
	libsecurity_filevault-36064
•	libsecurity_keychain-55017
	libsecurity_ldap_dl-38579
	libsecurity_manifest-36064
	libsecurity_mds-36495
•	libsecurity_ocspd-55004
	libsecurity_pkcs12-40627
	libsecurity_sd_cspdl-35752
	libsecurity_smime-36873
	libsecurity_ssl-40581
•	libsecurity_utilities-55010
	libsecurityd-37613
	libstdcxx-39
	libstdcxx_40-5
	libtelnet-8
	libutil-21
	libxml2-21.11.1
•	libxslt-10.9.1
	llvmCore-2120
	llvmgcc42-2118
	lsof-42
	lukemftp-12
	lukemftpd-41
•	mDNSResponder-258.21
	mail_cmds-24
	mailman-132.2
	man-14
	memcached-6
	misc_cmds-27
	modemccl-25
	msdosfs-168.2
	nano-5
	nasm-13
	ncurses-27
	neon-11.1
	net_snmp-127
	netcat-7
	netinfo-382
	network_cmds-329.2.2
	notify-25.1
	ntfs-65.5
	ntp-45.1
•	objc4-437.3
	openmpi-8
	pam_modules-76
	passwordserver_sasl-159
•	patch_cmds-11.1
	pb_makefiles-1001
	pcre-4.2
	pdisk-7
	perl-63
	portmap-39
	postfix-197.7
•	ppp-412.5
	procmail-12
	pyOpenSSL-3
	pyobjc-26
	python-44.2
	python23-18
	python_dateutil-2
•	python_modules-23
	quarantine-30 (coming soon!)	-
	rcs-14
	remote_cmds-22.1
	removefile-17
	rsync-40
	ruby-75.3
	ruby_dnssd-6
	ruby_libxml-8
•	samba-235.7
	screen-19
	security_authtrampoline-36090
•	security_certificates-50002
	security_certtool-36090
	security_crlrefresh-36090
	security_dotmac_tp-38498
•	security_ocspd-55005
	security_systemkeychain-39457
	securityd-40600
	shell_cmds-149
•	smb-431.11
	srm-6
•	subversion-40.2
	sudo-46
	svk-13
	swig-4
	syslog-100.2
	system_cmds-498.2
	system_config-50.1
	tcl-87
	tcp_wrappers-19
	tcpdump-28
	tcsh-63.2
	texi2html-5
	texinfo-17.1
	text_cmds-71
	tidy-15.3.6
	top-67
	usertemplate-71
	uucp-11
	vim-44
	webdavfs-293.2
	wxWidgets-13
	xar-36.2
	xelf-1
•	xnu-1504.15.3
	zip-11.1
	zlib-23.4
	zsh-53

 

[Doq]

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.

 

[educovas]

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.

 

[barracuda156]

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.

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.

 

[ChrisCharman]

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.

I’ve left the first two posts intentionally blank on this thread for that potential eventuality.

 

[B S Magnet]

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?​

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.

 

[ChrisCharman]

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.

I already knew your vote before creating the poll @B S Magnet 😂

 

[B S Magnet]

I already knew your vote before creating the poll @B S Magnet 😂

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.

 

[ChrisCharman]

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.

 

[B S Magnet]

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.

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.

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.

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.

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.

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. 🤷‍♀️

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.

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.

@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’.

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.

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.

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.

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.

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.”

It is a community decision and the outcome will be respected.

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.

 

[barracuda156]

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.

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.

 

[ChrisCharman]

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.

In defence of @B S Magnet - they are simply responding honestly and fully to the points I’ve mentioned.

 

[ChrisCharman]

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?

Regarding the purpose of the thread and wiki including Xcode up to 3.2.6

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

Regarding the benefits of running Snow Leopard and Xcode on PowerPC

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!

Early attempts to get 10A222 functional on PowerPC

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.

Discussion regarding compiling from source and sourcing at least some components from later builds or from Leopard

@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.

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

Please do! Not sure how much of the OS build the open-source components for SL cover, but they could be helpful!

Welcoming open-source components

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.)

Regarding renaming the project

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..

Further discussion regarding getting the retail kernel working on PowerPC

…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.

Predicting a fork in the road

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.

Me doing what I said i was going to do

 

[ChrisCharman]

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.

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.

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.

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.

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.

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.

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.

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.

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.).

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.

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.

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.

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'.

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.

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.

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.”

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?

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.)

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.

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).

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.

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.

Please do, i look forward to it.

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

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.

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

This is the first poll i've posted on MacRumors and i'm unfamiliar with the options.

 

[Tankerthebuberz]

anyone have an updated download link for the 10.6.8 image....it looks like it was removed from megaupload

 

[Tankerthebuberz]

great work by the devs btw!

 

[ChrisCharman]

great work by the devs btw!

Yes, here is the latest version uploaded by @educovas incorporating some new binary and framework fixes:

10.6.8 PowerPC (Test version 2)

The link in the wikipost has been updated to direct to the latest image.

 

[Project Alice]

How did I not see this thread until now. This'll give me something to do my next weekend

 

[barracuda156]

Yes, here is the latest version uploaded by @educovas incorporating some new binary and framework fixes:

10.6.8 PowerPC (Test version 2)

The link in the wikipost has been updated to direct to the latest image.

> The file you are trying to download is no longer available

 

[Doq]

> The file you are trying to download is no longer available

This post has a good link: 10.6.8_PPC.dmg (mega.nz)

Main post updated as well.

 

[ChrisCharman]

The WikiPost of this thread will always contain the most recent updates and download links

 

[Doq]

Post #2 is not widely editable as part of a WikiPost.

 

[ChrisCharman]

Post #2 is not widely editable as part of a WikiPost.

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.