Note that the Apple TV is designed to be shared (you can have it set up to log into multiple iTunes accounts, because the TV is something that in fact multiple people use). It also doesn't have to worry about app ownership, and if it's stolen, you don't have much personal information on it.
]]>Then explain why they patented using the fingerprint sensor on iOS devices to log in different per-person user IDs -- both work/private profiles for one person (to enable BYOD use in the workplace) and different people (to allow home use), each of which would be associated with different views of installed apps and data (so that your work view of Safari wouldn't show the same bookmarks/tabs/browsing history as your home view or your partner's home view or the guest account)?
Apple want to sell you as many devices as possible, period. This implies making them sufficiently versatile to do the job in hand. Nobody wants to carry around three iPads for different work cases: if Apple tried to ram that down their customers' throats they'd risk losing market share. Their usage model is personal because they're selling personal computing devices, that's all.
]]>If you want reliable Terabit throughput, you'll need a fiber optic land line (with a whole bunch of fibers). Right now we're in the early stages of developing the 400 Gigatbit Ethernet. Last I heard, a 400GbE transceiver (the MSA hasn't been codified, yet), will probably require 16 Tx and 16 Rx fibers, each running at 25Gb/s (25 Gig is about the max that we can put on short range fiber right now).
]]>Now as to how many Apps would not barf all over themselves, well their data, is a horse of an entirely different color.
]]>Not to mention that the ASIC chips used to route traffic between ports of high speed switches are pushing up against some touch limits at gig speeds. 10Gig costs are very high just now. Way more than 1 gig 10 years ago.
]]>Second: Given that it was decided to be single-user, and that the user name was "mobile," and that its home directory was /var/mobile (or, rather, /private/var/mobile), that path is hard-coded in a lot of places. Including where applications are installed.
Third: None of that addresses the issues I actually mentioned. The OS is not just the kernel; the system is not just a strictly-separated kernel + GUI. The issues of ownership, access, data sharing, data access, and a few dozen other things I cannot recall off the top of my head are issues that would need to be examined in depth, designed, tested like mad, and so forth.
And as an example of that: one recent announcement by Apple was allowing families to share purchased apps. And this requires a contractual change on behalf of Apple, and requires developers to agree to it.
None of this is easy. A lot of it is due to decisions made previously, but changing it is not a simple matter of deciding, "Oh, we'll just have multiple users!"
And yes, I know what I'm talking about.
]]>Didn't say it was.
]]>I'm certain you're not. Remember who took a smartphone to a stolen Bible?
]]>And the Application (NOT App!) which is my primary use for all those iThings is Music; not iPod style MP3 playback, rather composition. To those who think the iThings are purely consumption devices, or are into electronic music but don't already know this, take a look at the professional and amazing instruments and processors available now in iOS. And I mean pro, stage-ready, hi quality stuff. Capture through released album tools. And the audio gear manufacturers are taking note. iOS supports Class Compliant and Class II Compliant Audio and MIDI USB interfaces through the Camera Connection Kit (but fail to mention this rather important fact in the CCK documentation).
All this pretty much exploded in the past 18 months or so. Been an exciting time.
But don't just look under "Music" in the App store; most of what that shows, of the 38,000 or so, are indeed mere toys, and the 300-400 diamonds get lost in the masses. Go to the Audiobus web site (Audiobus was a key enabler of the explosion) http://audiob.us and look at their list of compatible Apps, and check out their general forum. Search on "iPad Music" on You Tube. Another App developer, of a 48 channel (stereo) workstation App called Auria, carries a list of compatible interfaces on their web site.
The bad part is: we need to be able to apply multiple tools to a track. No one tool does everything to perfection. But Apple's sandboxing of data means we end up with copies all over the place and no means of keeping track of them or their workflow stages.
This is yet another SciFi dream become reality. Equivalent also to the Desktop Publishing, then Web Publishing, paradigm changes. Maybe even more so, since this can be done on the bus, in the park, or wherever the inspiration strikes.
]]>You regularly travel with an iPhone (iOS), an iPad (iOS) and a MacBook Air (OS/X which, as you often tell us, is the basis of iOS). Apple has already persuaded you to carry around three devices, what's even better from their point of view is that they've convinced you to buy three different devices from them. Ka-ching!
From an earlier comment: "they need a multicore 64-bit ARM (check) that's able to emulate the i7 instruction set"
No, not really. Apple control the horizontal and the vertical as far as what runs on their hardware. There's no reason a new full-fat Apple OS (it might not be called OS/X) capable of running heavy-hitting code on desktop or even server setups needs to be backwards compatible with the current Intel family of laptop/desktop CPUs. Any emulation by ARM of i7 without several MB of L1 cache and all the other intrinsic hardware trickery like the internal data busses would be as slow as molasses at the South Pole for the OS, never mind programs running under the OS itself. The only way that's fixable would be for ARM to include a Haswell-in-all-but-name on silicon and that's not going to happen.
]]>For the same reasons Apple had backwards compatibility through the last two architecture transitions - from 68K to PPC and from PPC to x86. To run critical applications from third parties who are tardy about releasing new versions that support the new architecture. Adobe for example. Microsoft for another.
]]>ARM systems are optimised for low-power consumption not speed and software emulation of even a Bay Trail Celeron on ARM, never mind an i7-series Haswell or a Xeon is going to limp badly to the point of unusability. The proposed 64-bit multicore ARMs are not going to be significantly faster than the Intel devices they would be replacing, unlike the change from 68k to PPC and the later shift from PPC to Intel silicon which in both cases permitted software emulation of the previous generation of CPUs without too much pain on the part of the user.
]]>