asdasd

Beats said:

So they're re-releasing iPhone 8? WTF? We're supposed to be excited about it? Why not just call it what it is: iPhone 9.




Seriously was it that hard to do Apple?

melgross said:

anonconformist said:

melgross said:

asdasd said:

melgross said:

lkrupp said:

Any ideas on how Apple will handle the X86 code of current apps to run on ARM architecture? I am not educated on this. Is ARM close enough to X86 that the transition will be easy or will it require a Rosetta-like translation framework like the move from Moto 68000 to X86 did. Will we have universal binaries again or something else during the transition?

This is the problem I’ve been wondering about for some time. While some people dismiss this as an issue, or in most cases, don’t even think about it (aren’t aware it is an issue), it’s the biggest issue apple will need to deal with. In previous changeovers, even Apple was very lax in getting their own big apps out. It took a year for them. It took a long time for Adobe and Microsoft, with their massive software, to come over too.

ARM is not close to x86. It’s optimized for battery life over performance. Apple and ARM have made significant advances on that front, but the instruction sets are different enough. We know from previous attempts at emulation, that a processor family needs to be 5 times as powerful in order to be able to run software at the same speed as the family they’re emulating. This hasn’t changed. Microsoft supposedly does it now, with their “universal” sdk. But they don’t, really. They require software to be rewritten, and recompiled for ARM. And there have still been issues with performance, specific features and bugs.

im not saying it can’t be done, because obviously it can. But if Apple is really going to release a device next year, there will either be significant limitations, or they’ve figured out a way around them. My suggestion, which no one here has ever commented on, from my memory, is to add a dozen x86 instructions to the chip. It’s been found that 80% of the slowdown between chip families is from about a dozen instructions. The chip, or OS, could hand that over to those when native x86 software needs them. Individual instructions aren’t patented, or copyrighted, as far as I know. If true, that would give Apple a way around the problem.

I can’t emphasise enough that the vast majority of apps produced for the Mac right now will be a recompile and some won’t even need that. The compiler is doing the work if you use the Apple tool chain. 

Dont confuse the compiled machine code with the higher level frameworks that might be used. 

You shouldn’t, because it’s a myth. Yes, small apps can be recompiled, and will often work without more revision other than to fix bugs that always creep in when recompiling. But anything else needs to be rewritten.  It seems that people here forget the announcements that some developers have made during these transition periods in Apple demonstrations. They come out and announce how easy it was to get their massive app up and running in just a weekend. But then, it actually takes six months, or more, before that app is released. Why, because for the demo, they showed a few chosen features that worked out, after frenzied work. But the rest needed a good deal of work to function properly.

its incrediably naive to think that this will be easy.

I laugh when I read you making these insane claims.  If it takes a company 6 months to move only from one CPU to another CPU, where the APIs are identical, and they're not adding features/rewriting their applications in any meaningful way, then they're grossly incompetent.  Consider that when a new CPU/system comes out, they don't want to look bad compared to others, and it's a great time to add new features to show off the new CPU, assuming it gives any added power.  Short of them coding to the lowest-level CPU instructions for multimedia encoding/decoding or the like, assembly language is a major waste of developer time: incredibly few applications will get anything resembling the time/effort/cost back by rewriting anything in assembly language, because compilers more often than not do a better job with optimizations these days than the majority of the best hand-coded assembly language implementations.

When you talk of developers needing to rewrite their applications because of a new CPU, even a new family/ISA where all that's changed is the CPU architecture? NOBODY REWRITES ANY MAJOR CODE FOR THAT!  That's insanely stupid for many reasons (including economically) and plain WRONG.  No major operating system is unable to be readily  rebuilt for other CPUs with only a very tiny amount of low-level assembly, and 99.99%  (admittedly, a number that's guessed, but no more than your no-proof data) of user applications in the last 10 years won't have any hand-coded assembly, regardless of their size. 

The lowest-level language you'll find used in that percentage of apps these days is C.  While you can write it in a not-fully-portable manner because the C/C++ standards leave some details to the implementation of the vendors, it's actually very straightforward, even if you do convert between CPU architectures, to make the required changes to have the code work as it did before: it's not rocket science, it's not even interesting computer science.  If they do find a need to fix it to be portable, then they should ensure they never need to fix that again.

For most applications, it truly is as simple as flipping an Xcode selection, as long as you've written in a reasonably portable way.  It's not hard in Objective-C/C/C++ to do so, and Swift makes it easier.  Switching from 32-bits to 64-bits had the biggest change with Apple changing from regular floats to double floats for CGFloats, but that's not nearly the hardest thing to fix.  You don't know what you're talking about.

Yes, it took Apple a YEAR to bring Final Cut over. More than a half year to bring LOGIC pro over. It took both Adobe and Microsoft a year as well. It took WolframAlpha (the company doing the demo) about 7 months to move over. There are numerous other examples.

of course, by your thinking, they are all incompetent.

king editor the grate said:

I've long wondered about the installed base. I have 12 devices listed on my account; three are occasionally powered on but not generally used. Are all 12 counted toward active install base? I also have iPod touch 2g and 2009 MBP; the latter is often connected to the Net for iTunes Match while ripping old media, and Touch is used for music occasionally. Neither is listed in my devices. Do they count as install base? Maybe Apple drops devices from the count when they're declared obsolete?

christopher126 said:

AppleExposed said:

This day is depressing in retrospect as Steve was proud of his new invention. It was the new iPod and they believed it would be the only one of it's kind and rightfully so.

The 62% iPod marketshare should have easily translated to %70 iPhone marketshare.

The fact the U.S. and tech companies allowed android to create patent-infringing knockoffs just to make a quick buck for carriers who doubted iPhone is sad. Then came the commercials attacking Apple which created the rabid iKnockoff Knights who shit on everything Apple worked hard for THEM to enjoy!

You are so right. Schmit is a scumbag of the first order! What he did to Stevo was unconscionable!

I do think Apple may get its revenge, though. 'Privacy' or lack, thereof, may undo, to some extent, Google/Android!

Finger's crossed!

P.S. Lots of commas in this post, my apologies!