In order to assert your point, you've had to conflate Apple's competitors (Nintendo and Sony) with users of the iPhone SDK. If this were to go before a court, they would ask what Nintendo and Sony could do to compete if apple were to attempt to exercise their market power "soley in terms of price". If they raised the $99 annual fee, as you suggest, this would actually put the iPod Touch in the same market as the Nintendo and Sony platforms (mobile gaming platforms with a high barrier to entry). This cuts against your original attempt to define the relevant market so that the iPod touch stands alone.
iPod Touch is the only handheld video game system that 1. allows part-time developers to make and publish apps and 2. is sold in U.S. and European stores.
This description does not rise to any legal standard for judging a monopoly that I'm aware of. You're attempting to describe a market in such a way that no other products match the description. Contrast this with what you see, for example, in T. Penfield Jackson's Findings of Fact document in the DoJ v MS case. (Note how it is defined in terms of market power, pricing, and what the alleged monopoly holder could do with that power to the prices)...
"33. Microsoft enjoys so much power in the market for Intel-compatible PC operating systems that if it wished to exercise this power solely in terms of price, it could charge a price for Windows substantially above that which could be charged in a competitive market. Moreover, it could do so for a significant period of time without losing an unacceptable amount of business to competitors. In other words, Microsoft enjoys monopoly power in the relevant market."
I think the question still stands: Precisely what monopoly does Apple hold?
Your bold statement about the design behind FAT binaries ignores an important historical use case: an operating system that was 4-way FAT for 68040, x86, PA-RISC, and SPARC.
If one's goal was to make a particular patch of land self-sufficient in its energy needs, the amount of energy produced per unit area would be an important metric, would it not?
...now I only need to come up with the perfect crime that only a person with no pulse could get away with and I can cash-in on a screenplay for an episode of CSI.
I remember the Clipper. I remember, back in '98 going to a state auction where lots of old furniture & equipment was being unloaded. They had maybe a dozen machines, and nobody bought them. I remember thinking that somebody, somewhere might like to port the linux kernel to them if they had the time & the right architecture documentation. It was hard to resist; like walking by puppies in the window.
Of course you are right to caution against the evils of the marketing literature. That's a good thing to remind people of. God knows I never tire of hearing it. Clearly your goal here is to prevent people from believing things about this technology that are not true, and that is laudable.
That is my goal too. My only skin in this game was to make sure that nobody assumed that the Apple C blocks extension was a necessary part of GCD and its use. A naive reader might have read your emphatic claim that "GCD from the programmers point of view within their application IS BLOCKS!", and left the thread not knowing that GCD can also be useful without these smalltalkish additions to C.
Sure, a lot of the real power of GCD rests on these closures, but not all applications need that sort of thing. Sometimes one is blessed with not having to share state among concurrent operations.
Whatever point you were trying to make didn't matter to me, because your whole rant seemed to be based upon a straw-man argument: wherein you would have us believe that someone claimed that apple invented the thread pool or closures or something.
I couldn't find where anyone actually made such claims, so I was tuning out everything except for those things that might misinform people about the system that was open sourced yesterday.
Blocks have some important properties that distinguish them from functions: they capture enclosing scope and can live beyond the lifetime of that enclosing scope. If the event handler that you want to put into a queue is an ordinary function pointer that has not captured enclosing state, you may do so. A type is provided: dispatch_function_t. Contrast this with dispatch_block_t while you're reading the API documentation. The very first paragraph under the heading "About Dispatch Queues" may help.
As someone with experience responding to retards, in particular those with inflated self-evaluations of competency.... the above comment is garbage. It's absurd that the above post could be useful to anyone evaluating libdispatch. In particular, it ignores the forgone conclusion that porting this to linux or windows would entail the standard macro preprocessor magic to replace the mach calls with equivalents for other target platforms.
Anybody actually evaluating libdispatch has seen ported C. Many times. While it's good to have a library that has already been ported, looking at the above comment, I think you'd have to be an idiot to think that the Mach primitives could not be conditionally compiled with #ifdef. Not to mention C++0x is a C++ standard, and this is a C library.
Actually, GCD from the programmers point of view is callbacks. For every function foo() in the GCD API that takes a block, there is a corresponding foo_f() that takes an ordinary function pointer. One can use blocks without using GCD. One can use GCD without using blocks.
Funny. I read the entire summary and can say unequivocally that I don't want *any* of that crap.
You simply rephrased what the AC said in a different way. Linux developers want what linux developers want, and they tend not to want what the average end user wants, and therefore the end product will never converge to something the average person desires. Is that really a controversial observation?
I'm not sure that bringing up CoreGraphics undermines anything, given that the marketing name for it was "Quartz". You're right that I left out a lot of uses of X. I'm sure one could come up with more.
These things happen. Sometimes words, and sometimes even letters, carry hype all by themselves. You wake up one day, and a capital letter X is all the rage. Apple buys NeXT, then you have MacOS X. Some agile methodology gurus want to sell some books and they invent eXtreme Programming. Microsoft, with a marketing department full of ironic hipsters from Seattle, decide that would make an awesome name for Windows XP too. X is everywhere.
Fast forward a few years, and the X is out, and the word Core is in. Live on the bleeding edge of the RedHat-derivitive universe with Fedora Core. Apple APIs abound: Core Data, Core Animation, Core Image. The megahertz race gives way to multicore.
X sounds cool. All by itself, it is one phoneme away from something that evokes coitus.
Core is hip, central, musical: hardcore, grindcore, metalcore.
Even the term for the captured state of an abnormally terminated computer program sounds cool: core dump.
None of those have the range necessary to overtake something at that speed. These are all anti-ballistic missiles, and the X-51 isn't a ballistic missile. At best, one would need one of these near the target site in order to get lucky. Given the purpose of the X-51, this seems unlikely.
Slashdot Mirror
Look up "chrome" in the jargon file. Read the definition. Think about it.
In order to assert your point, you've had to conflate Apple's competitors (Nintendo and Sony) with users of the iPhone SDK. If this were to go before a court, they would ask what Nintendo and Sony could do to compete if apple were to attempt to exercise their market power "soley in terms of price". If they raised the $99 annual fee, as you suggest, this would actually put the iPod Touch in the same market as the Nintendo and Sony platforms (mobile gaming platforms with a high barrier to entry). This cuts against your original attempt to define the relevant market so that the iPod touch stands alone.
iPod Touch is the only handheld video game system that 1. allows part-time developers to make and publish apps and 2. is sold in U.S. and European stores.
This description does not rise to any legal standard for judging a monopoly that I'm aware of. You're attempting to describe a market in such a way that no other products match the description. Contrast this with what you see, for example, in T. Penfield Jackson's Findings of Fact document in the DoJ v MS case. (Note how it is defined in terms of market power, pricing, and what the alleged monopoly holder could do with that power to the prices)...
"33. Microsoft enjoys so much power in the market for Intel-compatible PC operating systems that if it wished to exercise this power solely in terms of price, it could charge a price for Windows substantially above that which could be charged in a competitive market. Moreover, it could do so for a significant period of time without losing an unacceptable amount of business to competitors. In other words, Microsoft enjoys monopoly power in the relevant market."
I think the question still stands: Precisely what monopoly does Apple hold?
Your bold statement about the design behind FAT binaries ignores an important historical use case: an operating system that was 4-way FAT for 68040, x86, PA-RISC, and SPARC.
Feel free to steal my sig. It's apropos.
If one's goal was to make a particular patch of land self-sufficient in its energy needs, the amount of energy produced per unit area would be an important metric, would it not?
...now I only need to come up with the perfect crime that only a person with no pulse could get away with and I can cash-in on a screenplay for an episode of CSI.
A shooting spree at the local mall gets media attention too, but I wouldn't want it associated with my brand.
...only works with IE and FF.
I remember the Clipper. I remember, back in '98 going to a state auction where lots of old furniture & equipment was being unloaded. They had maybe a dozen machines, and nobody bought them. I remember thinking that somebody, somewhere might like to port the linux kernel to them if they had the time & the right architecture documentation. It was hard to resist; like walking by puppies in the window.
Of course you are right to caution against the evils of the marketing literature. That's a good thing to remind people of. God knows I never tire of hearing it. Clearly your goal here is to prevent people from believing things about this technology that are not true, and that is laudable.
That is my goal too. My only skin in this game was to make sure that nobody assumed that the Apple C blocks extension was a necessary part of GCD and its use. A naive reader might have read your emphatic claim that "GCD from the programmers point of view within their application IS BLOCKS!", and left the thread not knowing that GCD can also be useful without these smalltalkish additions to C.
Sure, a lot of the real power of GCD rests on these closures, but not all applications need that sort of thing. Sometimes one is blessed with not having to share state among concurrent operations.
Whatever point you were trying to make didn't matter to me, because your whole rant seemed to be based upon a straw-man argument: wherein you would have us believe that someone claimed that apple invented the thread pool or closures or something.
I couldn't find where anyone actually made such claims, so I was tuning out everything except for those things that might misinform people about the system that was open sourced yesterday.
Blocks have some important properties that distinguish them from functions: they capture enclosing scope and can live beyond the lifetime of that enclosing scope. If the event handler that you want to put into a queue is an ordinary function pointer that has not captured enclosing state, you may do so. A type is provided: dispatch_function_t. Contrast this with dispatch_block_t while you're reading the API documentation. The very first paragraph under the heading "About Dispatch Queues" may help.
As someone with experience responding to retards, in particular those with inflated self-evaluations of competency.... the above comment is garbage. It's absurd that the above post could be useful to anyone evaluating libdispatch. In particular, it ignores the forgone conclusion that porting this to linux or windows would entail the standard macro preprocessor magic to replace the mach calls with equivalents for other target platforms. Anybody actually evaluating libdispatch has seen ported C. Many times. While it's good to have a library that has already been ported, looking at the above comment, I think you'd have to be an idiot to think that the Mach primitives could not be conditionally compiled with #ifdef. Not to mention C++0x is a C++ standard, and this is a C library.
Actually, GCD from the programmers point of view is callbacks. For every function foo() in the GCD API that takes a block, there is a corresponding foo_f() that takes an ordinary function pointer. One can use blocks without using GCD. One can use GCD without using blocks.
You might find the Plausible Blocks project to be useful in the interim.
If other compiler vendors don't pick it up (and they won't with a standards-based alternative)
What standards-based alternative do you have in mind? C++0x? You do know that's a C++ standard, right? Blocks are anonymous functions for plain C.
So why is it again that I would want an iPod or to run iTunes becaues any of that marketing jibber jabber?
Did someone say that you should?
I just can't legitimize spending that sort of money on something like that with [vaporware] around the corner.
Fixed for brevity
Look it up.
Hmm.... "lowest form of wit"... thank you.
Funny. I read the entire summary and can say unequivocally that I don't want *any* of that crap.
You simply rephrased what the AC said in a different way. Linux developers want what linux developers want, and they tend not to want what the average end user wants, and therefore the end product will never converge to something the average person desires. Is that really a controversial observation?
...and rare earth magnates at that, since most of us on this planet are not.
I'm not sure that bringing up CoreGraphics undermines anything, given that the marketing name for it was "Quartz". You're right that I left out a lot of uses of X. I'm sure one could come up with more.
True, but not terribly relevant to the trend. CoreFoundation may be that old, but CoreFoo didn't become a leitmotif until Tiger.
These things happen. Sometimes words, and sometimes even letters, carry hype all by themselves. You wake up one day, and a capital letter X is all the rage. Apple buys NeXT, then you have MacOS X. Some agile methodology gurus want to sell some books and they invent eXtreme Programming. Microsoft, with a marketing department full of ironic hipsters from Seattle, decide that would make an awesome name for Windows XP too. X is everywhere. Fast forward a few years, and the X is out, and the word Core is in. Live on the bleeding edge of the RedHat-derivitive universe with Fedora Core. Apple APIs abound: Core Data, Core Animation, Core Image. The megahertz race gives way to multicore. X sounds cool. All by itself, it is one phoneme away from something that evokes coitus. Core is hip, central, musical: hardcore, grindcore, metalcore. Even the term for the captured state of an abnormally terminated computer program sounds cool: core dump.
None of those have the range necessary to overtake something at that speed. These are all anti-ballistic missiles, and the X-51 isn't a ballistic missile. At best, one would need one of these near the target site in order to get lucky. Given the purpose of the X-51, this seems unlikely.