Which is why he has to make the cut hurt. Instead of minimizing waste (reducing travel budgets, etc.) he's going to cut positions with that 1%...
Actually, the sequester mechanism, when it was passed by Congress and signed by the President as part of a short-term funding agreement was designed by both sides to be painful because both sides wanted it that way so that it would be a disincentive to the other side to refuse to compromise on an actual budget agreement that would deal with specifics of addressing budget priorities going forward.
In a sense, it was a version of mutually-assured destruction that went into effect if bilateral action wasn't taken to avert it.
The problem with this is MAD may work when you have to take an active step to trigger it, it doesn't work as well when you have to have to jointly avoid it, because its easy to convince yourself that the other side will back down if you wait a little longer, so you don't have to compromise.
GOOD!! If the program needs to maintain or increase then our representatives need to actively decide to increase funding. Funding should NOT be automatic.
They do and funding isn't automatic under the current system. That's why we have a government shutdown if no appropriation is passed by Congress and signed by the President (or repassed by Congressional supermajority over a Presidential veto.) Even so-called "non-discretionary" spending isn't automatic.
Baseline budgeting is simply a matter of how budget proposals are calculated and presented, it has no bearing on the actual substantive process and requirements around passing a budget.
And it's not even a real cut. It's merely a reduction to the increase.
It is, in fact, a real cut to the currently-appropriated spending and the current spending rate. While it is often the case that reductions in projected increases are sold as "cuts" in government budgets, this is not one of the cases.
Baseline Budgeting ensures that ALL budgets increase by a certain percentage every year automatically.
The sequester has nothing to do with baseline budgeting, it has to do with cuts to funds that are already appropriated for the current period.
Also, nothing in the federal budget happens automatically. If an appropriation isn't passed for each year, there are no funds, period, full stop. Baseline budgeting has to do with how budget proposals are drafted and presented, it doesn't mean that if no legislative action is taken an appropriation automatically remains in effect indefinitely.
capitalism is a name invented by 19th Century socialists to describe the system they opposed
riiiiiiight.... whatever dude
Simple historical fact.
government has a role to play, just not in the free market
While frequently stated as a broad platitude, that's completely incoherent; as there is nothing conceivable that government could do that doesn't involve the market. Either government has a role in the market, or it has no role at all. You can have a meaningful and substantive discussion of what government's role with respect to the market ought to be, but when you say that government has a role to play but that that role is somehow not in the market, its sloganeering with no substantive content.
Children are learning to express math equations in a certain way. Not that way.
Which ("are learning") is actually why its probably not as hard for children a language that uses prefix rather than infix notation than it is for older people who hav been using infix notation exclusively for longer; just like its easier for kids to learn different natural languages.
BTW, the world's first bug was a moth caught in a computers wiring, hence its name.
No, it wasn't. The term "bug" predates that (and computers) as a term for faults in electrical systems. The well-known moth that is the source of this myth was described in the notebook to which it was taped as the "first known instance of an actual bug being found", clearly indicating that computer "bugs" had existed before that time, but that the novel thing wasn't the term, but the fact than an actual arthropod was located and identified as the source of the problem.
To be blunt, most people can't learn to code beyond a painfully basic level.
I'm not sure that's any except in the same way that its true that most people can't learn a foreign language beyond a painfully basic level; I think lots of people aren't exposed to anything like programming young enough, and that as a result many people who do encounter programming only do so after there brain is fixed in a way that doesn't allow them to learn it easily, and so if they aren't put in a position where they have no choice but to learn it, they often aren't going to stay with it. But that's not the same thing as not having the innate ability to learn it, that's just not starting learning it at the right time.
Come on guys, lets be honest, think about who they are marketing to, kids under the age of 18.
Code.org isn't marketing primarily to kids, its marketing primarily to teachers, parents, and potential engineer volunteers.
This is the message that will most strongly resonate with that group. Trotting out genuinely passionate programmers probably wont carry the same weight as a name or face they can recognize.
If they were marketing to kids under 18, neither would trotting out politicians that have been out of office for more than half of the life of kids at the upper end of the age range. Or Dr. Oz.
You can't become a passionate *anything* if you find the world pretty much ok as it is.
Not true at all; its quite possible to become passionate about preserving the status quo, which pretty much requires finding the world pretty much ok as it is, at least compared to the apparent immediately-available alternatives.
You can't become passionate about change without being dissatisfied with something in the status quo, but change isn't the only thing it is possible to be passionate about.
because capitalism is where the government stays out of the way
No, capitalism is a name invented by 19th Century socialists to describe the system they opposed, in which the structures of the system (including those imposed by government) systematically and often actively favored capital over labor.
The system where government stays out of the way is called "anarchy", and is completely different.
Learning how to use a wordprocessor. Learning how to make professional looking documents that communicate well to people is a valuable skill.
Learning how to make professional looking documents that communicate well to people is a valuable skill. Its also has about the same relationship to learning how to use a word processor as systems analysis (in the broadest, non-IT-specific, sense) has to coding.
HTML5 spec clearly states that this exact behaviour should be looked out for and blocked
There are two errors in this statement:
The less significant error is that the relevant spec is the Web Storage specification, not the HTML5 specification;
The more significant error is that while the spec recommends per-origin quotas (which most browsers have), and recommends taking measures to identify and prevent the use of affiliated origins to circumvent per-origin limits, it does not, in fact, define what constitutes "affiliated origins" for the purpose of that recommendation, it just provides one example of a set of origins (and the origins in that example are incompletely specified).
Erm, you got it backwards. Firefox implements the standard properly
Since the actual behavior of the recommended-but-not-required functionality to identify "affiliated" origins and prevent their use to circumvent the likewise recommended-but-not-required per-origin quotas is not actually specified in the Web Storage specification (particularly, the criteria for defining affiliated origins are never specified, all that is provided is one example of a set of incompletely-specified origins as an example of affiliated origins), it is inaccurate:
To say that a browser which does not implement any functionality in this regard does not implement the standard "properly", or
To even say based on any particular test that a browser does or does not implement the recommended behavior.
You must be awful fun when talking to customers. They tend not to understand the distinction between "shall" and "should".
There is a reason why internet specifications (whether or not they are from IETF, and often whether or not they are even intended as standards-track) reference the RFC2119 definitions. "MUST" vs. "SHOULD" is an important distinction.
In this particular case, whats even more important is that the recommended functionality at issue isn't defined at all, there is just one example -- and the example doesn't fully specify the origins, so its an incomplete example -- given and no definition of the parameters of the identification of "affiliated origins". So if it was a "MUST", it would be a broken standard (since it would be impossible to assess conformance), and as it is, its impossible to say whether a particular implementation even implements the recommended functionality.
"there may exist valid reasons in particular circumstances to ignore a particular item" - in other words, this is a case where the feature should ALWAYS be applied to generic software because that must deal with all circumstances, not just "particular" ones
Any particular user agent is a "particular circumstance" (it is specific software with a specific use case within the scope of all possible kinds of user agents which might implement the Web Storage API); there is no such thing as an implementation that must deal with "all circumstances".
It really should not be hard to have a popup that says "This web page wants to create local storage on your computer allow/disallow"
Its not at all hard, but that's not related to the recommendation to implement per-origin quotas, or the further recommendation to build on top of the per-origin quotas functionality to detect and limit the use of "affiliated origins" to circumvent the per origin quotas, which is what is at issue here. Per-origin allow/disallow for Web Storage use isn't even a recommendation of the specification. (Though it is explicitly permitted behavior.)
Except that the specification is perfectly fine, it's the implementation that does something different.
Well, except that if you actually read the specification, nothing raised in TFS involves doing something different than required by the specification, and, in fact, the relevant recommended-but-not-required functionality described in the specification isn't defined at all (there is no definition of "affiliated origin", and only one example given.). Its outside of the simplest naive generalization of the example given, but that interpretation (e.g., treating all subdomains of the same 2LD as "affiliated origins") would also mean everything on, e.g., ".co.uk" would share the single-origin quota belonging to "co.uk".
Let's hope they understand how CCTLDs are organised. I don't like the idea of every site under *.co.uk sharing the same 5MB.
There's probably a reason that, contrary to the implication in TFS, the actual Web Storage Candidate Recommendation:
Recommends, but does not require, a per-origin quota,
Recommends, but does not require, user agents to take steps to identify and prevent use of "affiliated origins" to circumvent per-origin quotas,
Does not, in the preceding recommendation, provide a concrete definition of an "affiliated origin", leaving it up to UA implementors to determine, if they are going to follow the recommendation to identify and limit the use of "affiliated origins", how best to identify that origins are affiliated.
So its a FEATURE that they do NOT follow the STANDARD... ok.
The specification at issue is not a standard, its a Candidate Recommendation. Ikay, that's a technicality, but more importantly: They are following it; both the per-origin quotas themselves and the controls regarding preventing use of affiliated origins to circumvent the quotas are recommendations (should), not a requirements (must), of the spec, so even if they were not implemented at all, the implementation could be following the spec completely. Further, the spec never defines criteria for determining affiliated origins with regard to the controls preventing circumvention of per-origin limits, so the fact that it doesn't prevent the particular use of related origins that were at issue in this test doesn't mean they don't have controls of the type recommended.
It's not intended behavior being exploited. Did you even read the summary?
I read the summary. The author of the summary, however, has not read the spec, or, if they have, has failed to understand all of the following (a) that both the use of per-origin quotas is a recommendation, not a requirement, of the spec; (2) that the use of controls to prevent the use of affiliated origins to circumvent the recommended per-origin quotas are also recommendations, not requirements, of the spec, and (3) that the spec actually doesn't define what constitutes an affiliated origin, so that even if per-origin quotas and affiliated-origin identification-and-blocking were required by the spec, it would be impossible to judge whether any particular implementation complied with the requirement.
If they understood any of those points, they wouldn't describe this as a "bug".
I think you need to review the relevant portion of the specification, particularly the use of the word "should" and the reference to RFC2119 for the specific definition of "should" that is applicable when used in the specification.
no. it's a bug. the HTML5 spec clearly states that this exact behaviour should be looked out for and blocked
Its not a bug. While the Web Storage API Candidate Recommendation (related to, but not part, of, the HTML5 spec) both says that user agents should set a per-origin storage limit and should identify and prevent use of "origins of affiliated sites" to circumvent that limit, it doesn't specify either what constitutes an "affiliated site", and neither of those things that it says "should" be done are requirements of the specification. "Should" has a quite specific meaning in the specification (defined by reference in the spec to RFC2119), and its not the same as "must", instead:
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
So, its both a recommendation rather than a requirement, and not specified clearly enough to be implemented. There are some cases where origins of the same second-level domain are meaningfully affiliated, and some times where they are not (for a clear case of the latter, consider subdomains of ".co.uk".) Its pretty clear that origins which differ only in protocol are almost always going to be affiliated by any reasonable definition (e.g., http://www.example.com/ and https://www.example.com/ which are different origins), but no automatic identification of origin affiliation by subdomain can be done simply without understanding of per-domain policies from the TLD down to the first level at which all subdomains are affiliated. (And this is a problem which will get worse with the planned explosion of TLDs.) W
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 1
multithreading,
The Ruby language has fine support for multithreading. The current main implementation uses a Global VM Lock that only allows one Ruby thread to run at a time (native extensions can release the GVL to run in parallel with Ruby threads), but that's an implementation issue, not a language issue. Other implementations (JRuby, IronRuby, MacRuby, now, and Rubinius is aiming for this) have native threads without a GVL.
UTF support (only just in - enjoy the bugs!)
Unicode support has been in Ruby since 1.9, which has been out for quite a while; it was a bit late to the party, mostly because in Japan, a key area for Ruby, not just because Matz is from Japan, but because a lot of money supporting Ruby development was coming from Japan, Unicode dominance isn't (or at least wasn't, when the issue arose) as dominant as elsewhere and it was important for Ruby to not only nail Unicode support, but to nail support for multiple encodings (which it did with 1.9.)
cross platform GUIs (TK or Fox. WTF if Fox?)
TK and Fox aren't the only cross-platform GUI toolkits with libraries available for Ruby; Qt, Wx, and GTK are all supported.
Re:Review Ruby for the perl enthusiast please
on
Ruby 2.0.0 Released
·
· Score: 1
I did heard it directly from a pretty credible source, someone famous in the Ruby community that I will not embarrass by drawing into this thread, so feel free to say, from no one. Is it written anywhere?
The particular comment regarding the effect of removing the GVL that I refer is directly attributed to Matz at Rubyconf here, but isn't a direct quote.
"Data safety" - meaning, Ruby is not a threading language, threading is hard, leave it to something else to do something that hard, while Ruby stays "safe" and "easy."
No, that's not what "data safety" means. "Data safety" has nothing to do with "easy".
Data safety is, in fact, the reason you have to locking of some kind, whether fine grained or GVL -- if data safety wasn't a concern, it wouldn't be an issue. So, yeah, that's obviously the fundamental reason. But the reason for keeping the GVL rather than fine-grained locking with the current mainline implementation -- since the GVL, per the above link, was removed from the mainline implementation and resulted in performance degradation for single-threaded tasks -- appears to be about unacceptable costs, not about what is easier (since the work was, in fact, already done, it would be just as easy to use it as not.)
Then of course there's all the discussions about how hard it would be to remove - and removing it without a rewrite is certainly hard, I am sure.
It probably would be, just as it would have been hard to switch from green threads to native threads with a GVL without a rewrite -- so a rewrite was done. The next rewrite may already be well along: there's been a lot of talk in the community about a GVL-free version of Rubinius as the next mainline implementation.
Office 365 lets me use Excel to setup my spreadsheets and then enter in data via a web service.
Google Docs always require spreadsheet.
No, you can setup a spreadsheet and use Google Apps Script to build a web app (which can also be accessed as a web service) to accept data. And you could do that for quite some time before Office 365 was even available.
Slashdot Mirror
Actually, the sequester mechanism, when it was passed by Congress and signed by the President as part of a short-term funding agreement was designed by both sides to be painful because both sides wanted it that way so that it would be a disincentive to the other side to refuse to compromise on an actual budget agreement that would deal with specifics of addressing budget priorities going forward.
In a sense, it was a version of mutually-assured destruction that went into effect if bilateral action wasn't taken to avert it.
The problem with this is MAD may work when you have to take an active step to trigger it, it doesn't work as well when you have to have to jointly avoid it, because its easy to convince yourself that the other side will back down if you wait a little longer, so you don't have to compromise.
They do and funding isn't automatic under the current system. That's why we have a government shutdown if no appropriation is passed by Congress and signed by the President (or repassed by Congressional supermajority over a Presidential veto.) Even so-called "non-discretionary" spending isn't automatic.
Baseline budgeting is simply a matter of how budget proposals are calculated and presented, it has no bearing on the actual substantive process and requirements around passing a budget.
It is, in fact, a real cut to the currently-appropriated spending and the current spending rate. While it is often the case that reductions in projected increases are sold as "cuts" in government budgets, this is not one of the cases.
The sequester has nothing to do with baseline budgeting, it has to do with cuts to funds that are already appropriated for the current period.
Also, nothing in the federal budget happens automatically. If an appropriation isn't passed for each year, there are no funds, period, full stop. Baseline budgeting has to do with how budget proposals are drafted and presented, it doesn't mean that if no legislative action is taken an appropriation automatically remains in effect indefinitely.
Simple historical fact.
While frequently stated as a broad platitude, that's completely incoherent; as there is nothing conceivable that government could do that doesn't involve the market. Either government has a role in the market, or it has no role at all. You can have a meaningful and substantive discussion of what government's role with respect to the market ought to be, but when you say that government has a role to play but that that role is somehow not in the market, its sloganeering with no substantive content.
Scheme is a real language that is in production use.
That it also has clear mapping to core concepts that are useful for teaching the theory of computation is nice side benefit.
Re: Your title:
Actually, it is in prefix, not postfix notation.
Which ("are learning") is actually why its probably not as hard for children a language that uses prefix rather than infix notation than it is for older people who hav been using infix notation exclusively for longer; just like its easier for kids to learn different natural languages.
No, it wasn't. The term "bug" predates that (and computers) as a term for faults in electrical systems. The well-known moth that is the source of this myth was described in the notebook to which it was taped as the "first known instance of an actual bug being found", clearly indicating that computer "bugs" had existed before that time, but that the novel thing wasn't the term, but the fact than an actual arthropod was located and identified as the source of the problem.
You mean, code.org isn't trying to recruit engineers to volunteer? Strange page reached from the prominent "Help Us" link on the front page, then.
I'm not sure that's any except in the same way that its true that most people can't learn a foreign language beyond a painfully basic level; I think lots of people aren't exposed to anything like programming young enough, and that as a result many people who do encounter programming only do so after there brain is fixed in a way that doesn't allow them to learn it easily, and so if they aren't put in a position where they have no choice but to learn it, they often aren't going to stay with it. But that's not the same thing as not having the innate ability to learn it, that's just not starting learning it at the right time.
Code.org isn't marketing primarily to kids, its marketing primarily to teachers, parents, and potential engineer volunteers.
If they were marketing to kids under 18, neither would trotting out politicians that have been out of office for more than half of the life of kids at the upper end of the age range. Or Dr. Oz.
Not true at all; its quite possible to become passionate about preserving the status quo, which pretty much requires finding the world pretty much ok as it is, at least compared to the apparent immediately-available alternatives.
You can't become passionate about change without being dissatisfied with something in the status quo, but change isn't the only thing it is possible to be passionate about.
No, capitalism is a name invented by 19th Century socialists to describe the system they opposed, in which the structures of the system (including those imposed by government) systematically and often actively favored capital over labor.
The system where government stays out of the way is called "anarchy", and is completely different.
Learning how to make professional looking documents that communicate well to people is a valuable skill. Its also has about the same relationship to learning how to use a word processor as systems analysis (in the broadest, non-IT-specific, sense) has to coding.
There are two errors in this statement:
Since the actual behavior of the recommended-but-not-required functionality to identify "affiliated" origins and prevent their use to circumvent the likewise recommended-but-not-required per-origin quotas is not actually specified in the Web Storage specification (particularly, the criteria for defining affiliated origins are never specified, all that is provided is one example of a set of incompletely-specified origins as an example of affiliated origins), it is inaccurate:
There is a reason why internet specifications (whether or not they are from IETF, and often whether or not they are even intended as standards-track) reference the RFC2119 definitions. "MUST" vs. "SHOULD" is an important distinction.
In this particular case, whats even more important is that the recommended functionality at issue isn't defined at all, there is just one example -- and the example doesn't fully specify the origins, so its an incomplete example -- given and no definition of the parameters of the identification of "affiliated origins". So if it was a "MUST", it would be a broken standard (since it would be impossible to assess conformance), and as it is, its impossible to say whether a particular implementation even implements the recommended functionality.
Any particular user agent is a "particular circumstance" (it is specific software with a specific use case within the scope of all possible kinds of user agents which might implement the Web Storage API); there is no such thing as an implementation that must deal with "all circumstances".
Its not at all hard, but that's not related to the recommendation to implement per-origin quotas, or the further recommendation to build on top of the per-origin quotas functionality to detect and limit the use of "affiliated origins" to circumvent the per origin quotas, which is what is at issue here. Per-origin allow/disallow for Web Storage use isn't even a recommendation of the specification. (Though it is explicitly permitted behavior.)
Well, except that if you actually read the specification, nothing raised in TFS involves doing something different than required by the specification, and, in fact, the relevant recommended-but-not-required functionality described in the specification isn't defined at all (there is no definition of "affiliated origin", and only one example given.). Its outside of the simplest naive generalization of the example given, but that interpretation (e.g., treating all subdomains of the same 2LD as "affiliated origins") would also mean everything on, e.g., ".co.uk" would share the single-origin quota belonging to "co.uk".
There's probably a reason that, contrary to the implication in TFS, the actual Web Storage Candidate Recommendation:
The specification at issue is not a standard, its a Candidate Recommendation. Ikay, that's a technicality, but more importantly:
They are following it; both the per-origin quotas themselves and the controls regarding preventing use of affiliated origins to circumvent the quotas are recommendations (should), not a requirements (must), of the spec, so even if they were not implemented at all, the implementation could be following the spec completely.
Further, the spec never defines criteria for determining affiliated origins with regard to the controls preventing circumvention of per-origin limits, so the fact that it doesn't prevent the particular use of related origins that were at issue in this test doesn't mean they don't have controls of the type recommended.
I read the summary. The author of the summary, however, has not read the spec, or, if they have, has failed to understand all of the following (a) that both the use of per-origin quotas is a recommendation, not a requirement, of the spec; (2) that the use of controls to prevent the use of affiliated origins to circumvent the recommended per-origin quotas are also recommendations, not requirements, of the spec, and (3) that the spec actually doesn't define what constitutes an affiliated origin, so that even if per-origin quotas and affiliated-origin identification-and-blocking were required by the spec, it would be impossible to judge whether any particular implementation complied with the requirement.
If they understood any of those points, they wouldn't describe this as a "bug".
I think you need to review the relevant portion of the specification, particularly the use of the word "should" and the reference to RFC2119 for the specific definition of "should" that is applicable when used in the specification.
Its not a bug. While the Web Storage API Candidate Recommendation (related to, but not part, of, the HTML5 spec) both says that user agents should set a per-origin storage limit and should identify and prevent use of "origins of affiliated sites" to circumvent that limit, it doesn't specify either what constitutes an "affiliated site", and neither of those things that it says "should" be done are requirements of the specification. "Should" has a quite specific meaning in the specification (defined by reference in the spec to RFC2119), and its not the same as "must", instead:
So, its both a recommendation rather than a requirement, and not specified clearly enough to be implemented. There are some cases where origins of the same second-level domain are meaningfully affiliated, and some times where they are not (for a clear case of the latter, consider subdomains of ".co.uk".) Its pretty clear that origins which differ only in protocol are almost always going to be affiliated by any reasonable definition (e.g., http://www.example.com/ and https://www.example.com/ which are different origins), but no automatic identification of origin affiliation by subdomain can be done simply without understanding of per-domain policies from the TLD down to the first level at which all subdomains are affiliated. (And this is a problem which will get worse with the planned explosion of TLDs.) W
The Ruby language has fine support for multithreading. The current main implementation uses a Global VM Lock that only allows one Ruby thread to run at a time (native extensions can release the GVL to run in parallel with Ruby threads), but that's an implementation issue, not a language issue. Other implementations (JRuby, IronRuby, MacRuby, now, and Rubinius is aiming for this) have native threads without a GVL.
Unicode support has been in Ruby since 1.9, which has been out for quite a while; it was a bit late to the party, mostly because in Japan, a key area for Ruby, not just because Matz is from Japan, but because a lot of money supporting Ruby development was coming from Japan, Unicode dominance isn't (or at least wasn't, when the issue arose) as dominant as elsewhere and it was important for Ruby to not only nail Unicode support, but to nail support for multiple encodings (which it did with 1.9.)
TK and Fox aren't the only cross-platform GUI toolkits with libraries available for Ruby; Qt, Wx, and GTK are all supported.
The particular comment regarding the effect of removing the GVL that I refer is directly attributed to Matz at Rubyconf here, but isn't a direct quote.
No, that's not what "data safety" means. "Data safety" has nothing to do with "easy".
Data safety is, in fact, the reason you have to locking of some kind, whether fine grained or GVL -- if data safety wasn't a concern, it wouldn't be an issue. So, yeah, that's obviously the fundamental reason. But the reason for keeping the GVL rather than fine-grained locking with the current mainline implementation -- since the GVL, per the above link, was removed from the mainline implementation and resulted in performance degradation for single-threaded tasks -- appears to be about unacceptable costs, not about what is easier (since the work was, in fact, already done, it would be just as easy to use it as not.)
It probably would be, just as it would have been hard to switch from green threads to native threads with a GVL without a rewrite -- so a rewrite was done. The next rewrite may already be well along: there's been a lot of talk in the community about a GVL-free version of Rubinius as the next mainline implementation.
No, you can setup a spreadsheet and use Google Apps Script to build a web app (which can also be accessed as a web service) to accept data. And you could do that for quite some time before Office 365 was even available.