That's what I remember 3M standing for. It has been quite a few years, after all. It might have been referring to 1 Mbit/sec LAN connections, instead: Ethernet was starting to show up around then, and Datapoint's ARCnet was available.
If you go back some 30-35 years, you find some HUGE mainframe installations, supporting dozens or hundreds of online users simultaneously.
Do a bit more research, and you find that those mainframe installations had processors that ran at clock rates somewhere between 1 and 20 MHz, with typically a few megabytes (equivalent) of RAM, and a few hundred megabytes of hard disk. (And a few tape drives, but the tapes were not really used that much, by comparison.)
As a convenient example, consider the Control Data 6600 supercomputer at UT Austin in 1970. The CPU clock was 10 MHz, and it had just 131,072 words of main core memory, at 60 bits/word (which works out to about 1 Megabyte). It had two disk subsystems, one of which stored 168 million characters, the other storing 241 million characters.
Compare this with a 486/33, with 4 megabytes of RAM, a 200 Mb and a 340 Mb hard drive. 4 times as much RAM, probably comparable CPU throughput (the 6600 CPU was a master of parallel execution: it could be running as many as 10 instructions simultaneously).
The 6600 was heavily time-shared.
Late in the 1970s, things started getting interesting. The magic point was called "3M", which stood for "1 MIP, 1 Megabyte, 1 million pixels", and the price on that was JUST BARELY within reach of an individual.
Now look today. Our LOW END personal computers come with HUNDREDS of megabytes of RAM, hundreds of MIPS, tens or hundreds of gigabytes of disk storage, and several million pixels. (The limit on pixels is what you can get onto a display and refresh at a reasonable rate.)
What limited these guys to "only" four users per PC wasn't processing power or video bandwidth. It was the number of PCI video cards they could physically stuff into a PC motherboard.
A few days ago, there was a thread on biodiesel, which waxed rhapsodic about dedicating ten thousand square miles of otherwise useless land to making ponds for growing algae, from which heavy raw oil could be extracted and refined into diesel fuel. (The question of waste disposal was not addressed.)
It would take considerably less than ten thousand square miles of otherwise useless land to hold a LOT of radioactive waste.
"Disposal" is actually easy: you mix the stuff with sand and heat, to make ceramics, and then you stack it in a well-marked "storage shed" somewhere. (It'll probably look more like the Astrodome, or a nuclear reactor confinement structure than an actual shed.)
On the one hand, we see no problem at all with dedicating 10,000 square miles of "otherwise economically useless land" to algae pools to produce oil (and waste material: recall that there is about 50% of that algae that is NOT oil).
On the other hand, we scream bloody murder at the idea of dedicating a few DOZEN square miles of that same "otherwise economically useless land" for building nuclear powerplants and waste storage facilities, even though the nuclear plants will deliver one hell of a lot more power than the algae will.
Granted, a lot of families COULD get along with something smaller than an SUV. The mileage that they have to drive is generally very inelastic, and is pretty much determined by distance between affordable housing and place of employment.
There was a pretty good piece in "USA Today" today about that problem. There are a lot of places in the US today where it is IMPOSSIBLE to find anything even remotely resembling affordable, acceptable housing anywhere near the workplace. In order to afford the roof over their heads, in a safe neighborhood, they have to live a long commute away, which turns into lots of miles driven. Further, for most of them, mass transit is not an option. The workplaces are too scattered. (There may be cheap housing nearby, but the neighborhood may well not be someplace you want your family living.)
In the cases where mass transit is an option, commuters from the high cost areas can quickly crowd the locals out of the housing market and bid the prices up.
As with anything, oversimplification causes problems. The standard examples for pills and oil are subject to those problems.
It is difficult to compare US and European transportation requirements, in part because of the other differences.
SUVs became popular in the United States when it became unlawful to sell passenger automobiles that do not meet the Corporate Average Fuel Economy (CAFE) standards. The customer requirement was for a mommy machine, capable of hauling the kids to soccer practice, the groceries home from the market, and the whole family to Aunt Suzie's place. You can't do that with a European-style economicrobox, and, at the time those rules went into effect, it was not technically feasible to build a full-size station wagon, at that time the standard mommy machine of choice, that could meet the standards. SUVs, being legally trucks, were and are not subject to the CAFE standards, and so, as the full-size station wagons died out, the SUVs took over their ecological niche. The problem with this is that the SUVs had to remain sufficiently truck-like that they do not fall under CAFE, which basically means BIG and HEAVY, and that's where your gas mileage problems come from.
Homework: Design a complete ambulance rig, including space for gurney, passenger, all necessary equipment, and oxygen, including communications, to fit inside a Nissan Altima.
Example: if your choice is take this pill every day, without fail, or die, you're going to take the pill, because if you don't take the pill, you die. If there are only so many people who need the pill, and only so many suppliers, it won't pay anyone any more to make more pills, so the existing suppliers just cruise along. When there are more people who need the pill than there are pills, you can get interesting economic effects.
Change "pill" to "food" in the above paragraph, and you get "wars" where it says "interesting economic effects".
If there are only the existing suppliers, and the existing customers are getting older, the suppliers have to find new customers or start losing money. Think "tobacco" and "RJ Reynolds".
When demand is elastic, so some people can go without the pills, but there are still more willing buyers than there are sellers, you get auctions, and the buyers with more quatloos bid the price up. In a free market, when the bid price gets high enough, other people notice that there is unsatisfied demand, and money to be made, and they start making more pills, and prices drop.
THIS IS FRESHMAN MACROECONOMICS, PEOPLE. GET A FSCKING CLUE!!!
OK, this is going to be a rant, and I'm going to lose some points for it.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE when it comes to BASIC SCIENCES: physics, chemistry, math?
Uranium mining is shaft mining, just like shaft mining for almost any other material: coal, minerals, metal ores, diamonds, you name it. The costs are similar, except that uranium miners don't get black lung disease.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about the laws of thermodynamics?
1. You can't get something for nothing. 2. You can't break even. 3. You can't quit the game.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about Carnot's work on engine efficiency? THIS IS FRESHMAN PHYSICS, PEOPLE. Wind and wave run off of very low temperature differentials, which NECESSARILY means that they CAN'T provide a whole lot of energy?
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about the fact that there are days when the wind don't blow and the sun don't shine? What the fsck do they want to use for power generation on those days? Or do they just believe Man should take a vacation, and civilization should stop, on rainy days or at night? Explain that to the guy whose wife is in intensive care, on a ventilator, that HAS to run 24 hours a day, WITHOUT FAIL.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about the implications of integral calculus? Plant oils are limited in energy content by the fact that they are essentially solar energy collectors, that integrate the solar energy that falls on them over their lifetime. This makes them subject to the same 1.3 kW/m^2 limit that controls EVERY solar technology, and they are also affected by the chemical energy conversion losses.
Fossil fuels are the same, but they integrated for a lot of years, before they were harvested (mined, drilled).
Nuclear fuels had the advantage of being formed in a VERY high-energy environment (the core of the earlier stars, natural fusion reactors) and hence contain VERY high stored energies compared to fossil or plant fuels.
Wind and wave are pumped by the sun. (DUH.) 1.3 km/m^2. Make that your mantra. I think I may have some T-shirts made if I go back to school again. Put that on the front, and the three laws on the back.
THIS IS *ALL* FRESHMAN STUFF, PEOPLE. IF YOU DIDN'T LEARN THIS IN SCHOOL, SHUT THE FSCK UP UNTIL YOU HAVE DONE YOUR FSCKING HOMEWORK!!!
The statement AS YOU POSTED IT is *STILL* factually incorrect, although you have to go back a few more years.
In 1982 or 1983, Don Good's group at UT Austin delivered the Message Flow Modulator to the United States Navy, for acceptance testing at Patuxent River Naval Air Station. This was a relatively small piece of code, running in (as I recall) an LSI-11.
The acceptance test suite was developed by a different company. No one in Don's group saw the acceptance test suite before the official test at PAX River, and (obviously) there had not been any "dry runs".
They passed, on the first try, with no exceptions, no deviations, no waivers, no "yeah but", no NOTHING. They passed.
This had NEVER happened before in military computing, on ANY project, of ANY size, large or small, from ANY contractor, EVER. As far as I know, it had never happened before on any civilian projects, either.
Read the paragraph again. There were NO bugs in that code. There were NO surprises. THERE WERE NO HOLES.
Now the punchline. They were working in a language called Gypsy, which was derived from PASCAL, but had certain things removed, and a lot of specification constructs added, that made it quite a bit like SPARK. Gypsy did have tasking, with special buffers between tasks (and no global variables at all), but I don't think the MFM used tasking for anything. Gypsy did not have dynamic memory allocation or function side-effects; I don't recall whether it had recursion. (I tend to doubt it, since recursion implies dynamic memory allocation "under the hood".) The whole point of the Gypsy feature set was that the features were ONLY those for which proof rules were known.
Now, we come to the crux of the matter. To paraphrase Gerald Weinberg, I can get wonderful programmer productivity, in any language you like, if the resulting program doesn't have to be correct. If you are willing to tolerate random bugs and random security holes and random system crashes, possibly resulting in random loss of human life, then there is no reason to go to something rigorous. If, however, the program must be correct, must not contain random bugs, must not crash at random moments, must not spray lethal doses of radiation into randomly-chosen therapy patients, then there does exist concrete evidence to suggest that those freedoms and powerful features are both unnecessary and dangerous.
The first problem is that nobody has any really convincing evidence that, all other things being equal (testing, design methods, skill of people involved, time/money available), SPARK or similiarly restricted languages actually gets you any meaningful improvment in security as compared to, say, Pascal, Ada95, C++, Java, O'Caml, or a similiarly "full of pointy bits" language.
I'm sorry, but that statement is factually incorrect.
Pratt & Whitney collected metrics on jet engine controller software development, over multiple projects, over a period of ten years. The military controllers were all in Ada, the civilian engine controllers were in various things, with C/C++ heavily represented. The team capabilities were about equal across the board. After they crunched the data down, they discovered that Ada was giving them twice the programmer productivity and 1/4 the defect density.
They now do ALL of their jet engine controller software in Ada.
There have been a number of other studies and experiments, and they ALL have yielded similar kinds of results. In theory, language shouldn't matter, but in practice, it does.
Why do people think of weaponry as the first use for a new method of power?
Step One is triggerable release of disordered energy (heat and noise) from a new source by whatever means.
Steps Two through N are learning to control it in various ways: maximizing the yield, tuning the yield, controlling the timing of the effect, using it in cascade with other things. Compare for example the incandescent light bulb, which gives most of its output in infrared, with fluorescent lights, light-emitting diodes. Compare the original ruby lasers with the various gas lasers and the modern laser diodes. Consider fission, fusion, and the more recent work in laser-triggered fusion with inertial confinement from all the lasers hitting from all sides.
The first step is ALWAYS making it go boom. Then you learn how to control the boom.
The original Little Boy and Fat Man devices were large, heavy, and very inefficient, compared to weapons with similar explosive yields today.
If you want an extreme example: black powder was originally developed as an explosive. That very same black powder is still in use today, powering small model rocket engines. All it takes is proper design and packing to control the combustion.
Thirty-some years ago, Arthur Haley (sp?) wrote "Airport". In it, one of his characters said something incredibly simple. It is, he said, simply not possible to tiptoe a quarter of a million pounds of machine anywhere.
That was when the Boeing 707 was still pretty close to the state of the art. Modern transports are anywhere from that size to three times that size, and are actually much quieter. A LOT has been learned in thirty years about building quiet airplanes.
You want to hear a loud airplane, try living under the pattern at a SAC base, listening to BUFFs taking off and landing. Been there, done that, and I'd do it again. Think of it as the sound of freedom.
Take a longer look at those Japanese bullet trains. The train companies put an army of track maintenance workers out there, every night, to recondition the tracks from the wear and tear that the trains put on them every day.
Take a longer look at the human environment in which those trains operate. Japan has incredibly high population densities compared to the overwhelming majority of the United States. Without those incredibly high densities, mass transit, of any kind, doesn't work. (About the only exception is Manhattan Island. No, thanks.)
Japan put that airport on the water because there wasn't ANY land available for a new airport. This is part of their population density problem.
The problem with "renewable" sources is that they are all inherently unsuitable for baseline supply.
Bluntly, you get days when the wind don't blow and the sun don't shine.
Even on days when the wind does blow, you are inherently looking at very low conversion efficiencies. (Fundamental thermodynamics, worked out by a fellow named Carnot, quite a few years ago.)
On days when the sun DOES shine, you are STILL limited to about 1.3 kW/sq meter absolute maximum. Photovoltaic conversion runs, last I heard, about 16% efficient, so you are looking at less than 300 W/sq meter of array. Start adding up what you need to replace a nuke plant, and start thinking about the Environmental Impact Statement you are going to have to file to cover that land in solar arrays. Don't forget your battery plant, to cover the nighttime demand, and don't forget the arrays that charge the batteries during the day while the other arrays are supplying the immediate demand.
As for wave power: A quick look at a map of the United States will show you, for example, that you aren't going to build very many wave power generators in, say, Arizona or New Mexico.
When you do the full-up analysis, you are led rapidly to the conclusion that there just aren't any silver bullets. If you are serious about generating electricity - and I really want to see how you explain to the voters that you can't run the hospital ICU 24x7 because you only have power when the sun shines and the wind blows - and you are serious about safety, then the inescapable conclusion is that negative void coefficient pressurized water reactors are the only way to fly.
The truth is that the better designs of forty years ago could have made safe nuclear power. The CANDU heavy water system is genuinely fail-safe. The coolant doubles as the moderator. That means if you loose one you loose the other and the reaction is halted.
The statement "(t)he coolant doubles as the moderator" is also true of American light-water designs.
The truth is that modern techniques could probably make nuclear power an extremely safe alternative.
What do you mean "could"?
In terms of lives lost, damage done, or just about any other measure you care to name, provided you restrict yourself to a competent design, nuclear fission is ALREADY the safest power generation technology known to man. Read "The Health Hazards of NOT Going Nuclear" by Dr. Petr Beckmann.
The key phrase in that sentence is "competent design." One of the key parameters in any nuclear reactor design is the void coefficient, and, most particularly, the sign of the void coefficient.
From http://www.nrc.gov/reading-rm/basic-ref/glossary/v oid-coefficient-of-reactivity.html "Void coefficient of reactivity: A rate of change in the reactivity of a water reactor system resulting from a formation of steam bubbles as the power level and temperature increase."
From http://www.disenchanted.com/dis/lookup.html?node=1 748 "The 'voids' refer to pockets of steam forming in the reactor core, and a reactor is said to have a positive void coefficient if an increase in voids leads to an increase in reactor power. A reactor with a negative void coefficient is one which will see a decrease in reactor power as pockets of steam increase."
Briefly, if a reactor is designed with a positive void coefficient, it will inherently have a risk of a Chernobyl-style thermal runaway. If a reactor is designed with a negative void coefficient, it will not have that particular hazard. This fact was known to the Soviet reactor designers, who designed the RBMK reactor at Chernobyl (among other places), and was also known the US designers who wrote the US standards for reactor design. Positive void coefficient designs are flat-out illegal in the United States.
To do the safety analysis, you have to take, for example, black lung deaths of coal miners into account, and supertanker oil spill environmental damage. You also have to take into account the number of people who will, while attempting to install solar water heating panels on their roofs, will slip, fall, and break their necks.
If you want to prattle about radiation hazards, bear in mind that every lump of coal you burn, every drop of oil, every cubic foot of natural gas, contains some amount of radioactive carbon-14, and the ash (and emitted CO2) is thus radioactive waste. Ditto for wood. (Wood smoke contains other nasty things.)
Hungarian notation was originally developed as a band-aid (tm) for the near-complete lack of type checking in C. When all ints are created equal, and may be freely assigned to each other, and pointers must routinely be type-coerced to something else, and the compiler refuses to help the programmer keep things straight, something like Hungarian notation becomes necessary.
Hungarian notation declined after Stroustrup added strong typing to C++. It is worth noting that Stroustrup never even considered NOT doing strong typing in C++. (Read his book on the design and evolution of C++.) Distaste on the part of hard-line C programmers for strong typing also declined, after C++ forced them to eat their broccoli, and they discovered it actually tasted pretty good (by catching errors that would otherwise not have been found nearly as easily).
It is also worth noting that Hungarian notation never caught on in any language other than C. In particular, Ada programmers never bothered with it: the Ada type system was rich enough that it could do everything that Hungarian notation pretended to do, and enforce it, by requiring compilers to refuse to compile type-incorrect programs.
(Somewhere, recently, I saw something about a commercial satellite project that was forced to use Ada, because there was no C/C++ compiler available for a recently-declassified microprocessor. Their programmers screamed bloody murder at the idea. The screams stopped when they noticed that the Ada compiler was catching errors for them.)
Back in college I would defend C/C++ against one of my professors who thought it was the spawn of satan (and oddly though Pascal was/is the greatest language ever) for the simple fact that it gives you the ability to do so many things with few limits.
If we ignore for the sake of argument the specific "high-level assembler" design goal for C, and look instead at philosophy which was carried into C++, there was this fundamental hacking philosophy that said that, because you occasionally needed to do something a bit bizarre, it should be EASY to do that bizarre thing. Further, the entire C/C++ philosophy was that the programmer was solely responsible for the consequences of his actions.
We contrast this with Ada. Ada's philosophy was that you only occasionally need to do bizarre things, that 95-99% of the time, you are doing perfectly straightforward things, that the effort should be distributed accordingly, and that the language should be helping the programmer to do the routine things correctly. This implies that, when the programmer attempts to do something bizarre, 95-99% of the time it is because he screwed something up, and he DIDN'T mean to do what he typed, and the compiler barfs.
At that point, it becomes the programmer's responsibility to tell the compiler, and NOT INCIDENTALLY everyone who will ever do maintenance on his code, that "Yea verily I DID intend to shoot myself in the foot here!". Idioms are provided for doing that. If the programmer really intended to take that floating-point number and treat it as a bitmask, he has to tell the compiler that this was indeed his intention.
Ada did not provide a "back door" array reference mechanism comparable to the C/C++ pointer hacking, for the reason that it is impossible to do proper bounds checking in that case. Ada does provide a mechanism for suppressing bounds checking, but it is NOT the default and it is explicitly forbidden by the standard from it being the default in any conforming implementation. If the programmer has a good reason for suppressing bounds checking, he has to do it EXPLICITLY, at some level.
Your analogy with hammers is OK, but it breaks down with guns. Guns have trigger guards and safety catches, PRECISELY to prevent naive users from shooting themselves in the foot, or from shooting someone else that they didn't intend to shoot. At the same time, those safety mechanisms do not prevent the gun from being used to shoot someone that the user most fervently WANTS shot right then.
In my view, if I utter a sequence of instructions that will dance a fandango on core, it is almost certainly the case that I have made an error, and I would prefer the toolset to ask me "Are you sure? (Y/N)". If I am certain that I intended to dance that fandango, I am also certain I want to warn the next guy in line that I am now lacing up my dancing wafflestompers, and the language should support that.
If it's not a requirement then it doesn't need to be in the license. They could GPL it and still request that everyone please sign up.
They want the software to get the widest possible distribution. That means secondary distribution, from places like tucows and universities. Expecting all of them to carry a "By the way, please register this with NASA" notice is probably unrealistic.
So the notice has to go with the Subject Software.
The catch here is that most humans don't read binary code, so the request has to be in a human-readable text file. The only such file that is required to be carried, unmodified, is the License. THAT'S why they put the signup request in the license.
The reason that they don't what to use the GPL is because they want every recipient to register with NASA that they have recieved the software. A more onerous condition I have trouble imagining and I sincerely hope that this license is never blessed as an open source license[though it is a step in the right direction].
Not so. Here is the relevant language from the proposed license.
F. In an effort to track usage and maintain accurate records of the Subject Software, each Recipient, upon receipt of the Subject Software, is requested to register with NASA by visiting the following website: ______________________________. Recipient's name and personal information shall be used for statistical purposes only. Once a Recipient makes a Modification available, it is requested that the Recipient inform NASA at the web site provided above how to access the Modification.
[Alternative paragraph for use when a web site for release and monitoring of subject software will not be supported by releasing project or Center] In an effort to track usage and maintain accurate records of the Subject Software, each Recipient, upon receipt of the Subject Software, is requested to provide NASA, by e-mail to the NASA Point of Contact listed in clause 5.F., the following information: ______________________________. Recipient's name and personal information shall be used for statistical purposes only. Once a Recipient makes a Modification available, it is requested that the Recipient inform NASA, by e-mail to the NASA Point of Contact listed in clause 5.F., how to access the Modification.
The key phrase in the language is "is requested to".
NASA is, among other things, a government agency. They do understand legalese. Had they intended to state a requirement, that phrase would have been the single word "shall".
"Shall" is a term of art in government specifications and legalese. It is used to state a requirement, and for no other purpose. (The standard tactic in defense firms for finding actual requirements in specifications is to do a text search for "shall".)
I saw an article in Av Leak several years ago. The Navy worked a project with NASA, to put an F/A-18 cockpit and sim gimbal out on the end of the old man-rated centrifuge, specifically to be able to evaluate pilots under g-forces.
The pilots recommended in the strongest possible terms that the Navy pursue the project as a training system.
The x86 architecture is obsolete, and has been obsolete for many years. Intel has been frantically propping it up with every trick they could think of, and they are running out of tricks, slowly but surely.
Eventually, Intel (and Microsoft) will be forced to throw in the towel, bite the bullet, and design a NEW processor, hopefully with a decent number of registers and a sane(r) architecture, that will have some room left to grow.
The original statement contained excerpts from the 1967 Outer Space treaty and the 1979 Moon treaty.
You are correct; the United States did ratify the 1967 Outer Space treaty. My bad.
However, the 1979 Moon treaty is a very different matter. Out of some 180 nations, only six ratified that one. NONE of the spacefaring nations at the time ratified it, and I believe that none of the nations that DID ratify it have come anywhere close to achieving space flight.
In order for a treaty to be binding, it must both be signed by the President *AND* be ratified by the Senate.
My recollection is that the Senate explicitly refused to ratify that treaty, after the L-5 Society organized a serious telephone campaign to defeat it. A large number of Senators heard from the Folks Back Home that this treaty was a Bad Thing and that the Folks Back Home were strongly opposed to it.
So when DID the Senate ratify the UN Outer Space Treaty?
Slashdot Mirror
That's what I remember 3M standing for. It has been quite a few years, after all. It might have been referring to 1 Mbit/sec LAN connections, instead: Ethernet was starting to show up around then, and Datapoint's ARCnet was available.
If you go back some 30-35 years, you find some HUGE mainframe installations, supporting dozens or hundreds of online users simultaneously.
Do a bit more research, and you find that those mainframe installations had processors that ran at clock rates somewhere between 1 and 20 MHz, with typically a few megabytes (equivalent) of RAM, and a few hundred megabytes of hard disk. (And a few tape drives, but the tapes were not really used that much, by comparison.)
As a convenient example, consider the Control Data 6600 supercomputer at UT Austin in 1970. The CPU clock was 10 MHz, and it had just 131,072 words of main core memory, at 60 bits/word (which works out to about 1 Megabyte). It had two disk subsystems, one of which stored 168 million characters, the other storing 241 million characters.
Compare this with a 486/33, with 4 megabytes of RAM, a 200 Mb and a 340 Mb hard drive. 4 times as much RAM, probably comparable CPU throughput (the 6600 CPU was a master of parallel execution: it could be running as many as 10 instructions simultaneously).
The 6600 was heavily time-shared.
Late in the 1970s, things started getting interesting. The magic point was called "3M", which stood for "1 MIP, 1 Megabyte, 1 million pixels", and the price on that was JUST BARELY within reach of an individual.
Now look today. Our LOW END personal computers come with HUNDREDS of megabytes of RAM, hundreds of MIPS, tens or hundreds of gigabytes of disk storage, and several million pixels. (The limit on pixels is what you can get onto a display and refresh at a reasonable rate.)
What limited these guys to "only" four users per PC wasn't processing power or video bandwidth. It was the number of PCI video cards they could physically stuff into a PC motherboard.
A few days ago, there was a thread on biodiesel, which waxed rhapsodic about dedicating ten thousand square miles of otherwise useless land to making ponds for growing algae, from which heavy raw oil could be extracted and refined into diesel fuel. (The question of waste disposal was not addressed.)
It would take considerably less than ten thousand square miles of otherwise useless land to hold a LOT of radioactive waste.
"Disposal" is actually easy: you mix the stuff with sand and heat, to make ceramics, and then you stack it in a well-marked "storage shed" somewhere. (It'll probably look more like the Astrodome, or a nuclear reactor confinement structure than an actual shed.)
How interesting it is to see the waffling.
On the one hand, we see no problem at all with dedicating 10,000 square miles of "otherwise economically useless land" to algae pools to produce oil (and waste material: recall that there is about 50% of that algae that is NOT oil).
On the other hand, we scream bloody murder at the idea of dedicating a few DOZEN square miles of that same "otherwise economically useless land" for building nuclear powerplants and waste storage facilities, even though the nuclear plants will deliver one hell of a lot more power than the algae will.
Granted, a lot of families COULD get along with something smaller than an SUV. The mileage that they have to drive is generally very inelastic, and is pretty much determined by distance between affordable housing and place of employment.
There was a pretty good piece in "USA Today" today about that problem. There are a lot of places in the US today where it is IMPOSSIBLE to find anything even remotely resembling affordable, acceptable housing anywhere near the workplace. In order to afford the roof over their heads, in a safe neighborhood, they have to live a long commute away, which turns into lots of miles driven. Further, for most of them, mass transit is not an option. The workplaces are too scattered. (There may be cheap housing nearby, but the neighborhood may well not be someplace you want your family living.)
In the cases where mass transit is an option, commuters from the high cost areas can quickly crowd the locals out of the housing market and bid the prices up.
As with anything, oversimplification causes problems. The standard examples for pills and oil are subject to those problems.
It is difficult to compare US and European transportation requirements, in part because of the other differences.
SUVs became popular in the United States when it became unlawful to sell passenger automobiles that do not meet the Corporate Average Fuel Economy (CAFE) standards. The customer requirement was for a mommy machine, capable of hauling the kids to soccer practice, the groceries home from the market, and the whole family to Aunt Suzie's place. You can't do that with a European-style economicrobox, and, at the time those rules went into effect, it was not technically feasible to build a full-size station wagon, at that time the standard mommy machine of choice, that could meet the standards. SUVs, being legally trucks, were and are not subject to the CAFE standards, and so, as the full-size station wagons died out, the SUVs took over their ecological niche. The problem with this is that the SUVs had to remain sufficiently truck-like that they do not fall under CAFE, which basically means BIG and HEAVY, and that's where your gas mileage problems come from.
Homework: Design a complete ambulance rig, including space for gurney, passenger, all necessary equipment, and oxygen, including communications, to fit inside a Nissan Altima.
Supply and demand only works for elastic demand.
If the demand is inelastic, it doesn't work.
Example: if your choice is take this pill every day, without fail, or die, you're going to take the pill, because if you don't take the pill, you die. If there are only so many people who need the pill, and only so many suppliers, it won't pay anyone any more to make more pills, so the existing suppliers just cruise along. When there are more people who need the pill than there are pills, you can get interesting economic effects.
Change "pill" to "food" in the above paragraph, and you get "wars" where it says "interesting economic effects".
If there are only the existing suppliers, and the existing customers are getting older, the suppliers have to find new customers or start losing money. Think "tobacco" and "RJ Reynolds".
When demand is elastic, so some people can go without the pills, but there are still more willing buyers than there are sellers, you get auctions, and the buyers with more quatloos bid the price up. In a free market, when the bid price gets high enough, other people notice that there is unsatisfied demand, and money to be made, and they start making more pills, and prices drop.
THIS IS FRESHMAN MACROECONOMICS, PEOPLE. GET A FSCKING CLUE!!!
OK, this is going to be a rant, and I'm going to lose some points for it.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE when it comes to BASIC SCIENCES: physics, chemistry, math?
Uranium mining is shaft mining, just like shaft mining for almost any other material: coal, minerals, metal ores, diamonds, you name it. The costs are similar, except that uranium miners don't get black lung disease.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about the laws of thermodynamics?
1. You can't get something for nothing.
2. You can't break even.
3. You can't quit the game.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about Carnot's work on engine efficiency? THIS IS FRESHMAN PHYSICS, PEOPLE. Wind and wave run off of very low temperature differentials, which NECESSARILY means that they CAN'T provide a whole lot of energy?
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about the fact that there are days when the wind don't blow and the sun don't shine? What the fsck do they want to use for power generation on those days? Or do they just believe Man should take a vacation, and civilization should stop, on rainy days or at night? Explain that to the guy whose wife is in intensive care, on a ventilator, that HAS to run 24 hours a day, WITHOUT FAIL.
Why the fsck is it that allegedly-educated people HAVE NO FSCKING CLUE about the implications of integral calculus? Plant oils are limited in energy content by the fact that they are essentially solar energy collectors, that integrate the solar energy that falls on them over their lifetime. This makes them subject to the same 1.3 kW/m^2 limit that controls EVERY solar technology, and they are also affected by the chemical energy conversion losses.
Fossil fuels are the same, but they integrated for a lot of years, before they were harvested (mined, drilled).
Nuclear fuels had the advantage of being formed in a VERY high-energy environment (the core of the earlier stars, natural fusion reactors) and hence contain VERY high stored energies compared to fossil or plant fuels.
Wind and wave are pumped by the sun. (DUH.) 1.3 km/m^2. Make that your mantra. I think I may have some T-shirts made if I go back to school again. Put that on the front, and the three laws on the back.
THIS IS *ALL* FRESHMAN STUFF, PEOPLE. IF YOU DIDN'T LEARN THIS IN SCHOOL, SHUT THE FSCK UP UNTIL YOU HAVE DONE YOUR FSCKING HOMEWORK!!!
OK, I see your argument a bit more clearly now.
The statement AS YOU POSTED IT is *STILL* factually incorrect, although you have to go back a few more years.
In 1982 or 1983, Don Good's group at UT Austin delivered the Message Flow Modulator to the United States Navy, for acceptance testing at Patuxent River Naval Air Station. This was a relatively small piece of code, running in (as I recall) an LSI-11.
The acceptance test suite was developed by a different company. No one in Don's group saw the acceptance test suite before the official test at PAX River, and (obviously) there had not been any "dry runs".
They passed, on the first try, with no exceptions, no deviations, no waivers, no "yeah but", no NOTHING. They passed.
This had NEVER happened before in military computing, on ANY project, of ANY size, large or small, from ANY contractor, EVER. As far as I know, it had never happened before on any civilian projects, either.
Read the paragraph again. There were NO bugs in that code. There were NO surprises. THERE WERE NO HOLES.
Now the punchline. They were working in a language called Gypsy, which was derived from PASCAL, but had certain things removed, and a lot of specification constructs added, that made it quite a bit like SPARK. Gypsy did have tasking, with special buffers between tasks (and no global variables at all), but I don't think the MFM used tasking for anything. Gypsy did not have dynamic memory allocation or function side-effects; I don't recall whether it had recursion. (I tend to doubt it, since recursion implies dynamic memory allocation "under the hood".) The whole point of the Gypsy feature set was that the features were ONLY those for which proof rules were known.
Now, we come to the crux of the matter. To paraphrase Gerald Weinberg, I can get wonderful programmer productivity, in any language you like, if the resulting program doesn't have to be correct. If you are willing to tolerate random bugs and random security holes and random system crashes, possibly resulting in random loss of human life, then there is no reason to go to something rigorous. If, however, the program must be correct, must not contain random bugs, must not crash at random moments, must not spray lethal doses of radiation into randomly-chosen therapy patients, then there does exist concrete evidence to suggest that those freedoms and powerful features are both unnecessary and dangerous.
I'm sorry, but that statement is factually incorrect.
Pratt & Whitney collected metrics on jet engine controller software development, over multiple projects, over a period of ten years. The military controllers were all in Ada, the civilian engine controllers were in various things, with C/C++ heavily represented. The team capabilities were about equal across the board. After they crunched the data down, they discovered that Ada was giving them twice the programmer productivity and 1/4 the defect density.
They now do ALL of their jet engine controller software in Ada.
There have been a number of other studies and experiments, and they ALL have yielded similar kinds of results. In theory, language shouldn't matter, but in practice, it does.
Step One is triggerable release of disordered energy (heat and noise) from a new source by whatever means.
Steps Two through N are learning to control it in various ways: maximizing the yield, tuning the yield, controlling the timing of the effect, using it in cascade with other things. Compare for example the incandescent light bulb, which gives most of its output in infrared, with fluorescent lights, light-emitting diodes. Compare the original ruby lasers with the various gas lasers and the modern laser diodes. Consider fission, fusion, and the more recent work in laser-triggered fusion with inertial confinement from all the lasers hitting from all sides.
The first step is ALWAYS making it go boom. Then you learn how to control the boom.
The original Little Boy and Fat Man devices were large, heavy, and very inefficient, compared to weapons with similar explosive yields today.
If you want an extreme example: black powder was originally developed as an explosive. That very same black powder is still in use today, powering small model rocket engines. All it takes is proper design and packing to control the combustion.
Lawrence Laffer?
as in Larry Laffer?
As in "Leisure Suit Larry in the Land of the Lounge Lizards"?
Somehow, this is about as cosmically appropriate as anything has ever been in my experience.
With all due respect, get a clue, they're cheap.
Thirty-some years ago, Arthur Haley (sp?) wrote "Airport". In it, one of his characters said something incredibly simple. It is, he said, simply not possible to tiptoe a quarter of a million pounds of machine anywhere.
That was when the Boeing 707 was still pretty close to the state of the art. Modern transports are anywhere from that size to three times that size, and are actually much quieter. A LOT has been learned in thirty years about building quiet airplanes.
You want to hear a loud airplane, try living under the pattern at a SAC base, listening to BUFFs taking off and landing. Been there, done that, and I'd do it again. Think of it as the sound of freedom.
Take a longer look at those Japanese bullet trains. The train companies put an army of track maintenance workers out there, every night, to recondition the tracks from the wear and tear that the trains put on them every day.
Take a longer look at the human environment in which those trains operate. Japan has incredibly high population densities compared to the overwhelming majority of the United States. Without those incredibly high densities, mass transit, of any kind, doesn't work. (About the only exception is Manhattan Island. No, thanks.)
Japan put that airport on the water because there wasn't ANY land available for a new airport. This is part of their population density problem.
The problem with "renewable" sources is that they are all inherently unsuitable for baseline supply.
Bluntly, you get days when the wind don't blow and the sun don't shine.
Even on days when the wind does blow, you are inherently looking at very low conversion efficiencies. (Fundamental thermodynamics, worked out by a fellow named Carnot, quite a few years ago.)
On days when the sun DOES shine, you are STILL limited to about 1.3 kW/sq meter absolute maximum. Photovoltaic conversion runs, last I heard, about 16% efficient, so you are looking at less than 300 W/sq meter of array. Start adding up what you need to replace a nuke plant, and start thinking about the Environmental Impact Statement you are going to have to file to cover that land in solar arrays. Don't forget your battery plant, to cover the nighttime demand, and don't forget the arrays that charge the batteries during the day while the other arrays are supplying the immediate demand.
As for wave power: A quick look at a map of the United States will show you, for example, that you aren't going to build very many wave power generators in, say, Arizona or New Mexico.
When you do the full-up analysis, you are led rapidly to the conclusion that there just aren't any silver bullets. If you are serious about generating electricity - and I really want to see how you explain to the voters that you can't run the hospital ICU 24x7 because you only have power when the sun shines and the wind blows - and you are serious about safety, then the inescapable conclusion is that negative void coefficient pressurized water reactors are the only way to fly.
The statement "(t)he coolant doubles as the moderator" is also true of American light-water designs.
What do you mean "could"?
In terms of lives lost, damage done, or just about any other measure you care to name, provided you restrict yourself to a competent design, nuclear fission is ALREADY the safest power generation technology known to man. Read "The Health Hazards of NOT Going Nuclear" by Dr. Petr Beckmann.
The key phrase in that sentence is "competent design." One of the key parameters in any nuclear reactor design is the void coefficient, and, most particularly, the sign of the void coefficient.
From http://www.nrc.gov/reading-rm/basic-ref/glossary/
From http://www.disenchanted.com/dis/lookup.html?node=
Briefly, if a reactor is designed with a positive void coefficient, it will inherently have a risk of a Chernobyl-style thermal runaway. If a reactor is designed with a negative void coefficient, it will not have that particular hazard. This fact was known to the Soviet reactor designers, who designed the RBMK reactor at Chernobyl (among other places), and was also known the US designers who wrote the US standards for reactor design. Positive void coefficient designs are flat-out illegal in the United States.
To do the safety analysis, you have to take, for example, black lung deaths of coal miners into account, and supertanker oil spill environmental damage. You also have to take into account the number of people who will, while attempting to install solar water heating panels on their roofs, will slip, fall, and break their necks.
If you want to prattle about radiation hazards, bear in mind that every lump of coal you burn, every drop of oil, every cubic foot of natural gas, contains some amount of radioactive carbon-14, and the ash (and emitted CO2) is thus radioactive waste. Ditto for wood. (Wood smoke contains other nasty things.)
Hungarian notation was originally developed as a band-aid (tm) for the near-complete lack of type checking in C. When all ints are created equal, and may be freely assigned to each other, and pointers must routinely be type-coerced to something else, and the compiler refuses to help the programmer keep things straight, something like Hungarian notation becomes necessary.
Hungarian notation declined after Stroustrup added strong typing to C++. It is worth noting that Stroustrup never even considered NOT doing strong typing in C++. (Read his book on the design and evolution of C++.) Distaste on the part of hard-line C programmers for strong typing also declined, after C++ forced them to eat their broccoli, and they discovered it actually tasted pretty good (by catching errors that would otherwise not have been found nearly as easily).
It is also worth noting that Hungarian notation never caught on in any language other than C. In particular, Ada programmers never bothered with it: the Ada type system was rich enough that it could do everything that Hungarian notation pretended to do, and enforce it, by requiring compilers to refuse to compile type-incorrect programs.
(Somewhere, recently, I saw something about a commercial satellite project that was forced to use Ada, because there was no C/C++ compiler available for a recently-declassified microprocessor. Their programmers screamed bloody murder at the idea. The screams stopped when they noticed that the Ada compiler was catching errors for them.)
Back in college I would defend C/C++ against one of my professors who thought it was the spawn of satan (and oddly though Pascal was/is the greatest language ever) for the simple fact that it gives you the ability to do so many things with few limits.
If we ignore for the sake of argument the specific "high-level assembler" design goal for C, and look instead at philosophy which was carried into C++, there was this fundamental hacking philosophy that said that, because you occasionally needed to do something a bit bizarre, it should be EASY to do that bizarre thing. Further, the entire C/C++ philosophy was that the programmer was solely responsible for the consequences of his actions.
We contrast this with Ada. Ada's philosophy was that you only occasionally need to do bizarre things, that 95-99% of the time, you are doing perfectly straightforward things, that the effort should be distributed accordingly, and that the language should be helping the programmer to do the routine things correctly. This implies that, when the programmer attempts to do something bizarre, 95-99% of the time it is because he screwed something up, and he DIDN'T mean to do what he typed, and the compiler barfs.
At that point, it becomes the programmer's responsibility to tell the compiler, and NOT INCIDENTALLY everyone who will ever do maintenance on his code, that "Yea verily I DID intend to shoot myself in the foot here!". Idioms are provided for doing that. If the programmer really intended to take that floating-point number and treat it as a bitmask, he has to tell the compiler that this was indeed his intention.
Ada did not provide a "back door" array reference mechanism comparable to the C/C++ pointer hacking, for the reason that it is impossible to do proper bounds checking in that case. Ada does provide a mechanism for suppressing bounds checking, but it is NOT the default and it is explicitly forbidden by the standard from it being the default in any conforming implementation. If the programmer has a good reason for suppressing bounds checking, he has to do it EXPLICITLY, at some level.
Your analogy with hammers is OK, but it breaks down with guns. Guns have trigger guards and safety catches, PRECISELY to prevent naive users from shooting themselves in the foot, or from shooting someone else that they didn't intend to shoot. At the same time, those safety mechanisms do not prevent the gun from being used to shoot someone that the user most fervently WANTS shot right then.
In my view, if I utter a sequence of instructions that will dance a fandango on core, it is almost certainly the case that I have made an error, and I would prefer the toolset to ask me "Are you sure? (Y/N)". If I am certain that I intended to dance that fandango, I am also certain I want to warn the next guy in line that I am now lacing up my dancing wafflestompers, and the language should support that.
If it's not a requirement then it doesn't need to be in the license. They could GPL it and still request that everyone please sign up.
They want the software to get the widest possible distribution. That means secondary distribution, from places like tucows and universities. Expecting all of them to carry a "By the way, please register this with NASA" notice is probably unrealistic.
So the notice has to go with the Subject Software.
The catch here is that most humans don't read binary code, so the request has to be in a human-readable text file. The only such file that is required to be carried, unmodified, is the License. THAT'S why they put the signup request in the license.
Not so. Here is the relevant language from the proposed license.
The key phrase in the language is "is requested to".
NASA is, among other things, a government agency. They do understand legalese. Had they intended to state a requirement, that phrase would have been the single word "shall".
"Shall" is a term of art in government specifications and legalese. It is used to state a requirement, and for no other purpose. (The standard tactic in defense firms for finding actual requirements in specifications is to do a text search for "shall".)
This isn't the first such.
I saw an article in Av Leak several years ago. The Navy worked a project with NASA, to put an F/A-18 cockpit and sim gimbal out on the end of the old man-rated centrifuge, specifically to be able to evaluate pilots under g-forces.
The pilots recommended in the strongest possible terms that the Navy pursue the project as a training system.
The x86 architecture is obsolete, and has been obsolete for many years. Intel has been frantically propping it up with every trick they could think of, and they are running out of tricks, slowly but surely.
Eventually, Intel (and Microsoft) will be forced to throw in the towel, bite the bullet, and design a NEW processor, hopefully with a decent number of registers and a sane(r) architecture, that will have some room left to grow.
The original statement contained excerpts from the 1967 Outer Space treaty and the 1979 Moon treaty.
You are correct; the United States did ratify the 1967 Outer Space treaty. My bad.
However, the 1979 Moon treaty is a very different matter. Out of some 180 nations, only six ratified that one. NONE of the spacefaring nations at the time ratified it, and I believe that none of the nations that DID ratify it have come anywhere close to achieving space flight.
So call it a push.
In order for a treaty to be binding, it must both be signed by the President *AND* be ratified by the Senate.
My recollection is that the Senate explicitly refused to ratify that treaty, after the L-5 Society organized a serious telephone campaign to defeat it. A large number of Senators heard from the Folks Back Home that this treaty was a Bad Thing and that the Folks Back Home were strongly opposed to it.
So when DID the Senate ratify the UN Outer Space Treaty?