On Jun 24, 2020, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
so running on all architectures ever supported by OSX (modulo system libraries...).
To be pedantic, it has been officially "macOS" for some years now. The upcoming version will be 11.0, so "OS X" will no longer be relevant anyway.
why not just add arm64 to that list?
I was only musing that the "Universal 2" format *might* be new. I haven't read any of the details about it yet. Hopefully it's the same thing with just the new architecture.
so initially, I was going to rebuke the idea oft a d_fat2 format.
apple's labelling as "Universal 2" is a bit concerning though...
anyhow, I don't really see why apple should make a 2nd universal format. iirc, "fat" is a technology from NextStep, so its well aged, and has proven itself. this of course is no reason to not drop it.
I mentioned that it *might* be different as there was some talk about Rosetta 2 and the other emulation/virtualization layers having some sort of way to optimize existing binaries for the different architecture, which led me to think that they might rework the "fat" approach with some additions or changes to facilitate this and/or lay the groundwork for the next 10-20 years.
OTOH I also cannot imagine them changing something as fundamental as this unless it's *really* necessary.
more important: can you (well: they) make money with a new format? i'm having a hard time here to imagine how (but then: i'm not very good in imagining how to make money in general).
(The following is not to IOhannes in particular.)
As per the usual Apple grumbling I will say "nobody is forcing people to buy an Apple product." Supporting is another story, but now there are people like me to help and I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it. If support is a pain, then those institutions relying on Macs, of which there are many, could maybe kick back some development support in some way or even a build machine or two...
i don't think there are still enough ppc users left for apple to care about them. thinkgs might be different with i386 though.
The last 32-bit only Intel Macs are from the late 00s, so there are some but their numbers are probably lower than you may think. There are probably fewer 32-bit Intel Macs in use now than ppc I bet, at least as far as Pd is concerned.
however, i guess the biggest issue is for the developers it's getting really hard to create fat binaries that cover more architectures than x86_64 and i-arm64. that's because there's no reasonable toolchains available that allow you to do so.
Right. I imagine we are looking at a minimum of needing the Xcode12 developer tools (ie. compiler chain), without the Xcode UI.
so the only way to produce fat binaries (that include mor ethan x86_&4 and amd64) is to have multiple build systems (parts of them unsupported by now) and combine the artifacts into a single binary in a second step.
I think it's better to have separate builds, which we already have. It's already hard enough, especially concerning Tcl/Tk frameworks, that I do not think making "one app bundle to rule them all" is even practical... feasible perhaps, but not sustainable.
that sounds like a big enough hurdle to be a rather plump nudge for most applications to support only "recent" architecture. no need to invent a new format.
-------- Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com/ robotcowboy.com http://robotcowboy.com/
As per the usual Apple grumbling I will say "nobody is forcing people to buy an Apple product."
True from a user's perspective. For open source cross-platform developers the story is a bit different.
Supporting is another story, but now there are people like me to help and I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it.
As a Windoze dev I can relate ;-) Don't take the occasional Apple bashing personally. Your work is highly appreciated!
If support is a pain, then those institutions relying on Macs, of which there are many, could maybe kick back some development support in some way or even a build machine or two...
Yes!
Christof
On 24.06.2020 16:00, Dan Wilcox wrote:
On Jun 24, 2020, at 12:00 PM, pd-dev-request@lists.iem.at mailto:pd-dev-request@lists.iem.at wrote:
so running on all architectures ever supported by OSX (modulo system libraries...).
To be pedantic, it has been officially "macOS" for some years now. The upcoming version will be 11.0, so "OS X" will no longer be relevant anyway.
why not just add arm64 to that list?
I was only musing that the "Universal 2" format *might* be new. I haven't read any of the details about it yet. Hopefully it's the same thing with just the new architecture.
so initially, I was going to rebuke the idea oft a d_fat2 format.
apple's labelling as "Universal 2" is a bit concerning though...
anyhow, I don't really see why apple should make a 2nd universal format. iirc, "fat" is a technology from NextStep, so its well aged, and has proven itself. this of course is no reason to not drop it.
I mentioned that it *might* be different as there was some talk about Rosetta 2 and the other emulation/virtualization layers having some sort of way to optimize existing binaries for the different architecture, which led me to think that they might rework the "fat" approach with some additions or changes to facilitate this and/or lay the groundwork for the next 10-20 years.
OTOH I also cannot imagine them changing something as fundamental as this unless it's *really* necessary.
more important: can you (well: they) make money with a new format? i'm having a hard time here to imagine how (but then: i'm not very good in imagining how to make money in general).
(The following is not to IOhannes in particular.)
As per the usual Apple grumbling I will say "nobody is forcing people to buy an Apple product." Supporting is another story, but now there are people like me to help and I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it. If support is a pain, then those institutions relying on Macs, of which there are many, could maybe kick back some development support in some way or even a build machine or two...
i don't think there are still enough ppc users left for apple to care about them. thinkgs might be different with i386 though.
The last 32-bit only Intel Macs are from the late 00s, so there are some but their numbers are probably lower than you may think. There are probably fewer 32-bit Intel Macs in use now than ppc I bet, at least as far as Pd is concerned.
however, i guess the biggest issue is for the developers it's getting really hard to create fat binaries that cover more architectures than x86_64 and i-arm64. that's because there's no reasonable toolchains available that allow you to do so.
Right. I imagine we are looking at a minimum of needing the Xcode12 developer tools (ie. compiler chain), without the Xcode UI.
so the only way to produce fat binaries (that include mor ethan x86_&4 and amd64) is to have multiple build systems (parts of them unsupported by now) and combine the artifacts into a single binary in a second step.
I think it's better to have separate builds, which we already have. It's already hard enough, especially concerning Tcl/Tk frameworks, that I do not think making "one app bundle to rule them all" is even practical... feasible perhaps, but not sustainable.
that sounds like a big enough hurdle to be a rather plump nudge for most applications to support only "recent" architecture. no need to invent a new format.
Dan Wilcox @danomatika http://twitter.com/danomatika danomatika.com http://danomatika.com robotcowboy.com http://robotcowboy.com
Pd-dev mailing list Pd-dev@lists.iem.at https://lists.puredata.info/listinfo/pd-dev
On 24.06.20 16:00, Dan Wilcox wrote:
On Jun 24, 2020, at 12:00 PM, pd-dev-request@lists.iem.at wrote:
so running on all architectures ever supported by OSX (modulo system libraries...).
To be pedantic, it has been officially "macOS" for some years now. The upcoming version will be 11.0, so "OS X" will no longer be relevant anyway.
of course i used "OSX" on purpose, as this was from a historic pov. iirc, most architectures in my list have been supported by the (historic) OSX rather than the (new) macOS.
it was not meant as a generic meant at as a generic rant about apple's naming scheme (though of course, i kinda accepted that interpretation too).
why not just add arm64 to that list?
I was only musing that the "Universal 2" format *might* be new. I haven't read any of the details about it yet. Hopefully it's the same thing with just the new architecture.
indeed. after reading up (somewhere between writing the first and the second part of my email), it's concerning that they chose to label it differently.
I don't often feel so welcome when the platform I'm explicitly contributing a good amount of time toward is often bashed by people who don't prefer to use it.
sorry. if my post came across like this, it was really unintentional. (on re-reading, i don't find my email especially snarky; except for the first line alluding to iOS as their mainline system)
so the only way to produce fat binaries (that include mor ethan x86_&4 and amd64) is to have multiple build systems (parts of them unsupported by now) and combine the artifacts into a single binary in a second step.
I think it's better to have separate builds, which we already have. It's already hard enough, especially concerning Tcl/Tk frameworks, that I do not think making "one app bundle to rule them all" is even practical... feasible perhaps, but not sustainable.
oh totally. i was only trying to explain why i think that apple might not need to put extra hurdles in the way of developers by inventing a new file format, as they have easier ways to nudge people towards supporting only recent architectures.
but of course, if *we* - as a bunch of open source devs - are able to setup CI systems that compile for multiple target architectures and OS-versions, it's to be expected that commercial software companies can do the same.
gfmddras IOhannes
-
Christof Ressi -
Dan Wilcox -
IOhannes m zmoelnig