Still rocking a 2019 (Intel) Mac Pro here, all slots filled with various Pro Tools and UAD DSP cards, SSD, GPU, etc. I'm planning to get as much mileage out of it as I can. I'm sure a Studio would be more performant, but the Thunderbolt to PCIe chassis are not cheap.
i’m in the same boat. I bought mine back in 2021 and honestly I don’t regret my decision. It’s my main software development of music production computer plus every Sunday night I get to play counterstrike with the boys by dual booting into Windows. I’m able to service repair and upgrade it myself and one day when I’m ready to move on I’ll use it as my home server. The crazy thing is that my next upgrade will be going back to a MacBook Pro most likely because the thunderbolt connectivity will be able to handle the Blackmagic 4 camera broadcast capture card and NVME PCIe storage card that are in my Mac Pro right now through some external enclosure.
The only real drawback that I’ve experienced with the Mac Pro has been the lack of support for large language models on the AMD GPU due to Apple's lacklustre metal drivers but I’ve been working with a couple of other developers to port a MoltenVK translation layer to Ollama that enables LLM’s on the GPU. We’re trying to get it on the main branch since testing has gone well.
One thing a lot of commenters in this thread are overlooking is that this is the death nell for repairable and upgradable computing for Mac, which is super disappointing.
Studios are repairable. Upgrading is being deprecated however, and I’m not sure that’s bad for Apple. It may not be bad for the end user either - it feels like external TB/USB peripherals might have a longer life transferred between computers than an internal PCIe version - and a larger market as they will work with any Mac.
I hear you. Actually I read this thread because we’re using jemalloc in an embedded product. The only way I found to work on interesting problems here was to work for myself. (Having said that I think Apple might have some security research in Canberra? Years ago there was LinuxCare there and a lot of smart people. But that was in 2003…)
To some degree. There are _many_ SwiftUI clones that support other frameworks such as Gtk and Windows, with varying states of maturity. Or you can share the business logic and write the UI natively in Swift.
It does like to weasel in if you let it write a commit message, and even after rewriting and force pushing, it seems to hang around on the GitHub contributor list.
Binding to C++ is an extremely difficult and complex problem for any language that is similarly rich and has lots of (seemingly) equivalent features. The number of subtle incompatibilities and edge cases becomes nearly endless. It's not surprising that some C++ code can't be bound properly.
Yeah, that's what I realised. But I just wanted to mention that this is not what I was expecting from "excellent" interop. I would say that C has excellent interop, in general.
I did this a long time ago as Swift calling Objective-C++ which can call C++ libs, in that case OpenCV. So it wasn't awful but did require making an ObjC++ wrapper, unless I did something wrong which is also possible.
Also things like support for GSS-API pre-authentication mechanisms (so, you can use an arbitrary security mechanism such as EAP to authenticate yourself to the KDC), the new SAnon mechanism, pulling in some changes from Apple's fork, replacing builtin crypto with OpenSSL, etc. Lack of release has been typical OSS lack of resources: no one is paid to work on Heimdal full time.
You also need synchronization to mix sources (common in any production) without incurring the latency and resampling of asynchronous sample rate conversion.
reply