[OT] really?

[Daniel Gimpelevich]

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.