So there's two versions of FuseHFS; we were banging our head against patching 0.14 to work ever since it broke (sometime around High Sierra).  Apple finally kindly fixed this for us by removing HFS support from the default filesystem bundle (instead of leaving an unusable stub in there like they had done before).

So 0.15 just has some tweaks to place the filesystem bundle in the correct place for modern macOS, and is otherwise indistinguishable from 0.14 that worked on OS X 10.6 - 10.11.

And as it's indistinguishable... it's essentially just hfsutils bundled up as a fsbundle.  So it shares the same limitations as hfsutils.

I will throw in one more warning: FuseHFS can stomp on Apple's implementation of HFS+ as well, and THAT can cause some issues with GPT formatted disks.  I've only ever had an issue once, and I fixed that by temporarily disabling MacFUSE and then re-enabling it, but there are definitely some minor differences.

That said, being able to load my HFS disk and CD images on Sonoma (on Apple Silicon) is a definite plus   Before I was having to boot into Linux to do it, which just felt wrong.  So now I can prep my OS 9 images on Sonoma, then write them out to disk

[edit] And now I remembered what the edge case is for me -- When using HFSFuse, if you create a sparsebundle and format it HFS+, and then "convert" that image to a new sparsebundle (which traditionally frees up unused space), the sparsebundle will balloon to its max size, because diskutil doesn't think it can see inside the file system to free up space, and so pads with nulls instead of stripping them.  Something to be aware of if you're using HFS(+) sparsebundles and HFSFuse.

GCC 3.x was a huge jump. 3.0 is a completely different beast from the previous versions.  We were able to build GCC 2.95 (I believe) and earlier with no problems on Power MachTen, but not any version of GCC 3.

We were able to get parts of it compiling, such as the binutils, cpp preprocessor, and many support libraries, but got stuck getting the whole thing together.

The trick will be if the m68k version of MachTen has a good enough virtual memory system, as any m68k machine will probably have a LOT less memory than any of the PowerMacs we've been running it on.

That MIGHT allow the compile to go through, but it will surely really thrash the swap subsystem...if it is good enough to handle it.  On a real *nix system you can (almost) keep allocating memory until you run out of disk space...almost...

The other things the m68k version hopefully does better is mmap and other shared memory, and pipes between processes.  I won't know until I try it.

Thanks for the quick reply!

They seem fairly expensive, though Ive tracked down a used one made by LevelOne..

I may just stick with two monitors and try and find a switcher for the mpuse and keyboard.
It also hinges slightly on whether I can sync the two macs with system link- so far no joy- I may post another question about that shortly...

Yeah, I can confirm as well. Although, I use a copper heatsink with my MDD and it has worked like this since 2018 or so without any issue together with my MDX.

Covering half of the CPU core seems to be enough after all. I don't recommend anyone to do this, but it does work just fine

Maybe this heatsink should be called "aBsink", if my bad English doesn't make it sound bad

Yes! Brilliant! And marketable!