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.

I'm not sure how much it speeded things up, but IIRC mechanical typewriters had two shift keys and touch typists -- a significant percentage of potential PC users in the 1980s -- would probably have been quite unhappy without their two shift keys.

Hey, look. Slackware is fine if you like it -- which, as it happens, I do. But installing anything other than the subset of frequently used applications that are available as slackware packages is often somewhere between annoying if ./configure,make,make install works and do it yourself dentistry without anesthetic painful if it doesn't. Slackware simply isn't for everyone.

There's a lot to be said for apt-get. I sometimes wish I could tolerate Ubuntu for the convenience of apt-get. But I've tried it several times and it's never been remotely satisfactory. And trying to fix/work around problems ... my God. I'd rather deal with the *&^*$ Windows Registry.

If memory serves me correctly, there's nothing all that new here. Back around 1960, the USAF was flying radio controlled WWII bombers out over the Gulf of Mexico to use in interception tests. Same thing, today? Better technology.

Like 16-bit DOS applications and Windows XP, all things eventually reach end of life.

Get over it and move on to something else.

T'aint broke so it's time to discard it?

Might want to consider the remote possibility that progress and motion are not always synonymous

The days when desktop environments improved as time went by seem to have gone. Now they just get more and more annoying with every iteration.

I have no mod points (I rarely post here anymore). But I think this nails a very real and quite annoying problem. Software of all sorts tends to start off simple, easy to use, but buggy and limited. As time goes by, problems get fixed, disconnects are resolved, obvious missing capabilities are provided. Then crap creeps in. And eventually the product becomes mostly crap. Bloated, slow, clunky, and -- too often -- virtually or actually unusable. Doesn't always happen. Windows (and Unix) hardware detection and driver installation seems finally to have reached the levels we were promised in 1995 ... and 1996 ... and 1997 ... and .... But it does happen often.

I've never used Icewm except for maybe 15 minutes to see if it looked usable. As I recall, it did. But does is really need much fixing? Would fixing it make it better? Would "fixing" it risk ending up with an incoherent, increasingly incomprehensible, shambles as has happened with Internet user interfaces, the Microsoft Windows UI, and a multitude of other software? If all Icewm needs is a few modest fixes, maybe it really doesn't need anything more than finding a student or enthusiast looking for a project.

If it needs extensive serous work, that's a different issue and probably does involve money.

And is Icewm really better/more useful than Fluxbox or Openbox or other more or less OK windows managers that may already provide all the capabilities the OP needs?

I think, and I'm not as smart as I once was, so this an opinion, not a statement of fact, that a geosynchronous satellite would be eclipsed by the Earth for a significant percentage of the time. There's probably an orbit that maximizes energy collection, but I don't have the slightest idea what it looks like.

I agree that putting a solar collector in orbit would be extraordinarily expensive using any currently extant technology. As would be maintaining it. On top of which, what would the point be? Solar energy can be collected on the surface at a small fraction of the cost and a technician can drive or walk to any component needing repair, Sure, a ground based facility might have to be larger than a space based facility, because of atrmospheric and sun angle losses. But not enough to make much difference?

BTW, I have to believe that a solar collector in orbit would probably constitute mankind's largest ever solar sail Is there some simple, cost effective, way to keep it from departing orbit on a journey in the general direction of Betelgeuse?

It won't be collected until the end of the tax year... just that you have to back-date it to the six-days-from-now mark.

Not that I know squat about how sales taxes are collected in Massachusetts, but across the border in Vermont, you pay them, as I recall, quarterly and the amount isn't as much a problem as the fact that many clients -- schools, local governments, etc are tax exempt but you still need to report the sale and their tax exempt certificate number. Which means one more piece of data to collect and one more piece of paper to send to someone periodically along with a check. OTOH, most resellers would presumably already be set up to handle this stuff if they ever resell hardware.