Oh, it quite likely is. Oracle doesn't like competition, and for SAP to have a database they can now tune to their products --- that's not something that will sit at all well with Oracle.
IBM has a virtual machine, mostly compiled from Sun's sources with some optimizations of their own. And, yes, I have facts to back my claims, and yes, I have used IBM's JVM (I use it in preference to the Sun/Oracle one when I can).
Easy. If Oracle owns all the names that the Pointy-Hair Bosses know about, Oracle rules the people with the money. Those who actually use the product? They have no say. Neither do any of the technical folk. So why would Oracle care about them?
However, it is a dangerous game to play. IBM tried the same trick in the 1970s and 80s. It nearly destroyed them when the playing-field shifted away from mainframes. It did destroy companies like Prime. Acorn tried the same stunt in the microcomputer field. They lasted a bit longer than the giants, but they're now only producing televisions, their PC division abandoned in the dirt.
Oracle will, eventually, fall the same way if they rely on destroying competition and propping up their brand name with buy-outs. The question is how much damage they will inflict on the markets in the meantime.
I would recommend Ingres (which is GPL) for the Data Warehouse environments, PostgreSQL for the mid-sized relational databases and Drizzle for the small-scale systems. (DO NOT support MySql as it is now an Oracle product -- support one of the official forks.)
Likewise, I would recommend using Libre Office (as soon as it hits a major release) over and above Oracle's OpenOffice.
For Java, I would recommend using IBM's JVM where possible (it's largely Oracle's but getting it from IBM will still kick dirt in Oracle's eyes). Where you're running a standalone Java application that can be compiled using GCJ, eliminate the JVM entirely and go native.
I strongly suspect you have left yourself crippled. Anyone who claims to be a long-time anything has failed to move forwards, has failed to adapt to the changing IT market. Nothing lasts forever and those who fail to keep up-to-date last no longer than the product they are fixed to. Oracle has moved forward. They support grid computing and clustered computing. These require a radically different mindset than those who grew up on monolithic client-server systems. Oracle will doubtless move forward again, exploiting cloud computing techniques. What use will they have for you then?
Consider this also - companies respect loyalty, but they rarely respect blind loyalty. Spying?! For chrissakes, this isn't the Cold War! Besides, why would these "spies" trust what Oracle said, when a debugger and Wireshark would yield far more? Besides, who would want to spy on Oracle? Their RAC database is impressive in that there are no other major databases that support Infiniband, but other than that their software is ancient, slow, archaic and uncompetitive. Oracle is a has-been. They were a decent company once. Twenty years ago. Today, they're losing ground. Their acquisition of Sun was expensive and has generated few returns.
As for a lot of information, Oracle doesn't know the meaning of the phrase. Their support site is frankly pathetic. Ingres is of the same era and used to hold many of the same attitudes, but they have matured and adapted to a new environment. Oracle have not. In evolution, those who adapt survive, those who do not die. Size is immaterial. Prime were big. Cray were big. SGI were big. Sun were big. Dinosaurs. And dinosaurs die.
This is high-stakes poker, with the winner claiming the cross-platform system as the prize. Yielding is getting dealt-in to the game.
If they play right, they can end up dumping Oracle, leaving Oracle in the dirt.
Or maybe the stakes are higher. Oracle and IBM are foes in many markets, and many of those markets now leverage Java. Whichever one is left controlling Java is also left controlling everything else.
To not yield (be dealt in), IBM would rapidly lose ground on its servlet engine (it would have no advance knowledge of how the specs are changing and no ability to ensure the specs benefit what they want to do). It could lose ground in the database arena (controlling the JDBC standard is valuable). And so on.
But if IBM gain control, by building a better Java on the sly and ensuring all the key systems use it at just the right time, then Oracle is in that boat. They now become the ones who lose control of servlets, JDBC, etc. That would wreck many of their key products.
This is a cut-throat business and these are two experts at throat-cutting rivals.
Perhaps, but in such an event Labour would still lose (Gordon Brown and Tony Blair are too fresh in people's minds), there's bugger-all chance the Liberal Democrats would win, which means that the Conservatives might actually secure an all-out victory.
Well, either that or they'll form a coalition with the Official Monster Raving Looney Party, who would likely win seats if it went to a general election right now.
Most of the extensions in C# were done better in D. And most aren't really necessary or useful. Now, this isn't to say I think Java is at the pinnacle of software engineering - it doesn't support a number of very nice features in "pure" OO, and there are "newer" concepts in Software Engineering (such as Templates, Aspects and Mobile Threads) that have no direct parallel. Obviously, some of these aren't getting used anywhere else either, so clearly they're not considered vital by anyone. At the moment, at least. In some respects, adding new concepts can be a bad thing, but it does mean that when those concepts are valuable, languages too rigid in their design won't be able to make efficient use of them. (C++ tries to include all kinds of new concepts, which is why it is so horribly complex. This is the price of being too fluid.)
"Better" is therefore hard to define. Better for what? The only real definition of "better" in any abstract sense is that the better language will be capable of evolving in the right direction at the right time without having too much baggage. And this can only ever be known in hindsight. Which is why Fortran is still useful in mathematics, even though it is a ghastly language -- it has evolved in ways mathematicians/engineers needed more than rival languages. In a battle of "survival of the fittest", it has survived and has thus demonstrated that it is fitter for some purposes. The usefulness of Fortran is utterly non-obvious and is only knowable because it exists.
In principle, on SMP/multi-core machines, Silk (an instruction-level parallel C), UPC and OpenMP-enabled C should have overwhelmed vanilla C by now. In practice, people just moved to better fork management, better threading libraries and better shared memory and used that to handle the parallelism. (The ATLAS maths library recently stopped developing its OpenMP support because it was inferior in practice.)
Not sure about the recission part, but they're definitely out to kill the competition. I fully expect the battle to get extremely bloody. Apple's sacrifice of their own Java implementation might well have been under duress, given this development.
It might be a good idea at this point to start looking at other languages. Since D is supposed to be "C# done right", it might be a language worth investigating. All you'd need is a portable virtual machine for it and you've a rival to Java that is (supposedly) superior to Java structurally. Tcl/Tk, Perl, Python and Ruby are already highly portable - although Perl largely shot itself in the foot with Perl 6 and Python did some serious self-inflicted damage with Python 3. Both should recover - after all, Python had just as much of a problem moving to Python 2 from the original form. Regardless, clearly there are potential competitors to Java if they can be mobilized.
If one or more of these can be embedded into multiple browsers (IE, Firefox, Chrome, Safari and Opera would be the obvious set and cover almost the entire browser market), Java would face some serious competition - at least at the browser end. Java applications and servlets would depend on whether the Java ABI was covered by the patents. If the ABI (in and of itself) is not IP-protected, then it would be possible to write virtual machines that run entirely differently than "native Java" VMs but which support Java objects. Bring GCJ up to Java 7 and have a backend to GCC that supports a portable virtual machine. You then have something that will handle existing Java bytecode and will allow a gradual weaking off of Java to any language GCC supports.
(Since IBM -is- permitted to contribute to GCC, this is another direction IBM might be looking into. Especially if they can get a Java bytecode frontend working for GCC. Java applications natively compiled to IBM's processors would be very appealing, especially if it didn't break any standards in the process.)
Oracle wants to reduce the competition and to "leverage" IBM's expertise. Once that expertise has fixed the issues with OpenJDK and Harmony has died, IBM becomes disposable to Oracle.
IBM is most unlikely to stop all work on Harmony, they're just not going to distribute it. Oracle's implementation of Java will suffer performance and reliability problems. IBM already has its own compiler (Jikes) and IBM already has a Java distribution. Once IBM has the certification toolkit, it can internally continue to develop Harmony and upgrade Jikes to v7 Java. Remember, this is just a repeat of IBM's experience with Microsoft regarding OS/2 - only Oracle hasn't the muscle of Microsoft. Once IBM is satisfied, they dump Oracle, release their Java as standard on all IBM hardware and, because they have better ties with Linux than Oracle, on many Linux distros, and they'll likely be able to convince the courts that they don't infringe on any patents because they are officially licensed to be able to use whatever the technology is.
Again, though, IBM won't want too much competition in the Open Source community. They can't rob Oracle of power over Java if they aren't the de-facto controllers of Java. For now, they'll be best of enemies. Going back to the OS/2 fiasco, they learned the hard way that in such partnerships the first one to dump the other will be the winner. The partner left in the dirt WILL be trampled over, no matter how much better their product might be technically. And IBM will want to be the winner in this. Mind you, so will Oracle. Oracle will also be familiar with this process and will want to pull a Microsoft, killing IBM's Java work, forcing IBM to either sacrifice all they've spent or to sell it to Oracle at bargain-basement prices.
That depends - if this is actually a tactic by the US to shake UK confidence, the British might try very hard to find the money somehow. The little surviving UK industry is heavily dependent on the US, giving the US significant leverage.
Also, bear in mind that even if the UK really can't get the money, the US DoD may well still try to intimidate the UK. I sincerely doubt the US defence contractors or the Pentagon are as concerned with a financially viable Britain as they are with improving their own balance sheets.
There's an unattended hydrogen bomb somewhere in a swamp in North Carolina, and enough unattended enriched plutonium in the Irish Sea to make several nukes.
Also, if you're testing a system you only need the missile to weigh the right amount. Nobody in their right minds would use a real warhead on a practice missile.
As for leaving a nuke unattended, remember that most navies are moving to stealth technology of one sort or another. There is no significant risk in leaving a missile that nobody can find in a stretch of ocean nobody would look in.
Besides, the point of a deterrant is not so that you would actually use such-and-such a system, but that your opponent knows you could.
That's because being an extraterrestrial zombie with the desire to eat human brains softened by Windows and marinated in Aero would likely reduce his popularity.
Since all you need is a sealed tube with the missile inside it, a sub could deposit such a device on the sea floor. The sub needn't be the actual launch platform. If the US has mastered the ability to do that, it would certainly shake things up some. Tracking subs (a major effort by most nations) suddenly gets a whole lot less effective if it doesn't have to be where the missile it launches is. Which would require the ability to communicate over a significant range underwater, which would itself shake things up.
Another consideration is that this might be a warning to Britain, rather than potentially hostile nations. Remember, Britain isn't upgrading its Trident missile system - something the US is very angry over. (The DoD was depending on that money to fund its fleet of luxury cruises.) Advertising new launch systems and/or new missiles at this precise moment may be intended to shake things up in the UK and persuade the British Government to find more money.
The technology wasn't acknowledged until a Congressman took a model kit of the Stealth Fighter onto the floor and demanded to know what the hell it was that the public could gawp at but Congress could not.
It wasn't that long ago since a silo's missiles were disabled due to a hardware failure at a single point. Single points of failure are Bad and suggest a poor design. If you've one poor design element, you may have others (such as a lack of failsafes). The odds of a sub or other launch site not having failsafes is low, but clearly not impossible given the design failures demonstrated in the silo incident. If you had a device that (a) could launch a missile, (b) wasn't fault-tolerant, and (c) had no failsafes, and that device then generated a suitable fault, you could see an accidental launch. The missile would not be primed and probably not targeted, but it would fire.
This sequence of events is extremely unlikely. But, then, so is a missile silo with no redundancy. For that matter, so is a stealth submarine beaching itself in Scotland, and that has happened too. Unlikely things happen, given enough time and enough opportunity. Only the actually impossible cannot happen.
Now that is very different. Not knowing why is indeed very interesting. The consequence of the misspellings depends on whether they ARE true misspellings versus data-driven modifications from non-encoding genetic material. If they are deliberate transforms, then to call them misspellings is flawed, since the spelling would then be precisely what the DNA coded for (when considering all other types of data). Likewise, when U is used in RNA, it is not considered a mis-spelling, even though that would not be the nucleotide in the DNA.
Now, there may well be consequences for non-encoded mis-spellings, and the consequences of those would be extremely interesting.
Well, no. The transcription cannot be faithful because there are more letters in RNA than in DNA. Even if you ignore that aspect, geneticists knew that there was a data-driven transform somewhere. Assuming that it is in point A rather than looking is not the hallmark of a scientist. That is the hallmark of the incompetent. Never, ever extrapolate further than the data will permit on the assumption that the extrapolation is valid. Extrapolation should only ever be done for the purpose of creating a hypothesis. Leave articles of faith to religion. On second thoughts, the religious tend to extrapolate beyond limits too, so that might not help.
Anyways, the fact is that there are only two possible places in which a transform could happen (and it could happen in both). This gives you a total of three possibilities. Now, only the DNA-to-RNA step could include information from the non-coding regions. It's possible that either stage could be effected by the epigenome. From this, it follows that two of the three cases involve the DNA-to-RNA step and two of the three methods involve the DNA-to-RNA step. It may be unexpected, in that they may not have considered that possibility sufficiently, but to call it a shock implies that they ignored the mechanisms entirely -- mechanisms the genetic scientists have been studying in depth for a very long time.
There are four letters in DNA, five letters in RNA. That tells me that something about not copying identically was indeed previously known. The protein encoding was also known for a fact - it wasn't just indicated, it was pretty much accepted by the genetics community as having been sufficiently gone over to be considered standard fare.
The question was WHERE the change happened - DNA to RNA, or RNA to protein? That wasn't established. Two possibilities, one (or both) could be possible. That gives two out of three outcomes in which the DNA to RNA conversion is not a carbon-copy but data-driven. Forgive me for being cynical, but finding out that an event with 2/3rds odds of happening actually happening is hardly "shocking". It might be interesting, it might be informative, it might be many things. But to call it "shocking" is absolutely insane.
We have known for many years that the same DNA codes to different proteins, with the adjustments given the information in the non-coding regions AND the information in the epigenome. That people have discovered that the intermediate step is also adjusted can hardly be called a shock. The proteins have to get built differently somehow, so some alteration in the intermediate coding was inevitable. Honestly! If geneticists aren't even reading their own bloody papers, maybe the government grants should be issued to those Slashdot readers who do.
HOTOL was dropped by Government orders and classified. If it were really that inefficient, I don't thing Maggie's minions would have gone to such lengths.
NASA's spaceplane designs in the 1990s followed essentially the same design and was abandoned through sharp funding cuts. NASA would have had access to BaE's work on HOTOL - if the design didn't work, they would not have followed the same approach.
HOTOL may well have had insurmountable technical problems. (The last time Britain tried to develop space technology was the Blue Streak rocket, which was an unmitigated disaster.) However, the manner of abandoning it indicates that there were political and/or economic concerns that went far beyond technical issues.
The Russian shuttle followed a similar plan to the original shuttle design, including the larger size. The best information anyone seems to have is that it would have been far more efficient, per unit mass of payload, than the American shuttle.
On the basis that the Russians had nothing like the advanced, lightweight materials available to the Americans, and that the Americans had vastly superior supercomputers for CFD work, the Americans should have been able to rival or better the Russian project.
What ended up happening is that by cutting back on development costs, we ended up with a launch system that actually had more dead-weight than the original shuttle design, less space for cargo and (because of the extra weight) less spare lifting capacity.
That saved money right there and then, but cost vastly more money in the longer-term.
NASA is investigating the use of turbine-assisted ramjets to do exactly what you're describing, and essentially what you are describing is what White Knight is for Space Ship 1. So it is being done and it is being discussed for much larger systems.
You are correct that the top altitude is 20km, but you must consider that rocket nozzles above a relatively small diameter become unstable (with a nasty propensity to explode), that you don't need to carry oxygen with you (which is bloody heavy) and that jets are much more fuel-efficient than rockets even if you do carry your own O2. (Rockets have a HORRIBLE level of efficiency.)
What you'd really want is a more-or-less horizontal launch using jets, ramping your way up to scramjets (which max out at about mach 20), slowly arcing upwards such that you hit top speed at the altitude jets would no longer be more effective than rockets.
The unit cost per launch would be lower for this, because whilst rockets do not work well at low altitude, jets do. And if you use the best fuel-to-speed conversion possible, you gain. The fact that it takes longer to reach a high altitude won't matter. All that matters is that you spend the least fuel before reaching escape velocity.
Sure, this doesn't seem "common-sensical", but you've got to consider that "common sense" in the 1930s was that rockets wouldn't work in space as there was nothing to push against. Rocket science isn't difficult, the only reason it has its reputation is because physics is not "common sense" and rockets make this more obvious than other fields.
Slashdot Mirror
Oh, it quite likely is. Oracle doesn't like competition, and for SAP to have a database they can now tune to their products --- that's not something that will sit at all well with Oracle.
IBM has a virtual machine, mostly compiled from Sun's sources with some optimizations of their own. And, yes, I have facts to back my claims, and yes, I have used IBM's JVM (I use it in preference to the Sun/Oracle one when I can).
Easy. If Oracle owns all the names that the Pointy-Hair Bosses know about, Oracle rules the people with the money. Those who actually use the product? They have no say. Neither do any of the technical folk. So why would Oracle care about them?
However, it is a dangerous game to play. IBM tried the same trick in the 1970s and 80s. It nearly destroyed them when the playing-field shifted away from mainframes. It did destroy companies like Prime. Acorn tried the same stunt in the microcomputer field. They lasted a bit longer than the giants, but they're now only producing televisions, their PC division abandoned in the dirt.
Oracle will, eventually, fall the same way if they rely on destroying competition and propping up their brand name with buy-outs. The question is how much damage they will inflict on the markets in the meantime.
I would recommend Ingres (which is GPL) for the Data Warehouse environments, PostgreSQL for the mid-sized relational databases and Drizzle for the small-scale systems. (DO NOT support MySql as it is now an Oracle product -- support one of the official forks.)
Likewise, I would recommend using Libre Office (as soon as it hits a major release) over and above Oracle's OpenOffice.
For Java, I would recommend using IBM's JVM where possible (it's largely Oracle's but getting it from IBM will still kick dirt in Oracle's eyes). Where you're running a standalone Java application that can be compiled using GCJ, eliminate the JVM entirely and go native.
I strongly suspect you have left yourself crippled. Anyone who claims to be a long-time anything has failed to move forwards, has failed to adapt to the changing IT market. Nothing lasts forever and those who fail to keep up-to-date last no longer than the product they are fixed to. Oracle has moved forward. They support grid computing and clustered computing. These require a radically different mindset than those who grew up on monolithic client-server systems. Oracle will doubtless move forward again, exploiting cloud computing techniques. What use will they have for you then?
Consider this also - companies respect loyalty, but they rarely respect blind loyalty. Spying?! For chrissakes, this isn't the Cold War! Besides, why would these "spies" trust what Oracle said, when a debugger and Wireshark would yield far more? Besides, who would want to spy on Oracle? Their RAC database is impressive in that there are no other major databases that support Infiniband, but other than that their software is ancient, slow, archaic and uncompetitive. Oracle is a has-been. They were a decent company once. Twenty years ago. Today, they're losing ground. Their acquisition of Sun was expensive and has generated few returns.
As for a lot of information, Oracle doesn't know the meaning of the phrase. Their support site is frankly pathetic. Ingres is of the same era and used to hold many of the same attitudes, but they have matured and adapted to a new environment. Oracle have not. In evolution, those who adapt survive, those who do not die. Size is immaterial. Prime were big. Cray were big. SGI were big. Sun were big. Dinosaurs. And dinosaurs die.
This is high-stakes poker, with the winner claiming the cross-platform system as the prize. Yielding is getting dealt-in to the game.
If they play right, they can end up dumping Oracle, leaving Oracle in the dirt.
Or maybe the stakes are higher. Oracle and IBM are foes in many markets, and many of those markets now leverage Java. Whichever one is left controlling Java is also left controlling everything else.
To not yield (be dealt in), IBM would rapidly lose ground on its servlet engine (it would have no advance knowledge of how the specs are changing and no ability to ensure the specs benefit what they want to do). It could lose ground in the database arena (controlling the JDBC standard is valuable). And so on.
But if IBM gain control, by building a better Java on the sly and ensuring all the key systems use it at just the right time, then Oracle is in that boat. They now become the ones who lose control of servlets, JDBC, etc. That would wreck many of their key products.
This is a cut-throat business and these are two experts at throat-cutting rivals.
Perhaps, but in such an event Labour would still lose (Gordon Brown and Tony Blair are too fresh in people's minds), there's bugger-all chance the Liberal Democrats would win, which means that the Conservatives might actually secure an all-out victory.
Well, either that or they'll form a coalition with the Official Monster Raving Looney Party, who would likely win seats if it went to a general election right now.
Most of the extensions in C# were done better in D. And most aren't really necessary or useful. Now, this isn't to say I think Java is at the pinnacle of software engineering - it doesn't support a number of very nice features in "pure" OO, and there are "newer" concepts in Software Engineering (such as Templates, Aspects and Mobile Threads) that have no direct parallel. Obviously, some of these aren't getting used anywhere else either, so clearly they're not considered vital by anyone. At the moment, at least. In some respects, adding new concepts can be a bad thing, but it does mean that when those concepts are valuable, languages too rigid in their design won't be able to make efficient use of them. (C++ tries to include all kinds of new concepts, which is why it is so horribly complex. This is the price of being too fluid.)
"Better" is therefore hard to define. Better for what? The only real definition of "better" in any abstract sense is that the better language will be capable of evolving in the right direction at the right time without having too much baggage. And this can only ever be known in hindsight. Which is why Fortran is still useful in mathematics, even though it is a ghastly language -- it has evolved in ways mathematicians/engineers needed more than rival languages. In a battle of "survival of the fittest", it has survived and has thus demonstrated that it is fitter for some purposes. The usefulness of Fortran is utterly non-obvious and is only knowable because it exists.
In principle, on SMP/multi-core machines, Silk (an instruction-level parallel C), UPC and OpenMP-enabled C should have overwhelmed vanilla C by now. In practice, people just moved to better fork management, better threading libraries and better shared memory and used that to handle the parallelism. (The ATLAS maths library recently stopped developing its OpenMP support because it was inferior in practice.)
Not sure about the recission part, but they're definitely out to kill the competition. I fully expect the battle to get extremely bloody. Apple's sacrifice of their own Java implementation might well have been under duress, given this development.
It might be a good idea at this point to start looking at other languages. Since D is supposed to be "C# done right", it might be a language worth investigating. All you'd need is a portable virtual machine for it and you've a rival to Java that is (supposedly) superior to Java structurally. Tcl/Tk, Perl, Python and Ruby are already highly portable - although Perl largely shot itself in the foot with Perl 6 and Python did some serious self-inflicted damage with Python 3. Both should recover - after all, Python had just as much of a problem moving to Python 2 from the original form. Regardless, clearly there are potential competitors to Java if they can be mobilized.
If one or more of these can be embedded into multiple browsers (IE, Firefox, Chrome, Safari and Opera would be the obvious set and cover almost the entire browser market), Java would face some serious competition - at least at the browser end. Java applications and servlets would depend on whether the Java ABI was covered by the patents. If the ABI (in and of itself) is not IP-protected, then it would be possible to write virtual machines that run entirely differently than "native Java" VMs but which support Java objects. Bring GCJ up to Java 7 and have a backend to GCC that supports a portable virtual machine. You then have something that will handle existing Java bytecode and will allow a gradual weaking off of Java to any language GCC supports.
(Since IBM -is- permitted to contribute to GCC, this is another direction IBM might be looking into. Especially if they can get a Java bytecode frontend working for GCC. Java applications natively compiled to IBM's processors would be very appealing, especially if it didn't break any standards in the process.)
Oracle wants to reduce the competition and to "leverage" IBM's expertise. Once that expertise has fixed the issues with OpenJDK and Harmony has died, IBM becomes disposable to Oracle.
IBM is most unlikely to stop all work on Harmony, they're just not going to distribute it. Oracle's implementation of Java will suffer performance and reliability problems. IBM already has its own compiler (Jikes) and IBM already has a Java distribution. Once IBM has the certification toolkit, it can internally continue to develop Harmony and upgrade Jikes to v7 Java. Remember, this is just a repeat of IBM's experience with Microsoft regarding OS/2 - only Oracle hasn't the muscle of Microsoft. Once IBM is satisfied, they dump Oracle, release their Java as standard on all IBM hardware and, because they have better ties with Linux than Oracle, on many Linux distros, and they'll likely be able to convince the courts that they don't infringe on any patents because they are officially licensed to be able to use whatever the technology is.
Again, though, IBM won't want too much competition in the Open Source community. They can't rob Oracle of power over Java if they aren't the de-facto controllers of Java. For now, they'll be best of enemies. Going back to the OS/2 fiasco, they learned the hard way that in such partnerships the first one to dump the other will be the winner. The partner left in the dirt WILL be trampled over, no matter how much better their product might be technically. And IBM will want to be the winner in this. Mind you, so will Oracle. Oracle will also be familiar with this process and will want to pull a Microsoft, killing IBM's Java work, forcing IBM to either sacrifice all they've spent or to sell it to Oracle at bargain-basement prices.
That depends - if this is actually a tactic by the US to shake UK confidence, the British might try very hard to find the money somehow. The little surviving UK industry is heavily dependent on the US, giving the US significant leverage.
Also, bear in mind that even if the UK really can't get the money, the US DoD may well still try to intimidate the UK. I sincerely doubt the US defence contractors or the Pentagon are as concerned with a financially viable Britain as they are with improving their own balance sheets.
There's an unattended hydrogen bomb somewhere in a swamp in North Carolina, and enough unattended enriched plutonium in the Irish Sea to make several nukes.
Also, if you're testing a system you only need the missile to weigh the right amount. Nobody in their right minds would use a real warhead on a practice missile.
As for leaving a nuke unattended, remember that most navies are moving to stealth technology of one sort or another. There is no significant risk in leaving a missile that nobody can find in a stretch of ocean nobody would look in.
Besides, the point of a deterrant is not so that you would actually use such-and-such a system, but that your opponent knows you could.
That's because being an extraterrestrial zombie with the desire to eat human brains softened by Windows and marinated in Aero would likely reduce his popularity.
Since all you need is a sealed tube with the missile inside it, a sub could deposit such a device on the sea floor. The sub needn't be the actual launch platform. If the US has mastered the ability to do that, it would certainly shake things up some. Tracking subs (a major effort by most nations) suddenly gets a whole lot less effective if it doesn't have to be where the missile it launches is. Which would require the ability to communicate over a significant range underwater, which would itself shake things up.
Another consideration is that this might be a warning to Britain, rather than potentially hostile nations. Remember, Britain isn't upgrading its Trident missile system - something the US is very angry over. (The DoD was depending on that money to fund its fleet of luxury cruises.) Advertising new launch systems and/or new missiles at this precise moment may be intended to shake things up in the UK and persuade the British Government to find more money.
The technology wasn't acknowledged until a Congressman took a model kit of the Stealth Fighter onto the floor and demanded to know what the hell it was that the public could gawp at but Congress could not.
It wasn't that long ago since a silo's missiles were disabled due to a hardware failure at a single point. Single points of failure are Bad and suggest a poor design. If you've one poor design element, you may have others (such as a lack of failsafes). The odds of a sub or other launch site not having failsafes is low, but clearly not impossible given the design failures demonstrated in the silo incident. If you had a device that (a) could launch a missile, (b) wasn't fault-tolerant, and (c) had no failsafes, and that device then generated a suitable fault, you could see an accidental launch. The missile would not be primed and probably not targeted, but it would fire.
This sequence of events is extremely unlikely. But, then, so is a missile silo with no redundancy. For that matter, so is a stealth submarine beaching itself in Scotland, and that has happened too. Unlikely things happen, given enough time and enough opportunity. Only the actually impossible cannot happen.
There are many, many twists to this sordid puzzle, but you are correct. The concept of a 1:1:1 translation has been dead for a very long time.
Now that is very different. Not knowing why is indeed very interesting. The consequence of the misspellings depends on whether they ARE true misspellings versus data-driven modifications from non-encoding genetic material. If they are deliberate transforms, then to call them misspellings is flawed, since the spelling would then be precisely what the DNA coded for (when considering all other types of data). Likewise, when U is used in RNA, it is not considered a mis-spelling, even though that would not be the nucleotide in the DNA.
Now, there may well be consequences for non-encoded mis-spellings, and the consequences of those would be extremely interesting.
This, really, is where the interest should be.
Well, no. The transcription cannot be faithful because there are more letters in RNA than in DNA. Even if you ignore that aspect, geneticists knew that there was a data-driven transform somewhere. Assuming that it is in point A rather than looking is not the hallmark of a scientist. That is the hallmark of the incompetent. Never, ever extrapolate further than the data will permit on the assumption that the extrapolation is valid. Extrapolation should only ever be done for the purpose of creating a hypothesis. Leave articles of faith to religion. On second thoughts, the religious tend to extrapolate beyond limits too, so that might not help.
Anyways, the fact is that there are only two possible places in which a transform could happen (and it could happen in both). This gives you a total of three possibilities. Now, only the DNA-to-RNA step could include information from the non-coding regions. It's possible that either stage could be effected by the epigenome. From this, it follows that two of the three cases involve the DNA-to-RNA step and two of the three methods involve the DNA-to-RNA step. It may be unexpected, in that they may not have considered that possibility sufficiently, but to call it a shock implies that they ignored the mechanisms entirely -- mechanisms the genetic scientists have been studying in depth for a very long time.
There are four letters in DNA, five letters in RNA. That tells me that something about not copying identically was indeed previously known. The protein encoding was also known for a fact - it wasn't just indicated, it was pretty much accepted by the genetics community as having been sufficiently gone over to be considered standard fare.
The question was WHERE the change happened - DNA to RNA, or RNA to protein? That wasn't established. Two possibilities, one (or both) could be possible. That gives two out of three outcomes in which the DNA to RNA conversion is not a carbon-copy but data-driven. Forgive me for being cynical, but finding out that an event with 2/3rds odds of happening actually happening is hardly "shocking". It might be interesting, it might be informative, it might be many things. But to call it "shocking" is absolutely insane.
You've got to bear in mind that researchers have only limited memory. They can't afford the 512Mb brain upgrade with all the funding cuts.
We have known for many years that the same DNA codes to different proteins, with the adjustments given the information in the non-coding regions AND the information in the epigenome. That people have discovered that the intermediate step is also adjusted can hardly be called a shock. The proteins have to get built differently somehow, so some alteration in the intermediate coding was inevitable. Honestly! If geneticists aren't even reading their own bloody papers, maybe the government grants should be issued to those Slashdot readers who do.
HOTOL was dropped by Government orders and classified. If it were really that inefficient, I don't thing Maggie's minions would have gone to such lengths.
NASA's spaceplane designs in the 1990s followed essentially the same design and was abandoned through sharp funding cuts. NASA would have had access to BaE's work on HOTOL - if the design didn't work, they would not have followed the same approach.
HOTOL may well have had insurmountable technical problems. (The last time Britain tried to develop space technology was the Blue Streak rocket, which was an unmitigated disaster.) However, the manner of abandoning it indicates that there were political and/or economic concerns that went far beyond technical issues.
The Russian shuttle followed a similar plan to the original shuttle design, including the larger size. The best information anyone seems to have is that it would have been far more efficient, per unit mass of payload, than the American shuttle.
On the basis that the Russians had nothing like the advanced, lightweight materials available to the Americans, and that the Americans had vastly superior supercomputers for CFD work, the Americans should have been able to rival or better the Russian project.
What ended up happening is that by cutting back on development costs, we ended up with a launch system that actually had more dead-weight than the original shuttle design, less space for cargo and (because of the extra weight) less spare lifting capacity.
That saved money right there and then, but cost vastly more money in the longer-term.
NASA is investigating the use of turbine-assisted ramjets to do exactly what you're describing, and essentially what you are describing is what White Knight is for Space Ship 1. So it is being done and it is being discussed for much larger systems.
You are correct that the top altitude is 20km, but you must consider that rocket nozzles above a relatively small diameter become unstable (with a nasty propensity to explode), that you don't need to carry oxygen with you (which is bloody heavy) and that jets are much more fuel-efficient than rockets even if you do carry your own O2. (Rockets have a HORRIBLE level of efficiency.)
What you'd really want is a more-or-less horizontal launch using jets, ramping your way up to scramjets (which max out at about mach 20), slowly arcing upwards such that you hit top speed at the altitude jets would no longer be more effective than rockets.
The unit cost per launch would be lower for this, because whilst rockets do not work well at low altitude, jets do. And if you use the best fuel-to-speed conversion possible, you gain. The fact that it takes longer to reach a high altitude won't matter. All that matters is that you spend the least fuel before reaching escape velocity.
Sure, this doesn't seem "common-sensical", but you've got to consider that "common sense" in the 1930s was that rockets wouldn't work in space as there was nothing to push against. Rocket science isn't difficult, the only reason it has its reputation is because physics is not "common sense" and rockets make this more obvious than other fields.
Witnesses' Waltz is a filk song commemorating the shuttle (and manned space flight in general).