Apple VP: third-party iPhones apps to use digital signature

[AppleInsider]

When Apple finally opens its iPhone and iPod touch to third-party developers early next year, it will employ some extra measures to maintain the security and stability of the mobile platforms, such as requiring a digital signature on each authorized application.

The move, which chief executive Steve Jobs first alluded to in an open letter posted to the company's website in October, was further implied by iPod and iPhone marketing chief Greg Joswiak in a new interview with Fortune. In it, he explains that checking IDs at the door is the best way to keep developers honest, as it will allow Apple to trace the origins of any malicious code.

"That way if there’s something wrong with an application, you have a way to track it back to where it came from," Joswiak said. "So one of the things we want to do, again, is create a development environment that is going to maintain the security and reliability of the iPhone yet at the same time offer developers some really cool things that we can do."

Accomplishing both those tasks simultaneously is a challenge in that they run in opposition to each other, the Apple vice president admits, and that's why it will take until February before his company finally unveils all the details of the software development kit (SDK) for iPhone (and iPod touch).

"Of course what we want to make sure we’ve done is keep the phone safe and reliable, and that’s why it’s taken us a little while to get this SDK out," he said. "Especially now that we’ll have a real SDK which means legitimate developers are going to come into the space."

In addition to those "legitimate developers," Joswiak also expects the SDK to mark the arrival of smaller, grassroots coders, which he finds exciting.

"Sometimes these one- or two-person teams have created the most dramatic things," he said.

In his interview with Fortune, Joswiak also admits that it was his idea to push for Apple to produce a 14-inch iBook several years ago, despite reservations on the matter by Jobs. The notebook, which featured a larger screen than the remainder of iBook line, went on to be a runaway hit.

That revelation alone may offer some reasoning behind the company's reported decision to adopted a 13-inch display as the foundation for its upcoming sub-notebook rather than something smaller.

[ View this article at AppleInsider.com ]

[nagromme]

What kind of steps (and cost) are typically involved in creating a digitally-signed product? Do you use the same security certificate you would use on your web site?

[palegolas]

I have high hopes for this SDK. Hoping Apple let developers dig deep into the iPhod and not just crawl around on the surface. It'd be great with a safe baby-SDK for easy development, but in order to do these "really cool things" or these "dramatic things" I think the developers must be offered as much access as possible to the hardware. It seems this Greg wants this too if I catch the spirit right. Cool.

Oh yeah.. and let's pray these digital ID's don't cost a lot of money for the developers. That'd just cause more hacking spirit wouldn't it?

[nagromme]

In addition to multitouch, if devs can also access the tilt sensor (with full accuracy, not just 90-degree) and the vibrate action (gamepad-style force feedback) then the iPhone would be a pretty unique game machine.

[SpamSandwich]

No comments from Apple on Android, huh?

[melgross]

Originally Posted by nagromme

What kind of steps (and cost) are typically involved in creating a digitally-signed product? Do you use the same security certificate you would use on your web site?

It doesn't look to be much in the way of cost. We don't know yet if apple will charge for a service here, or whether it will be automatic.

Nokia charges each developer a tiny $20 fee, as Jobs stated that Nokia was on the right track, it could mean that Apple will likely charge a small fee, or, possibly, nothing at all.

Since Joswiak was so excited about those one and two developer teams, Apple can't be charging an arm and a leg.

This does sound very good. But, we still have at least two months to go.

Hopefully, something will be explained, and unveiled, at Macworld 6 weeks from now. I guarantee, that time will come up very quickly.

[pmjoe]

Originally Posted by nagromme

What kind of steps (and cost) are typically involved in creating a digitally-signed product? Do you use the same security certificate you would use on your web site?

The steps are pretty simple, you usually just run some program that uses a certificate to sign the code (OK, I'm oversimplifying it, but usually once you do it the first time, it's pretty easy to write a script that'll do it for you).

Cost and same certificate as a website? No, code signing certificates are typically different and more expensive. Not prohibitively expensive, but ~$300/year or more isn't cheap either for Joe Schmo to give away his free app. Maybe Apple will offer something themselves through their developer's program/website to keep it affordable. Or they could support something like CAcert.org (free) certificates.

The whole thing is somewhat stupid. All that code signing does for you is verify who signed the program you are installing (assuming they've kept their private credentials secure); it does not guarantee a program is safe. If you use discretion in where you download your programs from in the first place and look at reviews from other users to see how stable/safe the software is, you're likely to be better off.

[melgross]

Originally Posted by palegolas

I have high hopes for this SDK. Hoping Apple let developers dig deep into the iPhod and not just crawl around on the surface. It'd be great with a safe baby-SDK for easy development, but in order to do these "really cool things" or these "dramatic things" I think the developers must be offered as much access as possible to the hardware. It seems this Greg wants this too if I catch the spirit right. Cool.

Oh yeah.. and let's pray these digital ID's don't cost a lot of money for the developers. That'd just cause more hacking spirit wouldn't it?

Digital ID's are not a big deal to implement.

[backtomac]

I wonder if apps will be universal? I've a feeling that the iPhone will move to x86 when silverthorne hits the street. No sense in making the developers rewrite code again.

[melgross]

Originally Posted by SpamSandwich

No comments from Apple on Android, huh?

Do you expect one?

From what I've read about it, it seems to be considered to be complementary to the iPhone, rather than competitive.

Anyway, it's too new. A product won't arrive for some time, if at all.

[melgross]

Originally Posted by pmjoe

The whole thing is somewhat stupid. All that code signing does for you is verify who signed the program you are installing (assuming they've kept their private credentials secure); it does not guarantee a program is safe. If you use discretion in where you download your programs from in the first place and look at reviews from other users to see how stable/safe the software is, you're likely to be better off.

You're missing the point here. No one has ever said that digital signatures ensure that a program will be safe.

If you re-read the article, you will see why they are wanted.

...he explains that checking IDs at the door is the best way to keep developers honest, as it will allow Apple to trace the origins of any malicious code.

[melgross]

Originally Posted by backtomac

I wonder if apps will be universal? I've a feeling that the iPhone will move to x86 when silverthorne hits the street. No sense in making the developers rewrite code again.

That would be up to the developers, wouldn't it? Even for the computer platform itself, developers decide this.

While I agree that Apple will likely move to the x86 platform (I'm hoping they do), it's just not likely that Apple will tip their hand this early by providing for universality in this first SDK. Developers would have to figure it out themselves, which would possibly not be aided by Apple's software, because it's written for the PPC-x86 transition.

But, code for the iPhone/iTouch universe will be much smaller, and simpler, than that for the Mac platform, due to memory and processor limitations, so re-writing this will be much easier in the future. If Apple then does offer a path, that will be easier as well.

[Feynman]

Knowing Apple, the SDK will be apart of Xcode and will just require a single click to encrypt it, or nothing at all - it will just all be built into the development process.

At least Apple is smart to release the SDK now so then they could have a new contest at WWDC next year!

[backtomac]

Originally Posted by melgross

That would be up to the developers, wouldn't it? Even for the computer platform itself, developers decide this.

While I agree that Apple will likely move to the x86 platform (I'm hoping they do), it's just not likely that Apple will tip their hand this early by providing for universality in this first SDK. Developers would have to figure it out themselves, which would possibly not be aided by Apple's software, because it's written for the PPC-x86 transition.

But, code for the iPhone/iTouch universe will be much smaller, and simpler, than that for the Mac platform, due to memory and processor limitations, so re-writing this will be much easier in the future. If Apple then does offer a path, that will be easier as well.

Good points mel. Just been wondering about it.

BTW a bit off topic but I wonder if Apple will try to gobble up all the silverthorne cpus like they did with flash memory? Wouldn't that be a sneaky little move on their part?

[BRussell]

Digital signature is fine, but I want to know if they'll require that apps be distributed through the iTunes store. That's the real difference - does Apple have to approve every app and offer it through them, or will we be able to just install whatever we want. And if we can install whatever we want, how will the installation be implemented? It will use iTunes in some fashion, presumably.

[pmjoe]

Originally Posted by melgross

You're missing the point here. No one has ever said that digital signatures ensure that a program will be safe.

If you re-read the article, you will see why they are wanted.

If you re-read posts in other threads on this topic, you'll see why such a disclaimer is needed. For that matter, "Of course what we want to make sure we’ve done is keep the phone safe and reliable [...]," Joswiak said.

If you want to go by the, "best way to keep developers honest, as it will allow Apple to trace the origins of any malicious code," quote ... this comes across as Draconian. At what point is Apple going to treat a bug or feature for that matter as "malicious", and what steps are they going to take to keep a developer "honest"? There are plenty of legitimate programs out there that some people consider to be unsafe, spyware, etc. because of the way they function and not because of malicious intent.

[TenoBell]

There are plenty of legitimate programs out there that some people consider to be unsafe, spyware, etc. because of the way they function and not because of malicious intent.

You elect to download the app. So why would people download an app they found malicious? Or delete it if they don't like what it does.

The point of this is to be able to trace an app back to its origins. If the developer has no malicious intent this should be no problem.

[Hattig]

Originally Posted by BRussell

Digital signature is fine, but I want to know if they'll require that apps be distributed through the iTunes store. That's the real difference - does Apple have to approve every app and offer it through them, or will we be able to just install whatever we want. And if we can install whatever we want, how will the installation be implemented? It will use iTunes in some fashion, presumably.

If it is like the Podcast search function that would be great. Search for applications by category, get updates automatically, etc. It seems like the logical place to centralise applications, rather than 1001 different websites with different install mechanisms.

I'll be getting an iPod Touch come SDK release time (esp. if there is a 32GB one by then) so I can get to grips with programming this particular beast, and trying out other people's software (nethack, c'mon! err, that'll require some ingenious thought as to input methods!).

Digital Signatures also mean that if another application or a hack or something alters an application's code, etc, then the signature will be wrong and the application hopefully will not run. Pretty much like on desktop Leopard. This is a good thing.

[backtomac]

Originally Posted by Hattig

If it is like the Podcast search function that would be great. Search for applications by category, get updates automatically, etc. It seems like the logical place to centralise applications, rather than 1001 different websites with different install mechanisms.

I'll be getting an iPod Touch come SDK release time (esp. if there is a 32GB one by then) so I can get to grips with programming this particular beast, and trying out other people's software (nethack, c'mon! err, that'll require some ingenious thought as to input methods!).

Digital Signatures also mean that if another application or a hack or something alters an application's code, etc, then the signature will be wrong and the application hopefully will not run. Pretty much like on desktop Leopard. This is a good thing.

How are you going code your app, universal or ppc only?

[melgross]

Originally Posted by pmjoe

If you re-read posts in other threads on this topic, you'll see why such a disclaimer is needed. For that matter, "Of course what we want to make sure we’ve done is keep the phone safe and reliable [...]," Joswiak said.

If you want to go by the, "best way to keep developers honest, as it will allow Apple to trace the origins of any malicious code," quote ... this comes across as Draconian. At what point is Apple going to treat a bug or feature for that matter as "malicious", and what steps are they going to take to keep a developer "honest"? There are plenty of legitimate programs out there that some people consider to be unsafe, spyware, etc. because of the way they function and not because of malicious intent.

What you have to do is to listen to the LATEST comments by an Apple executive, who, presumably, knows what he's talking about.

Nowhere has it EVER been said that digitally signing software assures safe code. Nowhere!

The concept has always been that developers who DO sign their software will not want to write malicious code, as it can be traced back to them.

But, it does not ASSURE that code won't have bugs that would result in being malicious. The signiture will make it easier to fnd that code on your device, so that it can be eliminated, or fixed.

That's all.

This should be obvious.


Personally, I don't want software that does something not recommended by the maker of the device, in this case, Apple.

If they say, as they always have in the past, that certain memory allocations, etc. are not to be used, then as far as I'm concerned, code that does use it is a problem. It doesn't have to be malicious, but if it causes problems, then it should be pointed out.

Application enhancer programs such as the one we all know cause problems, shouldn't be used at all, even if it gives one benefits. That's an example of bad programming practice.

Sometimes, even if there are features we want, they shouldn't be used if they don't follow the rules.

Most of the time we hear of people having problems, it's because of poorly written programs.

If digital signatures will let us find out which programs they are, I'm all for it.

If Apple can then ban those programs, I'm all for that as well.

What I find interesting is that most of these bad programs duplicate features that other programs do without the bad code.

[Cleverboy]

Wow... "legitimate developers", that's going to go over well. I remember working at a company where the bosses excused the programmers by saying, "We just want to meet with the creative people". Even though "creatives" is pretty clear in meaning, one of the programming guys got really offended. "--What I can't be creative???"

~ CB

[gsmumbo]

Originally Posted by melgross

What you have to do is to listen to the LATEST comments by an Apple executive, who, presumably, knows what he's talking about.

Nowhere has it EVER been said that digitally signing software assures safe code. Nowhere!

The concept has always been that developers who DO sign their software will not want to write malicious code, as it can be traced back to them.

But, it does not ASSURE that code won't have bugs that would result in being malicious. The signiture will make it easier to fnd that code on your device, so that it can be eliminated, or fixed.

That's all.

This should be obvious.


Personally, I don't want software that does something not recommended by the maker of the device, in this case, Apple.

If they say, as they always have in the past, that certain memory allocations, etc. are not to be used, then as far as I'm concerned, code that does use it is a problem. It doesn't have to be malicious, but if it causes problems, then it should be pointed out.

Application enhancer programs such as the one we all know cause problems, shouldn't be used at all, even if it gives one benefits. That's an example of bad programming practice.

Sometimes, even if there are features we want, they shouldn't be used if they don't follow the rules.

Most of the time we hear of people having problems, it's because of poorly written programs.

If digital signatures will let us find out which programs they are, I'm all for it.

If Apple can then ban those programs, I'm all for that as well.

What I find interesting is that most of these bad programs duplicate features that other programs do without the bad code.

I believe the developer should have the option to have it digitally signed. The user can choose to only install signed apps if he or she likes. As for the "

Personally, I don't want software that does something not recommended by the maker of the device, in this case, Apple.

"

I am running 3rd party apps on my iPhone right now and they aren't causing a problem. They aren't messing up my phone. And those are definitely not recommended by Apple.

[melgross]

Originally Posted by gsmumbo

I believe the developer should have the option to have it digitally signed. The user can choose to only install signed apps if he or she likes. As for the "

Personally, I don't want software that does something not recommended by the maker of the device, in this case, Apple.

"

I am running 3rd party apps on my iPhone right now and they aren't causing a problem. They aren't messing up my phone. And those are definitely not recommended by Apple.

I don't agree. Why should they be given that option?

Give some reasons. Testemonials don't count.

There are very few programs for the iPhone/iTouch right now. I would hope that most of the few that are available are testements to those parties who are on display.

But when there are hundreds of programs, thousands, it will be a different matter.

As far as I'm concerned, any developer who would refuse to sign their apps, would be suspicious.

I can't think of a single valid reason not to do so, and several that would be of concern.

[melgross]

Originally Posted by Cleverboy

Wow... "legitimate developers", that's going to go over well. I remember working at a company where the bosses excused the programmers by saying, "We just want to meet with the creative people". Even though "creatives" is pretty clear in meaning, one of the programming guys got really offended. "--What I can't be creative???"

~ CB

Well, should developers who require that someone take the chance of voiding their warrantee be considered legitimate?

I don't think so.

[TenoBell]

I am running 3rd party apps on my iPhone right now and they aren't causing a problem. They aren't messing up my phone. And those are definitely not recommended by Apple.

Just because there isn't right now does not mean there will never be. There are apps that cause unintentional problems on the Mac.

Luckily it seems the iPhone developers are fairly competent and honest. Since they are using vulnerabilities and are not really accountable. Someone could easily write an app that looks into your contact information, email, information, and text messages. Sending that information back without your knowledge.

[melgross]

Originally Posted by TenoBell

Someone could easily write an app that looks into your contact information, email, information, and text messages. Sending that information back without your knowledge.

Of course, despite his disclaimers, he doesn't know if it isn't already happening on his phone.

[minderbinder]

Originally Posted by pmjoe

The whole thing is somewhat stupid. All that code signing does for you is verify who signed the program you are installing (assuming they've kept their private credentials secure); it does not guarantee a program is safe. If you use discretion in where you download your programs from in the first place and look at reviews from other users to see how stable/safe the software is, you're likely to be better off.

It also can block out apps that circumvent limits like unlocking and ringtones. I bet apple also will have apps linked from their website, or iTunes, with the code registration, they'll know about all apps and can sort through them to find the ones they want to endorse.

[wizard69]

Originally Posted by melgross

While I agree that Apple will likely move to the x86 platform (I'm hoping they do), it's just not likely that Apple will tip their hand this early by providing for universality in this first SDK.

I don't think Intel can ever be competitive with ARM when performance is measured based on the power used for a given bit of logic. X86 just has to much dead weight in its architecture.

Developers would have to figure it out themselves, which would possibly not be aided by Apple's software, because it's written for the PPC-x86 transition.

But, code for the iPhone/iTouch universe will be much smaller, and simpler, than that for the Mac platform, due to memory and processor limitations, so re-writing this will be much easier in the future. If Apple then does offer a path, that will be easier as well.

I'm not sure at all that I follow what you are trying to say. Personally I don't see the iPhone universe as being smaller than the Mac Platform. If anything it will grow to be larger. The Cell phone market as a whole is already larger than the PC market. This isn't even taking into account Apple ship more newer TOUCH based devices. They upside potential is pretty huge.

In any event Apple just needs to add a cross compiler to XCODE and a few other tools to build the binaries. No big deal at all.

What apparently is a big deal is getting their security structure right so that it is effective but not limiting. Or they are making it out to be a big deal. I won't be convinced until the SDK is on the shelf for all of us to buy.

Dave

[Constable Odo]

Apple seems to be spending a lot of time and taking precautions that the iPhone becomes a dependable, solid platform, yet people keep screaming that Apple is a monster and control freak. They want to run any code just to get a couple of new apps on the iPhone. I really can't understand why users should have a need to do anything they darn well please just because they own something. Practically everything we do or own is restricted to some degree by laws or manufacturer's policies.

I know that a lot of third-party apps are available for other handsets, but I've heard that they aren't always that good. They can hog up memory and processor cycles and cause users to need to reboot their handsets. What's so great about that? Even using a Mac computer, I try not to fill it with needless programs that break or cause problems. I used to like to try betas and little utilities to make my Mac look better, but now I'd trade all that for stability. Kernel panics are a downright pain.

I don't own an iPhone (probably never will) but I would like to purchase an iPod touch when it's storage capacity increases. I'll wait until legal apps are made and won't complain about Apple being unfair and controlling. If I don't like the way they are doing things, I can always buy another product instead.

[JeffDM]

Doesn't ARM now have memory protections and capable of preemptive multitasking?

[melgross]

Originally Posted by wizard69

I don't think Intel can ever be competitive with ARM when performance is measured based on the power used for a given bit of logic. X86 just has to much dead weight in its architecture.

you haven't been following Intel's new mobile designs. They are very good. this isn't just my speculation.

I'm not sure at all that I follow what you are trying to say. Personally I don't see the iPhone universe as being smaller than the Mac Platform. If anything it will grow to be larger. The Cell phone market as a whole is already larger than the PC market. This isn't even taking into account Apple ship more newer TOUCH based devices. They upside potential is pretty huge.

Sigh! I guess there's always someone who dosn't understand my posts. I was, I thought, talking about program size. I thought that was obvious.

In any event Apple just needs to add a cross compiler to XCODE and a few other tools to build the binaries. No big deal at all.

No big deal at all. The question wasn't whether they would, or could do it, the question was about the timing.

What apparently is a big deal is getting their security structure right so that it is effective but not limiting. Or they are making it out to be a big deal. I won't be convinced until the SDK is on the shelf for all of us to buy.

Dave

I doubt if the security aspects are as big as they claim. I'm pretty convinced that their main concern is to have some control over what's being sold.

[melgross]

Originally Posted by Constable Odo

Apple seems to be spending a lot of time and taking precautions that the iPhone becomes a dependable, solid platform, yet people keep screaming that Apple is a monster and control freak. They want to run any code just to get a couple of new apps on the iPhone. I really can't understand why users should have a need to do anything they darn well please just because they own something. Practically everything we do or own is restricted to some degree by laws or manufacturer's policies.

I know that a lot of third-party apps are available for other handsets, but I've heard that they aren't always that good. They can hog up memory and processor cycles and cause users to need to reboot their handsets. What's so great about that? Even using a Mac computer, I try not to fill it with needless programs that break or cause problems. I used to like to try betas and little utilities to make my Mac look better, but now I'd trade all that for stability. Kernel panics are a downright pain.

I don't own an iPhone (probably never will) but I would like to purchase an iPod touch when it's storage capacity increases. I'll wait until legal apps are made and won't complain about Apple being unfair and controlling. If I don't like the way they are doing things, I can always buy another product instead.

I've used Palms, and Palm smartphones for a fair amount of time. Stability really isn't much of an issue.

Upon the rare occasion that the device freezes over a bad program, all I have to do is to push the reset. I've never lost any data, or anything else. This is a bugaboo.

[melgross]

Originally Posted by JeffDM

Doesn't ARM now have memory protections and capable of preemptive multitasking?

You want to preemptively multitask with such slow processors?

This can be done by simply stopping the program while another is open. Use the phone while looking something up elsewhere? That can be done already.

[JeffDM]

Originally Posted by melgross

You want to preemptively multitask with such slow processors?

This can be done by simply stopping the program while another is open. Use the phone while looking something up elsewhere? That can be done already.

Is there really that much of a performance penalty? I thought the only difference between the two is that it's hardware assisted. Cooperative multitasking is its own Achilles heel because it depends on everything cooperating.

[vinea]

Originally Posted by melgross

You want to preemptively multitask with such slow processors?

This can be done by simply stopping the program while another is open. Use the phone while looking something up elsewhere? That can be done already.

Because cooperative multi-tasking as you descibe sucks to code for.

A 620Mhz ARM isn't so slow that multi-tasking isn't useful. A 600Mhz PXA270 ARM is faster than a Pentium 90 which was faster than a Sun IPX workstation from the 90s.

We've had premptive multitasking for a long long time on processors much slower than what is in the iPhone.

I don't see the iPhone going x86 for at least a couple years. The power consumption difference is still going to be large enough that ARM maintains a significant advantage in the mobile domain even given the processing advantage x86 has over ARM on a per cycle basis.

[backtomac]

Originally Posted by vinea

I don't see the iPhone going x86 for at least a couple years. The power consumption difference is still going to be large enough that ARM maintains a significant advantage in the mobile domain even given the processing advantage x86 has over ARM on a per cycle basis.

Are you sure about that? i read an article at ars that suggested that silverthorne will have a power draw of 5w at load. It supposed to be pretty low. I don't know the power draw of ARM.

[vinea]

Originally Posted by backtomac

Are you sure about that? i read an article at ars that suggested that silverthorne will have a power draw of 5w at load. It supposed to be pretty low. I don't know the power draw of ARM.

The 90nm ARM11 with MMU + TrustZone + cache are .43 to .45 mW/MHz. For 1Ghz that would be around 450mW. The iPhone's 620Mhz around a thrifty 279mW.

http://www.arm.com/products/CPUs/ARM1176.html

The next gen 65nm ARMs will be less and run up to 1Ghz+. Still a year or so away.

Silverthorne is pretty low power...for x86. Targetted at the larger end of mobile...like UMPCs/MIDs and maybe iPhone+. Intel is scaling x86 down while ARM is scaling ARM up to higher performance. They certainly intend to duke it out in the next few years. Intel lost the last round selling off XScale to Marvell.

Moorestown in 2009/2010 will be the real contender vs ARM IMHO and not Silverthorne. 32nm is another break point. Few fabs will go 32nm...even companies like TI are stepping out at 45nm leaving it to big foundries like TSMC.

[melgross]

Originally Posted by JeffDM

Is there really that much of a performance penalty? I thought the only difference between the two is that it's hardware assisted. Cooperative multitasking is its own Achilles heel because it depends on everything cooperating.

All that is being done it to slice up the cycles amongst the programs. each program gets a percentage of the total, minus what the Os itself needs. It slows everything down. There are some efficiencies, of course, because each program isn't using all of the cycles, but still.

Once more cpu's were used in a machine, it began to become more practical.

[melgross]

Originally Posted by vinea

Because cooperative multi-tasking as you descibe sucks to code for.

No it doesn't. Every little program for my Palm 700p works that way. Many of these programs are a whole 50KB of code. Not much of a challenge.

A 620Mhz ARM isn't so slow that multi-tasking isn't useful. A 600Mhz PXA270 ARM is faster than a Pentium 90 which was faster than a Sun IPX workstation from the 90s.

We've had premptive multitasking for a long long time on processors much slower than what is in the iPhone.

Yes, but those machines weren't just phones. After all the I/O matters as well, which is why a mainframe with a slower processor can do much more work that a faster desktop.

I don't see the iPhone going x86 for at least a couple years. The power consumption difference is still going to be large enough that ARM maintains a significant advantage in the mobile domain even given the processing advantage x86 has over ARM on a per cycle basis.

I don't know if it will be at least two years, but Intel's got product that I'm talking about, that you mentioned, and should be out in 2009, 2010, linked to below.

http://www.anandtech.com/tradeshows/...spx?i=3103&p=2

[vinea]

Originally Posted by melgross

No it doesn't. Every little program for my Palm 700p works that way. Many of these programs are a whole 50KB of code. Not much of a challenge.

Gee...given I've actually written a program for PalmOS (once) and read the docs I happen to know that PalmOS has had a multitasking kernel.

http://www.access-company.com/develo...s.html#1046570

They just locked that away from 3rd party devs until...umm...cobalt. All apps ran in the UIAS.

Cooperative MT can/was done/faked using

1) Notifications
2) setjmp/longjmp and getSP/setSP macros to set the stack pointer.
3) something I hadn't bothered to learn since I was just fooling around.

Any mis-behaving app broke multitasking and there's always one. Or you could just live in your singly-threaded world which would have REALLY sucked if PalmOS didn't actually have a preemptive multitasking kernel and running Hotsync, TCP-IP, sound, etc as seperate system tasks in the background.

Oh, and I bet you haven't written 50KB of code so you have no clue as what is or isn't a challenge. It is often MORE of a challenge to write for resource limited mobile devices than for desktops.

Yes, but those machines weren't just phones. After all the I/O matters as well, which is why a mainframe with a slower processor can do much more work that a faster desktop.

Mainframes have zip to do with this discussion.

The point is that the iPhone CPU is not slow and an iPhone has about as much compute power as machines that vastly benefited from pre-emptive multitasking...which you actually had in your Treo.

I don't know if it will be at least two years, but Intel's got product that I'm talking about, that you mentioned, and should be out in 2009, 2010, linked to below.

http://www.anandtech.com/tradeshows/...spx?i=3103&p=2

ARM isn't sitting still either. 2010 should be a fight from from back here in 2007 the outcome can easily go either way.