Who needs astrologers when we have computer models?

We probably need some sort of government program to retrain astrologers faced with technical obsolesence as network administrators of C++ programmers.

Solution: use natural language

Interesting idea. ten to one, you would get a great lesson in how ambiguous "natural language" is. A language that does not distinguish between inclusive and exclusive OR, has no rules for resolving the order/priority of ANDs and ORs when both occur in a clause, and which has a rather cavalier approach to NOT ("Isn't the door open?" is likely to mean "I think the door is open" rather than "Is the door closed?") may not be the ideal medium for communicating your wishes to a box.

Not that I know anything at all about this specific eReader, but I do know that the military in general tends to prefer old, proven technology for electronics. That's because they can assess the reliability of stuff that has been around a while. Newer stuff is probably better/more capable, cheaper. But you'd prefer not to find out that x component is an exception in a situation where replacing x component is going to be impossible.. On top of that, they tend to prefer stuff that is known to work in gawdawful environments -- high or low humidity, high or low temperature, lots of salt water, etc. Bottom line: the rom in these things is probably old and small capacity.

Note, for example, that the kid's iPad failed when onlookers were dousing runners with water during a marathon on a dreadfully hot and humid day. Doesn't mean the iPad is a poorly designed box. But it would not be the kind of box the military would prefer.

Emacs and Vim are both terribly unproductive text editors.

I don't know if I'd go that far, but I've loathed vi since before many of the folks posting here were born and I've never really warmed to emacs although I did give it a serious try once. Look (dammit), I have to learn a set of keystroke conventions (CUA pretty much) to use my web browsers. What possible reason would I have to learn a different set conventions for code editing? I use kwrite in x-windows and jed on the rare occasions that X isn't available. When I used Windows, I used some enhanced Notepad or other that doesn't work right under Wine. I've long since forgotten its name. I use Windows as infrequently as possible, and in the one or two hours a year I have to work in Windows, Notepad seems to be adequate.

IMHO, vi was a crummy text editor -- only a slight improvement over ed -- in 1980 and although modern vi-s are vastly improved, they really aren't anything special. I think I see the point to emacs, but I think you either love it or you don't. I don't.

Of course it'll help sometimes. "Restricted Visibility" isn't just for people. It'll surely apply to vehicle on-board sensors also. The ability to "see" potential hazards obscured by terrain, vegetation, traffic, looking directly into the rising or setting sun, etc isn't going to solve all or even most problems. But it'll help.

And frankly, self driving cars are going to need all the help they can get -- especially once one gets down off the freeways onto roads shared with pedestrians, bicycles, skateboards, joggers, drunks, wildlife, livestock, tree limbs, etc,etc, etc.

Pumped storage is great in theory. In practice, it's got some problems -- including, but not limited to -- inefficiency, lack of suitable sites, and evironmental issues from constantly fluctuating water levels. But the BIG problem is the huge amount of water that has to be moved to buffer energy to meet the electricity needs a modern industrial society on low wind days.

wind doesn't vary on a minute by minute basis, though.

I think perhaps you need to get outside of the basement occasionally and actually experience this wind phenomenon.

There are two different definitions of 'base load' in common use:

- In one definition, the base load is the minimum amount of power that must be provided at any given time and situation. Ideally, every utility will be able to meet its base load requirements even if all the variable load sources (wind, solar, etc) are simultaneously unavailable. Base Load generation facilities are power plants that can reasonably be expected to be available at any time for as long as is needed -- coal and gas powered power plants, nuclear plants, hydroelectric power.

- In the other definition, base load facilities are those which must be run at full output if that is possible in order to satisfy economic expectations and eventually pay for the investment in the facility. Unpredictable sources like wind are likely to be baseline load under the second definition, but not the first.

There are two problem areas here:

- Using the first definition, a utility must be able to somehow satisfy maximum demand even if major variable supplies are unavailable.

- Using the second definition, base load sources must be given priority lest the owners lose money. If utility owners routinely lose money, there will be no new utilities built, and possibly no maintenance of existing facilities. The problem is that most power sources are base load sources under this definition, thus everyone must have priority.

I've been through most of this thread and see a lot of gratiutious nastiness, a bit of serious discussion of GUIs vs CLIs, and some humor. But few answers to the original question. Anyway, there are a great many little and not so little tools out there. It's unclear what OS the OP is using, but if he/she can get access to a Unix system, there are a zillion command line tools in the /bin and /usr/bin directories (probably. I imagine there are distributions where the binaries have been "improved" to some other location(s)).

On unixlike systems "man whatever" and/or "info whatever" and/or "whatever --help" will likely get some usage information (which may be a bit incomprehensible in some cases). Many -- by no means all -- of these programs are available on multiple platforms

some useful websites for little tools -- not that all the stuff there is multiplatform,useful, or even usable
    - https://github.org/
    - http://sourceforge.net/
    - http://www.onethingwell.org/
    - http://tinyapps.org/blog/

The UNIX shell model for the last three decades is, you run a program and the shell finds it in the path, forks a child process, execs the program and waits on the child process. When the child process exits, the shell resumes and has the return status of the child process available for examination. And that does actually have its place. But it doesn't need to be all there is anymore.

It's not the mechanism you have in mind, but appending an & to the end of a shell command will run the command without locking up the user interface. For that matter, you can detach from a running CLI program with ^Z.. There are ways to reattach of course, but I don't remember what they are as I never use them.

Maybe "walled garden" isn't the proper term, but there are some legitimate gripes about GUIs.

1. As a practical matter, they are more or less unscriptable -- which means that tedious,repetitive tasks like backups, malware scans, etc frequently require my attention instead of being left to the computer which is much better at tedious, repetitive tasks than I am. I didn't buy this thing to make my life more difficult.

2. GUIs are hard to write and harder to test (because of the user can do any damn thing any time they wish aspect). As a result they are frequently buggy.

3. For those of us who use relatively minimal hardware (and there are a LOT of computers out here that are underpowered relative to the applications and OSes inflicted on them), GUIs tend to be kind of slow. Virtually every time I visit a doctor or other professional, I hear complaints about slow boots, eternal logins, slow software, etc, etc, etc.

4. The number of people who think they can design an effective, easy to use, GUI interface seems to be MUCH smaller than the number who can actually do so.

That said, GUIs have a valid place in the universe. For example, I don't think I'd care to try to do Google Maps from the command line. But the idea that GUIs are inherently superior to CLIs for all purposes has always seemed very odd to me.

For the money you're paying a service, why not just hoop up an inexpensive machine for a server, put a TB or two in it?

Fires, thefts, etc can happen to pretty much anyone. There's something to be said for encrypted off-site storage. OTOH, there's no particular reason that can't be on a usb flash drive in the glove compartment of a car. (I'd suggest in the trunk under the spare tire instead). After all, the data is encrypted. What can possibly go wrong?)

Not that I know anything about cracking encryption or have given this much thought, but wouldn't packing well known and unknown files into single files -- e.g. zip,tar,etc -- prior to encrypting make known content analysis pretty much impractical? ... for todays computers anyway?

Not a bad idea, but the schedule may be kind of aggressive. It doesn't seem to allow a lot of time for dealing with problems.

I'm aware of at least one outdoor LED roll-out that hasn't been problem free. It's at the recently rebuilt (at a cost of $76,000,000) Crown Point Bridge over a narrow spot on Lake Champlain. It's not that big a deal since drivers crossing the bridge at night have their headlights on anyway. But similar problems in NYC would presumably earn some bad publicity and increase costs beyond what is expected.. Here are some links http://www.northcountrypublicradio.org/news/story/21643/20130320/why-don-apos-t-all-the-lake-champlain-bridge-lights-work http://www.rutlandherald.com/article/20130628/THISJUSTIN/702149975

The problem apparently isn't the LEDs themselves. It's the circuits powering them.

I've spent way too many days of my life trying to deal with persuading printers and scanners to work with Linux. Unix printing has always been as dubious as its networking/file handling is good. Postscript? Not the unix community's best idea ever. Nevertheless, unix printing nowadays is acceptable except that manufacturers seem to regard unix printer drivers for their hardware as an an after thought. Having said that, I bought an HP-1102W a few years ago because the 20 year old HP-2P was on life support and HP unit was on sale. That was despite a great deal of ill-will that HP had generated when I had to support a few dozen of it's nasty unrepairable ink-jets with their ever changing, unrefillable ink cartridges. Not to say that their Linux driver actually worked on my old version of Slackware, but HP had obviously put some effort into it and it almost worked. I think it might have worked on one of the mainstream Linux distributions. I was able to get the printer going by installing/configuring with Windows -- which worked flawlessly -- then digging out a third party translator for Postscript to the printer protocol.

Then there's CUPS. But at least CUPS actually does an decent job of managing and routing printouts if you can get your printer set up properly and can tolerate the clunky http: interface. And it's free, so I reckon it'd be impolite to bitch too much about it.

My advice. The suggestion made by others of a printer with postscript support might have merit, but search the web first to make sure that the postscript support actually works well and isn't just window dressing. If possible avoid, printers using uncommon protocols like SPL where broadbased support is iffy (although the shareware rkkda driver does work on my two SPL printers and splix may work for some people sometimes). The suggestion of a low end color laser printer over an inkjet probably has merit. If possible, buy a printer where third party refilled cartridges are available. Specific models? I dunno. If you can find any specific model where users say Linux just works, I'd pay a bit extra for one if those.

Manufacturers? I dunno. At least HP seems to be trying to support Unix, but others may do better.

BTW, those indestructable HP printers of yore -- at least the HP-II,HP-iii lines were built around Canon print engines.