One does not pay the premium for hardware from the Big Three because it's a bargain.
Of course you do, if its a rational decision. You buy it because the expected combined cost of the hardware + support + cost of expected downtime and other losses despite the support is lower than with the available alternatives. Its bargain hunting, just with a wider scope of costs included in the analysis than just the sticker price of the hardware.
The cloud providers (which includes Google, if you ignore the fact that they only provide high-level cloud services, unlike Amazon) mostly build their own hardware.
Google provides low-level cloud services (IaaS in the form of Google Compute Engine, PaaS in the form of Google App Engine, RDBMS-in-the-cloud in the form of Google Cloud SQL, bucket-style storage in Google Cloud Storage) as well as higher-level services (all of Google's various apps build on their cloud infrastructure.)
So the Google-Amazon distinction drawn in the parenthetical is inaccurate.
While yes, right now, the tide may be against the server manufacturers -- the cloud still requires them in large quantities to host those services.
Google's position on the list of Intel server-chip buyers makes it clear that the problem isn't for people server manufacturers (which Google, very much, is), its for server vendors. Sure, the cloud requires servers. But if the people selling cloud services are also building their own servers, that doesn't create a market for server vendors.
Slashdot stories are frequently months or even years after the event. Why the sudden urgency?
Its not "sudden urgency." Slashdot stories are also frequently during the event, too.
Slashdot is remarkably inconsistent in terms of the timing, quality, and viewpoint of stories. But there is nothing new about this, or unusual about this story in that regard; it falls well within Slashdot's usual range of variation.
It looks like the 9.2 implementation uses its own definition for -infinity/+infinity unrelated to the type in question, which thinking about it now might not have been the best decision (at least, without the ability to define that [,y] and [-infinity,y] are synonymous) since -infinity (as defined by range types) is less than all other values including -infinity (as defined by the contained type).
I think it is a good decision in that it provides a syntactic construct for ranges that are unbounded on either end -- so it applies well to all types -- and works correctly with types that have an infinity value if that is used. You probably don't want the syntactic construct to have to be specially-aware of all the special values within types (because that increases the cost of expanding the type system), and the decision that syntactically-unbounded is "outside" (on either end) of any value in the domain (including, where it exists, an "infinite" value) is the decision that allows the range syntax to not be aware of special type values.
OTOH, code that deals with ranges ought to be type-aware, and as a general rule should use ranges bounded by the types infinity rather than unbounded ranges where the type has an infinity (and, for range values stored in tables, this should probably be enforced by an appropriate constraint which is quite straightforward with the exclusion constraint support implemented alongside range types in 9.2.)
Still, yeah, I can see the argument that more type-aware ranges that treated [,y] as equivalent to [-infinity,y] for types with a meaningful -infinity (and the equivalent for +infinity as the upper bound) would be slightly more convenient.
What the article MEANS is "betting on HTML5 as a MOBILE strategy instead of writing native SMARTPHONE applications was a mistake."
And its still wrong, IMO. The biggest mistake in Facebook's mobile app isn't performance issues linked to HTML5 (or any other source), its that the navigation sucks, the presentation of information sucks for a mobile device screen, and they keep increasing the screen real-estate taken up by things that are either UI or ads, which compounds the problem of the poor presentation of the content of interest.
Optimization of a constraint involving date ranges is a bit more difficult than you might think, and having it as one unified type makes queries a lot cleaner and indexes a lot more efficient (if done as GiST indexes anyways)
Old: WHERE (a.starttime BETWEEN b.starttime AND b.endtime OR b.starttime BETWEEN a.starttime AND a.endtime) New: WHERE a.timerange @@ b.timerange
Also, strictly speaking, you can't do the first one as a constraint at all (you can do it as a query condition, or enforce a constraint-like behavior through a series of triggers using queries with that condition.) OTOH, the latter form you can do as an exclusion constraint in 9.2, which -- in addition to any performance improvements -- is a lot more direct and expressive.
Before 9.2, I did this (for timestamp ranges only) using Jeff Davis's Temporal Extensions for PostgreSQL, which I've submitted a few patches to.
Which really is the direct predecessor of 9.2's Range Type support (from the same developer, too.)
Mainly, one-to-many relationships may be easier. Usually, they are two separate select statements.For example, one to get the article, another to get the comments. Then you patch it all together in PHP, or whatever middle language you're using.
I'm not sure adding new SQL features is going to deal with the problem of people not using the features they already have. Its already quite possible in PostgreSQL to do a single select that gets the article data and an aggregate that contains all the comments. Features that let you store JSON directly aren't necessary for that.
So you want to do that in the DB now. Will you have to change column definition to change that range?
No, the range is data, not part of the column definition, I would say "RTFA", but to be fair the link was mislabelled in TFS as being about "range-restricted types", rather than range types.
But here's the docs on range types. The scheduling use case is the basic example of exclusion constraints on range types (Sect 8.17.10 in the linked doc.)
I think everyone has glossed over the single most important feature in the Postgre SQL that they have refined in this release, IMHO. Ranged data types.
TFS apparently (from the link, which goes to range datatypes) meant to refer to them when it made the comment about "range-restricted datatypes".
Minor, but probably a welcome relief to those who need them, 9.1 adds range restricted types.
First, its 9.2, not 9.1.
Second, (as shown in the link) these are range types, not range-restricted types. Range-restricted types (as known from, e.g., Ada) are something that (via domains with check constraints) PostgreSQL has supported for a very long time.
Range types, combined with 9.2s support for exclusion constraints, are a pretty major new feature that give 9.2 a great facility in dealing with (among other things) temporal data and enforcing common logical constraints on such data in the database as simple-to-express constraints rather than through triggers.
Capitalism is to economics as natural selection is to Darwinism.
And regulation is to capitalism as medicine is to natural selection.
Yeah, and that medicine is what produced this outcome -- this isn't the unregulated market outcome, its the result of the DoJ enforcing regulations against price fixing.
What do you think is going to happen when Amazon gets its monopoly status back?
Since Amazon isn't doing anything with its ebook pricing to attract marketshare to its reading platform that its competitors aren't also doing, I don't expect it to get a monopoly through its pricing.
Or take the easier action and just file a DMCA response that says the files are not copyrighted. The ISP has to restore the files.
As I understand the safe harbor provisions of the DMCA, this is incorrect.
They have a safe harbor from copyright liability if they restore them in response to a proper counter-notice, and if they do not restore them they lose the safe harbor benefit they had with regard to any cause of action the user may have had -- but the DMCA doesn't create a cause of action requiring restoration, so unless the service provider has an obligation imposed outside of the DMCA to restore the material -- such as a contractual obligation to the user -- losing the safe harbor benefit with respect to actions by the user is a non-event, since there was no cause of action available in the first place.
IIRC, the DMCA provides immunity for a service provider that takes down material persuant to a valid complaint. That implies that without a valid complaint, there would be a cause for action against the service provider.
This inference is incorrect. The safe harbor provisions of the DMCA protect a service provider (under certain conditions) from copyright liability provided they take down material once they receive a compliant takedown notice, and from any liability they might otherwise face for taking down material in response to a takedown notice meeting its requirements (provided they take other steps required in the safe harbor provision), and also provides similar safe harbor for them if they restore material that was taken down in response to a counter-notice that meets the requirements in the DMCA.
Whether or not there would be any cause of action (e.g., for breach of contract for the takedown, or under copyright for the restoration) for any particular act within the safe harbor provisions depends on facts beyond the existence of the takedown/restoration and the deficiency of the notification.
The reason the superficially-symmetric safe harbor provisions for notice/takedown and counternotice/restoration aren't really symmetric is because in many cases service providers relationships to users are structured in a way specifically to avoid any cause of action for taking down material posted by the user for any reason whatsoever, and often are structured to allow more extreme measures (like no-notice cancellation of service.) Consequently, the main safe harbor those service providers care about is the one for copyright liability that applies so long as they always takedown material when a proper a takedown notice exists, which is satisfied if the set of takedown they will accept is a superset of the set of the DMCA-compliant notices.
Unit testing fails because if your code changes, you must change your unit tests.
Wrong.
If your the requirements for code change (or it is discovered that your previous unit tests didn't cover all of them completely and correctly), you must change the tests that exist to determine whether the code meets those requirements.
If your unit tests fail, you must change the code.
But you don't need to change the unit tests because you changed the code. That's backwards.
Few managers realize that Unit Testing adds 20 - 30% or more overhead to software but plan development as if Unit Testing takes no effort.
I've yet to see any place that does anything like unit testing at all -- whether in the bad test-last way or the good test-first way -- where the fact that writing unit tests takes time is not considered in planning and estimating. The good test-first places tend to be low-ceremony environments where the dev team does estimates which include unit testing as part of the overall development-time estimate, and the bad test-last places tend to by high-ceremony bureaucratic environments with top-down planning by management that explicitly breaks out unit testing. So, IME, this is generally false.
Yeah and what happens when the 'worknotes' server is taken offline or moves?
This is one reason why "worknotes", to the extent that they are needed, should be maintained with the source code (i.e., in the same repository) even though the notes are separate files from the source code.
It should be impossible for the worknotes referenced in the source code to become unavailable while the source code itself is available.
But when debating the policy implications of AGW a climatoligist is useless. What insight can they offer into whether cap and trade is a good idea?
There are at least five important questions whose answers are needed to address whether cap-and-trade is a good idea:
1. How much effect would cap-and-trade have on GHG emissions? 2. What other direct effects would cap-and-trade have besides its effect on reducing emissions? 3. What would the climate impact be of the effects described in #1? 4. Would any of the effects described in #2 have climate effects, and, if so, what effects? 5. Does the net social benefit of the climate effects in #3-4, combined with the net social benefit of the non-climate effects described in #2, offset the net social costs of effects described in #2.
#1-4 are scientific questions. #5 is a question that, while there may be some scientific aspects of it (aside from those in the preceding questions on which it relies) is largely about subjective values.
Of the four scientific questions, two of them are questions specifically about climatology. So, while there's very good reason for there to be other scientists providing input, its pretty clear that climatologists have quite a lot to contribute on the question.
They aren't economists.
Since one of the scientific questions listed above is largely an economic one (#1) and one is partially an economic one (#2), there certainly is a role for economists advising on the issue as well. But that role is not exclusive of the role of climatologists, as there remain climatological questions that are important in addressing the utility of cap and trade (or any approach to climate change, since the effectiveness of the approach in addressing the core problem it seeks to address will always involve a question of climatology, even if it also involves other questions.)
If the conversation turns to carbon sequestration they aren't the person to ask whether that is feasable.
No, but once someone else provides input on the degree to which sequestration is feasible and what other near-term environmental impacts that sequestration will have, your going to need to turn to climatology to answer what the net effect of the sequestration (both from the direct carbon reductions and indirectly through any environmental side effects) is likely to be on climate.
If we want to talk alternative energy they can't provide any insight on that either.
They certainly are the best positioned, once others answer what is feasible and what effects those options would have on GHG emissions and other environmental inputs, to provide insight on what those alternatives are likely to do in terms of climate. Which, when evaluating alternative energy supplies as a solution to a climate problem, is a pretty critical insight.
You need different scientists and experts to answer those questions.
Its true that you need a variety of experts to address those questions.
Its not true that the need for other scientists to address those questions means you don't also need climatologists to address each of them.
Climatology is a pretty narrow specialty.
Yes, but its pretty freaking central to evaluating options to address climate change, for reasons which should be intuitively obvious to the most casual observer.
Doesn't the autobahn have a lower death rate per mile than the US highway system?
Germany (and most of Europe, for that matter) makes it much harder and more expensive to get a driving license than the US, and provides much better alternatives to driving for getting from point A to point B than does the US.
The sad fact is that its not speed that kills, its differential speed.
Technically, its energy transfer, disruption of tissue, and blood loss. But, other aspects of the regulatory and transit context remaining constant, higher highway speed limits -> more differential speed -> more collisions producing energy transfer, tissue disruption, etc.
If you look at Germany they take drivers ed a lot more seriously, as well as licencing, with 6 month courses costing thousands of dollars being the norm.
Well, yeah, better driving training, more selective admission criteria for the driving club, and more transit options so that people don't need to drive as much (all of which Germany -- and lots of other places -- have compared to the US) can all mitigate the increased danger of higher-speed driving.
But I don't see evidence that Texas is adopting those along with the raised speed limit, so that observation is irrelevant, or at least tangential to the immediate issue.
But if it is not probable, or at least highly unlikely, what's the point of even discussing that notion
It is "probable, or at least highly unlikely". But I'm fairly sure that's not what you meant (I suspect you meant "probable, or at least somewhat likely".)
That aside, let's just say that, if the post in question had received positive moderation, "Informative" would have been rather surprising, "Insightful" would have been somewhat less surprising, and "Funny" would not have been surprising.*
* all reference to moderation being surprising are relative and for illustrative purposes; I'm not really "surprised" much by anything in Slashdot moderation these days.
Heard about this on NPR this morning, according to the report, Amazon buys a license to sell ebooks from the publisher, then proceeds to undercut the publisher by a fair amount.
Of course, the smart publisher would not sell a license to Amazon.
Actual publishers are smart enough that, if they would make more money not selling licenses to Amazon and instead selling through other outlets while shutting out Amazon, they would.
In the real world, what publishers did is sell to Amazon while trying to set up their own (independently and in collaboration) venues to sell e-books that would cut-out Amazon. There were a number of different such efforts that were hyped within the industry as the thing that would displace Amazon and restore full control of e-book retail to the publishing industry.
The failure of all those efforts is why the big publishers were willing to join together and sign on to a deal to try to swap Amazon's practical domination of the retail e-book market for Apple domination on terms slightly more favorable to the publishers.
Slashdot Mirror
Of course you do, if its a rational decision. You buy it because the expected combined cost of the hardware + support + cost of expected downtime and other losses despite the support is lower than with the available alternatives. Its bargain hunting, just with a wider scope of costs included in the analysis than just the sticker price of the hardware.
Google provides low-level cloud services (IaaS in the form of Google Compute Engine, PaaS in the form of Google App Engine, RDBMS-in-the-cloud in the form of Google Cloud SQL, bucket-style storage in Google Cloud Storage) as well as higher-level services (all of Google's various apps build on their cloud infrastructure.)
So the Google-Amazon distinction drawn in the parenthetical is inaccurate.
Google's position on the list of Intel server-chip buyers makes it clear that the problem isn't for people server manufacturers (which Google, very much, is), its for server vendors. Sure, the cloud requires servers. But if the people selling cloud services are also building their own servers, that doesn't create a market for server vendors.
Its not "sudden urgency." Slashdot stories are also frequently during the event, too.
Slashdot is remarkably inconsistent in terms of the timing, quality, and viewpoint of stories. But there is nothing new about this, or unusual about this story in that regard; it falls well within Slashdot's usual range of variation.
I think it is a good decision in that it provides a syntactic construct for ranges that are unbounded on either end -- so it applies well to all types -- and works correctly with types that have an infinity value if that is used. You probably don't want the syntactic construct to have to be specially-aware of all the special values within types (because that increases the cost of expanding the type system), and the decision that syntactically-unbounded is "outside" (on either end) of any value in the domain (including, where it exists, an "infinite" value) is the decision that allows the range syntax to not be aware of special type values.
OTOH, code that deals with ranges ought to be type-aware, and as a general rule should use ranges bounded by the types infinity rather than unbounded ranges where the type has an infinity (and, for range values stored in tables, this should probably be enforced by an appropriate constraint which is quite straightforward with the exclusion constraint support implemented alongside range types in 9.2.)
Still, yeah, I can see the argument that more type-aware ranges that treated [,y] as equivalent to [-infinity,y] for types with a meaningful -infinity (and the equivalent for +infinity as the upper bound) would be slightly more convenient.
And its still wrong, IMO. The biggest mistake in Facebook's mobile app isn't performance issues linked to HTML5 (or any other source), its that the navigation sucks, the presentation of information sucks for a mobile device screen, and they keep increasing the screen real-estate taken up by things that are either UI or ads, which compounds the problem of the poor presentation of the content of interest.
Also, strictly speaking, you can't do the first one as a constraint at all (you can do it as a query condition, or enforce a constraint-like behavior through a series of triggers using queries with that condition.) OTOH, the latter form you can do as an exclusion constraint in 9.2, which -- in addition to any performance improvements -- is a lot more direct and expressive.
Which really is the direct predecessor of 9.2's Range Type support (from the same developer, too.)
I'm not sure adding new SQL features is going to deal with the problem of people not using the features they already have. Its already quite possible in PostgreSQL to do a single select that gets the article data and an aggregate that contains all the comments. Features that let you store JSON directly aren't necessary for that.
No, the range is data, not part of the column definition, I would say "RTFA", but to be fair the link was mislabelled in TFS as being about "range-restricted types", rather than range types.
But here's the docs on range types. The scheduling use case is the basic example of exclusion constraints on range types (Sect 8.17.10 in the linked doc.)
TFS apparently (from the link, which goes to range datatypes) meant to refer to them when it made the comment about "range-restricted datatypes".
First, its 9.2, not 9.1.
Second, (as shown in the link) these are range types, not range-restricted types. Range-restricted types (as known from, e.g., Ada) are something that (via domains with check constraints) PostgreSQL has supported for a very long time.
Range types, combined with 9.2s support for exclusion constraints, are a pretty major new feature that give 9.2 a great facility in dealing with (among other things) temporal data and enforcing common logical constraints on such data in the database as simple-to-express constraints rather than through triggers.
Bandwidth and transaction processing aren't cost-free. There may be a very small marginal costs, but there is not really "no cost to distribute".
Yeah, and that medicine is what produced this outcome -- this isn't the unregulated market outcome, its the result of the DoJ enforcing regulations against price fixing.
Since Amazon isn't doing anything with its ebook pricing to attract marketshare to its reading platform that its competitors aren't also doing, I don't expect it to get a monopoly through its pricing.
Prior art -- of the kind that invalidates a patent -- doesn't require that it be patented.
Recovering for patent infringement (naturally) does require that the invention be patented.
As I understand the safe harbor provisions of the DMCA, this is incorrect.
They have a safe harbor from copyright liability if they restore them in response to a proper counter-notice, and if they do not restore them they lose the safe harbor benefit they had with regard to any cause of action the user may have had -- but the DMCA doesn't create a cause of action requiring restoration, so unless the service provider has an obligation imposed outside of the DMCA to restore the material -- such as a contractual obligation to the user -- losing the safe harbor benefit with respect to actions by the user is a non-event, since there was no cause of action available in the first place.
This inference is incorrect. The safe harbor provisions of the DMCA protect a service provider (under certain conditions) from copyright liability provided they take down material once they receive a compliant takedown notice, and from any liability they might otherwise face for taking down material in response to a takedown notice meeting its requirements (provided they take other steps required in the safe harbor provision), and also provides similar safe harbor for them if they restore material that was taken down in response to a counter-notice that meets the requirements in the DMCA.
Whether or not there would be any cause of action (e.g., for breach of contract for the takedown, or under copyright for the restoration) for any particular act within the safe harbor provisions depends on facts beyond the existence of the takedown/restoration and the deficiency of the notification.
The reason the superficially-symmetric safe harbor provisions for notice/takedown and counternotice/restoration aren't really symmetric is because in many cases service providers relationships to users are structured in a way specifically to avoid any cause of action for taking down material posted by the user for any reason whatsoever, and often are structured to allow more extreme measures (like no-notice cancellation of service.) Consequently, the main safe harbor those service providers care about is the one for copyright liability that applies so long as they always takedown material when a proper a takedown notice exists, which is satisfied if the set of takedown they will accept is a superset of the set of the DMCA-compliant notices.
Wrong.
If your the requirements for code change (or it is discovered that your previous unit tests didn't cover all of them completely and correctly), you must change the tests that exist to determine whether the code meets those requirements.
If your unit tests fail, you must change the code.
But you don't need to change the unit tests because you changed the code. That's backwards.
I've yet to see any place that does anything like unit testing at all -- whether in the bad test-last way or the good test-first way -- where the fact that writing unit tests takes time is not considered in planning and estimating. The good test-first places tend to be low-ceremony environments where the dev team does estimates which include unit testing as part of the overall development-time estimate, and the bad test-last places tend to by high-ceremony bureaucratic environments with top-down planning by management that explicitly breaks out unit testing. So, IME, this is generally false.
This is one reason why "worknotes", to the extent that they are needed, should be maintained with the source code (i.e., in the same repository) even though the notes are separate files from the source code.
It should be impossible for the worknotes referenced in the source code to become unavailable while the source code itself is available.
There are at least five important questions whose answers are needed to address whether cap-and-trade is a good idea:
1. How much effect would cap-and-trade have on GHG emissions?
2. What other direct effects would cap-and-trade have besides its effect on reducing emissions?
3. What would the climate impact be of the effects described in #1?
4. Would any of the effects described in #2 have climate effects, and, if so, what effects?
5. Does the net social benefit of the climate effects in #3-4, combined with the net social benefit of the non-climate effects described in #2, offset the net social costs of effects described in #2.
#1-4 are scientific questions. #5 is a question that, while there may be some scientific aspects of it (aside from those in the preceding questions on which it relies) is largely about subjective values.
Of the four scientific questions, two of them are questions specifically about climatology. So, while there's very good reason for there to be other scientists providing input, its pretty clear that climatologists have quite a lot to contribute on the question.
Since one of the scientific questions listed above is largely an economic one (#1) and one is partially an economic one (#2), there certainly is a role for economists advising on the issue as well. But that role is not exclusive of the role of climatologists, as there remain climatological questions that are important in addressing the utility of cap and trade (or any approach to climate change, since the effectiveness of the approach in addressing the core problem it seeks to address will always involve a question of climatology, even if it also involves other questions.)
No, but once someone else provides input on the degree to which sequestration is feasible and what other near-term environmental impacts that sequestration will have, your going to need to turn to climatology to answer what the net effect of the sequestration (both from the direct carbon reductions and indirectly through any environmental side effects) is likely to be on climate.
They certainly are the best positioned, once others answer what is feasible and what effects those options would have on GHG emissions and other environmental inputs, to provide insight on what those alternatives are likely to do in terms of climate. Which, when evaluating alternative energy supplies as a solution to a climate problem, is a pretty critical insight.
Its true that you need a variety of experts to address those questions.
Its not true that the need for other scientists to address those questions means you don't also need climatologists to address each of them.
Yes, but its pretty freaking central to evaluating options to address climate change, for reasons which should be intuitively obvious to the most casual observer.
Germany (and most of Europe, for that matter) makes it much harder and more expensive to get a driving license than the US, and provides much better alternatives to driving for getting from point A to point B than does the US.
So that's hardly surprising.
Technically, its energy transfer, disruption of tissue, and blood loss. But, other aspects of the regulatory and transit context remaining constant, higher highway speed limits -> more differential speed -> more collisions producing energy transfer, tissue disruption, etc.
Well, yeah, better driving training, more selective admission criteria for the driving club, and more transit options so that people don't need to drive as much (all of which Germany -- and lots of other places -- have compared to the US) can all mitigate the increased danger of higher-speed driving.
But I don't see evidence that Texas is adopting those along with the raised speed limit, so that observation is irrelevant, or at least tangential to the immediate issue.
It is "probable, or at least highly unlikely". But I'm fairly sure that's not what you meant (I suspect you meant "probable, or at least somewhat likely".)
That aside, let's just say that, if the post in question had received positive moderation, "Informative" would have been rather surprising, "Insightful" would have been somewhat less surprising, and "Funny" would not have been surprising.*
* all reference to moderation being surprising are relative and for illustrative purposes; I'm not really "surprised" much by anything in Slashdot moderation these days.
Apparently, you didn't read any of the rest of my post except the sentence you quoted, since it addresses exactly the argument you make in your post.
Actual publishers are smart enough that, if they would make more money not selling licenses to Amazon and instead selling through other outlets while shutting out Amazon, they would.
In the real world, what publishers did is sell to Amazon while trying to set up their own (independently and in collaboration) venues to sell e-books that would cut-out Amazon. There were a number of different such efforts that were hyped within the industry as the thing that would displace Amazon and restore full control of e-book retail to the publishing industry.
The failure of all those efforts is why the big publishers were willing to join together and sign on to a deal to try to swap Amazon's practical domination of the retail e-book market for Apple domination on terms slightly more favorable to the publishers.