That's the opportunity to run your Java bytecode or Python on their boxes with a set of APIs for Google's raw cluster services. It's hardly the first port of call for building typical small business glue code on existing software.
Nor did I recommend it for "building typical small business glue code on existing software".
I said it was the more capable, more portable, less locked-in choice for implementing workflow management, when compared to Google Apps Script, for Google Apps users.
This is as specious as ".NET isn't lock-in because Mono".
Well, I'd agree, but in exactly the opposite sense that you intended, since -- presuming one doesn't use features of.NET that aren't present in Mono --.NET isn't lock-in because of Mono. If an open-source alternative that supports the same APIs is availabe so that you are not dependent on the original vendor for continued support of the platform on which your custom code runs, you aren't in any meaningful sense "locked-in" to anything. So neither is specious.
Ignoring the 'one line change', does it seem appropriate that changing a company string should cause an "Out of memory" error? I realize the OOM error happened about 8 stack frames later but I mean, seriously ?
Apparently, the VM sniffing was done to determine whether to use a particular mechanism to adjust memory settings. So, while it probably should have thrown up a "this is an unknown VM and things might not work" type of error at least the first time it encountered the unknown VM, its not entirely surprising that on an VM that it didn't know how to handle it ended up getting a memory-related error.
You'd figure that if there were one Java app that they'd test, it'd be Eclipse.
I wouldn't even think that that would be the Java IDE they'd be most likely to test -- I would pick NetBeans for that.
I mean, saying that if they were going to test one app on a new Java update it would be NetBeans is like saying if Microsoft was going to test one app on a Windows update it would be iTunes.
Google "Access Now v. Southwest Airlines" It's already been decided in court that web sites are not public accommodations.
Sure, one trial court found that way (which doesn't address the issue that the web site of an entity that is a public accommodation is subject to the requiremenst of the ADA.) That decision, further, has almost no precedential weight, as the decisions of a trial court aren't binding on any other court in any case between other litigants.
(There was also a decision in the 11th Circuit on this case, but the decision in the 11th Circuit was based on the fact that the legal argument made on appeal was completely different than that made at the trial court, and didn't reach the merits of either the issues that were before the trial court or the issues that were made on appeal, refusing to reach the merits because the new arguments were improperly first raised on appeal.)
You will, having thought a bit and found out that even Google agrees, be itching to point out the glorious lock-in that is Google Apps Script
Actually, while you can use Google Apps Script for workflow programming, what I would point out is Google App Engine, which integrates with Google Apps for domains, which, since independent implementations of the APIs exist, isn't lock in, and is far more capable. Apps Script is essentially "macros on steroids", and I'd suggest that they would be best seen as serving the same role as macro programming in existing office suites.
This is incorrect. Per the relevant statutory definition (42 U.S.C. Sec. 12181(7)) a variety of "entities" are defined as public accommodations, not "physical places".
Most of those entities would commonly also have physical facilities that would be their sole or primary mechanisms of interaction with the public, but many of them would, these days, also interact with the public through the Web. Some of them (particularly, certain undergraduate and postgraduate private schools, which are entities named as "public accommodations") might have the Web as their primary mode of access rather than a secondary one.
I never understood this, if a student is substandard then they are substandard. If this superintendent knew what the definition of average was he would realise that, by definition, some students HAVE to fall below a 'C' mark.
Its true that if you define "C" as "exactly the arithmetic mean performance" and require every measured level less than that as a lower letter grade and every measured performance greater than that as a higher letter grade, and if not all students have exactly the same measured performance, some students would need to have grades lower than "C".
However, most people would not define "C" in that way, and with most reasonable definitions of "C" as a grade range it is actually not true, by definition, that some must fall below it.
Stock is a LOUSY indication of a CEO's performance.
Often -- and in this case -- its not. The CEO works for the stockholders, and his job is to maximize their realization of their shared interest, which in the case of most publicly traded companies, is limited to maximization of their own financial returns in the form of stock appreciation + dividends (and, mostly, its preferred these days that the form be "stock appreciation" rather than dividends.)
What this would appear to mean is that any use of a dongle by a program for licensing is now null and void. If a "remover" tool is available to eliminate the need for the dongle, then anyone is free to use this.
Well, no, it doesn't mean that "anyone is free to use this", it just means that its not a violation of the DMCA.
But simply disabling the dongle would appear to be perfectly legal.
That it doesn't violate the DMCA doesn't mean that it could not be a violation of some other legal restriction (such as those imposed by a contract.)
For expensive software, this pretty much means only a single copy ever need be purchased and the customer can do this with impunity.
No, it doesn't. Believe it or not, license restrictions on expensive software could be enforced through the courts before the DMCA existed, so finding that bypassing a particular technical mechanism isn't a violation of the DMCA does not suddenly make it so that customers may use copies of expensive software beyond what their licensing agreement allows with "impunity".
But again, once you enshrine the right to disable dongles you have opened the door to unlimited redistribution.
No, you haven't. Copyright law already prohibits unauthorized reproduction (a necessary precursor to unlimited distribution), and copyright holders can enforce those provisions in the courts whether or not they can use the DMCA in the courts to punish bypassing dongles.
While you might try to equate this to legal vs. illegal use of a hammer where murder isn't a legal use I would frame this far closer to the idea of someone marketing full-size guillotines for trimming "Really Big Cigars" and attempting to say that the legal vs. murderous use of such a device outweighs any other interest in the matter.
You might, but that wouldn't be any different than the hammer case, and indeed devices that amount to "really big guillotines" (only generally automated and much more suited to mass decapitation, if that was what someone chose to use them for, are not only legal but widely used in various industries.
But if you start monkeying around with the UI and changing things that quickly. You make people mad.
Google hasn't said they plan to increase the number of UI changes Chrome experience per unit time. They just said they plan on releasing on a frequent and regular schedule, and releasing whatever features are ready for a stable release at each release.
Just like MS, Google is versioning browser to catch up, not because they do anything new. Google can't even get a product out of beta in less than two years, so why should it be expecting a major upgrade every quarter?
Its not "expecting" a "major upgrade" every quarter.
It is scheduling a stable feature release of Chrome every six weeks (a little bit more than twice a quarter) with whatever features are ready for a stable release at the time.
Since the feature releases will have whatever features are ready, (and since Chrome has always, AFAIK, used stable feature releases as the basis for "major" version numbers, not any other measure of significance), each such release will get a new "major" version number, no matter how significant the new features are or are not.
The goal is to have a predictable release schedule, get features out to users as quickly as possible when they are ready, and to avoid high-stakes "major releases" that have to be delayed because one feature isn't quite ready.
Version numbering really does not matter, but to assert that releasing a version every six weeks is necessary to release features more often is silly.
Uh, no, its true.
Its impossible to release new features more often without releasing versions of the software more often.
Google is just saying "we're releasing stable versions of Chrome every six weeks from now on. They'll include whatever features are ready for a stable release at the time we do the release. The major version number' -- as, AFAIK, it always has with Chrome -- will simply be the sequential number of the stable feature release, because version numbers really don't matter, so wasting time determining whether the feature set ready at the time of any particular release warrants a new major version number or not is a waste of effort that could be devoted to something more productive, like evaluating features to include in the next release.
What Google is in fact saying is that Chrome is a very immature browser with a very immature feature set, and they are wiling to sacrifice everything else that once made Chrome a legitimate browser in an effort to make it buzzword compliant.
No, what Google is, in fact, saying is that they are very serious about continuing to push out new features in Chrome rapidly for the forseeable future (not because Chrome is an "immature browser", but because technology advances rapidly and Chrome is committed to staying at the front) and aren't going to let piddly concerns about version numbers get in the way of that -- Chrome users will get the new features that are ready for public consumption every six weeks. Sometimes those might be big packs of new features. Sometimes they might be small packs. Whatever, its ready, it ships.
Anyone whose read or heard anything about lean methods should recognize the strategy. And should be unsurprised that Google would adopt it.
The beta channel is planned to be updated at the same pace as the stable channel for Chrome, but presumably would be something like a version ahead. Dev channel is expected to continue to get weekly updates.
What other reason could it be - can they possibly crank out that many major versions and rewrites in this time frame and justify its technical viability
Yes, but that's because Google is (unsurprisingly, as they are one of the companies whose practices are held up as models of lean methods) implementing a lean approach to what a "major version" is: a "major version" just means a stable release that contains anything other than bugfixes. Instead of setting up a system where there are a bucketload of features in each "major release" that all have to get ready together, with long times between major releases, they have lots of major releases, on a regular schedule, with whatever features are ready.
Has anyone complained that there were too few new Chrome releases?
Certainly, there have been complaints that features that are stable in the beta channel not being in stable; having more frequent feature releases to stable addresses that.
Serious question firm an iPhone owner... I've always thought that the appeal of Android was that it was wide open.
Android is an open source operating system. As such, part of its appeal, to a certain segment of the market (including manufacturers), is its openness.
That had me considering picking up one in the future.
Android (the mobile OS) is not a physical product that you can "pick up one" of.
Android is an an operating system which you can install on hardware. Phones and other devices which have been made to use Android are products you can pick up. Various hardware vendors and/or service providers that market such devices may have chosen to include restrictions with them that are not part of the base operating system.
If I have to perform what sounds like a jailbreak why should I not stick with my current (and possibly future) jail broken iPhones?
If your only concern when it comes to mobile hardware is having complete control of the device, then you are probably better off not getting a vendor-locked-down device (whether Android or iOS-based) in the first place, rather than rooting/jailbreaking locked-down devices.
If you have other concerns, but still value having control of the device, you probably want to look at particular hardware features of each device, particular software features of the bundeled OS and available Apps, the degree of control you have without taking unusual steps and the difficulty of gaining more control, and the services the device can be used with.
Then 'when' part tells you that you mean to wait for the event to happen, rather than act beforehand in anticipation of the event.
No, the "when" part tells you that you mean to act immediately when the event occurs, not wait later. The "if" part says that the response is not guaranteed if the event does not occur.
Actually, thinking about it logically I suppose the actual meaning of the structure does in fact simply equate to "if".
It really doesn't.
It is closer to equating simply to "when", with a specific acknowledgement that the trigger may not occur. It differs from "if" because the structure "if X then Y" says nothing about the temporal relationship between X and Y.
"When X, Y" states a temporal relationship.
"If and when X, Y" likewise states a temporal relationship but calls attention to the possibility that X may not occur. Since "When X, Y", strictly speaking, does not guarantee that X will occur, this can be viewed as strictly superfluous, but "When X, Y" is often read as implying that X will occur, so the "If and when" construct is useful to expressly state that X is uncertain while still conveying the temporal relationship between X and Y communicated by "When".
"If and when..." is a common idiom in (US?) English. It's not supposed to be read literally.
Its occasionally used imprecisely to mean "if" or "when", which seem to be the not-literal readings you suggest it is "supposed" to have, but its most common use seems to be fairly literal and precise, and to mean "if [event occurs], then, when [event occurs]."
It addresses the fact that "if" alone doesn't indicate that the result is proximal in time to the trigger, and "when" alone can imply that the trigger is certain to occur.
If india can make a working tablet for $35 that, while probably underpowered, can do web, email, and wordprocessing, Why are the big companies cheapest products $200 or more?
When you don't actually have anyone committed to manufacture any of the devices at any price, its easy to say the price will be $35.
I'm really glad from this announcement (and XO-3) - they show what the price really can be.
Well, for some definition of "really can be". This seems to be very simil to the same thing that India first announced as a $10 laptop, then revealed not to be a laptop but to be some kind of device with storage and an LCD screen but no keyboard and actually be likely to cost $30. Now its a tablet with a hoped-for initial $35 price -- without any manufacturer lined up, and with nothing cited supporting the $35 price (and, since no manufacturer is lined up, it almost certainly based on any manufacturer's estimate of what they can actually produce the device for.)
Its (comparatively) easy to put together a prototype and state a hoped-for mass production price and release date. Its often much harder to get a manufacturer that can mass produce the product at the price and meet the hoped-for release date.
Slashdot Mirror
Many ATMs are not inside, nor even on the premises of, a bank.
Nor did I recommend it for "building typical small business glue code on existing software".
I said it was the more capable, more portable, less locked-in choice for implementing workflow management, when compared to Google Apps Script, for Google Apps users.
Well, I'd agree, but in exactly the opposite sense that you intended, since -- presuming one doesn't use features of .NET that aren't present in Mono -- .NET isn't lock-in because of Mono. If an open-source alternative that supports the same APIs is availabe so that you are not dependent on the original vendor for continued support of the platform on which your custom code runs, you aren't in any meaningful sense "locked-in" to anything. So neither is specious.
Apparently, the VM sniffing was done to determine whether to use a particular mechanism to adjust memory settings. So, while it probably should have thrown up a "this is an unknown VM and things might not work" type of error at least the first time it encountered the unknown VM, its not entirely surprising that on an VM that it didn't know how to handle it ended up getting a memory-related error.
I wouldn't even think that that would be the Java IDE they'd be most likely to test -- I would pick NetBeans for that.
I mean, saying that if they were going to test one app on a new Java update it would be NetBeans is like saying if Microsoft was going to test one app on a Windows update it would be iTunes.
Sure, one trial court found that way (which doesn't address the issue that the web site of an entity that is a public accommodation is subject to the requiremenst of the ADA.) That decision, further, has almost no precedential weight, as the decisions of a trial court aren't binding on any other court in any case between other litigants.
(There was also a decision in the 11th Circuit on this case, but the decision in the 11th Circuit was based on the fact that the legal argument made on appeal was completely different than that made at the trial court, and didn't reach the merits of either the issues that were before the trial court or the issues that were made on appeal, refusing to reach the merits because the new arguments were improperly first raised on appeal.)
Actually, while you can use Google Apps Script for workflow programming, what I would point out is Google App Engine, which integrates with Google Apps for domains, which, since independent implementations of the APIs exist, isn't lock in, and is far more capable. Apps Script is essentially "macros on steroids", and I'd suggest that they would be best seen as serving the same role as macro programming in existing office suites.
This is incorrect. Per the relevant statutory definition (42 U.S.C. Sec. 12181(7)) a variety of "entities" are defined as public accommodations, not "physical places".
Most of those entities would commonly also have physical facilities that would be their sole or primary mechanisms of interaction with the public, but many of them would, these days, also interact with the public through the Web. Some of them (particularly, certain undergraduate and postgraduate private schools, which are entities named as "public accommodations") might have the Web as their primary mode of access rather than a secondary one.
Actually, it does; see 42 U.S.C. Sec. 12102.
Its true that if you define "C" as "exactly the arithmetic mean performance" and require every measured level less than that as a lower letter grade and every measured performance greater than that as a higher letter grade, and if not all students have exactly the same measured performance, some students would need to have grades lower than "C".
However, most people would not define "C" in that way, and with most reasonable definitions of "C" as a grade range it is actually not true, by definition, that some must fall below it.
Often -- and in this case -- its not. The CEO works for the stockholders, and his job is to maximize their realization of their shared interest, which in the case of most publicly traded companies, is limited to maximization of their own financial returns in the form of stock appreciation + dividends (and, mostly, its preferred these days that the form be "stock appreciation" rather than dividends.)
Well, no, it doesn't mean that "anyone is free to use this", it just means that its not a violation of the DMCA.
That it doesn't violate the DMCA doesn't mean that it could not be a violation of some other legal restriction (such as those imposed by a contract.)
No, it doesn't. Believe it or not, license restrictions on expensive software could be enforced through the courts before the DMCA existed, so finding that bypassing a particular technical mechanism isn't a violation of the DMCA does not suddenly make it so that customers may use copies of expensive software beyond what their licensing agreement allows with "impunity".
No, you haven't. Copyright law already prohibits unauthorized reproduction (a necessary precursor to unlimited distribution), and copyright holders can enforce those provisions in the courts whether or not they can use the DMCA in the courts to punish bypassing dongles.
You might, but that wouldn't be any different than the hammer case, and indeed devices that amount to "really big guillotines" (only generally automated and much more suited to mass decapitation, if that was what someone chose to use them for, are not only legal but widely used in various industries.
Google hasn't said they plan to increase the number of UI changes Chrome experience per unit time. They just said they plan on releasing on a frequent and regular schedule, and releasing whatever features are ready for a stable release at each release.
Its not "expecting" a "major upgrade" every quarter.
It is scheduling a stable feature release of Chrome every six weeks (a little bit more than twice a quarter) with whatever features are ready for a stable release at the time.
Since the feature releases will have whatever features are ready, (and since Chrome has always, AFAIK, used stable feature releases as the basis for "major" version numbers, not any other measure of significance), each such release will get a new "major" version number, no matter how significant the new features are or are not.
The goal is to have a predictable release schedule, get features out to users as quickly as possible when they are ready, and to avoid high-stakes "major releases" that have to be delayed because one feature isn't quite ready.
Uh, no, its true.
Its impossible to release new features more often without releasing versions of the software more often.
Google is just saying "we're releasing stable versions of Chrome every six weeks from now on. They'll include whatever features are ready for a stable release at the time we do the release. The
major version number' -- as, AFAIK, it always has with Chrome -- will simply be the sequential number of the stable feature release, because version numbers really don't matter, so wasting time determining whether the feature set ready at the time of any particular release warrants a new major version number or not is a waste of effort that could be devoted to something more productive, like evaluating features to include in the next release.
No, what Google is, in fact, saying is that they are very serious about continuing to push out new features in Chrome rapidly for the forseeable future (not because Chrome is an "immature browser", but because technology advances rapidly and Chrome is committed to staying at the front) and aren't going to let piddly concerns about version numbers get in the way of that -- Chrome users will get the new features that are ready for public consumption every six weeks. Sometimes those might be big packs of new features. Sometimes they might be small packs. Whatever, its ready, it ships.
Anyone whose read or heard anything about lean methods should recognize the strategy. And should be unsurprised that Google would adopt it.
The beta channel is planned to be updated at the same pace as the stable channel for Chrome, but presumably would be something like a version ahead. Dev channel is expected to continue to get weekly updates.
Yes, but that's because Google is (unsurprisingly, as they are one of the companies whose practices are held up as models of lean methods) implementing a lean approach to what a "major version" is: a "major version" just means a stable release that contains anything other than bugfixes. Instead of setting up a system where there are a bucketload of features in each "major release" that all have to get ready together, with long times between major releases, they have lots of major releases, on a regular schedule, with whatever features are ready.
Certainly, there have been complaints that features that are stable in the beta channel not being in stable; having more frequent feature releases to stable addresses that.
Android is an open source operating system. As such, part of its appeal, to a certain segment of the market (including manufacturers), is its openness.
Android (the mobile OS) is not a physical product that you can "pick up one" of.
Android is an an operating system which you can install on hardware. Phones and other devices which have been made to use Android are products you can pick up. Various hardware vendors and/or service providers that market such devices may have chosen to include restrictions with them that are not part of the base operating system.
If your only concern when it comes to mobile hardware is having complete control of the device, then you are probably better off not getting a vendor-locked-down device (whether Android or iOS-based) in the first place, rather than rooting/jailbreaking locked-down devices.
If you have other concerns, but still value having control of the device, you probably want to look at particular hardware features of each device, particular software features of the bundeled OS and available Apps, the degree of control you have without taking unusual steps and the difficulty of gaining more control, and the services the device can be used with.
No, the "when" part tells you that you mean to act immediately when the event occurs, not wait later. The "if" part says that the response is not guaranteed if the event does not occur.
It really doesn't.
It is closer to equating simply to "when", with a specific acknowledgement that the trigger may not occur. It differs from "if" because the structure "if X then Y" says nothing about the temporal relationship between X and Y.
"When X, Y" states a temporal relationship.
"If and when X, Y" likewise states a temporal relationship but calls attention to the possibility that X may not occur. Since "When X, Y", strictly speaking, does not guarantee that X will occur, this can be viewed as strictly superfluous, but "When X, Y" is often read as implying that X will occur, so the "If and when" construct is useful to expressly state that X is uncertain while still conveying the temporal relationship between X and Y communicated by "When".
Its occasionally used imprecisely to mean "if" or "when", which seem to be the not-literal readings you suggest it is "supposed" to have, but its most common use seems to be fairly literal and precise, and to mean "if [event occurs], then, when [event occurs]."
It addresses the fact that "if" alone doesn't indicate that the result is proximal in time to the trigger, and "when" alone can imply that the trigger is certain to occur.
When you don't actually have anyone committed to manufacture any of the devices at any price, its easy to say the price will be $35.
Its a little bit harder to deliver.
Well, for some definition of "really can be". This seems to be very simil to the same thing that India first announced as a $10 laptop, then revealed not to be a laptop but to be some kind of device with storage and an LCD screen but no keyboard and actually be likely to cost $30. Now its a tablet with a hoped-for initial $35 price -- without any manufacturer lined up, and with nothing cited supporting the $35 price (and, since no manufacturer is lined up, it almost certainly based on any manufacturer's estimate of what they can actually produce the device for.)
Its (comparatively) easy to put together a prototype and state a hoped-for mass production price and release date. Its often much harder to get a manufacturer that can mass produce the product at the price and meet the hoped-for release date.
Did you think it was a "big deal" and "innovation" last year when India announced they would make a $10 tablet?
Do you remember how that turned out?
Or not. Last year, Indian officials announced a $10 laptop for the masses, which turned out to be much more than $10, and nowhere close to a laptop.
I wouldn't expect much from their "$35 tablet" announced when the OLPC XO-3 tablet is getting some attention.