I read the linked Devops article and know even less about than before I read the article. It's full of management buzzwords and I'm sure a CIO would love it, but what does it mean?
Never heard of it before, but after doing some quick reading -- the linked page, the Wikipedia page, and some of the pages linked from the Wikipedia page -- it seems like DevOps is just this: just as agile methodologies focus on frequent small releases with close and frequent interaction between developers and business end users, DevOps promotes frequent small releases with close and frequent interaction between the developers building the software and the technical operations staff that will be responsible for the operation of the software once it is live (also, QA as well as operations.)
Underneath the buzzwords, it seems to just be the recognition that technical operations, like business, needs to be involved early and often with the development process, since if they aren't you lose many of the benefits that agile methods are intended to provide.
Since GoogleTV is the software platform running on the TV that includes the web browser, video decoding software, etc., yes.
If the content providers want consumers to watch the show on TV instead of streaming it, maybe they shouldn't make it available on their site to begin with?
They don't stop you from streaming it.
They don't stop you from streaming it on a computer that displays on a TV.
For some reason, they want to stop you from streaming it on a TV that has the computer built into it.
There is but it's never been enforced. For example Opera Browser let's you pretend to be Firefox or Internet Explorer, and access sites that might otherwise be blocked. According to the DMCA that's "hacking" and illegal
Really? Under what specific provision of the DMCA?
the technical domains (bioengineering, mechanical engineering, materials science) are only superficially relevant to Silicon Valley's prime skill set (microlithography, electrical engineering)
Silicon Valley is pretty close to one of the nation's more significant biotech centers (South San Francisco.) Northern California, generally, is a pretty big area for bioengineering.
That's reason number one. That's the last place I'd want to build an industry, not just because of me but also my workers would have to deal with the heavy tax burden.
It would be "the last place" to build an industry because of the "high tax burden" when its not in the top 10 of US states by tax burden, measured either by (tax $)/population or by (tax $)/($ personal income)?
Oh, and foreign subsidiaries are available to anyone willing to make the investment and do the work.
Yeah, so there's a cost there.
And its not always possible to arrange it so that your personal foreign income instead belongs to the foreign subsidiary of your domestically-chartered corporation. (This is fairly trivial with income earned from foreign investment assets, it may be difficult with other foreign income.)
So, no, the corporate loophole at issue isn't equivalent to the stated rule that "the US does not charge tax on income you earn over seas and never bring home."
I believe the US does not charge tax on income you earn over seas and never bring home. Which is why the Google "loophole" works
That's income transferred to a foreign subsidiary corporation and not transferred back to the US-based parent that isn't taxed. It only works for corporations.
The US is one of the few countries, maybe the only one, which charges domestic taxes on income earned overseas.
Actually, most countries that assess corporate and personal income taxes do so on global income for resident/locally headquartered individuals and corporations, and on local income for nonresident individuals and foreign corporations.
Surely that development model is orthogonal to issue of which version number they pick, though?
Not entirely. If you use that development model where you have frequent, small feature releases rather than a mix of less frequent, larger (compared to Google's model) "minor" feature-set releases and even less frequent, even-bigger, "major" feature-set releases, then it doesn't make sense to label the feature releases you do have as "minor" version releases, since you'll then never have a "major" version release. So, essentially, your major version number becomes noise.
Admittedly, Google arguably has a related problem with chrome versions in that the minor version number is irrelevant, since every release -- AFAIK -- is x.0.m. But this is perhaps desirable given the common perception in looking at version numbers that feature releases bump either the major or the minor version number, so Google dropping the.0. minor version so that bugfixes were simple x.m releases might lead to confusion that bugfix releases were feature-change releases.
Actually, that might explain another reason for Google bumping the major version consistently -- since some of the feature releases will contain changes of the kind that other products would restrict to "major" versions (and since the features for a particular stable release may not ve fixed until shortly before the release so that you don't want to have a version number re-evaluation at that point), consistently bumping the major version rather than minor version with the feature releases may avoid the problem of people making assumptions based on traditional version numbering that certain types of changes are not being made and that they don't need to check the changelog.
In summary, while the development model doesn't dictate the version numbering approach, there are certainly reasons why it is reasonable for it inform the version numbering approach.
Artificially dividing feature releases into major and minor feature releases makes sense only if you have preplanned major and minor releases. Chrome does not. Chrome has a regular release schedule. The features that are ready for stable release at the time for the stable release go into the release. All of these get a major version number. You don't have a long process building to a 3.7 release that gets renumbered 4.0. You get a short cycle between stable feature releases, each of which has a major version number.
If the difference between chrome 8.0 and chrome 7.0 were as big as that between firefox 3.0 and firefox 2.0, or between opera 10.0 and opera 9.0, then you'd have a point.
No, then Google would just be coding faster.
The differences are smaller and the releases tighter (than even Opera or Firefox regular minor feature -- as opposed to bugfix -- releases) because they are taking a lean approach, which involves not bundling up more changes at once, so that you don't have as many things that need to happen before a release happens, and so that if a feature gets bumped to the next release, its not that significant, because the next release is right around the corner.
Perhaps I am being a paranoid security freak, but directory upload sounds like a dangerous feature.
Directory upload is just a variant of the existing multiple file upload mechanism; its implemented separately because multiple file upload doesn't allow (regardless of different path information) files with the same path, and because differentiating them in terms of the input type allows implementations to correctly use the native directory chooser for the platform rather than the file chooser when implementing the feature.
Its no more (and no less!) of a "dangerous feature" than existing file upload and multiple file upload are.
Wasn't XHTML supposed to let us format to whatever we wanted?
CSS additions for paged media and other media other than screen were supposed to that.
XSL (XSLT+XSL:FO) was supposed to do that for XML.
XHTML is a subset of XML, and is pretty much irrelevant to what improved CSS was supposed to do, but conceptually could leverage XSL for formatting, if XSL was widely supported by user agents.
As a registered iPhone developer you can install anything you want on your iPhone, so it's just the same as Android that way, right?
Not at all.
Because iOS isn't open source, and so you can't legally modify it and install it on any device even if you are a registered iPhone developer.
Android is open source. You can legally modify it and install it on any device you want (per the Android license.) You can, in fact, buy hardware that will allow you to install Android on it (including, but not limited to, the unlocked Nexus One Dev Phone.)
Just because a development device is available to developers doesn't mean there's open hardware that will run the open OS in any meaningful sense.
Nice attempt to move the goalposts. But, in fact, there is hardware with unlocked bootloaders on which you can run modified versions of the OS, and it is available for sale. Yes, its easier to find locked down devices. So what?
Yes, Android is an open, and open source operating system, that currently doesn't have any hardware, except for a development platform, to run on.
There is plenty of hardware that Android runs on. There is limited hardware that is sold with an unlocked bootloader that will allow non-standard versions to run. The only thing that makes the Android Dev. Phone 3 a "development platform" is the unlocked bootloader, so your "nothing except a development platform" argument, even if true, would be meaningless.
And its not true: there are other unlocked devices available. Few, if any, are sold that way, and all of them are out of warranty if the bootloader is unlocked, and you aren't getting a carrier subsidy for anything with an unlocked bootloader, but that doesn't mean they aren't available.
Sure, its easier to find devices that have locked bootloaders. And, you know what, most people don't want to run non-standard OS spins, they want supported ones. The benefit for most people of the OS being open is that: 1) They have a choice of different spins from different manufacturers and can choose the one that best fits their preferences, 2) Official upgrades benefit from community work.
Having a dev phone that supports custom versions of the OS, an open source license, and accepting community contributions acheives that.
Yeah, Google tried making a phone and it didn't work out
No, they didn't.
Google sold their own branded phone, made by HTC, to the public as part of the effort to promote Android.
Promoting Android seems to have been a runaway success, rendering sales of the Google-branded phone to the public no longer necessary.
An open operating system isn't open at all if there's nothing to run it on.
The Nexus One, unlocked, is still available for sale to registered Android developers as the Nexus One Developer Phone.
So the "openness" of Android is just a marketing slogan.
Android is available under an open source license. The tools to build your own system images exist. The hardware on which you can install those system images exists for sale.
And the main project accepts code contributions back from the community of developers that are building and running their own system images.
All the factors necessary for openness to be a meaningful benefit both to those who do want to run custom Android builds and those who want a supported build are in place.
Android only has one problem - Google doesn't make a phone.
Google isn't, and doesn't want to be, a consumer electronics company. Google is an online information services company. They make money buy monetizing online services (either via advertising, or by selling cloud hosting directly, etc.)
They make browsers, and operating systems for consumer devices, etc., simply to create market conditions which support their online services (in part, they do so to promote features in consumer systems that are needed to best use their services, and in part they do it to stop some other firm from monopolizing these markets and using control of the consumer experience to favor services that compete with Google's.)
So far, Android and Chrome have been doing pretty good at doing what Google wants them to do, in that regard.
Typical elite geek attitude that only people who know how to hack are entitled to the fullest benefits of computing.
Entitlement is irrelevant. People's ability (not entitlement) to derive maximum benefit from computers is directly related, as a basic fact, to their understanding of how to use computers.
Apple's limiting the freedom of those most able to do so doesn't actually do anything to increase anyone else's ability to realize the potential of computers. In fact, since those who can't do it on their own rely on those more technical users to enable them to realize the potential benefits, those restrictions actually limit everyone else, too.
BSD/ApachBSD/Apache style licenses intend to provide "openness" for developers and hardware makers.
GPL(especially v3) intends to provide openness for the end user.
e style licenses intend to provide "openness" for developers and hardware makers.
Its more accurate to say that BSD/Apache licenses (and public domain dedications like SQLites) provide openness for the people directly receiving and licensing the software from the licensor, while GPL licenses restrict the licensee more narrowly with the intent of compelling them to serve other interests of the licensor in order to benefit from the license.
GPL(especially v3) intends to provide openness for the end user.
GPLv3, almost uniquely among F/OSS licenses, limits the freedom of choice the end-user has in selecting what features they want in products based on what market segment they are in. I'm not quite sure how that amounts to providing openness for the end user.
It's a short hand for "install the build somewhere". Something which many in the latest crop of Android devices aren't too friendly about. If Google really wanted to equate Android with "open", they'd stop allowing the use of the Android trademark by manufacturers and carriers who lock down devices that way...
And then there'd be no Android phones available to anyone at all, and no Android developers because there was no market to develop for.
Android is freer than that, which is why it succeeds -- vendors are free to make locked-down versions, which gets it adopted widely. The more it is adopted, the more potential market there is for unlocked devices without the restrictions, with without the wide adoption and the ecosystem it enabled, there wouldn't be.
They made fun of Google docs. And now they are doing it.... but not for free....
The version of Google Apps (Google Apps Premier) that is tied to your companies domain, allows more than 50 users from your organization, and comes with an uptime guarantee and 24/7 technical support, etc., etc., etc. is also not for free.
Its also less expensive for Microsoft's offering.
Does anyone really want to pay for this stuff anymore..... I don't......
Businesses -- though some small businesses get buy with the free organization version of Google Apps (Google Apps Standard) -- actually very often prefer to pay for something and get service guarantees to which the vendor can be held accountable, technical support, etc. Even aside from the other features the for-pay cloud offerings have over their free counterparts.
Slashdot Mirror
Never heard of it before, but after doing some quick reading -- the linked page, the Wikipedia page, and some of the pages linked from the Wikipedia page -- it seems like DevOps is just this: just as agile methodologies focus on frequent small releases with close and frequent interaction between developers and business end users, DevOps promotes frequent small releases with close and frequent interaction between the developers building the software and the technical operations staff that will be responsible for the operation of the software once it is live (also, QA as well as operations.)
Underneath the buzzwords, it seems to just be the recognition that technical operations, like business, needs to be involved early and often with the development process, since if they aren't you lose many of the benefits that agile methods are intended to provide.
Since GoogleTV is the software platform running on the TV that includes the web browser, video decoding software, etc., yes.
They don't stop you from streaming it.
They don't stop you from streaming it on a computer that displays on a TV.
For some reason, they want to stop you from streaming it on a TV that has the computer built into it.
Really? Under what specific provision of the DMCA?
Silicon Valley is pretty close to one of the nation's more significant biotech centers (South San Francisco.) Northern California, generally, is a pretty big area for bioengineering.
It would be "the last place" to build an industry because of the "high tax burden" when its not in the top 10 of US states by tax burden, measured either by (tax $)/population or by (tax $)/($ personal income)?
Not always free of charge.
Yeah, so there's a cost there.
And its not always possible to arrange it so that your personal foreign income instead belongs to the foreign subsidiary of your domestically-chartered corporation. (This is fairly trivial with income earned from foreign investment assets, it may be difficult with other foreign income.)
So, no, the corporate loophole at issue isn't equivalent to the stated rule that "the US does not charge tax on income you earn over seas and never bring home."
That's income transferred to a foreign subsidiary corporation and not transferred back to the US-based parent that isn't taxed. It only works for corporations.
Actually, most countries that assess corporate and personal income taxes do so on global income for resident/locally headquartered individuals and corporations, and on local income for nonresident individuals and foreign corporations.
TFS says "Google only pays a 2.4% tax rate"
TFA says "Google’s income shifting [...] helped reduce its overseas tax rate to 2.4 percent"
Not entirely. If you use that development model where you have frequent, small feature releases rather than a mix of less frequent, larger (compared to Google's model) "minor" feature-set releases and even less frequent, even-bigger, "major" feature-set releases, then it doesn't make sense to label the feature releases you do have as "minor" version releases, since you'll then never have a "major" version release. So, essentially, your major version number becomes noise.
Admittedly, Google arguably has a related problem with chrome versions in that the minor version number is irrelevant, since every release -- AFAIK -- is x.0.m. But this is perhaps desirable given the common perception in looking at version numbers that feature releases bump either the major or the minor version number, so Google dropping the .0. minor version so that bugfixes were simple x.m releases might lead to confusion that bugfix releases were feature-change releases.
Actually, that might explain another reason for Google bumping the major version consistently -- since some of the feature releases will contain changes of the kind that other products would restrict to "major" versions (and since the features for a particular stable release may not ve fixed until shortly before the release so that you don't want to have a version number re-evaluation at that point), consistently bumping the major version rather than minor version with the feature releases may avoid the problem of people making assumptions based on traditional version numbering that certain types of changes are not being made and that they don't need to check the changelog.
In summary, while the development model doesn't dictate the version numbering approach, there are certainly reasons why it is reasonable for it inform the version numbering approach.
Artificially dividing feature releases into major and minor feature releases makes sense only if you have preplanned major and minor releases. Chrome does not. Chrome has a regular release schedule. The features that are ready for stable release at the time for the stable release go into the release. All of these get a major version number. You don't have a long process building to a 3.7 release that gets renumbered 4.0. You get a short cycle between stable feature releases, each of which has a major version number.
No, then Google would just be coding faster.
The differences are smaller and the releases tighter (than even Opera or Firefox regular minor feature -- as opposed to bugfix -- releases) because they are taking a lean approach, which involves not bundling up more changes at once, so that you don't have as many things that need to happen before a release happens, and so that if a feature gets bumped to the next release, its not that significant, because the next release is right around the corner.
Directory upload is just a variant of the existing multiple file upload mechanism; its implemented separately because multiple file upload doesn't allow (regardless of different path information) files with the same path, and because differentiating them in terms of the input type allows implementations to correctly use the native directory chooser for the platform rather than the file chooser when implementing the feature.
Its no more (and no less!) of a "dangerous feature" than existing file upload and multiple file upload are.
CSS additions for paged media and other media other than screen were supposed to that.
XSL (XSLT+XSL:FO) was supposed to do that for XML.
XHTML is a subset of XML, and is pretty much irrelevant to what improved CSS was supposed to do, but conceptually could leverage XSL for formatting, if XSL was widely supported by user agents.
The point is to reduce the delay between work being done and value being realized by the customer.
What Google is doing is applying Lean Software Development principles to eliminate waste and deliver useful features more quickly to customers.
Not at all.
Because iOS isn't open source, and so you can't legally modify it and install it on any device even if you are a registered iPhone developer.
Android is open source. You can legally modify it and install it on any device you want (per the Android license.) You can, in fact, buy hardware that will allow you to install Android on it (including, but not limited to, the unlocked Nexus One Dev Phone.)
Nice attempt to move the goalposts. But, in fact, there is hardware with unlocked bootloaders on which you can run modified versions of the OS, and it is available for sale. Yes, its easier to find locked down devices. So what?
There is plenty of hardware that Android runs on. There is limited hardware that is sold with an unlocked bootloader that will allow non-standard versions to run. The only thing that makes the Android Dev. Phone 3 a "development platform" is the unlocked bootloader, so your "nothing except a development platform" argument, even if true, would be meaningless.
And its not true: there are other unlocked devices available. Few, if any, are sold that way, and all of them are out of warranty if the bootloader is unlocked, and you aren't getting a carrier subsidy for anything with an unlocked bootloader, but that doesn't mean they aren't available.
Sure, its easier to find devices that have locked bootloaders. And, you know what, most people don't want to run non-standard OS spins, they want supported ones. The benefit for most people of the OS being open is that:
1) They have a choice of different spins from different manufacturers and can choose the one that best fits their preferences,
2) Official upgrades benefit from community work.
Having a dev phone that supports custom versions of the OS, an open source license, and accepting community contributions acheives that.
I think we already have. Aren't Triton and Charon both KBOs?
No, they didn't.
Google sold their own branded phone, made by HTC, to the public as part of the effort to promote Android.
Promoting Android seems to have been a runaway success, rendering sales of the Google-branded phone to the public no longer necessary.
The Nexus One, unlocked, is still available for sale to registered Android developers as the Nexus One Developer Phone.
Android is available under an open source license. The tools to build your own system images exist. The hardware on which you can install those system images exists for sale.
And the main project accepts code contributions back from the community of developers that are building and running their own system images.
All the factors necessary for openness to be a meaningful benefit both to those who do want to run custom Android builds and those who want a supported build are in place.
Google isn't, and doesn't want to be, a consumer electronics company. Google is an online information services company. They make money buy monetizing online services (either via advertising, or by selling cloud hosting directly, etc.)
They make browsers, and operating systems for consumer devices, etc., simply to create market conditions which support their online services (in part, they do so to promote features in consumer systems that are needed to best use their services, and in part they do it to stop some other firm from monopolizing these markets and using control of the consumer experience to favor services that compete with Google's.)
So far, Android and Chrome have been doing pretty good at doing what Google wants them to do, in that regard.
Entitlement is irrelevant. People's ability (not entitlement) to derive maximum benefit from computers is directly related, as a basic fact, to their understanding of how to use computers.
Apple's limiting the freedom of those most able to do so doesn't actually do anything to increase anyone else's ability to realize the potential of computers. In fact, since those who can't do it on their own rely on those more technical users to enable them to realize the potential benefits, those restrictions actually limit everyone else, too.
Its more accurate to say that BSD/Apache licenses (and public domain dedications like SQLites) provide openness for the people directly receiving and licensing the software from the licensor, while GPL licenses restrict the licensee more narrowly with the intent of compelling them to serve other interests of the licensor in order to benefit from the license.
GPLv3, almost uniquely among F/OSS licenses, limits the freedom of choice the end-user has in selecting what features they want in products based on what market segment they are in. I'm not quite sure how that amounts to providing openness for the end user.
And then there'd be no Android phones available to anyone at all, and no Android developers because there was no market to develop for.
Android is freer than that, which is why it succeeds -- vendors are free to make locked-down versions, which gets it adopted widely. The more it is adopted, the more potential market there is for unlocked devices without the restrictions, with without the wide adoption and the ecosystem it enabled, there wouldn't be.
Google Apps Premier already exists. This is just Microsoft offering a more expensive alternative.
The version of Google Apps (Google Apps Premier) that is tied to your companies domain, allows more than 50 users from your organization, and comes with an uptime guarantee and 24/7 technical support, etc., etc., etc. is also not for free.
Its also less expensive for Microsoft's offering.
Businesses -- though some small businesses get buy with the free organization version of Google Apps (Google Apps Standard) -- actually very often prefer to pay for something and get service guarantees to which the vendor can be held accountable, technical support, etc. Even aside from the other features the for-pay cloud offerings have over their free counterparts.