Exactly. It's a breath of fresh air to see an announcement like this and discover that it isn't about locking me into their ecosystem.

Hopefully Google (the only other player with a web app store - that I know of) will implement support for that 'receipt protocol'.

>Yep, pretty much. I can't be the only one who remembers Google Gears, either, and offline gmail for firefox. But that got tossed over when Google decided to implement their own browser.

Gears worked with Chrome too. They killed it in favour of standard HTML5 functionality (though they killed it too soon - the HMTL5 stuff wasn't ready).

> That still doesn't tell us if it has the features needed to run this software. There have been things which ran on the chromebook which didn't run in chrome in the past.

Yes, such as the photo editor and the file manager. But the articles about this new 'edition' of QuickOffice say that it uses NaCl and NaCl is the same on Chrome and Chrome OS.

If there is currently some small dependency on Chrome OS itself, then surely they are working hard to eliminate that - not much point in building this new QuickOffice and have it limited to the tiny # of ChromeOS users, when it could be made available to every Chrome user.

> It doesn't matter how they are delivered, if they install and run locally then they're installed and run locally, and if they're run from chrome then they're in chrome.

But then how do you distinguish this from regular web apps/pages? Perhaps your use of the word 'install' is your key, but these NaCl apps are no more or less installed then an advanced web apps: they can be cached in the browser, or even pre-cached, but they are still not a component of the OS or of the browser.

Come to think of it, I'm using Firefox and I have a bunch of add-ons 'installed' in my browser, so I guess the term 'install' is already used for web-apps. Now I'm getting lost in terminology.

> It could be delivered to them just as easily, but would it run on them? Chrome on Chromebooks is different from Chrome on PCs is different from Chrome on Android.

Yes. The Chrome browser has supported NaCl for a while. It is mostly used for games.

They are separate apps that they are delivered from the cloud (not baked in) and store their data in the cloud (though they can work offline). They are web apps but they use NaCl instead of javascript (often the NaCl apps still use HTML, though I don't know in this case). NaCl is built-in, but the apps that run on it aren't.

There are some native apps that are 'baked' or 'hacked' into ChromeOS (I believe the photo editor), but QuickOffice is not - that's why this new edition of QuickOffice could just as easily be delivered to regular Chrome browsers while the ChromeOS photo editor can't.

(Theoretically it requires any web browser that support the NaCl runtime as an alternative to javascript.)

I should clarify that one of the 'features' of Google Apps is the lack of ads that the summary yearns for. It also includes Enterprise support and a bunch of other small features and services. It is provided on your domain, not on google/gmail.com.

No. You can't have Google Search, Docs, etc. in-house.

What you can have, is exactly what the summary describes as a "pipe dream".

It's called Google Apps, it costs $50/year. Also, Google never has "sold" people's data. (Twitter does and Netflix is going to soon.)

How did this summary (and the previous one about the Pixel, which was equally misleading) ever get through?

Ah slashdot. Someone writes negative comment that is factually incorrect on every point - modded to 5. I correct their mistakes - modded down to zero. I think it would be more satisfying if the modder had to also respond to my comment.

No. ATL was for developers to write components compatible with ActiveX - that's different then making ActiveX itself open-source.

And, as you point out, MS's license ensured that no one else adopted it. It was meant as a proprietary extension.

Google mostly uses standard open-source licenses, like GPL and Apache - that's why their technologies get adopted.

Native client is open-source; activeX was not. That has very real implications: though I doubt we'll see MS adopt, there is a very real possibility that Firefox and Opera could.

Look at SPDY for comparison. Google added it to Chrome, now Amazon, Opera, Firefox, Facebook, Twitter, etc. are all using it.

Your 'translation' is wrong on every point.
- Native Client apps are cloud apps - they just use a different client technology.
- Second Chrome OS (and Chrome) does have native apps - via NaCl - and has for a while. This isn't new at all.
- This isn't hacked into Chrome - it's not part of Chrome at all.
- There is no way that anyone at Google would want to write such a misleading and confusing summary.

This is just a new cloud app, that runs on an existing client technology that's been built-into Chrome and Chrome OS for a while.

Agreed, but what does this have to do with the Pixel??

I can see this as a story about MS vs. Google, or about Google's Native Client technology - which, incidentally, is supported by the Chrome browser. It is not - as this story seems to suggest - limited to ChromeOS or the Pixel.

Given that it is in the 10-50 million installs bracket (in spite of the fact that the current incarnation hasn't been around that long) I think this item is more relevant then most on /.

I think there are many reasons it is great, but the most important for most users is that it sync's with desktop Firefox. So, I would say that Firefox for Android is the best choice for a mobile browser for anyone who uses desktop Firefox, and that must be hundreds of millions of users.

If it were that simple they could just go to a Canadian website, but the problem is the codes. Excepting a few models where the codes are cracked, an individual code is needed for each phone. The codes come from the manufacturer, and it is the manufacturer in consultation with the carrier that sells the codes to third parties.

When they made 'unlocking' illegal in the U.S. they were essentially banning those codes. This will probably result in the codes no longer being sold to the 3rd parties, so you won't be able to get the code no matter what country you are in.

The carriers will still have the codes and will presumably agree to sell you your code for a ridiculous admin fee, once your contract has expired.

Okay, but you've left out the key detail. You have to apply via the #ifihadgass hashtag, so I assume that the pertinent question is - what did you have for lunch?

Which brings us right back to the question about where they go their marketoids?

Above I defend Google in this regard, but I think your statement goes too far. People gave Google their data under one set of privacy policies, now Google wants to change those policies unilaterally. I happen to think that the changes are good for users and necessary for Google to move forward, but I think it is OK to question any unilateral change like this.