unless congress passes a law i don't see this surviving a lawsuit.
If the elements reported as being in the discussion draft are accurate (not having seen the draft -- which, in the modern age, not either linking if it is published, or providing for download if it is unpublished, is, IMO, bad-though-common journalism -- and if they were proposed as regulation, not only would they contradict the existing statute law (and thus be invalid) barring a new law, they in many cases be unconstitutional even if Congress did pass a new law incorporating them.
But discussion drafts are just that -- ideas about means that could be used to address a problem for discussion -- and often include things that that would be rejected on further analysis as undesirable, or that would be rejected on further analysis because they would require Constitutional or legislative changes that are not politically viable.
Because Yahoo! shareholder's want their stock value to grow, and social networking is perceived as a way of acheiving that.
Social networking features promote stickiness (which helps advertising sales) and provide something that third party developers can leverage to provide additional social apps, which then further promote stickiness, and help sell more ads.
Seriously can anyone name a single benefit for the end user?
More competition in the social networking space means more consumer choice in that space. If you aren't interested in social networking features, that's not a benefit to you, but social networking is a big thing in the market specifically because lots of end users are interested in those features.
All valid C code is valid Objective C code (well, all C code as of the standard at the time Objective-C was created -- I'm not sure to what extent Objective C has tracked evolution of the C standard.)
Almost no substantial valid Java code is also valid Objective C code.
That second "quote" (even though it's not a direct quote per the article) is directly contradicted by the first, which has much more detail as to specific triggers and which IS a direct quote.
Whether its a direct quote or not is irrelevant. The key thing is that they are contradictory characterizations by different staffers, and neither one of them ought to be trusted, not because they are contradictory (though that is a clue that there is an issue), but because they are characterizations of the bill by political staffers, not the actual language of the bill or even analysis of the provisions of the bill by a party for whom we have reason to believe that they are both competent and inclined to be objective.
The fact that there is a "direct quote" in a media article may (if the news outlet is credible) give a reason to believe that's what the source actually said, but it certainly doesn't (on its own) lend any wait to that source's characterization of the facts.
You assume every staffer is all briefed on all data so everyone is on the same page?
No, nor did I say that.
I would imagine he has a large group of staffers
He who? The staffers were identified as "senate staffers", not which senator they were staffers for.
Nothing nefarious.
I didn't say there was anything nefarious in the contradiction. I said that the contradiction in the characterizations was one indication of why you shouldn't trust second-hand interpretations, especially ones from potentially interested parties (as the nameless senate staffers clearly are) as a basis for trusting that a law has clear limits.
The fact that one or more staffers (particularly if they are staffers for a Senator trying to sell the bill) characterizes the bill as being narrowly crafted doesn't mean it actually is. This is underlined when a different staffer characterizes it differently, but the problem would remain even without the contradiction.
Let me ask you, did you feel uncomfortable with the fact that they already have this authority with your electric infrastructure? Your water? You're local emergency services?
What authority, and under what conditions?
I'm not arguing that the bill is bad, I'm arguing that relying on comments from interested political actors rather than the bill text doesn't provide a reliable basis for even making claims about what the bill does much less whether that is a good or bad thing to do.
It's too early to draw that conclusion. A lot of smart economists think that we've just delayed the inevitable and made the eventual crash that much worse. Time will tell of course
No, it won't.
If you want to believe that a crash is "inevitable" and can only be "delayed", then you can continue to say that new events have "delayed" it and made it "much worse" when it eventually comes until the heat death of the universe.
If you can give me ONE example, where a set of laws were introduced (like the Patriot Act) with the promise they wouldn't go down slippery slope, AND THEY KEPT THAT PROMISE, then I'll shut up about the slippery slope.
The recent bank bailouts where the "slippery slope" presented by critics was a complete and permanent government direct management of banking, and where instead money is being paid back and the banks continue to be privately managed in the interests of their shareholders (or, at least, their management.)
I'll be the first to say you shouldn't trust on faith a politicians claims about how a law will be applied (or even its contents), and, particularly relevant to this law, any claim that a bill crafted by Joe Lieberman granting executive "emergency" powers will be carefully crafted to apply narrowly.
That's not at all clear. An actual bill number would let us check the text, all we have in TFA is two characterizations by staffers which disagree, and you've pulled the one favorable to your position and ignored the other:
As to the trigger in this bill, from TFA:
"In order for the President to declare such an emergency, there would have to be knowledge both of a massive network flaw — and information that someone was about to leverage that hole to do massive harm. For example, the recent “Aurora” hack to steal source code from Google, Adobe and other companies wouldn’t have qualified, one Senate staffer noted: “It’d have to be Aurora 2, plus the intel that country X is going to take us down using that vulnerability.”
See, that sounds somewhat narrowly applicable. But if you keep reading the following paragraph in TFA, you'd see another staffer suggesting that something like the Conficker worm might have triggered based on unspecific evidence that "hackers" were looking to "leverage" it in some way (not the kind of specific "country X" kind of requirement the first staffer suggested):
A second staffer suggested that evidence of hackers looking to leverage something like the massive Conficker worm — which infected millions of machines and was seemingly poised in April 2009 to unleash something nefarious — might trigger the bill’s emergency provisions. “You could argue there’s some threat information built in there,” the staffer said.
So, given that the staffers quoted in TFA don't agree -- and, frankly, even if they did -- maybe we shouldn't take the most inoffensive characterization in TFA as being an accurate reflection of the bill.
People complain that politicians lie too much, but you know -- if people didn't just accept the most comforting thing they or their staffers said on faith, maybe they wouldn't keep lying.
Sorry to troll, but what exactly is a "strict superset"? A superset is a set that contains another set, in this case Objective-C contains C; all of it. If it didn't contain all of C, then it wouldn't be a superset at all. So what makes a superset strict?
A simple analogy:
"Strict superset" is to "superset" as ">" is to ">=".
I've never understood why Apple has such an obsession with Objective C. To me it really does seem like being different for the sake of being different. In the event they really felt like a new language was needed, well, they should have made one (as MS did in the case of C#). Otherwise it makes sense to use C and C++.
Objective-C is a strict superset of C, so anything that can use Ojective-C can use C as well.
Apple didn't "feel a new language was needed" for Mac OS X and adopt Objective-C; Mac OS X is, in large part, a repackaging of NeXTstep, for which Objective-C was always the primary language. NeXTstep adopted Objective-C (NeXT didn't invent it, though, they licensed the existing language) in 1988 when both it and C++ were young languages, neither one of which had much penetration.
And if I'd ask you to name another compiled language with dynamic message routing/dispatch it would be what? C libs compatibility is desired.
If you by "compiled" you mean merely "has a implementation that relies on compilation", than there are lots of options -- Ruby in the form of JRuby, Ruby 1.9.x, or Rubinius; Erlang, and a bunch of others (AFAIK, Ruby -- including JRuby -- can use C libs fairly readily; Erlang makes that more difficult, though ISTR seeing that there is some improvement on that front in the most recent releases.)
If you mean "has an implementation that is compiled to native machine code rather than VM bytecode", then the number is smaller, but Smalltalk -- which is where Objective-C got the features it added to C -- certainly counts, as there are Smalltalk systems that support compilation to machine code and link C-derived libs.
Any rule that imposes consequences on any behavior or status can be viewed as a double standard. Whether the distinction it draws is desirable, appropriate, or justified is more important than whether it sounds like a double standard.
Basically, Microsoft is not allowed to compete by law.
This is inaccurate. A firm exercising monopoly power in one market is not allowed to exercise that power to prevent other firms from competing with it in another market.
That does not prevent the monopolist from competing outside its monopoly market (indeed, insofar as the monopolists chooses to participate in another market, it requires them to compete rather than merely dictating terms.)
Google Apps deliver a quite limited subset of general office suite features available only under certain environments.
To an extent this is true, but IMO not as significant as some people make it. Office suites are -- while often the only tool users have and so applied far more broadly than they are ideal -- generally inferior to tools crafted directly to support an organizations workflow, which modern tools make it much easier to construct than was once the case.
ChromeOS is another option for Netbooks - i.e. it might be suitable as another alternative in the already harmfully and unnecessarily flooded market of Netbook operating systems. But no firm should entertain using ChromeOS to prepare content.
Why not, especially if the firm already uses -- as a number, including some large organizations, do -- Google Apps Premier as their primary general purpose application suite, supplemented by custome web apps (possibly also hosted by Google through App Engine) specific to that firms own workflow?
They kinda do force you to use Google search - switching search providers (unlike IE or Firefox) in Chrome is a major inconvenience (it involves digging through menus and dialogue boxes). Firefox/IE its a matter of pointing and clicking.
"Digging through menus and dialogue boxes" and "pointing and clicking" are really the same thing, and if you reversed those descriptions they'd be just as accurate as they are the way you presented them.
Google are freely offering Chrome (+ChromeOS maybe) on the home page to users of their search service: "A faster way to browse the web - install Google Chrome".
What you miss is that this is non-discriminatory offering; you don't have to get the Chrome browser to get their dominant search service, and getting the Chrome browser doesn't get you privileged access to their dominant search service. So, even if consumer search were a market in which a monopoly could exist (since what Google provides their is free of charge, its arguably not a market at all just a tool for Google to sell products in a different market -- the relevant market is advertising, where Google does not have anything like a dominant share) there is nothing being done to leverage it in an anticompetitive manner.
Since Google's entire business model revolves around advertising
Right. Its not like Google sells anything other than advertising, like, for instance, application hosting services for both custom web apps, and for versions of its own web apps tied to domains and coupled with SLA's and support.
Well, except that they do.
while Microsoft, Apple (and Linux, in a fashion)'s business model revolves around selling OSes
"Linux" isn't an organization with a business model, and while some organizations may sell support for Linux, none are selling the OS as such.
And Microsoft and Apple both sell online advertising -- Apple making a major strategic push in that area recently.
I think it would be pretty easy for MS or Apple to simply say, "We will never collect any data about our OS users' application usage, browsing habits, or other personal information."
You might imagine it would be easy for them to say that -- but in the real world, that would substantial changes in their business even beyond abandoning their efforts to sell advertising, since, in fact, they do seek to collect OS and application users application usage, browsing habits, and other personal information, for their own direct marketing, for advertising, and as a way of getting information on how their products are used to guide future plans.
And Microsoft and Apple are trending toward doing more of that, not less.
To be fair, google is using it's search revenue to muscle it's way into a lot of other online services markets by offering the services for free (domain hosted Gmail, google apps, etc). That seems pretty shady to me, but what do I know.
Using revenue from one market to expand into another isn't, IMO, "shady" (if you think about it, other than soliciting specific outside financing to do it, that's the only way businesses expand.)
Leveraging your dominance in one market to create dominance in another in a way which obstructs effective competition, is a very different thing from merely using revenue from success in one market to finance expansion into another.
I admire Google's pioneering spirit, and I also welcome any move towards relegating Microsoft to the trashcan of history, but I find it hard to believe that any OS intended for a PC environment that fundamentally requires an always-on internet connection could successfully compete for market share against those that also provide the option of running apps locally.
Chrome OS isn't designed to require an "always on" internet connection, which is why features for offline use of apps are key to it; it requires internet access for online tasks, and for the first logon of a given user.
It is designed to run offline HTML5 web apps locally.
I don't think the world is wired enough yet for the Chrome/Software-as-a-service concept. I also don't think people will just silently accept making regular payments for a service that replaces what they used to be able to do for free locally.
Nothing required to use Chrome requires making regular payments other than the payments already required for having some kind of (at least intermittent) network access.
With Chrome the whole privacy issue is a serious one, and I can also imagine that just the associated network latency of running an app on a remote server instead of locally on a reasonably specced PC is always bound to make the experience feel clunkier.
Google's put a lot of effort (both in the HTML5 standards processes and in the Chrome browser, a key Chrome OS component) to allow "web" apps to do more work locally (including working completely offline.) No doubt, the latency experienced with tradition web apps that do almost all of their work on the server side is precisely the reason for this. This work continues in the runup to Chrome OS (improvements in this area in the Chrome browser are part of what needs to happen before Chrome OS is ready to deploy.)
If Chrome manages to fulfill Google's dream of entirely killing the notion that PCs can run apps locally,
If Chrome OS was intended to do that, it probably wouldn't include as a key component Native Client, whose whole purpose is to enable running native applications locally in a secure sandbox.
It's an OS to launch and run a browser, which does *all* the work.... and do as little as possible otherwise....
It's competing with very little....at the moment, except if you have a thin client desktop machine ?
With Native Client as a key component, I'm not sure Chrome OS is really very much like a "thin client" machine. It takes browser-as-primary-user-interface to the extreme, but it is intended to supporting doing a lot more than traditional web apps through that interface.
I know we all want to use our new toys, but there is a big shift in data traffic through the networks now and it'll take a while for the telecom operators to be able to catch up.
You know, that's the excuse that apologists have been made for every unpopular action by carriers since wireless data service became available.
I don't think its innocent carriers that are just overtaken by the pace of change, I think its barriers to effective competition (small number of total significant carriers, and vendor lock-in both through contracts and technical limitations of various devices) that means carriers don't have much incentive to deliver service in a way which keeps up with changes in technology.
It doesn't mean I can use it to run the plethora of native apps I already have.
Sure, if you are dependent on existing apps that are intrinsically tied to an existing platform, a new platform that doesn't include an implementation of your existing platform won't work as a complete replacement for you, no matter what features and advantages it has for new users that aren't as tied to legacy apps.
Which is probably one reason Google is targetting netbooks first: they are frequently mobile second computers for people who also have desktop computers (or even less-portable laptops) -- and for people who really need legacy apps, those will likely be on the less portable devices, and the many of the uses people have for netbooks won't be as bound to the legacy apps.
Give Native Client time to establish a userbase (not only on Chrome OS, but with Chrome browser on other platforms), and apps that are currently available only as (e.g.) Windows-native apps may become availabe targetting Native Client, which will give people an upgrade path for the legacy apps and reduce reliance on OS-specific apps, increasing the potential reach of Chrome OS.
HTML5 is part of the future. I think plug-ins, though, are also part of the future, though Flash may be edged out from the "simpler" side by HTML5 and from the "richer capabilities" side by things like Google's Native Client.
But on a brand level, I think "Android Chrome" or "Chrome on Android" would be a much better idea than "Chrome" and "Android".
My guess is that they are separating them for two reasons:
(1) Chrome OS doesn't run Android apps; putting Android in the name would create a consumer expectation that would not be fulfilled. (2) Android is well-established brand as a phone/handheld OS, while Chrome is a well-established brand for a desktop/laptop/netbook browser. Using "Chrome OS" as the brand name intends to suggest that the OS extends the browser experience on those platforms, where using the Android brand would suggest that it extends the handheld experience.
Existing, Windows-specific games? No Existing, web-games? Yes New, native games? Probably. Google's Native Client system, which downloads, compiles, and runs code natively in a secure sandbox, abstracting the underlying OS and hardware -- and which is planned as a launch component of Chrome OS and for (presumably concurrent) inclusion in the Chrome browser more generally -- may well be an attractive target for developers.
Will it run them reliably, effecivly and as table as Windows 7? Y/N
The ones it runs at all (see above), there is no particular reason to believe it won't run at least as reliably, effectively, and stably as Windows 7.
will it have support, patching, ease of use and compatibility with 3d party aspects? (printers for example) Y/N
Ease of use for printers may well exceed traditional OS's with Google's Cloud Print technology, though that remains to be seen. More generally, hardware support will probably be less complete than Windows for some time, but lots of existing hardware has decent support under Linux (on which Chrome OS is based), and Google putting resources behind Chrome OS will no doubt improve that further over time, particularly for the categories of hardware most used.
Slashdot Mirror
A discussion draft is not an indication that the government is willing to do anything.
If the elements reported as being in the discussion draft are accurate (not having seen the draft -- which, in the modern age, not either linking if it is published, or providing for download if it is unpublished, is, IMO, bad-though-common journalism -- and if they were proposed as regulation, not only would they contradict the existing statute law (and thus be invalid) barring a new law, they in many cases be unconstitutional even if Congress did pass a new law incorporating them.
But discussion drafts are just that -- ideas about means that could be used to address a problem for discussion -- and often include things that that would be rejected on further analysis as undesirable, or that would be rejected on further analysis because they would require Constitutional or legislative changes that are not politically viable.
Because Yahoo! shareholder's want their stock value to grow, and social networking is perceived as a way of acheiving that.
Social networking features promote stickiness (which helps advertising sales) and provide something that third party developers can leverage to provide additional social apps, which then further promote stickiness, and help sell more ads.
More competition in the social networking space means more consumer choice in that space. If you aren't interested in social networking features, that's not a benefit to you, but social networking is a big thing in the market specifically because lots of end users are interested in those features.
All valid C code is valid Objective C code (well, all C code as of the standard at the time Objective-C was created -- I'm not sure to what extent Objective C has tracked evolution of the C standard.)
Almost no substantial valid Java code is also valid Objective C code.
Whether its a direct quote or not is irrelevant. The key thing is that they are contradictory characterizations by different staffers, and neither one of them ought to be trusted, not because they are contradictory (though that is a clue that there is an issue), but because they are characterizations of the bill by political staffers, not the actual language of the bill or even analysis of the provisions of the bill by a party for whom we have reason to believe that they are both competent and inclined to be objective.
The fact that there is a "direct quote" in a media article may (if the news outlet is credible) give a reason to believe that's what the source actually said, but it certainly doesn't (on its own) lend any wait to that source's characterization of the facts.
No, nor did I say that.
He who? The staffers were identified as "senate staffers", not which senator they were staffers for.
I didn't say there was anything nefarious in the contradiction. I said that the contradiction in the characterizations was one indication of why you shouldn't trust second-hand interpretations, especially ones from potentially interested parties (as the nameless senate staffers clearly are) as a basis for trusting that a law has clear limits.
The fact that one or more staffers (particularly if they are staffers for a Senator trying to sell the bill) characterizes the bill as being narrowly crafted doesn't mean it actually is. This is underlined when a different staffer characterizes it differently, but the problem would remain even without the contradiction.
What authority, and under what conditions?
I'm not arguing that the bill is bad, I'm arguing that relying on comments from interested political actors rather than the bill text doesn't provide a reliable basis for even making claims about what the bill does much less whether that is a good or bad thing to do.
No, it won't.
If you want to believe that a crash is "inevitable" and can only be "delayed", then you can continue to say that new events have "delayed" it and made it "much worse" when it eventually comes until the heat death of the universe.
The recent bank bailouts where the "slippery slope" presented by critics was a complete and permanent government direct management of banking, and where instead money is being paid back and the banks continue to be privately managed in the interests of their shareholders (or, at least, their management.)
I'll be the first to say you shouldn't trust on faith a politicians claims about how a law will be applied (or even its contents), and, particularly relevant to this law, any claim that a bill crafted by Joe Lieberman granting executive "emergency" powers will be carefully crafted to apply narrowly.
That's not at all clear. An actual bill number would let us check the text, all we have in TFA is two characterizations by staffers which disagree, and you've pulled the one favorable to your position and ignored the other:
See, that sounds somewhat narrowly applicable. But if you keep reading the following paragraph in TFA, you'd see another staffer suggesting that something like the Conficker worm might have triggered based on unspecific evidence that "hackers" were looking to "leverage" it in some way (not the kind of specific "country X" kind of requirement the first staffer suggested):
So, given that the staffers quoted in TFA don't agree -- and, frankly, even if they did -- maybe we shouldn't take the most inoffensive characterization in TFA as being an accurate reflection of the bill.
People complain that politicians lie too much, but you know -- if people didn't just accept the most comforting thing they or their staffers said on faith, maybe they wouldn't keep lying.
Irrelevant to GP, which referenced exercising monopoly power in a market, not whether or not they "were a monopoly".
I have yet to see a credible argument that Google exercises monopoly power in any definable market under antitrust law.
As for Google.
A simple analogy:
"Strict superset" is to "superset" as ">" is to ">=".
Objective-C is a strict superset of C, so anything that can use Ojective-C can use C as well.
Apple didn't "feel a new language was needed" for Mac OS X and adopt Objective-C; Mac OS X is, in large part, a repackaging of NeXTstep, for which Objective-C was always the primary language. NeXTstep adopted Objective-C (NeXT didn't invent it, though, they licensed the existing language) in 1988 when both it and C++ were young languages, neither one of which had much penetration.
If you by "compiled" you mean merely "has a implementation that relies on compilation", than there are lots of options -- Ruby in the form of JRuby, Ruby 1.9.x, or Rubinius; Erlang, and a bunch of others (AFAIK, Ruby -- including JRuby -- can use C libs fairly readily; Erlang makes that more difficult, though ISTR seeing that there is some improvement on that front in the most recent releases.)
If you mean "has an implementation that is compiled to native machine code rather than VM bytecode", then the number is smaller, but Smalltalk -- which is where Objective-C got the features it added to C -- certainly counts, as there are Smalltalk systems that support compilation to machine code and link C-derived libs.
Any rule that imposes consequences on any behavior or status can be viewed as a double standard. Whether the distinction it draws is desirable, appropriate, or justified is more important than whether it sounds like a double standard.
This is inaccurate. A firm exercising monopoly power in one market is not allowed to exercise that power to prevent other firms from competing with it in another market.
That does not prevent the monopolist from competing outside its monopoly market (indeed, insofar as the monopolists chooses to participate in another market, it requires them to compete rather than merely dictating terms.)
That'
To an extent this is true, but IMO not as significant as some people make it. Office suites are -- while often the only tool users have and so applied far more broadly than they are ideal -- generally inferior to tools crafted directly to support an organizations workflow, which modern tools make it much easier to construct than was once the case.
Why not, especially if the firm already uses -- as a number, including some large organizations, do -- Google Apps Premier as their primary general purpose application suite, supplemented by custome web apps (possibly also hosted by Google through App Engine) specific to that firms own workflow?
"Digging through menus and dialogue boxes" and "pointing and clicking" are really the same thing, and if you reversed those descriptions they'd be just as accurate as they are the way you presented them.
What you miss is that this is non-discriminatory offering; you don't have to get the Chrome browser to get their dominant search service, and getting the Chrome browser doesn't get you privileged access to their dominant search service. So, even if consumer search were a market in which a monopoly could exist (since what Google provides their is free of charge, its arguably not a market at all just a tool for Google to sell products in a different market -- the relevant market is advertising, where Google does not have anything like a dominant share)
there is nothing being done to leverage it in an anticompetitive manner.
Right. Its not like Google sells anything other than advertising, like, for instance, application hosting services for both custom web apps, and for versions of its own web apps tied to domains and coupled with SLA's and support.
Well, except that they do.
"Linux" isn't an organization with a business model, and while some organizations may sell support for Linux, none are selling the OS as such.
And Microsoft and Apple both sell online advertising -- Apple making a major strategic push in that area recently.
You might imagine it would be easy for them to say that -- but in the real world, that would substantial changes in their business even beyond abandoning their efforts to sell advertising, since, in fact, they do seek to collect OS and application users application usage, browsing habits, and other personal information, for their own direct marketing, for advertising, and as a way of getting information on how their products are used to guide future plans.
And Microsoft and Apple are trending toward doing more of that, not less.
Using revenue from one market to expand into another isn't, IMO, "shady" (if you think about it, other than soliciting specific outside financing to do it, that's the only way businesses expand.)
Leveraging your dominance in one market to create dominance in another in a way which obstructs effective competition, is a very different thing from merely using revenue from success in one market to finance expansion into another.
Chrome OS isn't designed to require an "always on" internet connection, which is why features for offline use of apps are key to it; it requires internet access for online tasks, and for the first logon of a given user.
It is designed to run offline HTML5 web apps locally.
Nothing required to use Chrome requires making regular payments other than the payments already required for having some kind of (at least intermittent) network access.
Google's put a lot of effort (both in the HTML5 standards processes and in the Chrome browser, a key Chrome OS component) to allow "web" apps to do more work locally (including working completely offline.) No doubt, the latency experienced with tradition web apps that do almost all of their work on the server side is precisely the reason for this. This work continues in the runup to Chrome OS (improvements in this area in the Chrome browser are part of what needs to happen before Chrome OS is ready to deploy.)
If Chrome OS was intended to do that, it probably wouldn't include as a key component Native Client, whose whole purpose is to enable running native applications locally in a secure sandbox.
It's an OS to launch and run a browser, which does *all* the work .... and do as little as possible otherwise ....
It's competing with very little ....at the moment, except if you have a thin client desktop machine ?
With Native Client as a key component, I'm not sure Chrome OS is really very much like a "thin client" machine. It takes browser-as-primary-user-interface to the extreme, but it is intended to supporting doing a lot more than traditional web apps through that interface.
You know, that's the excuse that apologists have been made for every unpopular action by carriers since wireless data service became available.
I don't think its innocent carriers that are just overtaken by the pace of change, I think its barriers to effective competition (small number of total significant carriers, and vendor lock-in both through contracts and technical limitations of various devices) that means carriers don't have much incentive to deliver service in a way which keeps up with changes in technology.
Sure, if you are dependent on existing apps that are intrinsically tied to an existing platform, a new platform that doesn't include an implementation of your existing platform won't work as a complete replacement for you, no matter what features and advantages it has for new users that aren't as tied to legacy apps.
Which is probably one reason Google is targetting netbooks first: they are frequently mobile second computers for people who also have desktop computers (or even less-portable laptops) -- and for people who really need legacy apps, those will likely be on the less portable devices, and the many of the uses people have for netbooks won't be as bound to the legacy apps.
Give Native Client time to establish a userbase (not only on Chrome OS, but with Chrome browser on other platforms), and apps that are currently available only as (e.g.) Windows-native apps may become availabe targetting Native Client, which will give people an upgrade path for the legacy apps and reduce reliance on OS-specific apps, increasing the potential reach of Chrome OS.
HTML5 is part of the future. I think plug-ins, though, are also part of the future, though Flash may be edged out from the "simpler" side by HTML5 and from the "richer capabilities" side by things like Google's Native Client.
My guess is that they are separating them for two reasons:
(1) Chrome OS doesn't run Android apps; putting Android in the name would create a consumer expectation that would not be fulfilled.
(2) Android is well-established brand as a phone/handheld OS, while Chrome is a well-established brand for a desktop/laptop/netbook browser. Using "Chrome OS" as the brand name intends to suggest that the OS extends the browser experience on those platforms, where using the Android brand would suggest that it extends the handheld experience.
Existing, Windows-specific games? No
Existing, web-games? Yes
New, native games? Probably. Google's Native Client system, which downloads, compiles, and runs code natively in a secure sandbox, abstracting the underlying OS and hardware -- and which is planned as a launch component of Chrome OS and for (presumably concurrent) inclusion in the Chrome browser more generally -- may well be an attractive target for developers.
The ones it runs at all (see above), there is no particular reason to believe it won't run at least as reliably, effectively, and stably as Windows 7.
Ease of use for printers may well exceed traditional OS's with Google's Cloud Print technology, though that remains to be seen. More generally, hardware support will probably be less complete than Windows for some time, but lots of existing hardware has decent support under Linux (on which Chrome OS is based), and Google putting resources behind Chrome OS will no doubt improve that further over time, particularly for the categories of hardware most used.