Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts tagged CPU

WWDC 2020 opens next June 22nd and all indications are that the highest-impact announcement will be the Mac’s migration from Intel to the ARM architecture.

While CPU architecture migrations are infrequent — they happen every decade or so — Apple has a good track record of pulling them off successfully.

The first major migration was the move from Motorola 68K to PowerPC chips around 1994, followed by moving from the Classic Mac System 9 to Mac OS X around 2000. Relevant here was that for some time Mac OS X ran older applications in the “Classic Environment”: a compatibility sandbox that emulated the APIs of System 9 and the instruction set of the 68K.

This worked reasonably well as PowerPC CPUs were several times faster than the old 68K ones. It also introduced the concept of “fat binaries“; the same application file contained code for both old and new environments.

A better historical precedent is the move from PowerPC to Intel processors in 2006. This was more traumatic for developers, as PowerPCs were “big-endian” and Intel CPUs were “little-endian”. This meant that, except for strings, values stored in memory, files or transmitted over networks had a different byte sequence ordering. To have the same program source code work on both systems you could no longer assume it would just work, but had to bracket your instructions with macros or function calls that would do nothing on one platform but swap bytes around on the other.

If you’re not an oldtimer like myself you probably never had to think about this — every Mac, iPhone, iPad, Apple Watch or Apple TV use little-endian values, and I even had to dig into documentation to make sure of it. ARM CPUs can be run in big-endian mode by setting a special bit at boot time but this is not the default, and no Apple device uses that mode.

Now, this meant that in 2006 developers could not just migrate their apps to Intel by recompiling; we had to look through every line to either check that it was endian-neutral, and if it wasn’t, those special macros had to be used. For people who had very CPU-specifically optimized code — perhaps even in (shudder) assembly language — separate code sections were necessary.

Having done all this, you recompiled your app twice; once for PowerPC, once for Intel; and the magic of fat binaries allowed you to ship it all in one app. Later on, some apps even needed 3 or 4 different code sections, depending not only on endianness but also on whether they would run on a 32- or 64-bit CPU!

Another — today mostly forgotten — aspect was that Apple prepared for the Intel migration by gradually modernizing and building their developer toolchain in-house. LLVM, Clang, LLDB etc. allowed Apple to ensure that, for whatever CPU they wanted to support, compilers were ready beforehand and could be optimized continuously later on, without depending on outsiders.

Still, in 2006 Apple had to ship special hardware, “Developer Transition Kits”, to select developers for testing. For software that couldn’t be converted to the new architecture, Apple introduced a limited compatibility box: Rosetta. If I recall correctly, it did on-the-fly translation of PowerPC code into Intel code, which was then cached. Because of its limitations it didn’t work for many larger applications and was soon phased out.

Moving in parallel to the PowerPC to Intel migration was a slower-motion shift in operating system APIs. Most notably, this involves Carbon and Cocoa.

Carbon was a C-based API introduced in 2000 to ease migration from Classic System 9 to Mac OS X. Cocoa, introduced around the same time, was an Objective-C based API for modern object-oriented programming, itself an evolution of NeXT’s OpenStep system. Underneath both APIs, in the now well-known layer model, was Core Foundation, which could be used from both types of apps; and some apps (like my own) could mix calls to both APIs with some care.

Not too long after the Intel migration, Apple announced that 64-bit was the future, and that Carbon would not be migrated to that environment. This process was stretched over several years and involved redefining what APIs were really considered “Carbon”; some, like the File Manager, were “de-carbonized” and lived on until macOS 10.5 (Catalina) came out.

Cocoa, on the other hand, continues to be used everywhere in macOS. The Finder, the Dock, Xcode, and Safari are all Cocoa apps. Even when Swift came out a few years ago most of it was built on top of Cocoa and Objective-C objects; the notable exception is the Swift toolchain itself.

So, after all this, here we’re looking at Yet Another Hardware Migration for Macs. Let’s look at the implications.

Economically, it makes sense for Apple, as many others have already commented. They’ll no longer be bound to a foreign evolution roadmap on which they have little influence. They have extensive experience in producing high-performance, low-power CPUs for their mobile devices, and the latest versions already outperform Intel in some situations.

Technically, it’s a huge win. Switching to ARM64 — and not just the standard ARMv8.x architecture licensed from ARM, but with their own, extensive modifications — will allow them to have unified GPUs, Neural Engines, memory controllers and so forth on all their line, with more uniform device drivers and low-level programming.

For 99% of developers, I think nothing will change. The new chips are little-endian also, so a simple recompile will have Xcode produce a fat binary for the new Macs which should run outright. Of course, if you have assembly language sections in your program and/or write kernel extensions/device drivers, time to learn a new architecture…

Snags will come for people who dislike, or can’t use, Xcode. Some have to use Intel’s compilers, for instance; I know too little about such cases to have an informed opinion, sorry.

Some pundits seem to expect a sudden concurrent change in macOS; something like Objective-C and/or Cocoa being obsoleted in favor of Swift and SwiftUI. Or even the Mac going away entirely, some sort of huge desktop iPad taking its place. In my view this won’t happen. For one, what would developers or even most Apple engineers use for development?

A big question is: will Apple be able to provide an Intel compatibility box on the ARM Macs? Certainly Boot Camp will not be available. Running a virtualizer like VMware Fusion or Parallels seems almost as difficult, unless the new CPUs have some sort of hardware assist to decode x86-64 instructions. This may not be as outlandish as it sounds; current Intel/AMD processors already break x86 CISC instructions into RISC micro-operations which are then cached and executed by the “inner” CPU. This is a gross oversimplification but in theory nothing — except silicon space — bars Apple from breaking x86 instructions into ARM instructions.

A Rosetta-like box seems more feasible for running individual Intel applications, but who needs that? Game users? Performance will be limited. Most virtualizer app users want the complete OS running and with native speed. Linux/BSD might be available soon; perhaps Windows for ARM.

But what about Catalyst, some of you may ask? Here I can only shrug. In its present form it certainly is not an important future technology for macOS. While simple apps can be done with it — perhaps purely for the benefit of developers unfamiliar with AppKit — can you envision a Catalyst Finder? SwiftUI is still very new and primitive, and will continue to be layered on top of AppKit/UIKit for some time. They may merge in the future, or be renamed gradually like Carbon was, but that’s a long time out.

Finally, hardware. I don’t think the existing A13 SoCs would be applicable to any Mac, though. Some version of the Mac mini would be the obvious candidate to be the first to get the all-new CPU. It would then percolate up through the laptop line and the iMac. In these cases, reduced power usage would be a bonus — even for the iMac, it would mean a smaller power supply, less heat and a thinner enclosure.

The Mac Pro should be the last Intel redoubt. Multiple CPUs, OEM graphic cards, generic PCIe cards — Apple will have to address a huge range of problems there and this will take years.

Enough handwaving for now; the usual disclaimers apply and I’m really looking forward to the keynotes next week.

Update:
— corrected date for the 68K->PowerPC migration. Thanks to Chris Adamson for catching the error.
— fixed some awkward language about virtualization. Thanks to Maurício Sadicoff.

Re: iPad time

No comments

Posted by richardl:

Rainer Brockerhoff wrote:

Via John Gruber, I just saw an interesting post by Steve Cheney:

It’s pretty evident that Apple isn’t wed to individual suppliers. Not only are they back to creating their own chips, but they are also one of the only ‘compute’ companies to have used each of the top 3 processor architectures over time – ARM, x86, and Power PC.

…This week Apple confined developers to a specific set of tools (XCode [sic]).

…By telling developers to move to XCode tools, Apple is setting the stage to potentially switch architectures.

…In 2003, Apple advised developers to switch to XCode tools. …2 years later Apple moved to Intel across its entire Mac line.

…perhaps the A4 is NOT an ARM architecture. In fact, it’s highly possible that the A4 is a dual core Power Architecture…

The last sentence is of course false, as Gruber says; the A4 does run ARM code.

While I don’t think that forcing developers to switch to Xcode (which is the correct spelling_ means that Apple will soon be switching architectures on their iPad/iPhone line, or on their desktop/laptop line for that matter, Xcode does offer developers a future-proof environment that hasn’t been commented on by other observers: the Clang/LLV project. Briefly, Clang is a compiler frontend for C-based languages, backed by LLVM – which stands for “Low Level Virtual Machine”. Both projects are heavily backed and staffed by Apple.

Clang has been increasingly supported by Xcode as a substitute for the gcc compiler toolchain. The details are quite esoteric, but one interesting capability is that C-based languages – C, Objective-C and C++ – are compiled to the LLVM bytecode, which is then translated into native machine language by a back-end. The last phase could even happen in a just-in-time fashion, allowing apps to be distributed in LLVM code (therefore running on all current and future Apple machines). Some groups are even working on chips that execute LLVM bytecode directly.

In other words, it’s no coincidence that Apple is now instructing developers to switch to Clang-supported languages and their Clang-wrapping IDE (Xcode). There may not be an architecture switch coming soon, but Apple will have much more freedom in doing their own CPUs for iPad/iPhone, and more ammunition in negotations with Intel and other top-end chip companies.

Rainer, it is interesting to note that Adobe built their ActionScript/Flash compiler for iPhone on top of LLVM.

http://cs.illinois.edu/news/2009/Oct8-2

http://www.adobe.com/devnet/logged_in/abansod_iphone.html

Re: iPad time

1 comment

Via John Gruber, I just saw an interesting post by Steve Cheney:

It’s pretty evident that Apple isn’t wed to individual suppliers. Not only are they back to creating their own chips, but they are also one of the only ‘compute’ companies to have used each of the top 3 processor architectures over time – ARM, x86, and Power PC.

…This week Apple confined developers to a specific set of tools (XCode [sic]).

…By telling developers to move to XCode tools, Apple is setting the stage to potentially switch architectures.

…In 2003, Apple advised developers to switch to XCode tools. …2 years later Apple moved to Intel across its entire Mac line.

…perhaps the A4 is NOT an ARM architecture. In fact, it’s highly possible that the A4 is a dual core Power Architecture…

The last sentence is of course false, as Gruber says; the A4 does run ARM code.

While I don’t think that forcing developers to switch to Xcode (which is the correct spelling) means that Apple will soon be switching architectures on their iPad/iPhone line, or on their desktop/laptop line for that matter, Xcode does offer developers a future-proof environment that hasn’t been commented on by other observers: the Clang/LLVM project. Briefly, Clang is a compiler frontend for C-based languages, backed by LLVM – which stands for “Low Level Virtual Machine”. Both projects are heavily backed and staffed by Apple.

Clang has been increasingly supported by Xcode as a substitute for the gcc compiler toolchain. The details are quite esoteric, but one interesting capability is that C-based languages – C, Objective-C and C++ – are compiled to the LLVM bytecode, which is then translated into native machine language by a back-end. The last phase could even happen in a just-in-time fashion, allowing apps to be distributed in LLVM code (therefore running on all current and future Apple machines). Some groups are even working on chips that execute LLVM bytecode directly.

In other words, it’s no coincidence that Apple is now instructing developers to switch to Clang-supported languages and their Clang-wrapping IDE (Xcode). There may not be an architecture switch coming soon, but Apple will have much more freedom in doing their own CPUs for iPad/iPhone, and more ammunition in negotations with Intel and other top-end chip companies.

Re: WWDC 2009

No comments

The conference will be over tomorrow and I’m quite satisfied with the outcome. Now for some comments about the announcements and (NDA permitting) about what I learned.

I had some vague idea of going to some iPhone sessions and letting presenters (or friends developing for the iPhone) convince me that I should start developing for it. No such thing happened; session overlap was so severe, and there were so many labs to go to, and people to talk to, that I skipped any non-Mac session or discussion. What little I heard in the corridors confirmed my notion that the current state of iPhone development and the AppStore deviates too far from my preferred position as a utility developer – a niche Apple still keeps closed on the iPhone. Maybe when the tablet comes out… icon_neutral.gif

Speaking of tablets, while everybody agrees that one is in the works, it seems to be a year or so away from announcement. (Ditto for the new CPUs I hinted at, in my last post.)

Snow Leopard is the small new thing. Small for the user in a sense; it’s just refinements and greater speed. For developers, though, it’s the BIG new thing. And, as variously described as early as a year ago (can’t find URLs right now), much of the new stuff is driven behind the scenes by open-source projects Apple is driving: the Clang compiler, the LLVM back end, and the technologies made possible by Grand Central Dispatch, blocks and OpenCL. So, most of the sessions either expanded on this directly or offhandedly mentioned “there’s an API for that now – and it’s fully XYZ-enabled” (insert one of the technologies above).

These things have become possible because CPU chips had run into a clock frequency “sound barrier”; 3GHz is about the maximum current silicon can do without extensive and expensive cooling or exotic technology. So multicore has become the solution du jour: all Apple computers now have at least 2 core, and the top machine has 8 (16 virtual). Expect that number to double every 2 years, at least.

But for years multi-processor machines were hard to program. About 14 years ago, at another WWDC I bought a Genesis MP 528: this Mac clone had 4 PowerPC 604 processors running at a blistering 132MHz. It didn’t have much caching on those chips, and only Photoshop and a few other specialized apps could see more than one CPU, and that only for image filters. In two years the first PowerPC G3 CPU card, with a single processor but caching, running at 300MHz, had about the same Photoshop performance – and that performance was then available to all apps. So why didn’t more apps take advantage of the 4 CPUs? The classic Mac System 7 (to 9) had no easy way to allow for this; there was a very primitive multiprocessing API but the system was pretty much locked out of it.

As said in the keynote, Snow Leopard will support only Intel Macs; PowerPC Macs are, therefore, stuck in the Leopard era, and only some few bug fixes will appear on 10.5, then it’s over. I couldn’t find hard figures comparing the installed base; I’ve seen percentages quoted of between 10 and 35% of Macs Macs still in use being PowerPCs. I personally didn’t think this would dip below 25% before 2011; then again, as a stockholder, I’m glad Apple sold so many new Macs recently… icon_wink.gif

Some people question why PowerPC users will be left out of the Snow Leopard advantages, and I think I know why. While the top 4-CPU PowerPC machines still can hold their own with more modern machines under certain circumstances, the vast majority of PowerPC Macs have only 1 CPU; only a few big desktops have 2, and even fewer have 4. Most advantages of Snow Leopard come into play when you have at least 2 CPU cores, and there’s serious testing and bug fixing to be done for supporting an entire architecture. Apple probably just weighed those factors (with better numbers than I have available) and decided it wouldn’t work out.

Positives of the new Clang/LLVM combo: better compiler speed, better code optimization – both still starting out but they’ve more power in reserve, while the current gcc compiler and backends are pretty much maxed out; way better error messages, the Clang static analyzer is just awesome (a word I usually hesitate to use, but this really is!); lots of goodies to come from tighter integration with Xcode. Negatives: may still generate wrong/inefficient code in some circumstances; no C++ support yet (I don’t care myself about this one).

A sleeper advantage is, also, that the intermediate (LLVM) bytecode generated by Clang could possibly be stored as such inside executables, and be just-in-time compiled for execution on any target CPU. In other words, the same executable could run on a new machine Apple puts out, even if it has a new CPU chip/architecture, as long as the JIT compiler is in place for that; application developers wouldn’t have know (or care).

Regarding blocks (or “closures”, as they’re known in other places), they’re a syntactic convenience for programmers to pass executable code as data. As such, they make programs more readable. What makes them inordinately powerful in Snow Leopard is that they’re also the basic executable units for all of the cool new multiprocessing stuff in Grand Central Dispatch. Therefore, with a little discipline, it becomes easy for developers to chop up tasks into little slices than can be executed in parallel by however many CPU cores (or, with OpenCL, GPU units) are available to do them; and for the first time anywhere I know of, this facility is available throughout the system, even at a quite low level.

So, am I running off to convert all of my code to the new technologies? Well, yes and no. Many things still have to be done in a serial manner, and the system will do others in parallel behind my back. Also, it seems that writing a generic application that runs on both 10.5 and 10.6 (using the new stuff) is tricky; I’m still investigating how to best do it. Stay tuned for developments…

Re: WWDC 2009

No comments

So much for regular posting; either no connection, or too much to do when I have one.

Still, everything else’s been good so far. The weather’s been quite good for San Francisco, though a little windy at times. I met a lot of old and new friends already and took some more nice pictures of downtown San Francisco.

In a couple of hours I’ll be in the WWDC keynote queue. Most speculation I’ve read so far has been about iPhone hardware/software, which I’m not too interested in. However, one nice rumor I’ve heard is that they may unveil a highly scalable CPU from the PA Semi group Apple acquired a year or so ago; one or two such chips could power the iPhone, with (say) 32 in a laptop, 128 in a desktop, and 8 or 16 in a hypothetical tablet. Will a tablet be announced? No idea, though I hope so.

Regarding Snow Leopard, I think the most likely announcement is going to be about price and availability; my tip would be between $39 and $59, and September/October. The rumored “Marble” interface theme sounds unlikely to me.

That said, I’m very excited about the things in Snow Leopard’s underlying technologies, but those are visible only to developers, anyway. (Also: NDA…)

Two interesting developments came up while I’m studying for my next post about code signing.

Firstly, every developer who has signed up for the $99/year program has gotten a letter which says, in part:

We have received your enrollment request. At this time, the iPhone Developer Program is available to a limited number of developers and we plan to expand during the beta period. We will contact you again regarding your enrollment status at the appropriate time.

The message for non-US developers also mentions that the program will be implemented in the US first. At this point, some developers went off in a huff, interpreting it as a rejection, and numerous complaints and conspiracy theories have been aired. So far (as I know) nobody who applied to the $99 program has been formally accepted – the ones who said they were are apparently newbies interpreting their ability to download the SDK as “acceptance”. On the other hand, a handful of companies have stated they’ve been accepted into the $299 enterprise program.

Well, my understanding of English may be faulty (it’s only my fourth language, after all) but let’s look at the 3 sentences I quoted above:

We have received your enrollment request.

Nice of them to reply.

At this time, the iPhone Developer Program is available to a limited number of developers and we plan to expand during the beta period.

This is just repeating what Steve Jobs said during the iPhone event… nobody would expect Apple to accept all applicants immediately and at the same time. There certainly are several thousands at the very least.

We will contact you again regarding your enrollment status at the appropriate time.

Meaning, as soon as we dig out from under, we’ll check your application. I see no problem there either.

Apparently, some people are indeed interpreting this as a poorly worded rejection, or at best as an ambiguous directive that you have to go to the end of the line or try again. Now, I’m the type of person who has difficulty in understanding the logic of “I’m afraid I’ll have to tell you that your credit card has been declined” – the first time I heard that in person I couldn’t follow at all (heh! he’s afraid of what? will he have to say what in some unspecified future? Why doesn’t he then say whatever he will have to say, then?) But I can’t see anything like that buried in that last line either.

Second item is that the SDK’s restriction on background process has been much-commented on, among others by John Gruber and Mike Ash. Along the way, there have been complaints about this and other restrictions imposed on third-party applications. Some have even pointed out (I can’t confirm or deny) that the APIs published in the SDK are just a small subset of the APIs ferreted out by people examining the previous iPhone firmware. Some commenters even seem to believe that Apple not publishing certain APIs is illegal in some way… witness the comments about unpublished APIs called by WebKit/Safari some weeks ago.

Well, Apple can certainly opt to tell people not to use certain APIs. In fact, on the Mac in the past, some large software publishers went ahead and used some of those “hidden” APIs anyway, with the result that Mac OS X still has to support lots of legacy calls that are broken, but can’t even be properly fixed without breaking those applications!

So, on the iPhone, they’re certainly making sure to avoid the legacy/unsupported/hidden API problem at all costs. Apparently the SDK license says that applications may not use any unpublished API, period. Note that this does NOT mean that Apple will have to examine your precious source code line-by-line; no, they’ll just run a tool that looks at your executable, sees what symbols in which frameworks are referenced, and produce a listing of whatever non-documented stuff you’re calling.

So, there are no documented APIs that let you run an application in the background, or start a background process. I’m sure we all agree that having any GUI application continue in the background after another GUI application starts will be too resource-hogging – after all, if you allow one, you have to allow any. From what I’ve read, no Apple application does that either; a few seem to have a background process or daemon running to take care of communications, but that’s of course much more lightweight.

I agree with Mike that obviously the iPhone OS does support multitasking in a generic way. I also agree that the relatively limited RAM (I heard that 64M are available to a third-party application) and CPU speed are no obstacles. To mention an even older example than he gives, I managed to write an embedded system running on a 4MHz Z80A CPU, with 32K of RAM, that handled a GUI, a foreground thread, and two background threads tracing several realtime signals on a screen.

But make no mistake, embedded systems are hard to keep responsive, even if you have no arbitrary code running at all. Apple apparently elected not to have full virtual memory swapping in the iPhone OS; here again, it’s not a limitation of the hardware (Flash memory can support swapping) or of the OS (it’s Unix-based after all) or of the CPU (it does have page tables etc.).

No, I think Apple simply is trying to keep “teh snappy” always happening, keep battery duration as high as possible, and avoid Flash RAM filling up by swapping. Also, swapping pages takes time and burns battery power. A wait of 2 or 3 seconds may be shrugged off if you sit at a desktop computer but may be unacceptable if you’re trying to answer a call on the iPhone.

Consider the MacBook Air with SSD. It has 64GB of flash and 2GB of RAM, with full swapping virtual memory of course. I’ve seen people leaving 20 or 30 applications running on a Mac and not noticing that their swap files grew to 12 or 20GB… but even that may already become a problem on the Air. I suppose Apple didn’t want to face telling people that they should leave 2 or 3GB free on their 8GB iPhone… and risk crashing or hanging when it suddenly fills up.

Still, I feel that if you do have a compelling application that absolutely depends on having a background process running, you’ll probably be able to ask Apple for an exemption… if you can prove that your process won’t hog the system. Also, Leopard (for one) has facilities to start processes on-demand – using launchd, you can have the system watch a certain port or socket and start up your process when data arrives there. No doubt we’ll see more such facilities being deployed.

Steve Jobs just said (I guess I should say, Real Steve Jobs, hehe) on his blog:

…We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February.

…Nokia, for example, is not allowing any applications to be loaded onto some of their newest phones unless they have a digital signature that can be traced back to a known developer. …we believe it is a step in the right direction.

This seems to indicate that the application installer – which will in all probability be iTunes – will check if the application is properly signed. Whether they’ll allow developer-signed apps is anybody’s guess, but I wouldn’t rely on it. (Signed apps is one of the 300 Leopard features, by the way. I’ll comment on the Leopard day announcement in a few days.)

I wrote two weeks ago:
Rainer Brockerhoff wrote:

Conclusions:

– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods; (I was wrong there, and a good thing too!)

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

So the February OS X version will be the first one with stable, public APIs… meaning current apps, written to reverse-engineered specs, will probably have to be seriously rewritten.

Rainer Brockerhoff wrote:

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then

Now I wonder how they’ll handle such a hypothetical future hardware migration… probably fat binaries, with the “other” executables being stripped out by iTunes when installing an app; this would be the most flexible without upping memory footprint on the phone side.

Update: Seems that Intel and ARM are collaborating on new TrustZone implementations… might that foreshadow TrustZone on Moorestown…?

Now, some people say this proves that Apple is listening to complaints and that they’re changing their original plans; on the contrary, I think this had been the plan all the time, but the Leopard delay also delayed the SDK. Regarding the timing of this announcement, this might be a trial balloon to see if they can minimize the inevitable profit-taking after next week’s earnings announcement. Hopefully that will happen.

Rumors say Apple may switch the iPhone main processor to Intel’s upcoming Moorestown.

It’s too early to speculate until details come out, but it wouldn’t be a surprise to hear that Apple is considering this. And it would explain the closedness of the iPhone/iPod touch architecture… after all, once Apple allows third-party apps in, and publishes a toolchain/SDK, they’re pretty much locked into the current architecture, and switching to a new one is a major/slow/costly undertaking.

Consider the previous iPods as a counterexample. Apple has switched architectures there – we can’t even say for sure how often – without any users noticing. With only the UI visible on OS X, and no toolchain/SDK or even documentation of the innards, Apple is free to change things radically between software updates. By all accounts, the 1.0.x software is pretty much a work in progress, and 1.1.1 has probably changed a lot.

So, keeping things closed for now means the software hasn’t stabilized, and very probably the hardware hasn’t stabilized either.

Conclusions:

– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods;

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then;

– the fabled OS X tablet will come out when the new hardware is ready; by that time screens will be ready in the proper sizes; Sony showed an 11″ OLED TV recently, remember…

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2020 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.