Re: Why Snow Leopard will Bomb.

Hmm. I originally made this post a week ago and the server (the free
news.motzarella.org service, which I'd recommend against using) never
seems to have propagated it. Reposting.

In article <s_udnQ79mpBptoTXnZ2dnUVZ_r6dnZ2d@xxxxxxxxxxxxx>,
"Dan Johnson" <danieljohnson2@xxxxxxxxxxx> wrote:

"ZnU" <znu@xxxxxxxxxxxx> wrote in message
news:znu-C20462.18492423052009@xxxxxxxxxxxxxxxxxxxxxxxx
I mean, AT&T is not going to subsidize Apple's hardware for kicks. They
will
do so only for devices that they have sufficient control over, like the
iPhone. Any such device is not going to be a personal computer as the
term
is usually understood.

AT&T provides subsidized wireless connect cards for personal computers,
so I don't see why they'd be unwilling to subsidize a computer that came
with 3G hardware built-in.

Those things are like fifty bucks unsubsidized. Even a real (ie, cheap)
netbook costs a lost more than that. And we're talking about a full-price
(ie, expensive) Apple netbook being subsidized down to competitive levels
here.

They've been subsidizing them for quite some time; they used to be
substantially more expensive. And AT&T subsidizes other devices, such as
the iPhone, to the tune of $300. In general, I see absolutely no reason
why, if Apple decided to sell a $500 netbook that required a two year
service contract with AT&T, AT&T would not be willing to subsidize it to
precisely the same level as they do with the ~$500 iPhone.

Maybe if AT&T were deriving app store or music store revenue from the
iPhone I could see there being a difference policy... but Apple has kept
them completely out of those revenue streams.

Even if they did this, an expensive laptop that someone else is paying
for
is still an expensive laptop, and not a netbook.

Meaningless argument over definitions.

I can't agree. "Subsidized" cell phones and such aren't free- you're paying
for them with the service, over time.

I'm not sure I understand your point.

I think this would hurt their image, even if it went perfectly. Apple has
some very nice snob appeal, and they would find it hard to keep if just
anyone could afford a Mac.

You seem to be making the same "premium" vs. "luxury" error that Daring
Fireball recently pointed out Microsoft's new "Macs are too expensive"
ads make. People buy Macs because they want a premium product; not
because they want something made exclusive via artificially high prices.

This seems poorly phrased. A "premium product" may simple mean a more
expensive one; you mean, I think, that the Mac is better and would still be,
even if cheap.

A premium product is one that costs more because it's better; a luxury
product is one that costs more in part simply to create artificial
exclusivity. When Microsoft compares a $700 HP notebook to a $2800
MacBook Pro and has "regular consumers" saying things like "I guess I'm
not cool enough to be a Mac user", this strongly implies that the two
machines are not materially different and the only difference is an
artificial exclusivity. In reality, of course, the MBP absolutely
crushes the HP notebook. (Possibly literally, given the construction
materials. Heh.)

However, even if the Mac were superior, part of its appeal is snob appeal.
This would be lost if it were commonplace. If it were genuinely better, and
also cheap, would you not expect it to become commonplace?

I simply disagree that "snob appeal" is actually a significant reason
why people buy Macs. Snob appeal is the only reason to choose luxury
products, so if the Mac were actually a luxury product one could safely
assume it was being chosen for that reason. But the Mac is, instead, a
premium product, and I believe the vast majority of people who buy Macs
do so because they want a better computer and consider the Mac to be
one, not because they want a more exclusive computer.

Beyond that, Apple has had some notable quality control problems even
with
the expensive products they have offered. I would fear that if they went
downmarket, this problem would worsen. If Apple did ship a lot of
defective
units for cheap, that would surely hurt the brand, no?

Apple only has "notable quality control problems" if one judges them
relative to some sort of hypothetical standard, not when judged next to
actual real-world competitors. Survey after survey shows generally
higher reliability for Apple products, and there is

Survey after survey shows that Apple's customer's give it high marks. But I
do not think you can seriously argue that Apple's QA is substantially
*better* than the norm in the industry, and I feel sure that it would be
negatively impacted if they had to cut costs.

Therefore, if Apple shipped cheap netbooks, those netbooks would suffer
poorer QA than the industry norm.

You have no argument. You basically seem to be saying that despite the
fact that Apple machines cost more and the fact that Apple's customers
give it comparatively high marks, you nonetheless believe that Apple's
machines are at or below the industry norm for quality. It would be far
more reasonable to assume that as a result of higher per-unit cost and
various other Apple practices, such as offering a narrower set of
hardware than, say, Dell, Apple's quality is in fact above average, and
the marks Apple receives from its customers simply reflect this.

[snip]

Moreover, a reasonable estimate of OS X development costs suggests they
make enough money solely from boxed retail upgrades alone to fully fund
development, so they effectively can the OS away for free with every
Mac.

Where on earth did you get that "reasonable estimate"? How was it arrived
at?

Apple sold 2M boxed copies of Leopard in the first week it was on the
market.
[snip- multiply by unit price, compared to total R&D, etc]

This seems very unsophisticated, somehow.

Yet you don't describe how.

Look, obviously an analysis this simple isn't going to produce terribly
exact numbers. But it doesn't particularly need to; it made assumptions
that were extremely generous to opposing side (the OS X team is twice
the size it was in 2006, Apple has only sold 4M copies of Leopard), and
still came up with numbers that weren't even close.

They do certainly know a thing or two about plastics, but perhaps not so
much about cheap. In any event, it would again hurt their brand if they
shipped a generic-looking case.

A nice looking polycarbonate case doesn't necessarily cost more than an
ugly one. If we were talking about desktops there would be a notable
difference; a good polycarbonate or metal case is going to cost a bunch
more than a typical *** metal case. Even for larger laptops there's a
difference, because you benefit from using better materials to improve
rigidity. But for a 9" netbook... the machine is so compact that
rigidity is not a serious challenge and the amount of material is also
so small that it doesn't necessarily cost much more do use something
better.

This is seriously unrealistic. Those netbooks use the cases they do because
it's the cheapest way to do it. If Apple does likewise, it won't stand out
from the crowd.

If you look at something like the Dell Mini 9, it has a decently thick
polycarbonate shell. It's not even particularly bad looking. To the
extent that it doesn't look as nice as Apple's polycarbonate shell
notebooks, it's mostly a matter of contours, proportions, and coloring.
These are not things that cost money to change.

[snip]
Um... I'll give to Exchange support. If you want anything else, you're
going to have to fight for it.

Well, I noted in an overly technical thread some time ago that, so far as
can be seen from the leaks, "Grand Central" is a package of technologies
MS
does already have; the key piece went in with .NET 2.0, shipped 2005.

Be specific.

The "key piece" is closures; these allow you to specify logic to run on your
thread pool in a very convenient way. The syntax in C# 2.0 looks like this:

delegate(int a, int b) { doSomething(a,b); }

The new 'blocks' syntax for Objective-C (and C, apparently) looks like this:

^(int a, int b) { doSomething(a,b); }

They don't have a keyword handy so they use '^' instead. It's similar
otherwise, and where it is different, it's worse. Most significantly, these
new blocks aren't compatible with C function pointers or Objective-C
selectors, so they can't be used with existing libraries too easily.

Blocks are necessary but not sufficient for Grand Central; I think the
automatic scheduling and management of them is more the point.

I have also noted that Snow Leopard is to bring a proper 64-bit
kernel, and perhaps a complete set of 64-bit apps as well. These
are both things 64-bit Windows has had for years now.

If one considers having shipped a 64-bit kernel the best measure of
success, Microsoft wins.

Naturally!

However, if one counts the percentage of the installed base who can
run applications which can use 64-bit addressing as the best
measure of success -- a more useful metric, I think -- then Apple
clearly wins.

I don't think your right here. You are counting every Mac that has
Leopard and a 64-bit capable chip, I believe- but many, many of those
Macs can't run 64-bit apps because no such app exists for them. Many
Macs run Safari, Mail, iLife- all 32-bit. Many run Photoshop or Maya
or something like that, all 32-bit again. Some of this stuff *can't*
be made 64-bit on the Mac due to the inadequacy of the 64-bit
frameworks.

Meaningless nonsense. There are few 64-bit applications primarily
because there are few applications that have any need to be 64-bit. As
I've pointed out to you repeatedly, 64-bit is of marginal benefit even
for Photoshop, with common use cases.

As far as Maya goes, yes, it has been prevented from going 64-bit on OS
X by the fact that the GUI API it was using wasn't 64-bit... but that
API isn't one of Apple's! Or at least not directly. It's Qt. At 64-bit
version of which was released for OS X last month.

You could argue that 64-bit Qt would have showed up sooner if Apple had
shipped 64-bit Carbon. The direct answer to which, I think, is maybe,
maybe not. The indirect and more meaningful answer is that the primary
effect of not shipping 64-bit Carbon so far seems to be that a bunch of
stuff is getting ported to Cocoa... which is pretty obviously the
precise outcome Apple wanted, and, I think, a more beneficial outcome
for the platform than making it OK to go on using an API with its roots
25 years in the past for another decade or two.

I suppose there are a handful of 64-bit Mathematica users, but I don't think
the fraction of the Mac installed base is very high.

Meanwhile, a handful of Windows users are running 64-bit word processors
for no apparently reason, and you consider that to be progress.

And, of course, I think we should compare absolute numbers here: the size of
the market for 64-bit apps on Windows or on the Mac, irrespective of how big
the corresponding 32-bit segment is.

Utterly meaningless, as I've already pointed out several times in this
thread.

I'm pretty confident that it does; but even if it did not, it would be a
barrier to portability, and a barrier to integration with other languages
and tools.

You might almost have something resembling a point if Objective-C wasn't
a superset of C and freely mixable with C++.

Objective-C provides fairly easy integration, but it is still a barrier. It
is not hard to invoke C code from Objective-C, and not much harder to invoke
C++. But the reverse is *not* true. You can't easily call Objective-C from C
or C++.

This sort of misses the point. You don't *need* to call Obj-C from C or
C++; because it's a strict superset, you have the compiler interpret
your C or C++ files as Objective-C or Objective-C++, and send Obj-C
messages via normal Obj-C syntax.

And C++ isn't quite freely mixable with Objective-C anyway: the situation is
quite a bit like C++/CLI. The memory management models conflict, and the
programmer has to reconcile the difference.

Sure. But as you point out, this is not unique to OS X. Semi- or
fully-automated memory management are not language-level features in C
or C++, so systems that implement these will do them in system-specific
ways.

As I've pointed out many,
many times before, about the only code you have to write in Objective-C
in an OS X app is code that ends up being platform-specific anyway
because of API differences.

If you do this, You're Doing It Wrong. Cocoa is pervasive, and you don't
just use it at the edges of the app- not if you want to gain the real
benefits.

This is silly. The primary benefits of using Cocoa everywhere are
related to developer productivity. No code requires less work for the
developer that code that is already written; wrapping cross-platform
code with Cocoa at the edges is an extremely common practice. Even Apple
uses it, as in WebKit.

Besides, even if Cocoa was meant to be used this way, it's a pain
to all the adapter stuff at the edges.



[snip]
I find the boasting about the iPhone's developer ecosystem to be pretty
silly, actually. It remains crippled by Apple's obsessive control, and as
a
"platform" it's rather less serious than, say, the XBox 360.

From what I can see, the apps that the iPhone has are of a fairly trivial
character. This is what you'd expect, given the extraordinarily risky
nature
of developing them.

Nice fear mongering.

Why, thank you!

Most iPhone apps are fairly trivial, but this has
far more to do with the nature of the device than the "risk" of
developing them.

There's something in that; the iPhone is a cell phone, not some kind of
little tablet PC. It's not a good form factor for any kind of heavy usage
anyway.

This may explain how Apple gets away with it. But it still means that the
iPhone isn't really much of a "platform". I think my analogy with the XBox
holds up.

When actually compared with other smartphone platforms,
the iPhone tends to have substantially more sophisticated apps.

I don't see this. Could you give an example?


--
"The game of professional investment is intolerably boring and over-exacting to
anyone who is entirely exempt from the gambling instinct; whilst he who has it
must pay to this propensity the appropriate toll." -- John Maynard Keynes
.

Loading