Certainly it is isn't for us (hardcore computer users) with tons of native applications.
I'm not so sure. I think that there is a reason that Native Client is a key component: Google realizes that, in addition to web apps that can be used offline that HTML5 is sufficient to support, apps that rely on native code run locally are important, and so Google wants to incorporate them fully into its model of platform-agnostic applications delivered and updated over the web and accessed through the browser.
Do they really intend to compete in the desktop market with Windows?
Yes, though netbooks and similar systems are the initial focus.
The joke, "will it run Crysis?" really isnt a joke at all, because nobody will use it if it doesn't.
The ability to leverage the full capabilities of the underlying native hardware from apps distributed over the web (that aren't required to even be aware of what the underlying hardware is) is exactly the point of Google's Native Client technology, which they've stated will be a key component of ChromeOS at launch.
Since Google has also stated that it will be incorporated in the Chrome browser off of Chrome OS (its actually a Chromium browser feature, not part of the OS outside of the browser) and be incorporated into Android, Native Client would seem likely to be an attractive target for developers.
Unless they have full binary compatibility with windows itself they will go nowhere.
If Native Client -- by being incorporated into Chrome, Chrome OS, and Android -- provides a big enough target that isn't a simple subset of the Windows market, it will attract its own developers, with or without binary compatibility with Windows.
Apple iPhone/iTouch/iPad has, I would think, proved that quite well.
Because Chrome OS is useless without Internet access.
AFAIK, Google has stated that Chrome OS will support offline use of web apps that use the appropriate HTML5 features (and will feature Google's Native Client to allow "web" apps that run native-compiled code in a secure sandbox), and that it will only need internet access to use web sites that aren't made to support use as an offline app or to use those that can be offline apps in their online mode, and for the first login for a user (which needs to access the user's Google Account.)
You could use it for office productivity tasks for bog standard office workers sure, but then all your company's private data is being held on a 3rd party server - which doesn't seem like something most bosses would want.
I don't think most bosses would care all that much, so long as the third-party was both perceived to be reliable and the legal infrastructure (contracts, etc.) were in place to assure that the third-party was also accountable.
Outsourcing support functions to someone who is specialized in them and can do perform them efficiently to allow a company to concentrate on its core competencies is hardly an unpopular approach.
And Android. If Chrome is just for running a browser, why not run a browser on an Android OS?
Because Android's UI isn't really designed for netbooks, laptops, and desktops (though its been used in netbooks by some vendors), and because Android incorporates an app model that Google wants to move away from in favor of Native Client (as they've stated that, in addition to being part of Chrome OS at launch, Native Client will eventually be part of Android as well, I expect that they'll provide some kind of upgrade path and phase out the existing Android app support -- that's consistent with what Schmidt has said about Android and ChromeOS converging in the long term.)
Other than that, Chrome OS and Android are very similar and share lots of components. Both are built on the Linux kernel. Both use the V8 javascript engine in a WebKit-based browser.
Actually, I think it'll be mostly competing with Android, which makes this whole thing kind of bizarre.
Why isn't Google packaging a version of Android as Chrome? A restricted version of Android would work fine, and give tinkerers a path up, sell better, allow local apps which are specially judged safe for Chrome/written with tattlers to integrate it into the cloud data, etc.
Two completely separate OS systems will cause confusion and not allow one to leverage work done on one for the other.
They aren't completely separate "OS systems". They are separate brands, both Linux-based, both placing WebKit-based browsers as key components (the key user-facing component in ChromeOS), both using the V8 javascript engine. They are different in that Chrome OS has UI -- both input and output -- features designed for traditional environments while Android targets mobile, and Android incorporates the JVM for apps while Chrome doesn't -- but that appears to be because at the time Android was released, the JVM was an easy choice for a cross-hardware app environment, while Google has spent much of the time since working on its Native Client mechanism, which it has stated is intended to be an important part of ChromeOS at launch, and also an important component of the Chrome browser and the Android operating system once it is ready.
And Google has said that they expect Android and Chrome OS to converge over time (which makes sense: the essential difference -- other than the ones that related to UI adaptation to different hardware platforms -- is over how apps more native than traditional HTML/JS web-apps are delivered, and Google has already stated that they intend to incorporate the same mechanism Chrome OS will use for that into Android, so the only additional thing necessary for convergence will be to either incorporate the JVM mechanism into Chrome or, more likely, to provide an easy mechanism to convert Android apps into Native Client-based apps.)
I get the idea that Google likes products and ideas and doesn't have any leadership at all. That they figure that the ideas can slug it out, and let the best one win.
That works fine within an organization, but on a product level, it seems NUTS.
It certainly isn't the conventional approach in traditional firms, but -- especially where the products aren't direct alternatives but merely have some overlap -- it makes some sense.
Once Chrome OS can run Android apps, then and only then will things be more peaceful. Until then, most folks will wait for Google to get it's head on straight and figure out what the hell it's trying to do. I get the impression Google isn't sure about product cohesion.
Google's OS lineup isn't any less "cohesive" than that of any other vendor that has an OS targetting handheld devices and one targetting more traditional computers (netbooks/laptops/desktops.)
About the only difference is that Google has at different times suggested both Android and Chrome OS for tablets, and Google doesn't exert control of what people do with its OS's and, despite the fact that Google has never pushed Android for netbooks, some hardware vendors have chosen to ship it as a (usually, AFAIK, dual-boot with Windows) netbook OS.
And Google has publicly stated that they expect, in the long-term, Android and Chrome OS to merge.
I've played around with ChromeOS on a virtual machine and it sucks. It's an OS for accessing Google apps and the web. Nothing else. Great if that's all You need, but I need a bit more.
IOW, Google Chrome OS is great for the market it is designed for, but you aren't part of that market.
Sorry, where does it say that they are aiming to compete with Windows, because it doesn't mention windows in TFA. They've never claimed to try and do that - they're targetting a completely different market.
Chrome OS addresses different needs than Windows, to be sure, but it is designed to compete directly with existing traditional consumer operating systems (Windows & Mac OS), which -- according to Google -- are not targetted at many modern users real needs, but instead are used "by default" as there is no alternative model OS designed for traditional computing devices (vs. phone/handheld/tablet style devices.)
Chome OS is just a browser than boot up with no host operating system.
No, Chrome OS is just a linux distro whose main native application is a web browser.
Windows IS an entire operating system.
Yes, and Google's entire idea by Chrome OS is that people who need to use a computer a keyboard, mouse, and other hardware features of a traditional PC often don't need a lot of the stuff that comes with a traditional desktop operating system -- they need access simple, secure, stable access to web applications and basic hardware peripherals (like printers).
"Competing with" something doesn't mean copying it. Chrome OS is certainly designed to compete with Windows in a large segment of Windows' current market; it is designed to do so, however, by being very different from Windows and thereby providing a superior experience to that segment of the market, not by being as nearly identical to Windows as possible.
While we're at it, your browser SSL encryption is only as secure as the least secure of the certificate authorities that your browser trusts.
Rather, its only at most as secure as the least secure of the certificate authorities that your browser trusts; its quite possible that either your computer or the server you are accessing is, itself, less secure than any of the CAs involved, in which case those are the limiting factors.
That doesn't really make sense. We are just reaching a point in time when Google realizes that Apple is a bigger threat to their business then Windows ever was (Windows users have the option of installing alternate codecs, browser, toolbars, etc), and Windows has finally got its security act together, and NOW Google is going to switch from Windows to Mac?
"Apple" and "Microsoft" are not the right units of analysis.
The dominance of Microsoft Windows, Internet Explorer, and Office are issues for Google, as could be the dominance of Apple's iPhone, iPod Touch, and iPad devices.
Apple's Mac desktop/notebook computers aren't a problem at all for Google, though.
Only for unusually small values of "All". The following are a few examples of Google apps that are that (while in some cases they interact with the web) do not "target a web platform", but instead run on a desktop OS (usually, and in some cases exclusively, Microsoft Windows) or (in one case) the add-in environment (rather than the "web platform") of a browser (often, Microsoft Internet Explorer on Microsoft Windows):
Google Chrome Google Desktop Google Toolbar Google Earth Google SketchUp
I am just wondering when "Google Linux" will debut (1-3 years?)
Google Linux (Mobile Edition) goes by the trade name "Android" and has been available in production for quite some time.
Google Linux (Netbook Edition) goes by the name ChromeOS and is in Beta; at the time work on ChromeOS was announced, it was discussed as "netbook-first", with possible expansion to address traditional desktop use, so any notional Google Linux (Desktop Edition) would likely just be a later version of ChromeOS.
So, really, the only thing we haven't seen is Google Linux (Server Edition), which I'm not sure Google has much interest in sharing.
That may well be part of Google's intention. Microsoft and Google have long been trying to kill each other.
I think it is Google trying to break MS's OS & office suite monopoly and MS trying to kill Google. Google doesn't need to kill Microsoft, it just needs Microsoft not to be absolutely dominant in the desktop OS, browser, or office suite space. The less dominated by one party those spaces are, the more room leverage Google has to promote open, public standards for web systems and documents (which are easy for Google-bot to index, read, and mine for data) as well as promote its for-pay cloud services like Google Apps Premier.
Microsoft knows that, of course, and since it wants to keep its dominance in those spaces, wants Google gone.
Heroku had a web-based, cloud-based Rails IDE at one point. That's the only example I could think of right away, so I google'd "web-based IDE" and found plenty more examples.
Probably the best example here is AppJet's web-based, cloud-based JavaScript IDE (which was discontinued when AppJet shifted from an AppEngine-like host to focus on marketing EtherPad, originally a demo application for their framework/service.) The best example, that is, because AppJet was later acquired by Google, so Google already owns a web-based IDE.
As a side note: scientifical theories must be testable through experiment (this means there should be a way to look for some evidence to prove the theory wrong).
Perhaps pedantic, but its an important point in this context:
A scientific hypothesis must be falsifiable through experiment (that is, it must make some prediction[s] about how things will work in specific circumstances that can be tested and which, if the test fails, will demonstrate that the hypothesis is incorrect.)
A scientific theory is not merely a testable hypothesis, but a hypothesis which has been subjected to testing and not yet been falsified.
This is really the analogy that you're going with?
No. You seem to be confused. There is no analogy being used. I'm not saying what Apple is doing is analogous to copying, I'm saying it is copying, and that copying is, under copyright law, an exclusive right under copyright (unlike distributing existing copies) and, therefore, unlike distributing existing copies does require a copyright license or an exception to copyright if you aren't the copyright owner.
Apple does indeed transmit a new digital copy each time someone purchases an app. But it not really the essence of what Apple does.
Yes, it is. Making and distributing electronic copies is the essence of what an internet software, music, etc. distribution service does.
It's no more possible for Apple to confirm that the copyright is correct on all these items, than it is for YouTube to police all it's videos. And, unlike YouTube, Apple has a contract with the developer, and knows exactly who should be held responsible.
YouTube, because -- unlike Apple's store -- it allows user-submitted content without a preliminary review, benefits from the DMCA safe harbor provision. Apple, by assuming the right to control what content is put into the App Store through an advance review process, doesn't benefit from the DMCA safe harbor and is, consequently, legally responsible for assuring that the content posted doesn't violate copyright.
If it decides to not include sufficient review to determine that in its review process -- something which it could do -- then it accepts the risk that it is exposed to for doing that.
And it's true for any store. Best Buy is ok to sell the same illegal bits because they are affixed to a physical media?
The bits aren't illegal. The act of copying the bits is illegal.
Apple will pull the app from the store LONG before they allow actual open software to slip through their stranglehold on content.
Pulling the app from the store stops further infringement, but doesn't address the illegal distribution that has already occurred; the only way they can deal with that is either an agreed deal with the FSF or a resolution through the courts.
In theory both could be found to be infringing, but I doubt that any legal decision would be particularly harsh with Apple, unless it became clear they were doing it purposefully.
I wouldn't count on it; courts have more than once awarded substantial damages to anyone for merely redistributing copyright-violating material that they received from a third-party when they aren't the first copyright violator.
And, you know, I'm sure that as such a case worked its way up on appeal, there are many big content owners (and industry groups representing copyright holders) that might be inclined to submit amicus briefs urging appellate courts not to create precedent that would be hostile to such awards.
Apple distributes something (a zip file) which includes an App licensed under the GPL written by an Author who provides said zip file to Apple to distribute.
Walmart distributes something (a router) which includes an App (Linux kernel) licensed under the GPL produced by an company (Linksys) who provides said router to Apple to distribute.
To me: A store sells an object licensed under the GPL produced by another party.
So.... how's Walmart not an acceptable analogy?
A zip file is not an "object" that the retail vendor receives from a supplier. It is a copy that the vendor creates of information that they are provided by a supplier.
Insofar as the information is covered by copyright law, producing the copy requires permission of the copyright holder (or an express exception to copyright, like fair use) -- hence the name "copyright" which consist primarily of the legal right to make copies -- this is different from the distribution of original physical objects that you have received from a supplier, which need no such license (as is made clear by the doctrine of first sale.)
It's normal for the FSF, but abnormal in the litigation-happy world of copyright law.
Actually, its fairly normal everywhere: a cease and desist and/or a demand to satisfy the requirements of the copyright holder without first being sued usually precedes a lawsuit.
Often, the copyright holder's only interest, however, is in money, so the initial demand is for money, and in amount approximately equal to the maximum the copyright holder thinks they could win in a civil action. The FSF however is interested primarily in promoting the distribution of software under specific terms, so its demands are often first for that rather than money.
In either case, the demands are backed by the explicit or implicit threat of legal action.
Slashdot Mirror
I'm not so sure. I think that there is a reason that Native Client is a key component: Google realizes that, in addition to web apps that can be used offline that HTML5 is sufficient to support, apps that rely on native code run locally are important, and so Google wants to incorporate them fully into its model of platform-agnostic applications delivered and updated over the web and accessed through the browser.
Yes, though netbooks and similar systems are the initial focus.
The ability to leverage the full capabilities of the underlying native hardware from apps distributed over the web (that aren't required to even be aware of what the underlying hardware is) is exactly the point of Google's Native Client technology, which they've stated will be a key component of ChromeOS at launch.
Since Google has also stated that it will be incorporated in the Chrome browser off of Chrome OS (its actually a Chromium browser feature, not part of the OS outside of the browser) and be incorporated into Android, Native Client would seem likely to be an attractive target for developers.
If Native Client -- by being incorporated into Chrome, Chrome OS, and Android -- provides a big enough target that isn't a simple subset of the Windows market, it will attract its own developers, with or without binary compatibility with Windows.
Apple iPhone/iTouch/iPad has, I would think, proved that quite well.
AFAIK, Google has stated that Chrome OS will support offline use of web apps that use the appropriate HTML5 features (and will feature Google's Native Client to allow "web" apps that run native-compiled code in a secure sandbox), and that it will only need internet access to use web sites that aren't made to support use as an offline app or to use those that can be offline apps in their online mode, and for the first login for a user (which needs to access the user's Google Account.)
I don't think most bosses would care all that much, so long as the third-party was both perceived to be reliable and the legal infrastructure (contracts, etc.) were in place to assure that the third-party was also accountable.
Outsourcing support functions to someone who is specialized in them and can do perform them efficiently to allow a company to concentrate on its core competencies is hardly an unpopular approach.
Because Android's UI isn't really designed for netbooks, laptops, and desktops (though its been used in netbooks by some vendors), and because Android incorporates an app model that Google wants to move away from in favor of Native Client (as they've stated that, in addition to being part of Chrome OS at launch, Native Client will eventually be part of Android as well, I expect that they'll provide some kind of upgrade path and phase out the existing Android app support -- that's consistent with what Schmidt has said about Android and ChromeOS converging in the long term.)
Other than that, Chrome OS and Android are very similar and share lots of components. Both are built on the Linux kernel. Both use the V8 javascript engine in a WebKit-based browser.
They aren't completely separate "OS systems". They are separate brands, both Linux-based, both placing WebKit-based browsers as key components (the key user-facing component in ChromeOS), both using the V8 javascript engine. They are different in that Chrome OS has UI -- both input and output -- features designed for traditional environments while Android targets mobile, and Android incorporates the JVM for apps while Chrome doesn't -- but that appears to be because at the time Android was released, the JVM was an easy choice for a cross-hardware app environment, while Google has spent much of the time since working on its Native Client mechanism, which it has stated is intended to be an important part of ChromeOS at launch, and also an important component of the Chrome browser and the Android operating system once it is ready.
And Google has said that they expect Android and Chrome OS to converge over time (which makes sense: the essential difference -- other than the ones that related to UI adaptation to different hardware platforms -- is over how apps more native than traditional HTML/JS web-apps are delivered, and Google has already stated that they intend to incorporate the same mechanism Chrome OS will use for that into Android, so the only additional thing necessary for convergence will be to either incorporate the JVM mechanism into Chrome or, more likely, to provide an easy mechanism to convert Android apps into Native Client-based apps.)
Eric Schmidt has said that he expects Android and Chrome OS to converge over time, so the distinction may not be all that significant.
It certainly isn't the conventional approach in traditional firms, but -- especially where the products aren't direct alternatives but merely have some overlap -- it makes some sense.
Google's OS lineup isn't any less "cohesive" than that of any other vendor that has an OS targetting handheld devices and one targetting more traditional computers (netbooks/laptops/desktops.)
About the only difference is that Google has at different times suggested both Android and Chrome OS for tablets, and Google doesn't exert control of what people do with its OS's and, despite the fact that Google has never pushed Android for netbooks, some hardware vendors have chosen to ship it as a (usually, AFAIK, dual-boot with Windows) netbook OS.
And Google has publicly stated that they expect, in the long-term, Android and Chrome OS to merge.
IOW, Google Chrome OS is great for the market it is designed for, but you aren't part of that market.
Chrome OS addresses different needs than Windows, to be sure, but it is designed to compete directly with existing traditional consumer operating systems (Windows & Mac OS), which -- according to Google -- are not targetted at many modern users real needs, but instead are used "by default" as there is no alternative model OS designed for traditional computing devices (vs. phone/handheld/tablet style devices.)
No, Chrome OS is just a linux distro whose main native application is a web browser.
Yes, and Google's entire idea by Chrome OS is that people who need to use a computer a keyboard, mouse, and other hardware features of a traditional PC often don't need a lot of the stuff that comes with a traditional desktop operating system -- they need access simple, secure, stable access to web applications and basic hardware peripherals (like printers).
"Competing with" something doesn't mean copying it. Chrome OS is certainly designed to compete with Windows in a large segment of Windows' current market; it is designed to do so, however, by being very different from Windows and thereby providing a superior experience to that segment of the market, not by being as nearly identical to Windows as possible.
Rather, its only at most as secure as the least secure of the certificate authorities that your browser trusts; its quite possible that either your computer or the server you are accessing is, itself, less secure than any of the CAs involved, in which case those are the limiting factors.
"Apple" and "Microsoft" are not the right units of analysis.
The dominance of Microsoft Windows, Internet Explorer, and Office are issues for Google, as could be the dominance of Apple's iPhone, iPod Touch, and iPad devices.
Apple's Mac desktop/notebook computers aren't a problem at all for Google, though.
Only for unusually small values of "All". The following are a few examples of Google apps that are that (while in some cases they interact with the web) do not "target a web platform", but instead run on a desktop OS (usually, and in some cases exclusively, Microsoft Windows) or (in one case) the add-in environment (rather than the "web platform") of a browser (often, Microsoft Internet Explorer on Microsoft Windows):
Google Chrome
Google Desktop
Google Toolbar
Google Earth
Google SketchUp
Google Linux (Mobile Edition) goes by the trade name "Android" and has been available in production for quite some time.
Google Linux (Netbook Edition) goes by the name ChromeOS and is in Beta; at the time work on ChromeOS was announced, it was discussed as "netbook-first", with possible expansion to address traditional desktop use, so any notional Google Linux (Desktop Edition) would likely just be a later version of ChromeOS.
So, really, the only thing we haven't seen is Google Linux (Server Edition), which I'm not sure Google has much interest in sharing.
I think it is Google trying to break MS's OS & office suite monopoly and MS trying to kill Google. Google doesn't need to kill Microsoft, it just needs Microsoft not to be absolutely dominant in the desktop OS, browser, or office suite space. The less dominated by one party those spaces are, the more room leverage Google has to promote open, public standards for web systems and documents (which are easy for Google-bot to index, read, and mine for data) as well as promote its for-pay cloud services like Google Apps Premier.
Microsoft knows that, of course, and since it wants to keep its dominance in those spaces, wants Google gone.
Probably the best example here is AppJet's web-based, cloud-based JavaScript IDE (which was discontinued when AppJet shifted from an AppEngine-like host to focus on marketing EtherPad, originally a demo application for their framework/service.) The best example, that is, because AppJet was later acquired by Google, so Google already owns a web-based IDE.
Perhaps pedantic, but its an important point in this context:
A scientific hypothesis must be falsifiable through experiment (that is, it must make some prediction[s] about how things will work in specific circumstances that can be tested and which, if the test fails, will demonstrate that the hypothesis is incorrect.)
A scientific theory is not merely a testable hypothesis, but a hypothesis which has been subjected to testing and not yet been falsified.
Really? Please describe the nature of this potential.
Which, for instance, any application running on AppSpot would have.
No. You seem to be confused. There is no analogy being used. I'm not saying what Apple is doing is analogous to copying, I'm saying it is copying, and that copying is, under copyright law, an exclusive right under copyright (unlike distributing existing copies) and, therefore, unlike distributing existing copies does require a copyright license or an exception to copyright if you aren't the copyright owner.
Yes, it is. Making and distributing electronic copies is the essence of what an internet software, music, etc. distribution service does.
YouTube, because -- unlike Apple's store -- it allows user-submitted content without a preliminary review, benefits from the DMCA safe harbor provision. Apple, by assuming the right to control what content is put into the App Store through an advance review process, doesn't benefit from the DMCA safe harbor and is, consequently, legally responsible for assuring that the content posted doesn't violate copyright.
If it decides to not include sufficient review to determine that in its review process -- something which it could do -- then it accepts the risk that it is exposed to for doing that.
The bits aren't illegal. The act of copying the bits is illegal.
Pulling the app from the store stops further infringement, but doesn't address the illegal distribution that has already occurred; the only way they can deal with that is either an agreed deal with the FSF or a resolution through the courts.
I wouldn't count on it; courts have more than once awarded substantial damages to anyone for merely redistributing copyright-violating material that they received from a third-party when they aren't the first copyright violator.
And, you know, I'm sure that as such a case worked its way up on appeal, there are many big content owners (and industry groups representing copyright holders) that might be inclined to submit amicus briefs urging appellate courts not to create precedent that would be hostile to such awards.
A zip file is not an "object" that the retail vendor receives from a supplier. It is a copy that the vendor creates of information that they are provided by a supplier.
Insofar as the information is covered by copyright law, producing the copy requires permission of the copyright holder (or an express exception to copyright, like fair use) -- hence the name "copyright" which consist primarily of the legal right to make copies -- this is different from the distribution of original physical objects that you have received from a supplier, which need no such license (as is made clear by the doctrine of first sale.)
Actually, its fairly normal everywhere: a cease and desist and/or a demand to satisfy the requirements of the copyright holder without first being sued usually precedes a lawsuit.
Often, the copyright holder's only interest, however, is in money, so the initial demand is for money, and in amount approximately equal to the maximum the copyright holder thinks they could win in a civil action. The FSF however is interested primarily in promoting the distribution of software under specific terms, so its demands are often first for that rather than money.
In either case, the demands are backed by the explicit or implicit threat of legal action.