Riled up? If by riled up, you mean daring to disagree with you, then I suppose. Otherwise no. It is good to hear that you're not enraged. That's not the way it came across when you were trouncing all over anyone who offered a differing opinion.
This thread should be proof that nobody, not even the coiners of terms, get to decide how those terms get used in the real world. I just did a brief polling of the guys in my IT department. Guess what, only one of the four knew what UB was and he only knew that "it refers programs that can run on more than one architecture". This was in response to "What does the term universal binary mean?" I'm not saying the guy is correct, just pointing out that the phrase isn't widely understood.
My only point here is that hopefully Apple figures out a great way to communicate compatibility information during the transition to 64bit. This involves more than just word-choice. It involves where to put those words, if to supplement with a symbol, and where to put that symbol. And that only scratches the surface.
Random thoughts: The finder could badge apps to indicate bitness. The get info window could not only offer that information, but also make it clickable in order to provide further info. Apple could suggest a naming scheme to use with apps. For instance, perhaps a standard prefix or suffix should be used in product names. Perhaps an informative and easy to understand error dialog could be invoked if attempting to execute an incompatible binary. Maybe that error dialog could link to a site that tells the user how to get the correct version of the program. I know these aren't great suggestions or even terribly thought out. Just random thoughts to show that there are many ways in which the situation might be handled.
In hindsight it will be more clear if Apple has made the right calls. Perhaps a few years from now, when the next transition is looming, future versions of ourselves will be commenting on how people interpreted (or misinterpreted) aspects of this transition.
Riled up? If by riled up, you mean daring to disagree with you, then I suppose. Otherwise no. It is good to hear that you're not enraged. That's not the way it came across when you were trouncing all over anyone who offered a differing opinion.
This thread should be proof that nobody, not even the coiners of terms, get to decide how those terms get used in the real world. I just did a brief polling of the guys in my IT department. Guess what, only one of the four knew what UB was and he only knew that "it refers programs that can run on more than one architecture". This was in response to "What does the term universal binary mean?" I'm not saying the guy is correct, just pointing out that the phrase isn't widely understood.
My only point here is that hopefully Apple figures out a great way to communicate compatibility information during the transition to 64bit. This involves more than just word-choice. It involves where to put those words, if to supplement with a symbol, and where to put that symbol. And that only scratches the surface.
Random thoughts: The finder could badge apps to indicate bitness. The get info window could not only offer that information, but also make it clickable in order to provide further info. Apple could suggest a naming scheme to use with apps. For instance, perhaps a standard prefix or suffix should be used in product names. Perhaps an informative and easy to understand error dialog could be invoked if attempting to execute an incompatible binary. Maybe that error dialog could link to a site that tells the user how to get the correct version of the program. I know these aren't great suggestions or even terribly thought out. Just random thoughts to show that there are many ways in which the situation might be handled.
In hindsight it will be more clear if Apple has made the right calls. Perhaps a few years from now, when the next transition is looming, future versions of ourselves will be commenting on how people interpreted (or misinterpreted) aspects of this transition.
All things pass with time. It never bothers me when a new tech comes out and some people aren't happy that it doesn't have everything they need. We're going through that in an iPhone thread.
How many people really think about 68xxx machines except in a nostalgic way?
I'm never "enraged" during discussions. Stating a position strongly shouldn't ever give one that impression. I don't know why some people get that from it.
There ARE people that get enraged. Those are the ones who come on and insult Apple, us, and everyone else they can think of for just using the product. I would hope that you can distinguish the difference between us.
Here's a quote from someone who's "enraged" though he would likely say he wasn't. It's just a disagreement but...
Quote:
It's ok, we'll keep it your way, wouldn't want anyone to get confused. God forbid any consumer would ever educate themselves on what they're spending they're money on. You know, instead of just assuming, because "that's how it was. Or you know the kind that buy things based solely on the emotions it sparks. Like those people still buying American cars cause they're American. Really though you're right UB does mean what I thought it didn't. For someone who says so much, you should read the thread. I said I was WRONG, and I was thinking of fat binary. Is that hard to understand. Sorry DUDE
Actually I'm on here everyday. Hate Tecfud, ok not hate, but do be so blind to one's own ignorance must be nice. Love almost all the conversation. Lots of smart, loyal fans.
That's honestly the way I and probably quite a few others interpret the posts. Not that our interpretations are right or wrong.
Keep in mind that cultural standards differ from place to place. Being from NYC, i'm sure you're closer to the seemingly "enraged" end of the spectrum than the seemingly "passive aggressive" end of the spectrum.
Combined with your tendency to post manifestos dripping with certainty, I probably interpret your emotions different than what they actually are.
Sorry to those who've made it this far in the trhead. I've tried to keep us on track by keeping the on-topic percentage high. With this post, I've failed that goal. I've nothing new to say about how Apple could have chosen a better word than "universal" when coining the phrase "universal binary".
That's honestly the way I and probably quite a few others interpret the posts. Not that our interpretations are right or wrong.
Keep in mind that cultural standards differ from place to place. Being from NYC, i'm sure you're closer to the seemingly "enraged" end of the spectrum than the seemingly "passive aggressive" end of the spectrum.
There's no such thing. Despite the nutty way people from outside of NYC look at us, we're not much different than anyone else around the country in our degree of "enragedness". I'm certainly not known for that. Your interpretations are certainly wrong.
Quote:
Combined with your tendency to post manifestos dripping with certainty, I probably interpret your emotions different than what they actually are.
My posts are no more "manifesto's" than are the posts from the others who disagree with mine. I can understand that those posting their own "manifesto's" thinking that theirs are just dandy, and that mine are a terrible expression from some down down oppressed id. But they aren't. They aren't any worse than anyone else's. If you agree with them, they are a well thought out expression, and if you don't, they are "manifesto's dripping with certainty".
Quote:
Sorry to those who've made it this far in the trhead. I've tried to keep us on track by keeping the on-topic percentage high. With this post, I've failed that goal. I've nothing new to say about how Apple could have chosen a better word than "universal" when coining the phrase "universal binary".
Well, I agree that Apple will not use Universal Binary term for marketing. Let's go back to the thread topic.
My understanding is that the push for 64-bit support is for divers only, and I believe it is recommended for printer divers and a must for the kernel extensions and other drivers.
Apple will definitely market the OS as a fully 64-bit one. In fact, it already does and we have seen the 64-bit logo during the WWDC SL presentation and on Apple's site.
As far as other (non Apple) applications are concerned, I think the situation is very different compared to the 68k/PPC and PPC/Intel transitions, and there may be no need at all for marketing terms like Fat binary and Universal binary coined down back then.
With the previous transitions the old code was running under emulation and had a measurable performance penalty, 30%-60% for 68k on PPC and about 30% PPC on Intel. Especially with the 68K to PPC transition, even the OS was running mostly in emulation mode when the first PPC Macs were released. As a result the end user could not see the performance benefits of the new architecture. Some important apps like Photoshop (it was even more important app back then) was about 30% slower overall. With the PPC/Intel transition, Rosetta was also slowing down the applications, especially the launch time, but the native OS and larger performance gap between the processors mostly compensated for this.
In both cases it was important to trumpet the fact that more and more applications are going native. And it was important to get this message to the end user.
Now the situation is very different. The performance of a 32 bit app is more or less the same, give or take a few percent the user can not perceive anyway. There are applications that will benefit a lot from the transition, but the great majority will not.
The drivers and kernel extensions are a different story. They will simply cease to work under 64-bit mode, unless they are compiled for 64 bit mode that is. Apple is aware that this was a huge problem for Vista. The problem for the Macs is a couple of magnitudes less pronounced, because the hardware options are much more limited and Apple will provide most of the drivers. As I mentioned above, I believe (but I am not sure) that the largest group of drivers, the printer drivers, is OK, because they are not executed as kernel extensions but as a separate processes. There are some printers and multifunctional devices that use kernel extensions though.
All this means that now the message is targeted to the developers mainly. Apple may decide not to promote the 64-bitness of the third party apps at all. There is no rush for it.
For developers it is important to know whether a Framework or a library supports 64-bit architecture or not. Also, some libraries are compiled as 4-way universal libraries, others may have different version for each architecture. But whether the developer utilities report a 32/64 bit binary as a universal or use different terminology does not really matter, the developers know what they are looking for.
The system preferences panes also need to be 64-bit, otherwise they will cause restart of the System Preferences app. Some generic extensions, like printer driver extensions, which are displayed in the print dialog, need to support both architectures in order to work with all apps.
Well, I agree that Apple will not use Universal Binary term for marketing. Let's go back to the thread topic.
My understanding is that the push for 64-bit support is for divers only, and I believe it is recommended for printer divers and a must for the kernel extensions and other drivers.
Apple will definitely market the OS as a fully 64-bit one. In fact, it already does and we have seen the 64-bit logo during the WWDC SL presentation and on Apple's site.
As far as other (non Apple) applications are concerned, I think the situation is very different compared to the 68k/PPC and PPC/Intel transitions, and there may be no need at all for marketing terms like Fat binary and Universal binary coined down back then.
With the previous transitions the old code was running under emulation and had a measurable performance penalty, 30%-60% for 68k on PPC and about 30% PPC on Intel. Especially with the 68K to PPC transition, even the OS was running mostly in emulation mode when the first PPC Macs were released. As a result the end user could not see the performance benefits of the new architecture. Some important apps like Photoshop (it was even more important app back then) was about 30% slower overall. With the PPC/Intel transition, Rosetta was also slowing down the applications, especially the launch time, but the native OS and larger performance gap between the processors mostly compensated for this.
In both cases it was important to trumpet the fact that more and more applications are going native. And it was important to get this message to the end user.
Now the situation is very different. The performance of a 32 bit app is more or less the same, give or take a few percent the user can not perceive anyway. There are applications that will benefit a lot from the transition, but the great majority will not.
The drivers and kernel extensions are a different story. They will simply cease to work under 64-bit mode, unless they are compiled for 64 bit mode that is. Apple is aware that this was a huge problem for Vista. The problem for the Macs is a couple of magnitudes less pronounced, because the hardware options are much more limited and Apple will provide most of the drivers. As I mentioned above, I believe (but I am not sure) that the largest group of drivers, the printer drivers, is OK, because they are not executed as kernel extensions but as a separate processes. There are some printers and multifunctional devices that use kernel extensions though.
All this means that now the message is targeted to the developers mainly. Apple may decide not to promote the 64-bitness of the third party apps at all. There is no rush for it.
For developers it is important to know whether a Framework or a library supports 64-bit architecture or not. Also, some libraries are compiled as 4-way universal libraries, others may have different version for each architecture. But whether the developer utilities report a 32/64 bit binary as a universal or use different terminology does not really matter, the developers know what they are looking for.
I think you guys are stuck in the classic "last word" loop.
But really the last word belongs to Apple. I think Melgross and I are the only ones here capable of grasping that.
edit: Last word!!! Lock'er up.
edit2: And I don't honestly give a crap that a few people here are trying to redefine what UB means. They can continue to misuse the term. When Apple comes up with a new term and/or logo to identify the apps that are 32/64 fat binaries, these people still using the term UB to identify 32/64 fat binaries that don't necessarily work on PPC computers will look like clowns.
From that post it isn't clear if you fully grasp the point that a few people are trying to make, that the term is at times used differently than Apple intended.
While Apple has the last word in officially defining their own term, communication involves at least two parties. The intention of the speaker and the interpretation of the listener are both part of the equation. As untidy as it sounds, the speaker doesn't get to entirely define the correct interpretation of their own words. People say things all the time and then discover that the masses interpreted their words quite differently than intended. Granted, the misunderstanding of UB isn't pervasive, but it does exist.
To avert a possibly lengthy retort, rest assured that I agree with the Apple definition. I'm just acknowledging that the other interpretations exist.
Communication is always key to successful transitions, as is the case with our impending switch to 64bits. Understanding your audience's interpretations is important to successful communication.
Once Apple stops supporting PPC with Snow Leopard and drivers is the major concern for wanting to run your system in full 64-bit mode, will we be using a term like "32/64 Driver", "Universal Driver" or some other term?
Communication is always key to successful transitions, as is the case with our impending switch to 64bits. Understanding your audience's interpretations is important to successful communication.
Yep. And now you see why some people here are trying to educate others so that the interpretation is perfectly clear...so the communication is successful. This is also why definitions exist and why they shouldn't be distorted...for successful communication.
There's no confusion for many people that UB means PPC/x86. Now we're just working on the other bunch that can't be bothered to look it up on Apple's site or Wikipedia.
But this thread will only reach 0.00001% of those that need to be educated. At some point it becomes most productive to also reevaluate or better choose the words that are being interpreted differently than intended. That's my attempt at pragmatism at least.
Once Apple stops supporting PPC with Snow Leopard and drivers is the major concern for wanting to run your system in full 64-bit mode, will we be using a term like "32/64 Driver", "Universal Driver" or some other term?
I suppose it depends on the plans Apple has with ARM processors.
From that post it isn't clear if you fully grasp the point that a few people are trying to make, that the term is at times used differently than Apple intended.
While Apple has the last word in officially defining their own term, communication involves at least two parties. The intention of the speaker and the interpretation of the listener are both part of the equation. As untidy as it sounds, the speaker doesn't get to entirely define the correct interpretation of their own words. People say things all the time and then discover that the masses interpreted their words quite differently than intended. Granted, the misunderstanding of UB isn't pervasive, but it does exist.
To avert a possibly lengthy retort, rest assured that I agree with the Apple definition. I'm just acknowledging that the other interpretations exist.
Communication is always key to successful transitions, as is the case with our impending switch to 64bits. Understanding your audience's interpretations is important to successful communication.
I for one, have no problem in acknowledging that deeper down, there may be an additional definition.
I'm just asking that we not bother people with it, as almost no one uses it.
What it ultimately all boils down to is the accepted marketing term for something. We as humans are very used to misusing technical terms from areas of expertise that we are not used to or proficient in - or just don't care about. There are far too many disciplines to study in the world to know everything about all of them!
So the fact that the majority of people measure weight in grams/ounces is amusing to those who know this is a measurement of mass; and that weight is really measured in Newtons and means something quite different. The masses are technically wrong, but it is accepted speech unless you are in a discipline that knows and cares. In which case when dealing with that area you [a] know, and [b] care.
Another example might be (say) electrical vs engineering current - flow of charge round a circuit. Edit - and how topical, I just noticed today's xkcd.
Not knowing about computing terms like `universal binary' does not imply you are stupid.
For those who are interested in digging a little deeper than Apple's marketing department goes, here is what the darwin tools apple provides to developers has to say on the matter:
Technically
If I compile a simple c program for just one `architecture':
% gcc -arch ppc hello.c -o hello
% file hello
hello: Mach-O executable ppc
There is no mention of `universal' according to the tool.
If (as has been pointed out earlier in this thread) one compiles a file for two `architectures' as Apple defines the term (i.e. i386 and x86_64)
% gcc -arch i386 -arch x86_64 hello.c -o hello
% file hello
hello: Mach-O universal binary with 2 architectures
The finder now says the program is `Universal' (even though there is no 64bit ppc).
If I remove the 32-bit intel (so I am left with 64bit intel and 32bit ppc) - the finder still says it is `Universal'.
Conclusion
Apple's marketing decision is thus very clear on this matter. `Universal' has been defined as a mach-o executable image that contains at least one ppc architecture and one intel architecture. They do not need to be the same bitness - bitness has nothing to do with it.
Now... Mac OS X (the gui, fluffy Apple side) has been (primarily) designed to enable people not literate in developer/computer terms to be able to do wonderful things without needing to know anything about all this.
It is designed for people who do not know about things like architectures, CPUs and bitness. OS-X is for people who might be so confused by options like ppc, x86, or x86_64 that if they saw terms like this in an info window, they become stiff from fear and maybe have a seizure and need to go to the hospital.
This is not because they are stupid, but because they have other interests and demands on their time. The computer (and software), like the electricity in your house, should just work. They do not (and will not) appreciate just how phenomenally difficult this is to achieve.
Apple's designers and marketeers do not want their users to go to the hospital, so they do not talk about things like that in the info window or on high-level websites. Instead they invent terms like `Universal Binary'. This is very thoughtful of them.
People (mainly developers) who do care can start a shell and investigate what is going on under the hood.
As to whether Apple was right or wrong to use the term `Universal' for what it is, that is completely subjective - neither here nor there; because they have already done it.
But... but(!)...
Yes, technically you can produce things which break the system if you know how. For example, I can produce an intel binary using assembly that contains (say SSE) instructions that will only run on the latest particular intel chip, and likewise a ppc counterpart that only runs on a G5. The finder will call it a `Universal Binary'. The end result is that my `mass market' end-users will be confused and not buy my software.
Ultimately what Apple terms an `architecture' isn't nearly fine grained enough for developers who care about chip optimised code for (say) simulators/models, and hence I might (with infinite time) compile one version of the program for every variant of every intel chip out there in a Mac to get the most performance I possibly can. (In simulators, this is extremely important). Apple's `Universal Binary' moniker is not interesting to me and my customers who know about this - I would have to make a lot of individual binaries. However here I am not aiming at the `mass market'. It is my field of expertise and I know/care.
A `Universal' debate
So personally (and here I continue to offer my own subjective view you are welcome to disagree with) I agree that the word `Universal' was not a particularly future-proof decision.
What will be interesting is not how the bitness denomination pans out* but how (as has been commented above) the potential for ARM `netbooks' (and the iPhone/iPod for that matter, which in some ways already are `netbooks') shakes up the field.
If someone were to hear that iPhone runs Mac OS X (or a cut down version thereof) they might try to copy their programs onto the iPhone from their Mac Desk/Lap-top. At the moment the average end user cannot do this (those that do know how, generally also know why it won't work). However if Apple were to bring out a net-book which runs on ARM, with unrestricted file transfer via ethernet/wi-fi, suddenly they would have a big user-re-education problem in their hands.
`Universal Binaries' under their current definition will not run there - leading to end-user confusion, and potential seizures and hospitalisation - because end-users will see `Universal' and think it runs on everything. Given Apple do not want to be responsible for this (or the lawsuits that would follow) they will need to do something about the `Universal' moniker before they release such a product. It will be interesting to see what.
My 2p
*32 bits addendum:
For those saying everything will go 64bit; that will (eventually) be true for drivers etc as ultimately 32bit kernels will die out.
However for user-space applications going 64bit, this is less likely, and why Apple probably won't care to market a 64bit slogan (or get it confused with `Universal'). 32bit apps will continue to run, and frequently run faster than their 64bit counter-parts. This depends of course on what the application needs to do. If it does need more than 32bits worth of RAM, it needs to go 64bit - end of story. Otherwise the reasons are not as compelling as have been made out earlier.
It is true that x64 gives access to extra general purpose registers, and this does mean fewer load/stores to shuffle numbers around from [disk to ram to] cache to register and hence faster execution. However, it also means that every time the program is chasing a pointer (and some programs that have to deal with large linked lists or tree structure have to do this a lot) are having to operate on 64bit values. This is (comparatively) slow. Too much of this will far outweigh the benefits of the extra registers.
For as long as 32bit has its own subsystem and does not need emulation in software to run, there is little reason for Apple to push/promote 64bit user-space applications.
The hubbub i'm reading from Devs is that if you don't deliver 64-bit applications you risk being the 32-bit app that causes ALL the 32-bit library to load eating up RAM and other resources.
If it's true that OS X must load all the 32-bit library upon launching a 32-bit app I think there will be a chorus of people wanting everything to be 64-bit just from an efficiency/resource perspective.
Comments
Wow, who would have thought my critique of Apple's word-choice would be met with such vehemence?
Why are you so riled up?
There's no vehemence except in your imagination.
Why are you so riled up?
There's no vehemence except in your imagination.
Riled up? If by riled up, you mean daring to disagree with you, then I suppose.
This thread should be proof that nobody, not even the coiners of terms, get to decide how those terms get used in the real world. I just did a brief polling of the guys in my IT department. Guess what, only one of the four knew what UB was and he only knew that "it refers programs that can run on more than one architecture". This was in response to "What does the term universal binary mean?" I'm not saying the guy is correct, just pointing out that the phrase isn't widely understood.
My only point here is that hopefully Apple figures out a great way to communicate compatibility information during the transition to 64bit. This involves more than just word-choice. It involves where to put those words, if to supplement with a symbol, and where to put that symbol. And that only scratches the surface.
Random thoughts: The finder could badge apps to indicate bitness. The get info window could not only offer that information, but also make it clickable in order to provide further info. Apple could suggest a naming scheme to use with apps. For instance, perhaps a standard prefix or suffix should be used in product names. Perhaps an informative and easy to understand error dialog could be invoked if attempting to execute an incompatible binary. Maybe that error dialog could link to a site that tells the user how to get the correct version of the program. I know these aren't great suggestions or even terribly thought out. Just random thoughts to show that there are many ways in which the situation might be handled.
In hindsight it will be more clear if Apple has made the right calls. Perhaps a few years from now, when the next transition is looming, future versions of ourselves will be commenting on how people interpreted (or misinterpreted) aspects of this transition.
Riled up? If by riled up, you mean daring to disagree with you, then I suppose.
This thread should be proof that nobody, not even the coiners of terms, get to decide how those terms get used in the real world. I just did a brief polling of the guys in my IT department. Guess what, only one of the four knew what UB was and he only knew that "it refers programs that can run on more than one architecture". This was in response to "What does the term universal binary mean?" I'm not saying the guy is correct, just pointing out that the phrase isn't widely understood.
My only point here is that hopefully Apple figures out a great way to communicate compatibility information during the transition to 64bit. This involves more than just word-choice. It involves where to put those words, if to supplement with a symbol, and where to put that symbol. And that only scratches the surface.
Random thoughts: The finder could badge apps to indicate bitness. The get info window could not only offer that information, but also make it clickable in order to provide further info. Apple could suggest a naming scheme to use with apps. For instance, perhaps a standard prefix or suffix should be used in product names. Perhaps an informative and easy to understand error dialog could be invoked if attempting to execute an incompatible binary. Maybe that error dialog could link to a site that tells the user how to get the correct version of the program. I know these aren't great suggestions or even terribly thought out. Just random thoughts to show that there are many ways in which the situation might be handled.
In hindsight it will be more clear if Apple has made the right calls. Perhaps a few years from now, when the next transition is looming, future versions of ourselves will be commenting on how people interpreted (or misinterpreted) aspects of this transition.
All things pass with time. It never bothers me when a new tech comes out and some people aren't happy that it doesn't have everything they need. We're going through that in an iPhone thread.
How many people really think about 68xxx machines except in a nostalgic way?
I'm never "enraged" during discussions. Stating a position strongly shouldn't ever give one that impression. I don't know why some people get that from it.
There ARE people that get enraged. Those are the ones who come on and insult Apple, us, and everyone else they can think of for just using the product. I would hope that you can distinguish the difference between us.
Here's a quote from someone who's "enraged" though he would likely say he wasn't. It's just a disagreement but...
It's ok, we'll keep it your way, wouldn't want anyone to get confused. God forbid any consumer would ever educate themselves on what they're spending they're money on. You know, instead of just assuming, because "that's how it was. Or you know the kind that buy things based solely on the emotions it sparks. Like those people still buying American cars cause they're American. Really though you're right UB does mean what I thought it didn't. For someone who says so much, you should read the thread. I said I was WRONG, and I was thinking of fat binary. Is that hard to understand. Sorry DUDE
Actually I'm on here everyday. Hate Tecfud, ok not hate, but do be so blind to one's own ignorance must be nice. Love almost all the conversation. Lots of smart, loyal fans.
Do I really post that way?
Do I really post that way?
That's honestly the way I and probably quite a few others interpret the posts. Not that our interpretations are right or wrong.
Keep in mind that cultural standards differ from place to place. Being from NYC, i'm sure you're closer to the seemingly "enraged" end of the spectrum than the seemingly "passive aggressive" end of the spectrum.
Combined with your tendency to post manifestos dripping with certainty, I probably interpret your emotions different than what they actually are.
Sorry to those who've made it this far in the trhead. I've tried to keep us on track by keeping the on-topic percentage high. With this post, I've failed that goal. I've nothing new to say about how Apple could have chosen a better word than "universal" when coining the phrase "universal binary".
That's honestly the way I and probably quite a few others interpret the posts. Not that our interpretations are right or wrong.
Keep in mind that cultural standards differ from place to place. Being from NYC, i'm sure you're closer to the seemingly "enraged" end of the spectrum than the seemingly "passive aggressive" end of the spectrum.
There's no such thing. Despite the nutty way people from outside of NYC look at us, we're not much different than anyone else around the country in our degree of "enragedness". I'm certainly not known for that. Your interpretations are certainly wrong.
Combined with your tendency to post manifestos dripping with certainty, I probably interpret your emotions different than what they actually are.
My posts are no more "manifesto's" than are the posts from the others who disagree with mine. I can understand that those posting their own "manifesto's" thinking that theirs are just dandy, and that mine are a terrible expression from some down down oppressed id. But they aren't. They aren't any worse than anyone else's. If you agree with them, they are a well thought out expression, and if you don't, they are "manifesto's dripping with certainty".
Sorry to those who've made it this far in the trhead. I've tried to keep us on track by keeping the on-topic percentage high. With this post, I've failed that goal. I've nothing new to say about how Apple could have chosen a better word than "universal" when coining the phrase "universal binary".
OK.
My understanding is that the push for 64-bit support is for divers only, and I believe it is recommended for printer divers and a must for the kernel extensions and other drivers.
Apple will definitely market the OS as a fully 64-bit one. In fact, it already does and we have seen the 64-bit logo during the WWDC SL presentation and on Apple's site.
As far as other (non Apple) applications are concerned, I think the situation is very different compared to the 68k/PPC and PPC/Intel transitions, and there may be no need at all for marketing terms like Fat binary and Universal binary coined down back then.
With the previous transitions the old code was running under emulation and had a measurable performance penalty, 30%-60% for 68k on PPC and about 30% PPC on Intel. Especially with the 68K to PPC transition, even the OS was running mostly in emulation mode when the first PPC Macs were released. As a result the end user could not see the performance benefits of the new architecture. Some important apps like Photoshop (it was even more important app back then) was about 30% slower overall. With the PPC/Intel transition, Rosetta was also slowing down the applications, especially the launch time, but the native OS and larger performance gap between the processors mostly compensated for this.
In both cases it was important to trumpet the fact that more and more applications are going native. And it was important to get this message to the end user.
Now the situation is very different. The performance of a 32 bit app is more or less the same, give or take a few percent the user can not perceive anyway. There are applications that will benefit a lot from the transition, but the great majority will not.
The drivers and kernel extensions are a different story. They will simply cease to work under 64-bit mode, unless they are compiled for 64 bit mode that is. Apple is aware that this was a huge problem for Vista. The problem for the Macs is a couple of magnitudes less pronounced, because the hardware options are much more limited and Apple will provide most of the drivers. As I mentioned above, I believe (but I am not sure) that the largest group of drivers, the printer drivers, is OK, because they are not executed as kernel extensions but as a separate processes. There are some printers and multifunctional devices that use kernel extensions though.
All this means that now the message is targeted to the developers mainly. Apple may decide not to promote the 64-bitness of the third party apps at all. There is no rush for it.
For developers it is important to know whether a Framework or a library supports 64-bit architecture or not. Also, some libraries are compiled as 4-way universal libraries, others may have different version for each architecture. But whether the developer utilities report a 32/64 bit binary as a universal or use different terminology does not really matter, the developers know what they are looking for.
The system preferences panes also need to be 64-bit, otherwise they will cause restart of the System Preferences app. Some generic extensions, like printer driver extensions, which are displayed in the print dialog, need to support both architectures in order to work with all apps.
Well, I agree that Apple will not use Universal Binary term for marketing. Let's go back to the thread topic.
My understanding is that the push for 64-bit support is for divers only, and I believe it is recommended for printer divers and a must for the kernel extensions and other drivers.
Apple will definitely market the OS as a fully 64-bit one. In fact, it already does and we have seen the 64-bit logo during the WWDC SL presentation and on Apple's site.
As far as other (non Apple) applications are concerned, I think the situation is very different compared to the 68k/PPC and PPC/Intel transitions, and there may be no need at all for marketing terms like Fat binary and Universal binary coined down back then.
With the previous transitions the old code was running under emulation and had a measurable performance penalty, 30%-60% for 68k on PPC and about 30% PPC on Intel. Especially with the 68K to PPC transition, even the OS was running mostly in emulation mode when the first PPC Macs were released. As a result the end user could not see the performance benefits of the new architecture. Some important apps like Photoshop (it was even more important app back then) was about 30% slower overall. With the PPC/Intel transition, Rosetta was also slowing down the applications, especially the launch time, but the native OS and larger performance gap between the processors mostly compensated for this.
In both cases it was important to trumpet the fact that more and more applications are going native. And it was important to get this message to the end user.
Now the situation is very different. The performance of a 32 bit app is more or less the same, give or take a few percent the user can not perceive anyway. There are applications that will benefit a lot from the transition, but the great majority will not.
The drivers and kernel extensions are a different story. They will simply cease to work under 64-bit mode, unless they are compiled for 64 bit mode that is. Apple is aware that this was a huge problem for Vista. The problem for the Macs is a couple of magnitudes less pronounced, because the hardware options are much more limited and Apple will provide most of the drivers. As I mentioned above, I believe (but I am not sure) that the largest group of drivers, the printer drivers, is OK, because they are not executed as kernel extensions but as a separate processes. There are some printers and multifunctional devices that use kernel extensions though.
All this means that now the message is targeted to the developers mainly. Apple may decide not to promote the 64-bitness of the third party apps at all. There is no rush for it.
For developers it is important to know whether a Framework or a library supports 64-bit architecture or not. Also, some libraries are compiled as 4-way universal libraries, others may have different version for each architecture. But whether the developer utilities report a 32/64 bit binary as a universal or use different terminology does not really matter, the developers know what they are looking for.
Hmmm!
That's actually correct.
I think you guys are stuck in the classic "last word" loop.
But really the last word belongs to Apple. I think Melgross and I are the only ones here capable of grasping that.
edit: Last word!!! Lock'er up.
edit2: And I don't honestly give a crap that a few people here are trying to redefine what UB means. They can continue to misuse the term. When Apple comes up with a new term and/or logo to identify the apps that are 32/64 fat binaries, these people still using the term UB to identify 32/64 fat binaries that don't necessarily work on PPC computers will look like clowns.
While Apple has the last word in officially defining their own term, communication involves at least two parties. The intention of the speaker and the interpretation of the listener are both part of the equation. As untidy as it sounds, the speaker doesn't get to entirely define the correct interpretation of their own words. People say things all the time and then discover that the masses interpreted their words quite differently than intended. Granted, the misunderstanding of UB isn't pervasive, but it does exist.
To avert a possibly lengthy retort, rest assured that I agree with the Apple definition. I'm just acknowledging that the other interpretations exist.
Communication is always key to successful transitions, as is the case with our impending switch to 64bits. Understanding your audience's interpretations is important to successful communication.
Communication is always key to successful transitions, as is the case with our impending switch to 64bits. Understanding your audience's interpretations is important to successful communication.
Yep. And now you see why some people here are trying to educate others so that the interpretation is perfectly clear...so the communication is successful. This is also why definitions exist and why they shouldn't be distorted...for successful communication.
There's no confusion for many people that UB means PPC/x86. Now we're just working on the other bunch that can't be bothered to look it up on Apple's site or Wikipedia.
But this thread will only reach 0.00001% of those that need to be educated. At some point it becomes most productive to also reevaluate or better choose the words that are being interpreted differently than intended. That's my attempt at pragmatism at least.
Once Apple stops supporting PPC with Snow Leopard and drivers is the major concern for wanting to run your system in full 64-bit mode, will we be using a term like "32/64 Driver", "Universal Driver" or some other term?
I suppose it depends on the plans Apple has with ARM processors.
From that post it isn't clear if you fully grasp the point that a few people are trying to make, that the term is at times used differently than Apple intended.
While Apple has the last word in officially defining their own term, communication involves at least two parties. The intention of the speaker and the interpretation of the listener are both part of the equation. As untidy as it sounds, the speaker doesn't get to entirely define the correct interpretation of their own words. People say things all the time and then discover that the masses interpreted their words quite differently than intended. Granted, the misunderstanding of UB isn't pervasive, but it does exist.
To avert a possibly lengthy retort, rest assured that I agree with the Apple definition. I'm just acknowledging that the other interpretations exist.
Communication is always key to successful transitions, as is the case with our impending switch to 64bits. Understanding your audience's interpretations is important to successful communication.
I for one, have no problem in acknowledging that deeper down, there may be an additional definition.
I'm just asking that we not bother people with it, as almost no one uses it.
So the fact that the majority of people measure weight in grams/ounces is amusing to those who know this is a measurement of mass; and that weight is really measured in Newtons and means something quite different. The masses are technically wrong, but it is accepted speech unless you are in a discipline that knows and cares. In which case when dealing with that area you [a] know, and [b] care.
Another example might be (say) electrical vs engineering current - flow of charge round a circuit. Edit - and how topical, I just noticed today's xkcd.
Not knowing about computing terms like `universal binary' does not imply you are stupid.
For those who are interested in digging a little deeper than Apple's marketing department goes, here is what the darwin tools apple provides to developers has to say on the matter:
Technically
If I compile a simple c program for just one `architecture':
% gcc -arch ppc hello.c -o hello
% file hello
hello: Mach-O executable ppc
There is no mention of `universal' according to the tool.
If (as has been pointed out earlier in this thread) one compiles a file for two `architectures' as Apple defines the term (i.e. i386 and x86_64)
% gcc -arch i386 -arch x86_64 hello.c -o hello
% file hello
hello: Mach-O universal binary with 2 architectures
hello (for architecture i386)
hello (for architecture x86_64)
Now the command line tools clearly state that this is a `universal binary' for the technical meaning of the term.
However, if you get information on that file in the finder, it says the binary is `Intel' (not `Universal').
If we add 32bit PPC to the mix:
% gcc -arch i386 -arch x86_64 -arch ppc hello.c -o hello
% file hello
hello: Mach-O universal binary with 3 architectures
hello (for architecture i386)
hello (for architecture x86_64)
hello (for architecture ppc7400)
The finder now says the program is `Universal' (even though there is no 64bit ppc).
If I remove the 32-bit intel (so I am left with 64bit intel and 32bit ppc) - the finder still says it is `Universal'.
Conclusion
Apple's marketing decision is thus very clear on this matter. `Universal' has been defined as a mach-o executable image that contains at least one ppc architecture and one intel architecture. They do not need to be the same bitness - bitness has nothing to do with it.
Now... Mac OS X (the gui, fluffy Apple side) has been (primarily) designed to enable people not literate in developer/computer terms to be able to do wonderful things without needing to know anything about all this.
It is designed for people who do not know about things like architectures, CPUs and bitness. OS-X is for people who might be so confused by options like ppc, x86, or x86_64 that if they saw terms like this in an info window, they become stiff from fear and maybe have a seizure and need to go to the hospital.
This is not because they are stupid, but because they have other interests and demands on their time. The computer (and software), like the electricity in your house, should just work. They do not (and will not) appreciate just how phenomenally difficult this is to achieve.
Apple's designers and marketeers do not want their users to go to the hospital, so they do not talk about things like that in the info window or on high-level websites. Instead they invent terms like `Universal Binary'. This is very thoughtful of them.
People (mainly developers) who do care can start a shell and investigate what is going on under the hood.
As to whether Apple was right or wrong to use the term `Universal' for what it is, that is completely subjective - neither here nor there; because they have already done it.
But... but(!)...
Yes, technically you can produce things which break the system if you know how. For example, I can produce an intel binary using assembly that contains (say SSE) instructions that will only run on the latest particular intel chip, and likewise a ppc counterpart that only runs on a G5. The finder will call it a `Universal Binary'. The end result is that my `mass market' end-users will be confused and not buy my software.
Ultimately what Apple terms an `architecture' isn't nearly fine grained enough for developers who care about chip optimised code for (say) simulators/models, and hence I might (with infinite time) compile one version of the program for every variant of every intel chip out there in a Mac to get the most performance I possibly can. (In simulators, this is extremely important). Apple's `Universal Binary' moniker is not interesting to me and my customers who know about this - I would have to make a lot of individual binaries. However here I am not aiming at the `mass market'. It is my field of expertise and I know/care.
A `Universal' debate
So personally (and here I continue to offer my own subjective view you are welcome to disagree with) I agree that the word `Universal' was not a particularly future-proof decision.
What will be interesting is not how the bitness denomination pans out* but how (as has been commented above) the potential for ARM `netbooks' (and the iPhone/iPod for that matter, which in some ways already are `netbooks') shakes up the field.
If someone were to hear that iPhone runs Mac OS X (or a cut down version thereof) they might try to copy their programs onto the iPhone from their Mac Desk/Lap-top. At the moment the average end user cannot do this (those that do know how, generally also know why it won't work). However if Apple were to bring out a net-book which runs on ARM, with unrestricted file transfer via ethernet/wi-fi, suddenly they would have a big user-re-education problem in their hands.
`Universal Binaries' under their current definition will not run there - leading to end-user confusion, and potential seizures and hospitalisation - because end-users will see `Universal' and think it runs on everything. Given Apple do not want to be responsible for this (or the lawsuits that would follow) they will need to do something about the `Universal' moniker before they release such a product. It will be interesting to see what.
My 2p
*32 bits addendum:
For those saying everything will go 64bit; that will (eventually) be true for drivers etc as ultimately 32bit kernels will die out.
However for user-space applications going 64bit, this is less likely, and why Apple probably won't care to market a 64bit slogan (or get it confused with `Universal'). 32bit apps will continue to run, and frequently run faster than their 64bit counter-parts. This depends of course on what the application needs to do. If it does need more than 32bits worth of RAM, it needs to go 64bit - end of story. Otherwise the reasons are not as compelling as have been made out earlier.
It is true that x64 gives access to extra general purpose registers, and this does mean fewer load/stores to shuffle numbers around from [disk to ram to] cache to register and hence faster execution. However, it also means that every time the program is chasing a pointer (and some programs that have to deal with large linked lists or tree structure have to do this a lot) are having to operate on 64bit values. This is (comparatively) slow. Too much of this will far outweigh the benefits of the extra registers.
For as long as 32bit has its own subsystem and does not need emulation in software to run, there is little reason for Apple to push/promote 64bit user-space applications.
If it's true that OS X must load all the 32-bit library upon launching a 32-bit app I think there will be a chorus of people wanting everything to be 64-bit just from an efficiency/resource perspective.