How can a task manager be "mind blowingly awesome"? Having to use a task manager at all is a fairly sure sign that things are not going well. That they've made that some sort of central feature is, IMO, a bit worrying.

Similarly: I've never used a platform other than windows where the act of copying or moving files around in the filesystem was so painful, or where there could be a reasonable cause to pretty up the dialog enough that you'd notice it. Everywhere else moves are normally instantaneous (unless to other filesystems) and copies are just copies. Yes, I am not a fan of MacOS asking whether you want to overwrite target files either: Unix had this right in the first place: unless it's locked down, in which case the action is failed, if I say I want to copy that over there, then that's what I want to happen. If I make a mistake I can jolly well recover from backup, or run around screaming.

I switched to MacOS from FreeBSD a few years ago because using appropriate proprietary graphics drivers weren't an issue (and always will be an issue on FreeBSD, as far as I can see), and because I wanted to use Lightroom for my photography hobby. That's all, but they're two things that I can't see changing any time soon. Switching to windows wouldn't have worked, because although I want those two specific features, I don't want to lose my comfy BSD/Posix command line environment. The windows command line experience has been astonishingly awful for its entire existence, so it is not something I can expect to change any time soon. I don't think that Ubuntu is in a measurably different position to FreeBSD in this.

Most of the whinging seems to centre around the existence of an app-store (which, as someone who uses FreeBSD ports and apt-get on a regular basis is simply a good idea, not something to be afraid of) and the (optional) removal of permanently-visible scroll-bars in favour of multi-touch swiping on the track-pad (or mouse-wheel, I suppose.) I count both of them improvements, but clearly tastes differ.

Real iOS-ification would be sandboxing applications so that they can't operate on arbitrary files in the file system, and removal of access to said file-system. I can't really see either of those happening.

Personally, I can see where the tea-leaves are pointing, and am in the progress of moving all of my daily activity into a personal "cloud" hosted on my own FreeBSD box. Then I can use osx or android or whatever has the good proprietary graphics stack at the time and just get on with it.

I think that you'll find that a fair chunk of the top-end of the top500 (and the graph500) are IBM Blue-something systems that run variants of Power. These are essentially descendants of the PowerPC440 series of embedded processors: not terribly fierce on their own, but have a significant advantage for this sort of work: they don't consume much power. So you can run a *lot* of them with a limited power budget. Much like ARM, which is why several folk, including AMD, are lining up to do server versions of AArch64.

Which is why Facebook and others have created the Open Server Aliance, and why Intel, AMD and ARM are all members, and are all producing CPU+memory modules to suit that space.

Low power devices are the present and the future, even if you need the power supply of a medium-sized town to run the data-centre.

The patents and the compatibility in question relate specifically to the way Microsoft encoded the long-file-name compatibility, and the short-form-contraction extensions into the FAT directory structure. It's an ugly hack that no-one with skill in the art would think of doing, so it's a legitimate patent. I don't know why camera makers don't just limit themselves to the 8.3 filename space and avoid even dealing with long file names: every camera I know of seems to work like that anyway.

The primary work-around du-jour (and it's a good one) is USB-PTP protocol (and variants) that avoid the question by not exposing the block device structure at all: operate more like a network file system. Makes perfect sense. This is why lots of mobile devices don't have SD card slots. Add an SD card slot and you have to support FAT or exFAT. Leave the slot out and you can run ext2 or whatever on your internal flash drive, and expose files to the external world over wifi or USB-PTP.

Since the controllers in SD cards are computers too, it would probably be feasible to build some sort of SD card variant that spoke PTP directly, but how likely is that?

I read a little of the on-line doco, and noticed that the "native development" system supports C++ but not exceptions. So two-phase object initialisation is a requirement and try/except is out, and a bunch of standard APIs can't be used. There was also something about restrictions on C use, should you prefer that, but also missing some standard library functions. That's not too surprising, but I suspect that the C++ restriction is going to make porting code from existing sources painful. I dimly remember C++ under Symbian being odd, for similar reasons. Maybe for exactly the same reasons and with the same heritage?

NeXT wasn't the only, or even the first OS that had vector graphics baked in at a low level. Acorn's RiscOS was all vector graphics and scalable, anti-aliased fonts from the late '80s on, on a 4MHz processor that had no cache and a dumb frame buffer in bandwidth-sucking "shared DRAM". True, it didn't have much in the way of actual resolution either, but it did work very well. Performance of the vector drawing primitives was never a big issue. That was a machine that was in the same ballpark as the IBM PC-XT (which was a contemporary), price-wise.

That's not it at all: tablets are now (or will be soon) just "screens": no different from the one in your lounge room or on front of the fridge. The circuits are just moving around a bit. If you want to *do* something with it, you'll be able to use that box with the hard drives and the peripherals sitting in the corner of your office just as easily as you can now, or you can rent space on someone's cloud server, if you prefer.

Don't think of it as losing your PC. It's more the case that your laptop/desktop monitor can still do a range of useful things after the "PC" has been powered down. There are already plenty of manufacturers who have the clue, and are selling WiFi enabled network hard drives: "personal cloud" systems.

No, Outlook with Exchange is terrible on many levels. Probably Exchange's fault, and the fact that it doesn't use IMAP. Every time I have to fire the beast up for some reason, it takes more than half an hour to "synch" to my mailbox. How is that even possible over gigabit ethernet? Why, every time? Does it forget everything it ever synched the last time? Rubbish.

Non-braindamaged message composition, sane integration with the rest of the native applications that I use, off-line access, seamless integration of multiple accounts and, oh, speed. Built-in searching, and integration with the platform's native searching are bonuses. Oh, and not being in a web browser.

BTW: Mail.app has some faults, but as an IMAP client (with dovecot back-end) I've met nothing that comes close. (OK, claws-mail is fairly close, but lack of html/rich-text composition is limiting in some contexts.) I would *love* to have something as good as Mail.app on Linux/FreeBSD.

Limiting factor these days is how much power you can get in and out of the box. They will have optimized for that. And these processors probably do have GPUs on them.

"Films" (at least the big-budget, blockbuster ones) haven't been recorded on "film" for years. Everything is video. Not VHS video, but electronic. That's one of the reasons why Kodak is out of business. Certainly some smaller film companies are probably still using actual film, but it's not mainstream. I haven't checked but I would be *very* surprised if any film stock was harmed in the making of the Hobbit.

This 48 Hz issue is a different problem.

Yeah, I'd have voted for R. Raneel Olivaw, but settled for Bishop.

Controversial missing option: Deckard?

"That quantization can be heard."
Only if you go and turn the volume up at that point, so that those quiet pieces are loud. (And that's why you want a larger bit-depth while recording and mixing, because mixing some parts up is something that you're doing.) If you don't go and fiddle with the volume knob, then you're competing against the noise floor of the listening environment. Even the quietest suburban listening rooms+hi-fi kit only have 85-or so dB peak-to-noise range, so the 16-bit CD's 120-ish floor is plenty.

There is essentially no virtue in a compressed filesystem because there is essentially no compressible data on a modern file system. The bulk of user data these days (by volume) is already compressed, as JPEG images or MPEG sound files, or similar. A very few people or situations will have a fair chunk of information in the form of documents and guess what: the modern forms of those are already compressed too (zipped XML is the new doc.)

The pieces of data that people will complain about, executables and libraries, aren't particularly compressible either, and are not useful in compressed form because the modern operating systems that execute them operate by demand paging. Everything else (directory structure, control files) is in the noise, and arguably much better off uncompressed for efficiency of access.