Just wanted to clarify a point here: bt11 is not a "strain of corn" any more than OnStar is a model of car. The bt11 gene is integrated into thousands of varieties of corn, from tropical sweet corns to Canadian flints, just as the OnStar system is integrated into many different models and makes of vehicles. These varieties of corn are developed first, without the bt11 gene, and then the gene is later bred into the line in what most companies call the trait conversion process just as base trim levels of cars are developed, and then add-on systems like OnStar and stereo systems are tacked on later as features and options.

Any type of monoculture weakness that could have the kind of impact you're describing would have to be a result of the bt11 gene itself. This kind of thing has happened before in corn, though no case of that has (so far) been associated with GM traits (e.g., T-cytoplasm, which was used to facilitate hybrid production in many different varieties caused susceptibility to gray leaf spot).

In car analogy terms, what you're afraid of would be like the OnStar system itself causing engine problems in every type of vehicle with which it is integrated due to a flaw in the remote engine ignition feature. This is in contrast to a true monoculture situation, which would be like if everyone drove a ford pinto and we suddenly found our highways clogged with burnt exploded wrecks every time an accident occurred. The first situation is easy to fix--just buy the base model instead--whereas the second is trickier if all every manufacturer makes and knows how to design anymore is a pinto.

This is a common misconception. The technology exists to sterilize plants (both via genetic engineering and also through non-GM systems such as use of sterilizing cytoplasm), but to my knowledge there are no GM sterilization technologies used in products on the market today.

Farmers don't go back to purchase hybrid seed each year because they are forced to do so. There are non-GM foundation seed lines sold by smaller companies, as well as heirloom stocks maintained by universities and other private institutions. The reason is more that seed from GM seed companies like Monsanto, Pioneer Hi-Bred, and Syngenta is to publically available seed lines what Android is to OpenMoko. I say Android rather than iPhone because the PVPA (plant variety protection act--i.e., patents for plant varieties) allows the general public to use lines whose protections have expired, and the overall effect is somewhat analogous to how Google releases the source to Android on a periodic basis but controls current development.

People don't write that kind of stuff, it's still an issue from a VM design standpoint because in some cases code geneneration tools might. This can be frustrating and/or introduce extremely difficult-to-trace runtime bugs into your system if, for example, your framework du jour does runtime code generation/modification deep under the hood in order to implement AOP or a scripting language or something.

Based on my interactions with people from both groups, I gather that it mostly stems from the fact that the subjects of microscopic observations are, for most practical purposes, exclusive to a specific microscope--especially where dynamic (and sometimes interactive) systems or events are concerned. In the case of telescopes used for astronomy, they are all pointed at the same, largely static things. The data from major telescopes is often made widely available such that there is essentially no scientific value for anything other than the highest quality available data set.

In the astronomy world, one telescope's team could feasibly pull a douchebag maneuver like tracking the observations of another team's inferior telescope and essentially reducing the value of the second team's data to marginal at best, where this is impossible in the case of microscopes unless they are physically co-located. Because of this, the implication is that once a superior telescope comes on line, all lesser telescopes of its type only retain whatever value they have to the extent that the superior telescope's team suffers them to make exclusive observations. The fact that there is too much sky for any one (or really all telescopes in the world) to observe at any given time apparently isn't enough to stop the dick swinging that often goes on.

All of the above. Processor time is ridiculously cheap nowadays though (e.g., Amazon EC2 rates vary from cents to dollars per hour for the range from modest virtual machines to virtual compute clusters with serious horsepower).

Diet and 'lifestyle' of the beef does make a difference in taste, but not always a difference that people enjoy. Purely grass-fed beef, without being heavily spiced to cover the flavor differences, is an acquired taste.

My father is a cowboy, and they regularly get to select cattle to butcher as a bonus of sorts. These are 100% grass-fed open range (as in mountain range, no pasture pens, no feed supplements) cattle. Most people I know (including on occasion my dad!) prefer corn-fatted beef from Costco for steaks.

Open range beef has a 'gamey' flavor that adds greatly to stews, chilis, burgers, etc., but most people in my experience dislike it for steaks or other preparations that showcase the flavors of the meat.

Living in a free speech society and subsequently using that freedom to shout "fire!" in a crowded theater will likely result in either court precedence being established or legislation being enacted that places conditions upon that freedom. Legislation is supposed to be a practical embodiment of the ideals of society that is updated to reflect contemporary reality. Where absolute adherence to a pure ideal is deemed to be harmful, placing practical restrictions on that ideal is a reasonable reaction to expect (not saying that compromise with reality is right or wrong, just that you should expect it).

In the case of Wikileaks, the issue is that they've chosen to release not only information which is defensible from the perspective of providing useful insight and transparency, but also information which serves no value to the public and actually endangers lives to no apparent or intended positive end. The latter provides leverage and justification to craft and enact broad legislation that will be used in practice to suppress the former.

For example, if there was a group that provided pamphlets detailing the correlation between campaign donations and introduction and adoption of legislation, but also decided that in the pursuit of absolute truth and disclosure as an ideal they would stand in graveyards and hand out pamphlets of the bad credit history, extramarital affairs, missed child support payments, etc. of people interred there, you can expect action to restrict distribution of pamphlets justified by the latter but broad enough to suppress the former as an intended side-effect.

Abrams' argument is that Ellsberg did not distract from or endanger his intended cause by publishing harmful and irrelevant information that could be used as a basis to justify suppression. Due to his insistence on doing the latter, Assange is, from Abrams' perspective, making himself a useful idiot for the opposing side. His actions are likely to greatly harm the cause of government transparency and disclosure. From my perspective this is made blatantly obvious by the fact that media coverage is dominated by the topic of the fact of disclosure and likely reactions to the leak as opposed to the contents of the leak. In contrast, society and media reaction to the Pentagon Papers was focused intensely on the contents of the information disclosed.

When it comes to software like Flash, AfterEffects, Illustrator, etc., becoming an expert user of the application software is orders of magnitude harder than learning a new OS.

Also, if you use any of the aforementioned software packages professionally, the value of time and money spent learning the software and developing a productive workflow is far in excess of hardware and OS costs. This becomes especially true as you integrate custom application-specific scripts into your workflow and build up a library of project templates and other application-specific assets.

Tape over the gap has nothing to do with altering the frequency response of the antenna or anything like that, but for providing an insulating layer so that your hand/clothes/other foreign object that may come into contact with the phone at that point does not.

The involvement of auto_increment may be your culprit. As another poster mentioned on a thread above, InnoDB auto_increment is implemented as roughly 'select max(t.col) + 1 from table t' rather than using an actual SQL sequence. This could mean one of 2 things (not familiar enough with InnoDB's inner workings to know which it is): either A) the concurrent write transactions are getting the same value for the auto_increment field, causing problems if the field is the pkey or an otherwise unique index, or B) transaction 1 locks its rows, transaction 2 locks its rows, transaction 1 tries to grab the next val for an auto_index column and deadlocks because the auto_increment select needs to grab rows locked by transaction 2.

As I said, there are quirks :P.

That is a problem with MyISAM tables, which only do table-level locking. PostgreSQL will do row-level locking with concurrent write transactions, so you would only 'deadlock' if both transactions modified the same row.

If you'll be writing to the same tables with concurrent write transactions and you have to use MySQL, you should consider using InnoDB tables instead, which do allow row-level locking, but also come with their own quirks, so a bit of research is advised before committing to that solution.

For concurrent read and write transactions, PostgreSQL has Multi-Version Concurrency Control (MVCC), as do InnoDB tables, so there should theoretically be no locking of read-only transactions due to write transactions in progress. That being said, InnoDB MVCC will only work if all your tables are controlled by the InnoDB table handler, which, due to the quirks alluded to above (including severe performance penalties in some situations) may make that requirement a deal-breaker.

As always, you have to have a good understanding of both your application's requirements and the tools available in order to make the right decision.

Yes, they absolutely own the copyright if the terms of your employment make the software you write on the job a work for hire (almost certainly the case unless you have an explicit exception in your employment contract).

They also cannot legally violate the GPL, but they will not even if they keep the source unpublished as long as they provide the source code with any binary distribution to another party.

The key here is that the GPL does not force you to distribute the source unless you distribute the binaries--and even then, you only need to provide the source to the people to whom you distributed the binaries.

--Charles Babbage