Just another crappy php website

That's all Facebook is and will ever be. A big crappy php website perhaps, but a crappy php website nonetheless. So this is a big crappy webmail with chat? Woohoo, no-one ever did that before.

Target market: American teenagers.

Email killer it is not

Also NFS

No, seriously - it's actually a great way to serve VMDKs.

iSCSI thanks

It's here now, affordable now, it's interoperable across a huge range of platforms now, and it performs well enough for 95% of applications.

overlong article missing the point

Given that the underlying protocol was a real-time federated social publish/subscribe service, they'd have been better off making the front end a Facebook killer. Instead they faffed about trying to make it a multimedia Instant Messenger, only one you have to visit a website to use and that didn't work in IE. Oops.

Summary:

Well engineered but poorly productised and didn't work for nongeeks. Or even geeks at nongeek workplaces.

= Fail.

Oddly reminds me of Sun Microsystems.

Engineering without decent productisation?

Perhaps EMC want to be the next Sun.

It may be Larry, but ...

... he's right on this one. Sun had terrific engineering but horrible productisation. No idea about bringing technical products to market. It's astonishing they stumbled along for so long at all, and the ponytailed one did little to improve matters. From Java to the SPARC - it almost always fell to others to make products built on the core engineering that enterprises actually bought (e.g. IBM, Oracle, BEA for Java. Cray and Fujitsu for the SPARC). The biggest squandered opportunity of all must surely be the Sun Ray end-user computing architecture, eclipsed by VMware and Citrix by sheer force of vastly better marketing.

The only glimmer was the 7000-series Unified Storage platform, which could've/should've been a NetApp killer. But it was too little, too late. Perhaps Oracle can still channel that potential better.

Maybe Schwartz saw himself as a Jobsian tech-visionary figure, only with enterprise rather than consumer products. But I think he lacked the charisma and his company certainly wanted for execution. Larry makes me nauseous but surely does both better.

Huge balls

It takes big cojones to come clean about your security blunders. The vast majority go unreported - how many of *your* passwords have leaked without your knowledge?

The whole notion of site-specific usernames/passwords is an horrible anachronism. I feel resentment every time yet another crappy site asks me to sign up for an useless account.

PCoIP: not as good as I'd hoped

Looks like a rebadged/OEM'd Teradici device. Which given the PCoIP support would hardly be a suprise. The IBM PCoIP device is very similar again in form factor and specification. They're very likely all based off the same Teradici reference design.

We studied VMware View as a wide-area VDI solution.

A pity that PCoIP seems so bandwidth hungry, because I was greatly looking forward to VMware View supplying a better protocol than RDP. In lab tests, PCoIP was only slicker than RDP or ICA over high latency links where bandwidth was not an issue, but borderline unusable even for web browsing over commonly encountered lower-bandwidth connections e.g. 512/512 DSL. Visible tearing, painfully slow scrolling & updates etc.

Even after tuning in conjunction with a VMware consultant it required at least a megabit to provide satisfactory performance for just one remote Windows XP desktop doing browsing & word processing on a typical business DSL circuit.

Trying to stuff a call center or entire retail site's traffic down affordable business-grade connectivity looked infeasible as a result. Especially since we then have to pay for new thin clients, virtual desktop backend servers & licensing, and of course a DR site for same. It worked out cheaper to stay with the conventional desktop model.

It was suggested that we could/would be able to deploy accelerators, but I'm primarily interested in protocol innovations that eliminate this additional cost and significant complexity - otherwise what's the point? I could just deploy RDP with WAN acceleration.

Our conclusion was that the much lower-impact ICA is still the leading national-scale desktop protocol for those who can't justify the cost of reliable very-high-bandwidth connectivity. I think most enterprises will fall into that category.

PCoIP only starts to look interesting for high latency global-scale remote access e.g. offshore developers, remote trading desks.

GWS vs Apache

The very long chain of command-line parameters (to the extent of historically requiring kernel tweaks to permit the length) that GWS takes points to a heritage other than Apache/NCSA.

Yep.

Confirming that mine is demonstrating occasional five-to-ten seconds pauses and has twice required a hard reboot since updating. I wouldn't call it "bricked", but clearly there are stability problems with this release.

I do wonder why people seem so keen to scream "nyah nyah told-you-so" like children at incredible length. Don't you people have lives? I don't particularly care for Mr Jobs, but the iPhone is the first phone or PDA that I've actually enjoyed using.

@AC

"Question for people: (maybe a rhetorical one): how can a company own a technology that is open source?"

For one thing, open source isn't the same as public domain. But that's actually beside the point.

Ownership of Java isn't about the rights to a source code repository. It's about owning the standardisation process, especially the JCP. It's also about perception amongst enterprise customers (i.e. the ones with money, and who have to plan their technology choices years ahead) and product developers (e.g. those with embedded Java, which is practically every device these days short of the iPhone) of who the pre-eminent entity is.

A matter of perspective.

I don't use the word backup any more; when people do they get my lecture on the Four Rs of data copy usage. Because there isn't ONE reason why we take copies, or replicas, or backups, or whatever you wish to call them, there are four!

As all the smart people have recognised already, what matters isn't that a copy is made. What matters is what you want to do with it afterwards. And it ain't so simple once you get beyond protecting your email and photo albums.

So the Four Rs of data copy usage are:

* Restore. Pull back one or more historical files, tables, volumes or what have you because the current working set was deleted or corrupted.

* Recover. Restart data processing using an alternate facility due to loss of a primary.

* Repurpose. Use a primary data set for production support, report generation, system test, or system development.

* Retain. Meet regulatory and legal requirements - and broader expectations - for data archival and discovery.

The interest in each outcome should guide you as to which storage technology capabilities to buy or build. Some are surprised to learn that traditional tape backup is not the best path to achieving all four at efficient cost in one package.

I've heard the phrase "Information Lifecycle Management" (ILM) used when introducing this topic, but I avoid doing so because it's an industry term and everyone else glazes over. Even your IT colleagues will look at you funny, suspecting a dose of Gartner kool-aid. To be fair, ILM "done right" is a bigger topic, encompassing people and process as well as technology: it is comparable to ITSM, PM and the SDLC as a complete subdiscipline of ICT. It is well worth treating as a separate competency once you have some scale.

DNA

And yet they just turned out to be a load of Golgafrinchans.

DSM

It's great to see someone resurrecting and productising distributed memory, a concept that's been around for donkeys years.

@Matt B: DEC Memory Channel would be more akin to, say, RDMA over Infiniband, which if I read correctly, is just one piece of this stack.

At that price point, the use cases for this will remain slim and are basically identical with those of main-memory databases i.e. transactional systems with large working data sets. Although I can also see possible uses by the starry-joined OLAP crowd.

Ultimately this stuff just forms part of a hypervisor and permits what amounts to main-memory lending between VM hosts. The cloud computing people will love being able to have a memory rack next to their CPU rack.

And thus we reinvent the mainframe ...

Get it right.

NetApp did not kill off SnapMirror, which is the core replication software.

They killed off the ReplicatorX software line, which came with the Topio acquisition, was branded "SnapMirror for Open Systems", never really found a market, and is more or less superseded by Open Systems SnapVault albeit at a file level rather than a block level.

BBC Micro Model B next

Here's hoping.

The value of VOIP

VOIP is not about cheaper calls, no matter what the marketing claims.

Historically, there were only voice bearers. Then we started running data circuits over those voice bearers; the PRIs and the OC-series. Then voice itself became packetized and suddenly we're running voice over data - but still over those same voice bearers. The technology ramps up, but underneath it's still a circuit, and you're still using roughly the same bandwidth to make a call.

The true value of VOIP is in rich voice functionality and the lower cost & complexity of operating a single data network with voice as "just a service".

As more services converge onto data networks (storage is next with FCoE) we'll see increasing utility from that notion. RIght now, we're still building infrastructure. So this is the expensive stage.

But in the meantime, you still need a reliable bearer at the bottom of it all. If you're serious about business-grade branch-office VOIP, you'll go BDSL, with SRST handing off to local PSTN, and a very highly available core switching capability in your DC.

And don't expect a ROI under five years.

Actually, I quite like it.

Although it does make you look more generic.

Would it be really too hard to have a wide-screen-friendly CSS styling option?