On Sun, 12 Jun 2005 10:13:53 -0400, Eric Dunbar wrote: > I see three confounding factors here. > > 1. Psychological. Now developers can code *just* for i86. Yes, they're > coding for two OSes but the CPU-specific compiled code is the same if > they're having to do processor-specific stuff (a la G4-specific code > for e.g.). They don't have to know anything about two set of > registers, different ways CPUs handle numbers, etc.
Unless they're intentionally writing incompatible code (and there are programmers who do that as part of their coding style), they already don't have to know anything about any of that. The programming language is an abstraction layer that insulates processor-specific stuff if used properly. Coders don't care what the CPU-specific compiled code looks like enough to even determine that the code is the same or not. From the coder's point of view, the OS's APIs are everything, and the CPU doesn't amount to much at all. The only exception is the writing of special code for specific processors, and the OSX-x86 APIs do not allow coders to even do that all without jumping through special hoops. > 2. "Fat binary" tools come on the market that will compile an app for > i86 and generate a fat binary that will run under both Windows and OS > X (and, when that happens, Linux may come along for the ride so that > would be good for Linux). It looks like you don't understand the concept of a fat binary. When a compiler is directed to generate a fat binary, it generates the SAME code for multiple different CPU architectures and ABIs. You need different code for different APIs. Apple and Microsoft do not provide a common API between Windows and OSX. Third-party APIs common to both have always existed, but the culture of Windows coders has never accepted them with any popularity, and as a direct consequence, porting of code for Windows to any other API, and therefore any other OS, is something that generally doesn't happen. Most code is relatively ABI-neutral, but API-neutral code is a contradiction in terms. Fat binaries run natively on any system they support, and to run natively on multiple OSes, you need a common API such as the one from Metrowerks to serve as an abstraction layer on top of the OS vendor's API. This is a fundamental difference from running non-natively using emulation, and I don't mean specifically CPU emulation. There is also API emulation, which is the method by which Linux binaries can be run under FreeBSD, and that's what WINE does. > 3. Direct access to h/w is just as discouraged under Windows as it is > under any other OS and will not really do much for 3rd party > developers. Gamewriters especially write and use their own libraries > and industry standard graphics programming languages. I don't know where you got that idea, but even if it were true, it wouldn't make any difference to a user unless the same "libraries and industry standard graphics programming languages" supported multiple OSes, like OpenGL does. Games generally do not get coded exclusively using OpenGL or any other multi-OS API. > The processor is much more than a coincidence. Codecs are often > written at a lower level and especially the multi-media ones that have > to use a lot of processor-specific stuff. They don't have to use it, but they do anyway, and that's a no-no under OSX-x86. > Granted they will call upon > system specific libraries BUT the difference between "Linux" and Mac > OS iX is that Linux is a hodgepodge of operating systems, libraries, > quirks and other such crud whereas Mac OS iX is ONE, and I repeat ONE > OS, supported by ONE company with a proven track record. Not only > that, but when you compile an app/plug-in for OS X that uses > Apple-approved and supported APIs you won't have to recompile your app > every time a library is updated! Yes, and this is exactly why an OSX codec is an OSX codec, while a Windows codec is not and never can be. > The other thing about Linux users is that many they want their > software to be "open source". Many plug-ins are *NOT* open source and > never will be since they use proprietary solutions to problems (and, > it wouldn't exactly be wise to give away your bread and butter). Linux > users just don't constitute a large enough *PAYING* market to justify > the expense of supporting ALL THOSE distros and ALL THOSE PROBLEMS > (Linux ain't exactly a walk in the park... I just pooched my Ubuntu's > X.org and now have to figure out how to use CLUI tools to login to my > server to back up my home directory before I "trouble-shoot" (which'll > probably entail format and install anew ;-). Linux users like free (as > in speech) and it seems like they like free (as in beer) even more. Windows users like "free as in beer" even more than Linux users do, and the bulk of codecs for Windows are free as in beer, but not free as in speech, i.e. not open-source. "Paying customers" refers to content providers, whose *NIX market share is far greater than among ordinary users. Linux users' desire for software to be open-source has not affected the availability of non-free (as in speech) codecs for Linux much. > Moving to i86 (not x86 since they're only talking Intel so far) will > bring a *lot* of benefits for Mac OS X users (and Mac Linux users... > though, it seems like YDL won't follow... I guess that makes sense > since Fedora and Ubuntu (which I think will supplant Debian as the > Debian distro of choice) are already well established on i86). What do x86 Linux users currently have that PPC Linux users don't? Not that much. What OSX-x86 users would have that OSX-ppc users don't would be comparable to that. The benefits of moving OSX to x86 aren't really benefits, and I can elaborate on why any such benefit you can list isn't really a benefit. The exception to that is that I can't counter the promise of faster processors with less physical overhead in the future. Before I continue, I think it's worth bringing up the phenomenon of the most popular Linux security exploits really being x86 processor exploits. PPC Linux users are immune to them, but people who run Linux on Intel Macs won't be. Debian as the Debian distro of choice? Depends on whose choice you mean. If you mean a desktop-based computer user such as yourself, I'd be astonished if Debian (the distro) were ever a first choice. Ubuntu is improving, but their competition as a Debian desktop distro of choice on x86 isn't Debian, but MEPIS. Fedora Core can never replace YDL, even on x86. If you want YDL on x86, Fedora is NOT your answer. > I think the place where we'll see real progress (as Mac users) is in > the realm of fat binaries and not in the use of WINE. Compilers and/or That's nothing new. Fat binaries (m68k/ppc) were a monumental accomplishment under the old Mac OS, but the fat binaries (i386/ppc) that the creation of Darwin introduced some half-decade ago were already anticlimactic. There is no more "progress" to be made in the realm of fat binaries. > libraries that can be used on both Windows and Mac will appear > (whether supplied by Apple or some third party). This will greatly > simplify development for both platforms since the same i86 coding > tricks to speed up performance will work for both platforms, and > OS-specific stuff can be handled by a "higher level" library. As I said above, that's nothing new, either. It already greatly simplifies development for both platforms, but only for coders who choose to use those libraries, and such coders are a rare breed indeed. > With a bit of imagination there's a *lot* that can be done now that > Apple's i86. I think in some ways we over-estimate the importance of > CPU since the same code (BSD) has been compiled for both x86 and PPC > with the same success (back in 2000 people were already compiling x86 > Darwin in public), but in other ways the psychological importance of > i86, both for developers and users cannot be underestimated. I see > good things coming from this move. A lot can be done, but almost none of that is new. It could always be done before. You're right that the importance cannot be underestimated in that if you try to underestimate it, you still won't be underestimating it. > Apple has been making good strategic decisions for its future in > recent years: iMac (need I say more :-); moving to OS X; making an > affordable consumer laptop and a killer pro laptop; and taking the MP3 > player market by storm with the iPod series (that was a stroke of That is an undeniable fact. > genius). And, what is good for Apple is good for us Apple > afficionados. That, however, is a logic-defying myth. > They take tried and tested ideas and revolutionise them > *before* anyone else does so, and they often do it right. Another fact, but one that, fairly or unfairly, paints Mac users as early adopters, with all that that implies. > I'd happily switch to another OS and/or hardware manufacturer if the > quality and experience were right, BUT, with Apple and its Mac you > know what you're getting, and you know how long you can rely on them > (that is perhaps their strongest point and why users have stuck with > them through thick and through thin). That was in Apple's interests before, but the success of the iPod seems to be saying to Apple that such reliability may no longer be in their interests. That is changing the landscape of the market forever, and in ways that will not be fully understood for quite some time. > If you are the first adopter of a new technology you know you won't > get software support for long (e.g. Macintosh (128), PPC x1x0/x2x0, > Beige G3/PB3400). That's a principle that's well known and understood > in the tech universe and not special to Apple (and, if you don't > understand that then you probably shouldn't be an early adopter and > shut up if you ever try to whinge (I love knocking those people down a > peg or two ;-)). It seems that Mac users truly tend not to understand that. What else can explain the mind-boggling percentage of OSX machines that have already been upgraded to Tiger? > (in general) If you buy a product that isn't the first in its category > you will have support for YEARS to come, and, if you buy something > near the end of its life cycle you know you'll be left without > software updates pretty soon. Both have advantages and disadvantages. > Buying early means you have the new tech for a long time but it > becomes dated after a while. Buying late means you have "new" tech for > only a short time, BUT, the software you run will never get "slower" > and more "bloated" because your system will be frozen in time. Again, not exclusive to Apple. What you left out was that buying in the middle of the life cycle is the worst of both worlds. > Apple's first line of Macs (68K) had a INCREDIBLY long life span. The > Mac Plus was still supported by an OS released TEN years after it was > released. My beloved Quadra 700 with a PPC accelerator likewise > survived for a whopping 8 years with new OSes. And, in the current > line-up the iMac from 1998 is still supported by the latest OS, 7 > years later and many B&W G3s from 1999 will undoubtedly be > *functional* with the latest version of an OS for even longer! Tiger only supports machines with built-in Firewire, so the iMac from 1998 that you mention is already frozen in time with its lack of Firewire. The lifespan of Apple machines is still incredibly long compared to Windows ones, but not compared to previous Apple machines. > The way Apple is now selling its OS upgrades as new versions of an OS > suggests to me that Apple *has already* been focussing on shifting its > business model to that of a hybrid OS-hardware manufacturer and not > just a hardware manufacturer that happens to produce an OS to sell its > h/w. I'll believe that when they take the restriction to Apple hardware out of their EULA, which won't happen as long as they know what's good for them. > I don't think so either b/c, if MSIE *really* is so integral to > Windows then having it run on another x86 OS would be admitting they > were lieing through their teeth during the anti-trust proceedings. You say that as if running it on a different CPU would be less hypocritical than running it on a different OS. Then again, let's not forget that Windows NT 3.51 was available for both x86 and PowerPC. _______________________________________________ yellowdog-general mailing list [email protected] http://lists.terrasoftsolutions.com/mailman/listinfo/yellowdog-general HINT: to Google archives, try '<keywords> site:terrasoftsolutions.com'
