You should exert absolutely no effort to be diverse, and you should exert absolutely no effort to not be diverse. What matters is the merit of the speakers, not their diversity.
Perhaps. But if you do that, you probably shouldn't advertise your conference on technology foo as one of the most diverse foo conferences anywhere, the way BritRuby did with regard to Ruby conferences. But when you explicitly sell diversity, you probably shouldn't be surprised when people actually look at, and comment on, whether that selling point is accurate.
[Is it just me...]...or does it look like the US and the UK are like 2 mirrors opposite to each other bouncing stupidity back and forth?
I'm genuinely not trying to be offensive
Suggestion: try harder.
That's like saying that you can't reserve a table for a night out with the guys because the group is not diverse enough.
That analogy fails in pretty much every way imaginable; particularly, no one told BritRuby that they couldn't do anything, and what they were doing was nothing like reserving a table for a night out with the guys.
No seriously, what's the difference?
What's even remotely similar?
BritRuby wasn't compelled by any outside force to cancel the conference over the criticism. The organizer chose to do so entirely on his own, without any sponsor backing out or indicating that they would back out. So, there's no "can't" at issue.
And most people don't try to attract sponsors and participants for a night out with the guys by publicly advertising it as "one of the most diverse" nights out available, so the analogy fails on that as well.
If you advertise a conference to the public as one of the most diverse of its kind, when 15 of the 20 speaker slots have been filled by invitation, and all of them by white men, well, you should probably expect exactly the kind of criticism that BritRuby got.
Before anyone makes any decisions about which proposals get accepted, have whoever initially got the submission hide the names of the presenters.
Not particularly relevant to the conference at issue, where the vast majority of the presenters were invited presenters, and all of those invited were white men. (And there is at least some indication that this fact, coupled with the fact that the invited presenters were announced when proposals for additional presenters were solicited, led at least some non-white-male potential presenters deciding not to submit proposals.)
I mean, you can't hide the names -- or more relevantly sex and race -- of the people in the community from the people actively extending invitations.
Just display calories, equivalent distant need to run to burn calories, and total calorie for the day?
I suspect it wouldn't work as well as what is being discussed here because it attempts to operate on a rational level, and eating decisions are usually not reasoned, and rational feedback often is not as effective as mechanisms that hook into visceral, subconscious responses.
Though, of course, if you know of research that shows that that kind of approach works as well as the research shown here, great, please post it.
Or have it tell the bank to not allow any more prepackaged food purchase for the day? In fact, you could have it only allow food purchases during certain time.
That could be a great diet aid.
Well, it would be a useful diet aid if there was a necessary close relationship between time of purchase and time of consumption of prepackaged food, and if you couldn't purchase prepackaged food with cash.
Yes, that is what I am referring to. There are now authorities who are stating that italics and bold have semantic meaning of themselves in some contexts, through established patterns of use in the Real World.
Except that's not what the source you are referring to is stating. Its stating that there exist semantic distinctions that are not emphasis for which the common typographic convention is to set them off with italics and bold, not that italics and bold have "semantic meaning of themselves".
And obviously I am blending "typography" in with "grammar" here.
Yeah, and making things way to confusing by making this about this weird typography/grammar hybrid.
You'd probably have this a lot clearer if you just thought of the same thing in terms of heirarchies (or perhaps venn diagrams, there may be some categories that overlap rather than being strictly contained) of semantic categories, and then attaching presentation to the categories. Sure, some of the categories might be defined in part in terms of typographic convention, but they are still semantic categories, and their presentation in a particular medium (or for a particular user with specified preferences) may not match the convention defining the category.
I think it is noteworthy that italics and bold are gaining recognition as semantic markups
The closest thing I've seen to that is that the HTML tags that used to mean "bold" and "italics" have been redefined (in current WhatWG HTML and W3C HTML5) to be semantic tags referencing traditional typographic conventions, specifically, they respectively now indicate, "text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is bold tex", and "text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is italic text".
I don't see the end-result-difference between having a "bold" button, an "italic" button, and an "emphasize" button over the traditional way of using hand-typed wiki-markup to achieve the same results.
The problem isn't using buttons for physical styles vs. using tags for physical styles attached directly to content, its using physical styles directly attached to content rather than semantic "styles" (whether entered as semantic markup or "applied" with an editor that presents thing in a form other than markup) with separate specification of physical presentation. That Wikipedia's existing standards use physical styles for some uses and semantic markup for others is problematic, a visual editor is just going to make things worse.
When U.S. Postal Service (however they were called back then)
The Constitution calls it "Post Offices and Post Roads".
While it changed organizational structure to become a cabinet-level department under the Constitution, the United States Post Office (as it was known before being kinda-sorta-privatized in 1971) predates the Constitution. In fact, it predates the Declaration of Independence, having been formed under the Second Continental Congress in 1775.
I wasn't able to easily locate a history on when the USPS funding was separated from the general budget, if indeed it was ever a direct part of it. Would love to see the history of that decision.
The United States Postal Office was created by the Second Continental Congress in 1775, became, the US Post Office Department in 1792, and remained a cabinet-level government department until 1971, when the Postal Reorganization Act moved it out of the regular structure of government into a government-directed corporation.
The USPS may be fading, but there is still a need for the immediate future and ending saturday delivery is a very logical way to make up some of its revenue gap.
Reducing delivery days isn't going to do much to reduce the revenue gap except, maybe, in the very short run; in the long run, its going to reduce the value of using the postal system compared to other options and accelerate the movement of communication off snail mail and into other systems (whether alternative physical delivery services or non-physical systems.)
If all the retail stores are going broke because everyone is buying stuff off the internet, then USPS should be doing a roaring trade in package deliveries.
Not sure why USPS don't seem to be able to leverage off all that traffic to make a profit.
First, because USPS is not supposed to make a profit (it supposed to target operating at break even.)
But, more importantly, because, while the USPS has a legal monopoly on regular mail delivery, it doesn't on package delivery, so private carriers that don't do regular mail delivery but are optimized for package and express delivery take a lot of that business.
In some other countries, when new communications mechanism -- starting with the telegraph, then the telephone, then the internet -- began displacing mail, the public entity that was the national postal system expanded to also include those functions and take a similar role with relating to them that it took with regard to mail. In the US, instead, the postal service has been kept to a narrow role, and its role that is less relevant over time to how the country operates. It is failing by design, even before considering knife thrusts to the heart like the Congressionally-imposed 75-year retirement funding mandate.
The ridiculous retiree benefits mandate handed down from congress is pretty much the sole reason for this unnecessary debacle.
No other organization is required to provide such an absurd level of retiree benefits payment so why is this insanity allowed to persist in light of the fact it could potentially doom the USPS?
The whole point of the insane prefunding mandate (what is ridiculous isn't the retiree benefits, it is the mandate to prefund them 75 years into the future) is to doom the USPS. Its not allowed to persist in spite of the fact it could doom the USPS, it is allowed to persist because it will doom the USPS.
wouldn't updating all phones to the latest android version be a better solution ?
It limits the use of the SDK in the process of creating non-Android-branded Android-like OS's, which is one aspect of fragmentation.
Google more aggressively pursuing and releasing updates for Google-branded (e.g., Nexus) devices would, for example, be a means of creating pressure on other Android device makers to be better at updating devices and reducing that aspect of fragmentation. (Which is, though, less of a problem for Google than the previously-mentioned kind of fragmentation.)
The GPL applies to gcc if it is bundled with the SDK, but mere bundling -- also known as aggregation -- doesn't cause the GPL to infect other software that it is bundled with.
Did they ever claim that the SDK is open source? They certainly claim that the code that is part of the AOSP is open source, but that's the unbranded version of the OS, which is neither Android nor the Android SDK.
Yes and that might account for the high failure rate for ERP projects at the federal level. You make a very good point. What I wonder is why, knowing all of this, are ERP systems selected in the first place? Square peg round hole.
I think the answer to that is the way that procurement rules, institutional culture, and other factors favor (1) contracting out (and, beyond that -- especially at the federal level but the same is true of State government in many cases -- under a set of contracting constraints where expertise in navigating the contracting-out system is a significant barrier to entry to competition), (2) using COTS solutions to the extent possible, and (3) big bang, monolithic projects over incremental progress toward a goal.
Time and again I see clients go out and buy an expensive ERP system only to customize the bejezus out of it to make it look exactly like the systems they are retiring. They are not open to better business practices. Too many political headwinds.
Ideally, any automation effort (and centralized integration of existing stovepiped non-integrated systems is automation at the level of the boundaries of the pre-existing systems) should (1) support existing processes and make them more efficient by removing inefficiencies that result from non-automated communication, status tracking, information storage and retrieval, etc., and (2) accomodate incremental business process improvements.
Any automation effort that doesn't return value by (1) alone initially is flawed from step 1. And if your best opportunity to realize value is making substantive change to the business processes rather than changing the technology implementing your business processes, you should do that instead, not try to hit the moving target of experimental and unproven processes with an automation effort (and that's even more true if its a massive, organization-wide, high-cost automation effort and the processes at issue are important, organization-wide, vital processes.)
One of the big problems with trying to shoehorn a best practice ERP system into a large government institution is that often they employ worst practices.
"Best practices" represented by ERP systems generally reflect common industry requirements (which are often shaped by the regulatory landscape); large government instutitions are often subject to radically different operational contexts and regulatory requirements than are common in industry (often to the point of being essentially sui generis in terms of the operational context, particularly when you are talking about the military.) The fact that your product doesn't fit what your customer needs isn't a problem with your customer, its a problem with you offering your product for those needs.
which would be great so it'd be a lot more unlikely for drive-by malware install ads to run, and if they ran the website owners wouldn't have the typical excuse of "oh sorry, one of our ad networks was compromised, we apologize"
Why wouldn't they? Just because the request from your browser goes to their server doesn't mean their server is the root source of the content; it is not at all impossible to have the website server, in handling a request for an ad with a "local" URL, make a request to the ad network server, and just relay the response to that request back to the client requesting the ad URL. (There are similar options that avoid the latency inherent in that approach that involve making requests to the ad network out-of-band.) This kind of approach deals with domain-based ad blocking, but still makes ad network compromise just as real as it is when the request go directly to the ad network (and is potentially attractive because it still offloads the work of actually managing the ads to someone other than the website owner.)
But it will probably take a lot to get back to locally-hosted ads, even if there is some incentive to do so in terms of blocking, because ad networks -- and advertisers -- want to know that clicks are real, and its going to be harder to detect click fraud when all the requests to the ad network are expected to be directly created by the site hosting (and getting paid for) the ads, rather than by the clients.
The browser is a crappy computing platform. For just about anything beyond simple games and basic calculations, you're better off writing in a real language instead of JavaScript.
There's a fairly widely used browser that both supports WebGL and supports applications written in "real language" (e.g., C) and compiled to native code, from a fairly large company that originally came to prominence because of its web search engine.
Basically HTML5test does not test just the HTML 5 spec by W3C.It tests things the authors think is cool on web mailing lists as well as WhatG.
This is fairly close to the truth, but everything that follows it is wrong:
So W3C is dividing it into HTML 5 and CSS 3 and its.1 counterparts for the more experimental things which HTML5test.com look at.
Wrong.
WhatWG has a continuously-evolving HTML "Living Standard", not HTML 5. W3C has HTML 5, which is a standard targetted for completion to Recommendation status in 2014, and it plans to start work on HTML 5.1 with a working draft due later this year. It also has a number of specifications outside of the HTML spec proper that are maintained by the W3C HTML working group. Some of the things HTML5test looks are in HTML 5, some are in other W3C specifications, some are in WhatWG work or elsewhere and may be included in HTML 5.1 or some other future W3C standard. But HTML 5.1 is not "the more experimental things which HTML5test.com look at", and, in fact, no one knows what HTML 5.1 will be since it doesn't exist, at least in any public draft, yet.
WhatWG has no CSS spec at all. W3C has CSS, but the last (not merely "most recent", but "last" according to the current plan, since the approach to CSS has changed) across the board release with a numbered level rather than a snapshot year is CSS Level 2 Revision 1 (CSS 2.1). After that, CSS switched to per-module updates. Some CSS modules have a Recommendation (i.e., final) Level 3 spec. Some have draft Level 3 specs. Some only have Level 2.1 specs. Selectors has a Recommendation level 3 spec and a draft level 4 spec.
There are also across-the-board snapshots (CSS Snapshot 2007 and CSS Snapshot 2010) representing the across-the-board stable status of CSS at the time of the snapshot. CSS 3.1 is a meaningless term, and even CSS3 used in a sense that implies a single standard like CSS 2.1 is misleading.
Webworkers (example) are HTML 5.1 which IE 10 does support so technically IE 10 is very HTML 5 compliant and partially 5.1.
No, Web Workers are a separate specification (currently, in Candidate Recommendation status) that is also from the W3C HTML working group, outside of any of the W3C's HTML specifications. This is part of the policy of modularity (similar to what W3C has done with CSS from Level 3 onward) now being applied by the W3C HTML Working Group where instead of the broad monolithic standard that HTML5 was in early drafts, the HTML 5 spec proper (and, as long as the policy is maintained, future HTML specs like 5.1) is much narrower with a lot of HTML-related functionality moved out into separate specifications that can develop from draft to recommendation at their own pace.
IE 10 is supposed to continue the new process and promises to be much faster and support more HTML 5, CSS 3, W3C HTML 5.1 and CSS 3.1
Wait, IE 10 is in final preview and it plans to support W3C HTML 5.1, which doesn't yet have a draft, and CSS 3.1, which doesn't even make sense given the way CSS Level 3+ is done by-module rather than as an across-the-board specification.
with a score of 320 on HTML5test.
Whoopty-frigging-do. The stable version of Chrome (23) has a 448. Chrome 10 beats IE 10 on HTML5test.
Seems like RTS customers are the ones who would have a right to demand the source to whatever GPLed software they bought or been given. And any of them could legally "leak" to Grover. Not sure how RTS currently has any obligations to Grover, though. Why would they?
Presumably because Grover as the Red Hat SCSI target maintainer (or, more likely, Red Hat as his employer) contributed, under the GPL, code (patches, etc.) to the piece of Linux he accuses RTS of infringing, thus what Grover is doing is accusing RTS of infringing the copyright on his (or Red Hat's) code by not complying with the GPL with regard to that code.
Remember that GPL is about protecting users. As handy as it usually is for developers, that's incidental; it's not for developers.
The GPL, like all copyright licenses written or chosen by the licensor with a take-it-or-leave-it choice for the licensee is used by copyright owners to protect the interests of the copyright owner; its not a contract, so users don't even have the arguable enforcement rights they might have as intended third-party beneficiaries of a contract.
Now, it may be that the FSF, as the original authors and users (as licensors) of the GPL had, as their interests in mind for it to protect, what they perceived to be the general public interest or the interests of end-users. But it would be a mistake to forget that its for copyright owners, first, last, and only.
If you have to explain a prefix (here: peta-), don't use it. Since this is Slashdot, the summaries should simply use the ubiquitous "engineering notation:" 1.62E+16 becquerels.
That's just the common ASCII-friendly version of scientific notation; the equivalent in engineering notation would be 16.2E+15 becquerels, as "engineering notation" differs from "scientific notation" in that while the latter uses the smallest exponent which gives a mantissa >= 1, the former uses the smallest exponent divisible by 3 which gives a mantissa >= 1.
Slashdot Mirror
Perhaps. But if you do that, you probably shouldn't advertise your conference on technology foo as one of the most diverse foo conferences anywhere, the way BritRuby did with regard to Ruby conferences. But when you explicitly sell diversity, you probably shouldn't be surprised when people actually look at, and comment on, whether that selling point is accurate.
Mandatory diversity rules have nothing to do with the issue here.
Suggestion: try harder.
That analogy fails in pretty much every way imaginable; particularly, no one told BritRuby that they couldn't do anything, and what they were doing was nothing like reserving a table for a night out with the guys.
What's even remotely similar?
BritRuby wasn't compelled by any outside force to cancel the conference over the criticism. The organizer chose to do so entirely on his own, without any sponsor backing out or indicating that they would back out. So, there's no "can't" at issue.
And most people don't try to attract sponsors and participants for a night out with the guys by publicly advertising it as "one of the most diverse" nights out available, so the analogy fails on that as well.
If you advertise a conference to the public as one of the most diverse of its kind, when 15 of the 20 speaker slots have been filled by invitation, and all of them by white men, well, you should probably expect exactly the kind of criticism that BritRuby got.
Not particularly relevant to the conference at issue, where the vast majority of the presenters were invited presenters, and all of those invited were white men. (And there is at least some indication that this fact, coupled with the fact that the invited presenters were announced when proposals for additional presenters were solicited, led at least some non-white-male potential presenters deciding not to submit proposals.)
I mean, you can't hide the names -- or more relevantly sex and race -- of the people in the community from the people actively extending invitations.
I suspect it wouldn't work as well as what is being discussed here because it attempts to operate on a rational level, and eating decisions are usually not reasoned, and rational feedback often is not as effective as mechanisms that hook into visceral, subconscious responses.
Though, of course, if you know of research that shows that that kind of approach works as well as the research shown here, great, please post it.
Well, it would be a useful diet aid if there was a necessary close relationship between time of purchase and time of consumption of prepackaged food, and if you couldn't purchase prepackaged food with cash.
Except that's not what the source you are referring to is stating. Its stating that there exist semantic distinctions that are not emphasis for which the common typographic convention is to set them off with italics and bold, not that italics and bold have "semantic meaning of themselves".
Yeah, and making things way to confusing by making this about this weird typography/grammar hybrid. You'd probably have this a lot clearer if you just thought of the same thing in terms of heirarchies (or perhaps venn diagrams, there may be some categories that overlap rather than being strictly contained) of semantic categories, and then attaching presentation to the categories. Sure, some of the categories might be defined in part in terms of typographic convention, but they are still semantic categories, and their presentation in a particular medium (or for a particular user with specified preferences) may not match the convention defining the category.
The $8.8 billion Autonomy write-down is "only" about 127% of the $6.9 billion quarterly loss.
The closest thing I've seen to that is that the HTML tags that used to mean "bold" and "italics" have been redefined (in current WhatWG HTML and W3C HTML5) to be semantic tags referencing traditional typographic conventions, specifically, they respectively now indicate, "text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is bold tex", and "text offset from its surrounding content without conveying any extra emphasis or importance, and for which the conventional typographic presentation is italic text".
The problem isn't using buttons for physical styles vs. using tags for physical styles attached directly to content, its using physical styles directly attached to content rather than semantic "styles" (whether entered as semantic markup or "applied" with an editor that presents thing in a form other than markup) with separate specification of physical presentation. That Wikipedia's existing standards use physical styles for some uses and semantic markup for others is problematic, a visual editor is just going to make things worse.
While it changed organizational structure to become a cabinet-level department under the Constitution, the United States Post Office (as it was known before being kinda-sorta-privatized in 1971) predates the Constitution. In fact, it predates the Declaration of Independence, having been formed under the Second Continental Congress in 1775.
The United States Postal Office was created by the Second Continental Congress in 1775, became, the US Post Office Department in 1792, and remained a cabinet-level government department until 1971, when the Postal Reorganization Act moved it out of the regular structure of government into a government-directed corporation.
Reducing delivery days isn't going to do much to reduce the revenue gap except, maybe, in the very short run; in the long run, its going to reduce the value of using the postal system compared to other options and accelerate the movement of communication off snail mail and into other systems (whether alternative physical delivery services or non-physical systems.)
First, because USPS is not supposed to make a profit (it supposed to target operating at break even.) But, more importantly, because, while the USPS has a legal monopoly on regular mail delivery, it doesn't on package delivery, so private carriers that don't do regular mail delivery but are optimized for package and express delivery take a lot of that business. In some other countries, when new communications mechanism -- starting with the telegraph, then the telephone, then the internet -- began displacing mail, the public entity that was the national postal system expanded to also include those functions and take a similar role with relating to them that it took with regard to mail. In the US, instead, the postal service has been kept to a narrow role, and its role that is less relevant over time to how the country operates. It is failing by design, even before considering knife thrusts to the heart like the Congressionally-imposed 75-year retirement funding mandate.
The whole point of the insane prefunding mandate (what is ridiculous isn't the retiree benefits, it is the mandate to prefund them 75 years into the future) is to doom the USPS. Its not allowed to persist in spite of the fact it could doom the USPS, it is allowed to persist because it will doom the USPS.
It limits the use of the SDK in the process of creating non-Android-branded Android-like OS's, which is one aspect of fragmentation.
Google more aggressively pursuing and releasing updates for Google-branded (e.g., Nexus) devices would, for example, be a means of creating pressure on other Android device makers to be better at updating devices and reducing that aspect of fragmentation. (Which is, though, less of a problem for Google than the previously-mentioned kind of fragmentation.)
Fragmentation is multidimensional.
The GPL applies to gcc if it is bundled with the SDK, but mere bundling -- also known as aggregation -- doesn't cause the GPL to infect other software that it is bundled with.
It would prohibit forking the SDK.
Did they ever claim that the SDK is open source? They certainly claim that the code that is part of the AOSP is open source, but that's the unbranded version of the OS, which is neither Android nor the Android SDK.
I think the answer to that is the way that procurement rules, institutional culture, and other factors favor (1) contracting out (and, beyond that -- especially at the federal level but the same is true of State government in many cases -- under a set of contracting constraints where expertise in navigating the contracting-out system is a significant barrier to entry to competition), (2) using COTS solutions to the extent possible, and (3) big bang, monolithic projects over incremental progress toward a goal.
Ideally, any automation effort (and centralized integration of existing stovepiped non-integrated systems is automation at the level of the boundaries of the pre-existing systems) should (1) support existing processes and make them more efficient by removing inefficiencies that result from non-automated communication, status tracking, information storage and retrieval, etc., and (2) accomodate incremental business process improvements. Any automation effort that doesn't return value by (1) alone initially is flawed from step 1. And if your best opportunity to realize value is making substantive change to the business processes rather than changing the technology implementing your business processes, you should do that instead, not try to hit the moving target of experimental and unproven processes with an automation effort (and that's even more true if its a massive, organization-wide, high-cost automation effort and the processes at issue are important, organization-wide, vital processes.)
"Best practices" represented by ERP systems generally reflect common industry requirements (which are often shaped by the regulatory landscape); large government instutitions are often subject to radically different operational contexts and regulatory requirements than are common in industry (often to the point of being essentially sui generis in terms of the operational context, particularly when you are talking about the military.) The fact that your product doesn't fit what your customer needs isn't a problem with your customer, its a problem with you offering your product for those needs.
Why wouldn't they? Just because the request from your browser goes to their server doesn't mean their server is the root source of the content; it is not at all impossible to have the website server, in handling a request for an ad with a "local" URL, make a request to the ad network server, and just relay the response to that request back to the client requesting the ad URL. (There are similar options that avoid the latency inherent in that approach that involve making requests to the ad network out-of-band.) This kind of approach deals with domain-based ad blocking, but still makes ad network compromise just as real as it is when the request go directly to the ad network (and is potentially attractive because it still offloads the work of actually managing the ads to someone other than the website owner.) But it will probably take a lot to get back to locally-hosted ads, even if there is some incentive to do so in terms of blocking, because ad networks -- and advertisers -- want to know that clicks are real, and its going to be harder to detect click fraud when all the requests to the ad network are expected to be directly created by the site hosting (and getting paid for) the ads, rather than by the clients.
There's a fairly widely used browser that both supports WebGL and supports applications written in "real language" (e.g., C) and compiled to native code, from a fairly large company that originally came to prominence because of its web search engine.
This is fairly close to the truth, but everything that follows it is wrong:
Wrong.
WhatWG has a continuously-evolving HTML "Living Standard", not HTML 5. W3C has HTML 5, which is a standard targetted for completion to Recommendation status in 2014, and it plans to start work on HTML 5.1 with a working draft due later this year. It also has a number of specifications outside of the HTML spec proper that are maintained by the W3C HTML working group. Some of the things HTML5test looks are in HTML 5, some are in other W3C specifications, some are in WhatWG work or elsewhere and may be included in HTML 5.1 or some other future W3C standard. But HTML 5.1 is not "the more experimental things which HTML5test.com look at", and, in fact, no one knows what HTML 5.1 will be since it doesn't exist, at least in any public draft, yet.
WhatWG has no CSS spec at all. W3C has CSS, but the last (not merely "most recent", but "last" according to the current plan, since the approach to CSS has changed) across the board release with a numbered level rather than a snapshot year is CSS Level 2 Revision 1 (CSS 2.1). After that, CSS switched to per-module updates. Some CSS modules have a Recommendation (i.e., final) Level 3 spec. Some have draft Level 3 specs. Some only have Level 2.1 specs. Selectors has a Recommendation level 3 spec and a draft level 4 spec.
There are also across-the-board snapshots (CSS Snapshot 2007 and CSS Snapshot 2010) representing the across-the-board stable status of CSS at the time of the snapshot. CSS 3.1 is a meaningless term, and even CSS3 used in a sense that implies a single standard like CSS 2.1 is misleading.
No, Web Workers are a separate specification (currently, in Candidate Recommendation status) that is also from the W3C HTML working group, outside of any of the W3C's HTML specifications. This is part of the policy of modularity (similar to what W3C has done with CSS from Level 3 onward) now being applied by the W3C HTML Working Group where instead of the broad monolithic standard that HTML5 was in early drafts, the HTML 5 spec proper (and, as long as the policy is maintained, future HTML specs like 5.1) is much narrower with a lot of HTML-related functionality moved out into separate specifications that can develop from draft to recommendation at their own pace.
Wait, IE 10 is in final preview and it plans to support W3C HTML 5.1, which doesn't yet have a draft, and CSS 3.1, which doesn't even make sense given the way CSS Level 3+ is done by-module rather than as an across-the-board specification.
Whoopty-frigging-do. The stable version of Chrome (23) has a 448. Chrome 10 beats IE 10 on HTML5test.
Presumably because Grover as the Red Hat SCSI target maintainer (or, more likely, Red Hat as his employer) contributed, under the GPL, code (patches, etc.) to the piece of Linux he accuses RTS of infringing, thus what Grover is doing is accusing RTS of infringing the copyright on his (or Red Hat's) code by not complying with the GPL with regard to that code.
The GPL, like all copyright licenses written or chosen by the licensor with a take-it-or-leave-it choice for the licensee is used by copyright owners to protect the interests of the copyright owner; its not a contract, so users don't even have the arguable enforcement rights they might have as intended third-party beneficiaries of a contract. Now, it may be that the FSF, as the original authors and users (as licensors) of the GPL had, as their interests in mind for it to protect, what they perceived to be the general public interest or the interests of end-users. But it would be a mistake to forget that its for copyright owners, first, last, and only.
That's just the common ASCII-friendly version of scientific notation; the equivalent in engineering notation would be 16.2E+15 becquerels, as "engineering notation" differs from "scientific notation" in that while the latter uses the smallest exponent which gives a mantissa >= 1, the former uses the smallest exponent divisible by 3 which gives a mantissa >= 1.