They US authorities on '60s started trying gravity on various types of reactors for many years (passive cooling) and it failed miserably all times. Download the excellent BBC's 1992 documentary on the subject A is for Atom, or watch it on YouTube.

It was after they had confirmed the problem that they started installing diesel generators to operate the cooling pumps. The problem was discovered also in USSR. Chernobyl erupted during an experiment to test the cooling apparatus while disconnecting the plant from grid.

The root cause of all this was that they designed the commercial Nuclear Plants by scaling the 60cm diameter Submarine Reactors into 3 meter or even more. That way, the multiplied the fuel mass x1000, and disregarded that fact they were no longer 100 meters deep below the ocean surface, something that would guarantee passive cooling simply by hydrostatic pressure.

SemanticMediaWiki(SMW) can utilize triple-stores (proper RDF databases). But even without using one you can make still run queries from within wiki. You create the new query by using a special query-page and after you are satisfied with it, you embed it in any wiki-page. Next, whenever you view this page, the semantic-results come always fresh on that page. Compared to a RelationDB, SMW comes bundled with UI. You just have to learn a new syntax for running the queries.

Now to get the results in different formats you have multiple choices. I remind you that each wiki-page is at the same time a REST API. And SMW follows this path, providing specific query-parameters for getting query-results as CSV, as XML, as text, as html-tables, or any html-structure. And there are numerous extensions for embeding the results into google-maps(assuming they are geo-coords), event-calendars (assuming dates), graphs, trees, and many more.

Actually nobody likes to be reminded of the hierarchy above him or her. And most of the times the official hierarchy-diagram does not denote the complete command-and-control relations. Therefore, i skipped the political part of the "fairly accurate reflection of the way the business itself is organized" and concentrated on the technical aspects of the business, some of which i described above. Assuming that all technical data were complete, you could grasp the way the busines is organised by running queries resulting in cluster of related entities (hosts, subroutines, data-flows, developers and their capabilities, projects, etc). That way you get the *actual* picture, but only indirectly. But that assumption does not alwayd stand...

Regarding the "gaps", you are quite right. Those departments that lack proper documentation, usually avoid the semantic-wiki altogether. And those that participate in the wikie, spot and fill-in the gaps. I expect that these attitudes come with the territory of beaurocratic companies.

Another interesting observation is the quality of content that each department genarates. Those involved in the marketing produce the most vague page-entities with less interconnections, quite the opposite from the technical stuff that makes a good and innovative use of the wiki. Whenever an administrational person participates, good(tm) things happen, such as resolving HR problems, deciding on postponed decisions, and so on. But those people have hardly the time required to participate.

Last year i used MediaWiki's SemanticWiki to describe the systems, projects, human-resources, external-urls and their dependencies of a telecom.

Besides trivial parent-child relations among developers/employees, departments, etc,
i described system dependencies as semantic-relationsships with names like this: part of, invokes, build by, implements, deployed on, etc.

I described developer responsibilities with names like this: maintained by, coded by, external contact, etc.

Finally, the documentation pages and the refs to external-URLs of projects were reorganized by semantic-relations, like this: javadoc, docUrl, webApp, section of, help page, etc.

Do not spread diss-information.
These are not genetically modified, crops, they are artificially-sellected crops.

But then they wouldn't need electricity to operate those high-pressure pumps,
a simple hose on each one of the 6 reactors would do the job, or even simpler, they could have done it with buckets of sea-water!

OTOH, a Nuclear Core tightly sealed inside a Containenment Vessel is different beast to cool.

Not true!

The http://twitter.com/#!/followfriday is a user and a frequent-trending trend.

The same with: http://twitter.com/TheWalkingDead

Busybox's shell also supports this expansion, though through build-time config options.

Yet, the couple of linux-devices i have in my home, all contain them.

Why do so many programmers are still unaware of Bash's string-parsing built-in capabilities,
and prefer to use the 'basename' command instead?

For the above renaming one would suffice to type:

mv $f ${f%.*}.jpg

See: http://www.gnu.org/software/bash/manual/bashref.html#Shell-Parameter-Expansion

Actually all decent FPS engines have geometry/physics engines quite distinct from the graphics-pipeline!

The geometry/physics engines work on body bounding-boxes and their respective velocity-vectors describing their trajectories, and they try to solve the intersection-problem among all bodies with regard to time, by responding with a timestamp - the collision-timestamp - to questions like this:

"When is body A going to hit body B?"

And on that collision-timestamp an event is scheduled, for the game-logic to kick-in, to calculate the new body-trajectories, or deaths, new body births, sarpnels, whatever.

The physics/geometry usually runs on the game-server *simultanesous* with the clients to avoid sending back-and-forth excessive info into the network. The server is only authoritative for the game-logic decisions. Yet the client runs additionally the graphics-pipeline which uses the next-frame's timestamp to calculate the body-positions on the 3D space.

But sometimes there is a slight delay between the collision-timestamp and the response from the server about what to do next (the game-logic's decision), that may allow a body to be drawn past its collisions point, and this is what make us think that FPS affects physics.

To sum it up, fps has nothing to do with physics, even if some times it seems that way.

prohibiting people from operating a vehicle while wearing them.

Tip: Don't sign your name when posting anonymously. :P

Most OS installs probably happen from a rescue partition in the HDD...

Netbooks and smaller laptops no longer have optical drives (even my thinkpad doesn't have one by default). More machines can probably boot from USB today than from CD.