Here's the thing that annoys me - Apple *already* has this technology for all Mac computers built after 2011.

There's no way to override the firmware password on newer Macs - you used to be able to do all sorts of tricks like removing a memory module, or manually accessing the NVRAM parameters. Now owners need to press the "secret keypress" (or bring to an Apple authorized retailer), read an encrypted keycode off of the monitor (probably based on the current password and the hardware ID of that particular system), go into the Apple store and prove you're the owner, and Apple Employees contact Apple HQ to generate an unlock USB key for you.

It would be exceedingly simple for them to implement the same thing in phones. Phone locked? Need to bring to an Apple store to prove ownership before unlocking (probably also wipe the filesystem encryption key, so the phone's contents are not revealed). Make it check the lock status in firmware as part of the bootloader so even a manual DFU needs to unlock first to prevent smarter thieves from just re-flashing the phone (come to think of it, with the new firmware security and signed blobs, this should already be possible - if a phone is reported stolen, simply refuse to sign a firmware-blob for reflash).

A "half-way" position would be to allow the phone to unlock if you connect it to a computer you've synced with.

To encourage people to use the lock (who typically don't like unlocking every 15 min or whatever), have a minimum requirement to enter the password once whenever the phone starts, so while someone may still steal your phone, if it's ever turned-off, battery runs out, or is reset, it requires the unlock code be entered.

Just noticed the LCARS marking on their website and it occurred to me that the LCARS interface, designed back in the late '80s to look futuristic, is starting to look pretty dated now.

Only when you look at the dates that you realize that the series is 25 years old now. I feel old :P

N.

Curious what that problem could have been - Drobos aren't fast, but at 1MB/s, something is seriously wrong.

Mine has 8TB of storage currently and the transfer rate is about 30MB/s. Not fast, but quick enough for media storage and such. That said, I'd probably buy Synology hardware in the future as it is quite a bit faster, less expensive and more versatile.

N.

It's an overgeneralization to say that Chinese buildings are crap - but there are some elements of truth in it, depending where you go. For example, downtown Shanghai has construction that looks on-par with any other major metropolis.

By contrast, areas outside of Shanghai in the more industrial/manufacturing centres had a construction quality that I'd generalize as "good enough", both for industrial complexes and housing. Visiting friends there, there were many elements of the construction that I would say were "sloppy". Probably not crap, but not created with a lot of care and attention to detail.

So any data transfers (file sharing, etc) between customers within Comcast's internal network shouldn't count against bandwidth either?

Cool!

Didn't buy it, not going to. I'm done with Sony products, there's absolutely nothing they're making now that I have any interest in purchasing.

Their anti-consumer policies only make it easier for me!

N.

Dutch "artist" admits faking video that only fooled the extremely gullible...

Sigh...

You can't beat pirates with better DRM, The crackers always look at that as a challenge, and they have the time and resources you don't.

Use a basic DRM to "keep people honest", then embed a serial number and client name in each copy you sell. Make it appear prominently in a splash-screen, or menu-bar for the software. Put a few routines deep inside your code that cause it to fail in subtle ways if someone messes with the embedded info:

-Cause an "out of memory error" with a code number specific to a license problem (could be a problem because if the crackers catch-on, they'll have a traceable element to identify your testing routine).
-Generate flash/corrupt frames during renders occasionally
-Modify keyframe values or parameters randomly enough to corrupt the output

If copies get out, you'll know which client leaked them and you can cut-off their support and black-list them, plus others will have unusable copies. The only risk is that if people think the corruption is due to your lousy coding rather than using a cracked copy...

The PSP was the last Sony product I bought - there are simply too many alternative manufacturers that make better products and there's nothing that's convincing me that their gaming system will be worthwhile. I'd sooner purchase a third-party input device for my phone to give it a real directional pad and proportional joystick.

I used to quite like the PS3, but Sony's mismanagement of their product and outright contempt for their customers has soured me even on that. It's not much more now than a decent blu-ray player. If they could at least make it a decent media hub that could play anything you throw at it, that would be fine, however the list of unsupported formats has made cheap solid state players like Boxee and Patriot that much more appealing.

Sorry Sony, I'm done playing your game.

I foresee some time in the (near?) future where Apple may "split" Siri - have some limited processing available on the client device for easy requests, or for when the network is unavailable, leaving network-only use for the really hard requests.

Because Siri is sending all of the requests to Apple's servers, I have no doubt that they're building a huge speech database and using it to refine their systems to make it far more accurate as people enter commands, use the correction tools and try rephrasing things in different ways.

This may be another reason why Apple is considering leaving Siri only for new devices. It's "possible" that if they provide client-side processing at some point, (some) older devices may really not have the memory or processing power available to handle that new version...

If you haven't seen the "Battle of the X-Planes" documentary, you probably should. A lot of detail about the behind the scenes development of the aircraft that were competing head-to-head for the JSF contract.

In the end Boeing's aircraft lost the battle, but it seems that their UAVs will probably win the war. The days of pilots in the cockpit may be much shorter than people previously thought...

Let's have a look at this blog post:

1. Android devices should advertise freedom and functionality.

Freedom makes sense - it's one of the reasons that people like Android phones, however Apple has functionality down cold, that's some tough competition...

2. Android devices should include a darn infrared emitter/sensor.

Nothing like a bit of "gadget creep" - let's throw a toaster in there too, or maybe a corkscrew and a can opener. That'll sell phones for sure! Why not stick with bluetooth and wifi - something all smartphones share. Want to control your TV or PVR? How long do you think it's going to be until they're bluetooth or wifi enabled rather than IR?

3. Get a standardized dock/interface connector.

Makes sense, but it's not going to sell phones. It should've been part of the spec and mandated for all manufacturers from day one.

4. Still be a smart device when docked to my computer.

Waitasec, I thought we were going to talk marketing here, not missing features...

5. Let users earn revenue from data collection.

Now we've completely jumped the shark. Now it's make money from sharing your data, rather than making a phone that appeals to people who just want things to be simpler and more efficient...

There are another 6 requests on his list that are even worse... Waterproof? Wireless charging? Fingerprint unlock? Does he even understand why so many people find Apple's products so appealing, and why the marketing works so well?

Just goes to show that various world governments didn't need to do a thing to get rid of their "leak" problem. Just them alone and they'll mutually self-destruct eventually.

Pretty sad...

Yes, well...

They're not going to get me until they roll it out for people who use their Apps for Domains service. But they don't seem to be in any rush for that.

I had a support issue similar to this which required only a few mouse-clicks to solve.

Unfortunately my verbal description of the clicks that were required seemed to be getting lost in translation to the "click-er". Fortunately both of our cell phones had video chat capability, so in the end, he was using his phone's camera to show the screen of the computer, and I was telling him where to click. Problem solved and it saved me an hour of driving in heavy traffic.

One of the first troubleshooting techniques I teach new employees is that if an unexpected error message pops up, or an error that they don't understand, snap a picture (screen shot or cell phone) and send it to me. It has probably made 50% of the "It's not working and an error message popped-up, so I clicked it but it's still not working" issues go away.