True, but in reviewing the above, one will notice that this only covers HARDWARE, not their software and not even their OS.
There is no rational reason to port OS software to de-supported hardware. If someone wants to play "stuck in time" with their Mac system they are better off coupling software stuck in time to it. Besides Apple the return on investment is extremely poor since the vast majority of users will abandon the hardware once de-supported and the die-hards that are left will generate higher than average support costs.
Indeed ... there were also many of us who have had G5 PowerMacs under the impression that we were getting 64 bit too...such as what the above Tiger statement gives the impression of.
This 32 or 64 bit kernel issues has been around for a long time. ( a quick google search for discussions of the issue
2006 here on Mac Forums
https://forums.macrumors.com/threads/255594/
[ Note here the Apple docs stated ".. Most device drivers do not need to change ..." . The most effective way of doing this is to leave the kernel 32-bit so don't break drivers. Apple "eased" the transition perhaps too much to the point where people who had no idea what they were reading were lulled into complacency with their ill conceived notions.
But yes, the general overall sloppiness of the notion of being a "64-bit" OS is being generated by the Users, not the Apple docs they actually link to. You can somewhat see how the Apple docs were revised over time with the section
" Beginning with version 10.4, Mac OS X supports command-line 64-bit executables on G5-based Macintosh computers and 64-bit-capable Intel Macintosh computers.
Beginning with version 10.5, Mac OS X supports full-featured 64-bit applications on G5-based and 64-bit-capable Intel Macintosh computers.
Beginning with Snow Leopard, Mac OS X uses a 64-bit kernel on some Intel computers."
https://developer.apple.com/library...rwin/Conceptual/64bitPorting/intro/intro.html
"executables" ( really applications without a GUI) and Applications are the only 64-bit porting option for 10.4 and 10.5.
]
2006 Just to show that now all the technical writing was confused about the issue ... from Dr. Dobbs
early in 2006 almost five months
BEFORE the Mac Pro 1,1 came out.
"... However, there is a 64-bit caveat: Support for 64-bit programming is not available throughout the entire OS X API for 64-bit computing on OS X Tiger. ... "
http://www.drdobbs.com/parallel/mac-os-x-tiger-64-bits/184406429
2009 At the Snow Leopard Transition
http://www.macworld.com/article/1142379/snow_leopard_64_bit.html
Apple KB arcticle on 10.6 32-bit vs 64-bit kernel booting.
http://support.apple.com/kb/HT3773
Understood, and while the 0th generation Intel Macs were indeed plunges, we should also recall that the Mac Pro was the last hardware to make the transition
This is not particularly material since the transition timeline was so short ("must move entire line up over to new platform in a 12 months" ) that development proceeded on all Macs in parallel fashion. There was no time to reflect upon what had already done with the other Macs to feedback into the Mac Pro. The transition was not that leisurely executed.
and since it was expected to be running with high end components by its product placement,
High end components and server like roles typically lead to longer product development cycles since those customers tend to be more intolerant of bug/defectives.
Particularly in light of the claims made in that recruitment video which came to light this past week, it is evident that there's a lot of areas where Apple isn't living up to their self-proclaimed and self-imposed standard of excellence.
Again this is more a miss-read of Apple is saying. Apple's whole "no detail is too small" will actually remove considerations for usage at end of life, not support it. Apple being "obsessive compulsive disorder" about what they can do
now with the technology they have
now means they they differ what they can do later with future technology to the future.
In 2006 Apple could ease the transition to 64 bits by support user-land/apps before the kernel. Apple kicked the 64-bit kernel down the road. Therefore the 2006-2007 Macs were optimally designed for 2006-2008 era Mac OS X. When 2008-2009 era comes then the Mac OS X target moved. There are downsides to a 64-bit kernel. For one they soak up more memory. If already have apps that soak up all the available memory then is actually a non-optimal feature.
So instead of getting an "OK" EFI32 and EFI64 out the door in 2006, Apple will concentrate on getting a "great" EFI32 out the door in 2006 and then work on a even greater EFI64 later on. Trying to do too many products and subcomponents at one time will pragmatically mean pulling resources away from some. For a fixed number of experts there is only so much they can work on at one time.
In contrast, Microsoft Windows 64-bit OS require all new drivers for the 64-bit kernel coupled to the 64-bit apps.
The intent at Apple is to somewhere over the 5-6 years the hardware is supported to come out with a new machine that is even better with the new tech and techniques they bring to the next, even greater, product for the user to transition to.
...and the demographic of the Mac Pro customer is all the more likely to be aware enough (and critical enough) to recognize these shortfalls as shortfalls.
This is more so a subset of the Mac Pro demographic that puts a high priority on "future proof" properties. "Great" does not mean lasts a long time; it means there is something it "needs" that isn't provided with the initial product but shows up later. As opposed to, "great" gets the most out of what is available at the time.
If the primary feedback clogging the "Mac Pro feedback" channel to Apple is about "how about firmware for 6 year old machines" then that isn't about work that is "going to change the world". The is just mundane maintenance code.