Shakespeare's Romeo and Juliet -- Given the number of good things that have been written that borrow the whole story, it's worth reading the original. Shakespeare borrowed the story himself, but improved it greatly.

Niven and Pournelle's The Mote in God's Eye -- Ignore how much Larry and Jerry wish we would give up an elected executive and install a monarch; it's still one of the very best first contact novels.

Michener's The Source -- Fictional but well-researched story of the evolution of religions in the Middle East, warts and all. Actually, more about the warts than anything else.

At some point I ended up writing a couple of small GUI applications with CodeWarrior, although on much more capable machines than the one where my colleague first ran MPW. The only thing I remember about the experience was being frustrated by having to learn yet another text editor, and one that wasn't -- IMO at the time -- nearly as competent as vi for writing code.

The guy in the cubicle next to mine got one of the early versions of MPW for the Mac. He thought it was hilarious that the first thing the software did when launched was open up a 24x80 terminal window running a CLI... More seriously, small text-based interfaces can provide a lot of bang for the buck when resources are scarce. MacFORTH was the first development environment for the Mac; you still see FORTH implementations in boot loaders; text-based interfaces ought to be in most programmers' box of tools, even if they seldom need (or in writing most software, want) one. Developers are sort of a natural group to make use of such interfaces, since the very large majority of them are going to spend lots of time writing down what the computer should do in a procedural text-based language...

There were a whole series of stories in the EE Times about 18 months ago when Intel started selling capacity on their then leading-edge fab line. The reality at the time was that Intel couldn't sell enough parts to keep the line full, and were going to eventually have to take big write-downs unless they found a way for the line to generate more revenue. That continues to be true. The really interesting event over the last 18 months has been the announcements by a number of Far East foundry companies that they can't afford to build fab lines that go below 20-nm. There seems to be a growing body of evidence that Rock's Law is starting to bite, and that as components shrink past 14-nm, there will be very, very few places in the world where you can get such parts made.

If it generates electricity, China is pushing it -- solar, wind, coal, NG, giant hydro dams, nuclear... They're trying to lift hundreds of millions of people up to some sort of modern, at least lower middle class lifestyle in a remarkably short period of time. And understand that to do that will require prodigious additional generating capacity.

The LANL presentation (and related material) is important to anyone who conducts extremely long-running calculations and thinks that they can have repeatability. Nor are the results new. 20+ years ago, paired lock-stepped 68020 processors with external hardware continuously checking pin states on output found that single-bit differences in results occurred about once every 30 days (proprietary data that I was shown under NDA, don't know that it was ever published). Contemporary hardware has considerably smaller geometry and runs at much higher clocks and lower voltages.

At least in the US, local authorities franchise cable-television video service. They have no say in the provision of high-speed data service or voice telephony offered over the same facilities. This puts the cities in the relatively weak position that if they want to franchise a different company for the video service, the existing company can, by simply not selling their facilities, force the new company to build an entirely new fiber/coax network. Years of work, very expensive. In the meantime, the franchising officials will almost certainly have had to run as the people who shut off cable TV in the city -- and probably lost the election as a result.

The balance of power changed drastically over the course of the 1990s, as the cable industry consolidated into a handful of very large companies and enormous amounts of investment were made in fiber to support two-way services.

Yep. Back when Gates was still running Microsoft and on his voice recognition bandwagon, one of my coworkers often remarked, "You can tell how long since he worked in a cubicle farm!"

That's why a tutor is often able to help these people when a classroom lecture setting has failed - a tutor picks up on their interest and relates the subject to the student in a meaningful way.

That's a really good point. One of the problems with doing real-world examples in a general introductory college math class (ie, calculus, probability and statistics, >25 students) is that many of the subjects one might use require quite a bit of basic knowledge about the field that the example is drawn from. So we end up with the same tired old problems based on experiences that a majority of the students will have a grasp on.

The problem is that most sites for the first two categories are either already taken or politically difficult...

The map on page 25 of this NREL document does a good job of showing potential conventional hydropower by state, separated by already developed, excluded (your political difficulties, mostly), and undeveloped. There are significant amounts of undeveloped hydro, mostly in the West.

Electricity is, and is likely to remain, a regional thing. The US doesn't have a single power grid; it has three -- Eastern, Western, and Texas -- that are almost completely independent of one another. The Western area is particularly rich in a variety of renewable sources, many located relatively close to the population/demand centers. The Texas area has a more limited set of resources available. The Eastern, particularly compared to its total population and demand, is poor in renewables. In addition, the Eastern's best renewable resources are quite far from the big population centers.

This is what I was thinking as well; just get together with peers in a similar situation, and 'Kickstart' an OSS version of the program, thus forever freeing yourselves from the shackles of proprietary software.

Based on some limited experience (largely post-mortems on failed medical software deliveries), and assuming that any sort of patient records are going into the system, I'm comfortable guessing that the "kickstart" cost will run to tens of millions of dollars. The big companies that play in this specialized field have entire groups dedicated to tracking the changes in federal and state government requirements. The people who use the software are going to insist on support contracts to keep the software in compliance as those changes appear.

If they can't find it, I'm quite sure some coders would be willing to write some for substantially less than than the $10,000 required for switching to yet another version of Windows that will be out-of-date in a year or two.

Are those coders working for a company that understands all of the HIPAA requirements that the code has to meet? Are they prepared to certify that the code does in fact meet those requirements? Are they working for a company that can afford the lawsuit if HIPAA privacy requirements are violated, even if the software is not at fault (and trust me, the company that provided the software will be included in the group being sued). Do those coders have experience in providing the government mandated audit hooks required if Medicare or Medicaid patients are treated? In the last case, it's not enough to provide some sort of audit hooks; you have to meet the very specific interfaces and data models specified by the government.

Building software for medical care providers has become a nightmare. In some parts of the industry, there are only a handful (as in literally four or five) companies that are eligible to bid for new software system contracts.

Or IBM's APL interpreters from the end of the same decade. Talented programmers have known what a debugging environment should provide for more than 40 years. Interpreted languages got there first, for all the obvious reasons. Same stuff just keeps getting reinvented for different languages and systems. That doesn't mean the new stuff isn't good, it just means it's not really new.

Then it's up to the physicists and mechanical engineers: without some cheap and easy method to LEO, we're not getting off the planet in numbers and equipment sufficient to survive out there. Say, controlled gravity.

Not in terms of learning curve for writers who are used to Windows or Mac.