Right, and this is one threat that if we do detect it far enough in advance, we can actually prevent it from happening! And having a good detection system is the key, if we detect the threat many decades in advance even the largest "planet killers" can be deflected for modest amounts of money.
Wait, scratch that. The majority of the dwellings will need to be underground to avoid the radiation. Instead of a 3D printer, take a tunnel boring machine.
You can't make everything you need out of holes. Your tunnels will need doors, partitions, tables, etc., etc. No IKEA on Mars and the shipping charges are horrendous. There are lots of things besides main structural walls to be made.
Thanks for all your calculations, but you entirely neglect auditory acoustic response issues, or the fact this energy is coming exclusively in rapid rise impulses.
There is more direct information in this readily available. We read here that the "Concorde's sonic boom noise level was 105 PLdB. The PLdB that researchers believe will be acceptable for unrestricted supersonic flight over land is 75, but NASA wants to eventually beat that and reach 70 PLdB." The measure PLdB is "perceived level of decibels" which takes into the account that impulsive, rapid rise sounds appear louder to humans. A 105 dB sound is a very loud sound to anybody. There would be hundreds, perhaps even thousands, of supersonic flights coast-to-coast a day if this became commercial. If you were under a common flight corridor, you might hear one of these every few minutes all day long.
The NASA article discusses though the fact that aircraft design can lessen sonic booms, and that is real key to making this a viable transcontinental technology.
But where we really need supersonic flight is on trans-Pacific flights! Where are the hypersonic trans-Pacific airliner projects these days?
There are exactly two different kinds of music - good music and bad music. What makes music good or bad is left up to the individual - everybody has different opinions.
I'm 62, from a small town in Alabama, a child in the fifties, high school in the late sixties, college in the early seventies, and guess what? I like it all! From classical to the latest, there's good to be found (and a LOT of crap). There's even good and bad music from the same artist, e.g. Eric Clapton early was great, but kinda lame later.
I usually listen to music played randomly from my collection. You could hear an old bluegrass song followed by Nirvana followed by Bach followed by a gospel song followed by a Disney tune. The only thing all the songs have in common is that they're only the good ones.
On the road I listen to XM. The presets are Symphony Hall, Met opera, Lithium, Classic Rewind, Bluegrass Junction, and BB King's Bluesville.
Amen to this! I like everything - if it is good. I enjoy discovering new styles, genres, bands. I have been around awhile, but I was one of Pentatonix's first fans for example. Went to one of their concerts a few months back - Cello/beatboxing was showcased and it was cool! Check out Mattisyahu: his Hassidic/Reggae/Rap fusion is brilliant. Here's a tip - listen to an unfamiliar style/genre more than once. I listen to music from all over the world. It takes time to appreciate the nuances that each style/genre brings. (Bluegrass is one of America's greatest contributions to music.)
I am a big proponent of agile methods (see the agile thread today), but here I disagree. A UI is part of the system architecture, and architecture fundamentals do need to be defined early in development (but then refined and evolved as development proceeds). Agile is definitely not "making stuff up as you go along".
There is no evidence of significant voter fraud anywhere, that's why voter ID proponents never cite any real cases. The only problems with corruption of the voting system occurs when the votes are counted, or measures to deny people the ability to vote.
... really I have no issue with mandatory voter ID -- you just need to severely over-engineer the solution to ensure it's not a burden on those in society with the least time/money/options/eduction.
And the fact that these voted ID laws never include proactive provisions to get IDs into the hands of all voters for free reveals their true intent quite clearly. Heck, Ohio is trying to enact a poll tax (banned explicitly by the Constitution, 24th Amendment) by requiring a voter ID card that you must pay for.
I actually agree with this. The documentation does need to evolve with the implementation, and if you don't, it is as you say. But having a clear concept about how it is to be used, and working out a coherent description of using it is a very strong design tool to make a usable, understandable system.
Inapplicable (or should be). There is no "standard" here. It is a collection of related, mutually supporting practices and tools. People who try to make it into "name brand" all-or-nothing methodologies can create that impression though.
Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).
"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.
I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.
This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.
One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".
For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.
There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.
And not because it has to be that way. The software is just poorly designed.
In an ideal world, user documentation would be written before the software so that an understandable, consistent, UI would exist. This sometimes happens, but even then, the implementation may not match the documentation (yes, I have seen this more than once).
Design principles like: simple things (and common tasks, even if not exactly simple) should be simple to do; the same technique should work in all contexts; etc. are often ignored in OS projects.
I have come to despair in trying to find a nice open source (Linux) object-drawing program that is intuitive (and thus easy to learn), has consistent behavior, and allows the quick creation of clean basic diagrams, and maybe has an additional level of finer controls for more precise work. The original Macintosh had this back in the 1980s with MacDraw, and the even more awesome MacDraw II. Complete novices could take the program and discover how to make good looking "boxologies" in minutes just by playing with the tools. Maybe such programs are still available on the Mac platform (I haven't had one in years), but no OS object drawing or 2D CAD program on Linux seems able to grasp what one of the first such pieces of software on the market was able to accomplish.
(Another really annoying thing to find in user documentation is self-praise about the product and accompanying documentation: making promises about how great the product is, and how wonderful the documentation you are looking at is, that are rarely kept.)
Videos have their place, I grant. Especially when it comes to manipulating some object (could be a graphical object on a screen), where a verbal description just cannot compete.
But I hate "video documentation" with an undying passion. They have an extremely so rate of information transfer, typically very low information density (see how little text is in a 5 minute video script), cannot be scanned at all, require you to have an audible audio hook-up, cannot be copied for notes,... I'm just getting started here, but you get the picture. I can literally take in information 10 times faster in printed form, and locate relevant content even faster than that.
If video documentation is available as optional back-up, great! But if that is the only documentation, I will not use whatever-the-heck-it-is, I'll find something else.
They need to refer the the pieces of hadoop. HDFS is the storage piece and many things can interface to it, it isn't great but is often good enough especially if you just have a couple local disks per node. YARN is the scheduler piece, it is mostly awful performance-wise but is fairly easy to use...long run it'll lose to something like mesos I think.
That's a good call. With Cloudera and HortonWorks both adding new components to the Hadoop stack it has exploded in the number of components in the last a year or two, and that can be a bad thing. The complexity of the whole ecosystem is getting horrendous, with a typical configuration file doubling from 250 or so to 500 configuration items, which are almost all undocumented (unless you read the code - which scarcely qualifies as "documented") in the last year. For a practical deployment you are pretty much forced to use a commercial stack to get something up and running in a manageable fashion. And then there is the fact that the HDFS foundation is showing its age.
MR is the map reduce piece that everyone thinks of when you say hadoop. Almost everything will run quicker in spark(still using a map/reduce methodology) than hadoop MR.
Spark on Mesos is looking mighty awesome.
As a side note, I don't know anyone who still writes MR jobs directly, they are all doing pig or hiveql.
MapReduce is still viable for stable production jobs, but not in a dynamic requirements environment.
Although HiveQL is alive and kicking, the complete replacement of Hive Server with Hive Server 2, while possibly an improvement in usability overall (I am not convinced), it trashes your skill investment in the (now) obsolete Hive stack component. Maybe I am just grousing, but I start having reservations about technology planning in the data center when a key stack component changes so much it a relatively short period of time
Brookings analyses have increasingly been up for sale. Not surprisingly it is taking up this pro-Microsoft, pro-Gates agenda after the Bill's foundation became their biggest contributor.
Durable generational trade agreements like GATT 1947 are formed from open discussions of mutual interest, and finding points where both/all sides can agree, or can at least agree to compromise.
Indeed, we are seeing the U.S. Crony Corporatist Capitalism reaching its highest level of development. Corporations now write out laws in secret - even from our elected representatives (despite the fact that they strictly vote the corporate lobbyist line anyway). And the clear intent here is that this will be presented as a fast track "deal" - no modification permitted, the corporation writ is final.
It should be remembered that "fast track" - secret trade deals with no modification allowed - only came into existence in 1974. It is one of the founding cornerstones of the crony capitalist edifice that has been built since 1970 - when worker wages stopped growing with economic growth as had been the historic norm, and a reasonable expectation by the American people.
This could be a parody of the thinking of the corporatist shills, and apologists for out present plutocracy, except that the actual shills and apologists often say exactly the same thing, deaf to the ludicrousness of the messages they lip-synch with./p
No, no...you misunderstand me. I'm not saying there should be less government control, just that it's done algorithmically.
Think automated DMV processing, automated welfare distribution, automated parolee management, IRS collections/auditing, and so forth.
Of course, the inevitable argument against this is that too much trust is placed into the programmers hands. This is why it would all have to not just be open source, but clearly laid out and audited by many many programmers and non-programmers alike. Further, the algorithms should have built in mechanisms for refinement and improvement.
As a guy who loves designing algorithms, and is very good at it, I must say you put w-a-a-a-y too much faith in algorithms. Even "open source" algorithms. Consider the Federal Government's determinant sentencing rules (with the Orwellian misname of "guidelines"). They are viewed with almost uniform horror by the judges that must use them to calculate sentences, even by Conservative judges who would be most expected to approve of the often Draconian result. There is nothing secret about these sentencing algorithms. Prosecutors are able to trigger whatever "enhancements" they wish by placing claims in the indictment regardless of merit.
I've never heard of a projectile being aimed like that. Do you have examples of it being used elsewhere?
Yes, it is a technique that has been developed for maneuvering re-entry vehicles for ICBMs (MARVs). Here is a Russian page with an excerpt from an English source about it: "There are multiple ways for the designer to provide maneuverable capability in a re-entry vehicle, 1....moveable flaps which can provide one, two, or three degrees of freedom 2....Control can also be effected by moving a mass laterally in the vehicle to offset the vehicle’s center of gravity.The resulting mass asymmetry is equivalent to an aerodynamic asymmetry."
That $11 figure is all over the Internet, but a better, in-depth, source is this one "Business Ethics: Case Studies and Selected Readings" By Marianne Jennings. In it we read that: “Among the design changes that could have been made were side and cross members at $2.40 and $1.80 per car, respectively; a shock-absorbent “flak suit” to protect the tank at $4; a tank within a tank and placement of the tank over the axle at $5.08 to $5.79; a nylon bladder within the tank at $5.25 to $8; a placement of the tank over the axle surrounded with a protective barrier at $9.59; the imposition of a protective shield between the differential housing and the tank at $2.35; improvement of the bumper at $2.60; and the addition of eight inches of crush space at a cost of $6.40.”
All of these individual fixes are less than $11. I do not know which of these by themselves would have been sufficient, but the absence of pursuing any of them is probably what led to the jury verdict.
I admit to being pleasantly surprised by the actions that Wheeler is taking. I had been quite skeptical that someone so deeply tied to the two industries had not been completely captured.
(It is not never necessary to assume pay-for-play or some sort of soft corruption. People who work in an institution a long time typically adopt its points-of-view through familiarity and socialization if nothing else.)
Something can be uniform and fluctuating at the same time. All that's required is that the fluctuations follow the same, regular pattern everywhere.
I have no idea whether this is true for the CMB, however.
It is true. Further, the fluctuations are tiny - at the parts per million level. It took 28 years after the CMB was discovered to detect any fluctations at all, requiring a sophisticated space probe (COBE) to do it.
Asserting that the CMB is "not uniform" because of these fluctuations is rather like saying the Bonneville Salt Flats are not really flat at all since the surface has millimeter scale irregularities, or your polished marble dining room floor isn't flat since it has micron sized irregularities.
I think it comes down to this: why there is a big cold spot in the CMB? Because there's a big void. Mystery solved!
Except there's still the mystery of why there is such a big void in the first place.
That is true, but it is a much lesser mystery. The previous record-holder was the Canes Venatici Supervoid at 1.3 billion light years, and an Eridanus Supervoid has been the preferred explanation for the Eridanus Cold Spot (or, humorously, CAOE: "Cosmic Axis Of Evil) for years ("parallel universe collisions" was always an exotic explanation), but the existence of such a supervoid had not been confirmed. Dr. István Szapudi of the Institute for Astronomy at the University of Hawaii at Manoa has has just announced findings that measures this supervoid at 1.8 billion light years. This is moderately bigger than the previous record-holder (40% wider), but there are quite a few that are 400-800 million light years across. This looks rather like a power law distribution, often found in nature.
The Canes Venatici Supervoid is closer as than the Eridanus Supervoid (red shift z=0.118 vs 0.22, or 1.5 vs 2.5 billion light years) as well as being smaller so there are two reasons for the Integrated Sachs-Wolfe Effect to be weaker, but apparently there is no anomalous cooling for that void at all. I would like to see someone address that.
The EU banned three neonicotinoids that are judged especially high risk for bees 17 months ago. If this is causing/contributing to colony collapse disorder, evidence should start settling this question over the next year or two I would think.
Slashdot Mirror
Right, and this is one threat that if we do detect it far enough in advance, we can actually prevent it from happening! And having a good detection system is the key, if we detect the threat many decades in advance even the largest "planet killers" can be deflected for modest amounts of money.
Wait, scratch that. The majority of the dwellings will need to be underground to avoid the radiation. Instead of a 3D printer, take a tunnel boring machine.
You can't make everything you need out of holes. Your tunnels will need doors, partitions, tables, etc., etc. No IKEA on Mars and the shipping charges are horrendous. There are lots of things besides main structural walls to be made.
Thanks for all your calculations, but you entirely neglect auditory acoustic response issues, or the fact this energy is coming exclusively in rapid rise impulses.
There is more direct information in this readily available. We read here that the
"Concorde's sonic boom noise level was 105 PLdB. The PLdB that researchers believe will be acceptable for unrestricted supersonic flight over land is 75, but NASA wants to eventually beat that and reach 70 PLdB."
The measure PLdB is "perceived level of decibels" which takes into the account that impulsive, rapid rise sounds appear louder to humans. A 105 dB sound is a very loud sound to anybody. There would be hundreds, perhaps even thousands, of supersonic flights coast-to-coast a day if this became commercial. If you were under a common flight corridor, you might hear one of these every few minutes all day long.
The NASA article discusses though the fact that aircraft design can lessen sonic booms, and that is real key to making this a viable transcontinental technology.
But where we really need supersonic flight is on trans-Pacific flights! Where are the hypersonic trans-Pacific airliner projects these days?
There are exactly two different kinds of music - good music and bad music. What makes music good or bad is left up to the individual - everybody has different opinions. I'm 62, from a small town in Alabama, a child in the fifties, high school in the late sixties, college in the early seventies, and guess what? I like it all! From classical to the latest, there's good to be found (and a LOT of crap). There's even good and bad music from the same artist, e.g. Eric Clapton early was great, but kinda lame later. I usually listen to music played randomly from my collection. You could hear an old bluegrass song followed by Nirvana followed by Bach followed by a gospel song followed by a Disney tune. The only thing all the songs have in common is that they're only the good ones. On the road I listen to XM. The presets are Symphony Hall, Met opera, Lithium, Classic Rewind, Bluegrass Junction, and BB King's Bluesville.
Amen to this! I like everything - if it is good. I enjoy discovering new styles, genres, bands. I have been around awhile, but I was one of Pentatonix's first fans for example. Went to one of their concerts a few months back - Cello/beatboxing was showcased and it was cool! Check out Mattisyahu: his Hassidic/Reggae/Rap fusion is brilliant. Here's a tip - listen to an unfamiliar style/genre more than once. I listen to music from all over the world. It takes time to appreciate the nuances that each style/genre brings. (Bluegrass is one of America's greatest contributions to music.)
I am a big proponent of agile methods (see the agile thread today), but here I disagree. A UI is part of the system architecture, and architecture fundamentals do need to be defined early in development (but then refined and evolved as development proceeds). Agile is definitely not "making stuff up as you go along".
Or: because anything that enables vote-count corruption favors Republicans.
There is no evidence of significant voter fraud anywhere, that's why voter ID proponents never cite any real cases. The only problems with corruption of the voting system occurs when the votes are counted, or measures to deny people the ability to vote.
But when a 101% of the population (not registered to vote, or of voters) of a black precinct votes in favor of the black guy, that's not racist.
Just makin' stuff up, I see.
... really I have no issue with mandatory voter ID -- you just need to severely over-engineer the solution to ensure it's not a burden on those in society with the least time/money/options/eduction.
And the fact that these voted ID laws never include proactive provisions to get IDs into the hands of all voters for free reveals their true intent quite clearly. Heck, Ohio is trying to enact a poll tax (banned explicitly by the Constitution, 24th Amendment) by requiring a voter ID card that you must pay for.
I actually agree with this. The documentation does need to evolve with the implementation, and if you don't, it is as you say. But having a clear concept about how it is to be used, and working out a coherent description of using it is a very strong design tool to make a usable, understandable system.
Inapplicable (or should be). There is no "standard" here. It is a collection of related, mutually supporting practices and tools. People who try to make it into "name brand" all-or-nothing methodologies can create that impression though.
Iterative, incremental development - the core of agile - has been around at least since Barry Boehm described the "spiral model" of development in 1986, and has been successfully used for nigh upon 30 years since under various monickers (and I'll bet there were practitioners before Boehm's paper).
"Agile" has matured and developed a lot of inter-related supporting practices and tools that have made it increasingly powerful and easy to implement. Continuous integration, test-driven development, use of "stories" as a tool for requirements definition, you cannot tell me these techniques and tools are not successful.
I have personally seen the development practices of a company dramatically transformed for the better by having an agile trainer brought in and training the entire staff, including managers, and instituting formal agile practices. It is great when a junior developer can tell the VP of marketing to take a hike because his request has not been submitted through the grooming and priority assignment process.
This one experience gives me complete confidence that people mocking agile simply do not know what they are talking about.
One problem agile does have is with zealots who don't understand that this is, and has to be, a collection of related practices that must be tailored to the needs of the environment, not a one-size-fits-all, all-or-nothing thing. Another problem is thinking that "form" is what is important, not "what is happening".
For example: holding stand-ups is not agile. It is a common, useful tool to use in an agile environment. If your team is coordinating with informal sessions as needed, Skype, chat tools, and an updated Wiki in real time, and the managers are keeping in the loop using these tools, then maybe a stand-up is a waste of time for you. I think most teams benefit, but design and planning is not part of a stand-up, other meetings are needed for these.
There can be long-term planning that does not follow the agile model, and can be described as water-fall, and this has its place too. But I think the only really successful development practices are variants of an "agile" type process.
And not because it has to be that way. The software is just poorly designed.
In an ideal world, user documentation would be written before the software so that an understandable, consistent, UI would exist. This sometimes happens, but even then, the implementation may not match the documentation (yes, I have seen this more than once).
Design principles like: simple things (and common tasks, even if not exactly simple) should be simple to do; the same technique should work in all contexts; etc. are often ignored in OS projects.
I have come to despair in trying to find a nice open source (Linux) object-drawing program that is intuitive (and thus easy to learn), has consistent behavior, and allows the quick creation of clean basic diagrams, and maybe has an additional level of finer controls for more precise work. The original Macintosh had this back in the 1980s with MacDraw, and the even more awesome MacDraw II. Complete novices could take the program and discover how to make good looking "boxologies" in minutes just by playing with the tools. Maybe such programs are still available on the Mac platform (I haven't had one in years), but no OS object drawing or 2D CAD program on Linux seems able to grasp what one of the first such pieces of software on the market was able to accomplish.
(Another really annoying thing to find in user documentation is self-praise about the product and accompanying documentation: making promises about how great the product is, and how wonderful the documentation you are looking at is, that are rarely kept.)
Videos have their place, I grant. Especially when it comes to manipulating some object (could be a graphical object on a screen), where a verbal description just cannot compete.
But I hate "video documentation" with an undying passion. They have an extremely so rate of information transfer, typically very low information density (see how little text is in a 5 minute video script), cannot be scanned at all, require you to have an audible audio hook-up, cannot be copied for notes,... I'm just getting started here, but you get the picture. I can literally take in information 10 times faster in printed form, and locate relevant content even faster than that.
If video documentation is available as optional back-up, great! But if that is the only documentation, I will not use whatever-the-heck-it-is, I'll find something else.
They need to refer the the pieces of hadoop. HDFS is the storage piece and many things can interface to it, it isn't great but is often good enough especially if you just have a couple local disks per node. YARN is the scheduler piece, it is mostly awful performance-wise but is fairly easy to use...long run it'll lose to something like mesos I think.
That's a good call. With Cloudera and HortonWorks both adding new components to the Hadoop stack it has exploded in the number of components in the last a year or two, and that can be a bad thing. The complexity of the whole ecosystem is getting horrendous, with a typical configuration file doubling from 250 or so to 500 configuration items, which are almost all undocumented (unless you read the code - which scarcely qualifies as "documented") in the last year. For a practical deployment you are pretty much forced to use a commercial stack to get something up and running in a manageable fashion. And then there is the fact that the HDFS foundation is showing its age.
MR is the map reduce piece that everyone thinks of when you say hadoop. Almost everything will run quicker in spark(still using a map/reduce methodology) than hadoop MR.
Spark on Mesos is looking mighty awesome.
As a side note, I don't know anyone who still writes MR jobs directly, they are all doing pig or hiveql.
MapReduce is still viable for stable production jobs, but not in a dynamic requirements environment.
Although HiveQL is alive and kicking, the complete replacement of Hive Server with Hive Server 2, while possibly an improvement in usability overall (I am not convinced), it trashes your skill investment in the (now) obsolete Hive stack component. Maybe I am just grousing, but I start having reservations about technology planning in the data center when a key stack component changes so much it a relatively short period of time
Brookings analyses have increasingly been up for sale. Not surprisingly it is taking up this pro-Microsoft, pro-Gates agenda after the Bill's foundation became their biggest contributor.
Durable generational trade agreements like GATT 1947 are formed from open discussions of mutual interest, and finding points where both/all sides can agree, or can at least agree to compromise.
Indeed, we are seeing the U.S. Crony Corporatist Capitalism reaching its highest level of development. Corporations now write out laws in secret - even from our elected representatives (despite the fact that they strictly vote the corporate lobbyist line anyway). And the clear intent here is that this will be presented as a fast track "deal" - no modification permitted, the corporation writ is final.
It should be remembered that "fast track" - secret trade deals with no modification allowed - only came into existence in 1974. It is one of the founding cornerstones of the crony capitalist edifice that has been built since 1970 - when worker wages stopped growing with economic growth as had been the historic norm, and a reasonable expectation by the American people.
A nice example of Poe's Law in action.
This could be a parody of the thinking of the corporatist shills, and apologists for out present plutocracy, except that the actual shills and apologists often say exactly the same thing, deaf to the ludicrousness of the messages they lip-synch with./p
No, no...you misunderstand me. I'm not saying there should be less government control, just that it's done algorithmically.
Think automated DMV processing, automated welfare distribution, automated parolee management, IRS collections/auditing, and so forth.
Of course, the inevitable argument against this is that too much trust is placed into the programmers hands. This is why it would all have to not just be open source, but clearly laid out and audited by many many programmers and non-programmers alike. Further, the algorithms should have built in mechanisms for refinement and improvement.
As a guy who loves designing algorithms, and is very good at it, I must say you put w-a-a-a-y too much faith in algorithms. Even "open source" algorithms. Consider the Federal Government's determinant sentencing rules (with the Orwellian misname of "guidelines"). They are viewed with almost uniform horror by the judges that must use them to calculate sentences, even by Conservative judges who would be most expected to approve of the often Draconian result. There is nothing secret about these sentencing algorithms. Prosecutors are able to trigger whatever "enhancements" they wish by placing claims in the indictment regardless of merit.
I've never heard of a projectile being aimed like that. Do you have examples of it being used elsewhere?
Yes, it is a technique that has been developed for maneuvering re-entry vehicles for ICBMs (MARVs). Here is a Russian page with an excerpt from an English source about it: "There are multiple ways for the designer to provide maneuverable capability in a re-entry vehicle, 1. ...moveable flaps which can provide one, two, or three degrees of freedom 2. ...Control can also be effected by moving a mass laterally in the vehicle to offset the vehicle’s center of gravity.The resulting mass asymmetry is equivalent to an aerodynamic asymmetry."
That $11 figure is all over the Internet, but a better, in-depth, source is this one "Business Ethics: Case Studies and Selected Readings" By Marianne Jennings. In it we read that: “Among the design changes that could have been made were side and cross members at $2.40 and $1.80 per car, respectively; a shock-absorbent “flak suit” to protect the tank at $4; a tank within a tank and placement of the tank over the axle at $5.08 to $5.79; a nylon bladder within the tank at $5.25 to $8; a placement of the tank over the axle surrounded with a protective barrier at $9.59; the imposition of a protective shield between the differential housing and the tank at $2.35; improvement of the bumper at $2.60; and the addition of eight inches of crush space at a cost of $6.40.”
All of these individual fixes are less than $11. I do not know which of these by themselves would have been sufficient, but the absence of pursuing any of them is probably what led to the jury verdict.
I admit to being pleasantly surprised by the actions that Wheeler is taking. I had been quite skeptical that someone so deeply tied to the two industries had not been completely captured.
(It is not never necessary to assume pay-for-play or some sort of soft corruption. People who work in an institution a long time typically adopt its points-of-view through familiarity and socialization if nothing else.)
Something can be uniform and fluctuating at the same time. All that's required is that the fluctuations follow the same, regular pattern everywhere. I have no idea whether this is true for the CMB, however.
It is true. Further, the fluctuations are tiny - at the parts per million level. It took 28 years after the CMB was discovered to detect any fluctations at all, requiring a sophisticated space probe (COBE) to do it.
Asserting that the CMB is "not uniform" because of these fluctuations is rather like saying the Bonneville Salt Flats are not really flat at all since the surface has millimeter scale irregularities, or your polished marble dining room floor isn't flat since it has micron sized irregularities.
...
I think it comes down to this: why there is a big cold spot in the CMB? Because there's a big void. Mystery solved!
Except there's still the mystery of why there is such a big void in the first place.
That is true, but it is a much lesser mystery. The previous record-holder was the Canes Venatici Supervoid at 1.3 billion light years, and an Eridanus Supervoid has been the preferred explanation for the Eridanus Cold Spot (or, humorously, CAOE: "Cosmic Axis Of Evil) for years ("parallel universe collisions" was always an exotic explanation), but the existence of such a supervoid had not been confirmed. Dr. István Szapudi of the Institute for Astronomy at the University of Hawaii at Manoa has has just announced findings that measures this supervoid at 1.8 billion light years. This is moderately bigger than the previous record-holder (40% wider), but there are quite a few that are 400-800 million light years across. This looks rather like a power law distribution, often found in nature.
The Canes Venatici Supervoid is closer as than the Eridanus Supervoid (red shift z=0.118 vs 0.22, or 1.5 vs 2.5 billion light years) as well as being smaller so there are two reasons for the Integrated Sachs-Wolfe Effect to be weaker, but apparently there is no anomalous cooling for that void at all. I would like to see someone address that.
The EU banned three neonicotinoids that are judged especially high risk for bees 17 months ago. If this is causing/contributing to colony collapse disorder, evidence should start settling this question over the next year or two I would think.