Personally, I'm not fond of replacing real world testing completely with simulations.
Exactly. A broad battery of simulations makes sense for regression testing to prove that the 2027 model year software handles all the situations that the 2026 did. But real world testing is required to verify that the system doesn't do nutty things when confronted with unusual conditions -- dust clouds, ice coated wall to wall potholes, a trackless rural road or rarely used off ramp covered with four inches of snow with whiteout conditions (where is the edge of this damn road?)..
Keep in mind that we treat human misjudgments in extreme conditions as unavoidable accidents. But unless I misjudge Homo lawyerensis (a species that regretably perhaps does not appear to be endangered), every significant accident involving a self-driving vehicle is probably going to be the manufacturer's fault.
MSDOS certainly was simple: it was 16-bit, it lacked preemptive multitasking, and each program was limited to 64kB of memory (that other processes were not prevented from overwriting)!
MSDOS also worked perfectly adequately as the centerpiece of Windows 95 and 98. Of course working is important only to users. And who gives a damn about THEM? (Unless they get fed up enough to leave)
Oddly enough Microsoft's stock price stopped rising about the time that NT started to replace Windows 9. And the rather widespread dislike of Microsoft started about that time.
Just coincidence, I'm sure
BTW, the overly complex OS (relative to current low end device capabilities) is only one of the problems MS faces. And probably not the largest. The multitude of poorly documented and idiosyncratic APIs is probably a bigger issue since the principle reason for selecting Windows is likely in many cases to be compatibility with old applications. If Windows 2016 can't support the software some dude wrote for you in 1996 to control your packaging machinery or deal with your peculiar audit requirements, you probably aren't going to buy Windows 2016.
Having about computers BEFORE there was such a thing as computer science, I have to confess, that I have never been able to appreciate the vast benefits of patterning operating systems on those used by 1970s mainframes. Truth be told, they often didn't actually work all that well in the 1970s. Sometimes still don't if you ask me.
Some "advances" in computing really have made things better/easier. Higher level languages with exception handing? Absolutely. File systems vs rigidly allocated mass storage? Terrific. NT vs MSDOS? No Hum. Not in the same class with meaningful advances in computing.
All other things being equal, I would probably go with NT. But all other things don't seem to be so equal. MSDOS was simple and ran well on minimal hardware. NT isn't simple and doesn't seem to run all that well on slow CPUs. We have a couple of EEE PCs around the house running XT and Windows 7. They are both terminally slow. That's not entirely an OS architecture issue I think. Unix often seems to do much better on lightweight hardware (as long as you aren't trying to print). But the NT architecture probably doesn't help and it's always been unclear to me exactly what NT brings to the party on a lightweight personal computer -- which is, after all, what all those itsy devices whose marketplace Microsoft is having trouble selling into are.
Now that hardware has advanced they have a much better shot at architectural unification
Trouble is that the hardware has been marching off in directions often orthagonal (or worse) to the direction software and applications have taken. Hardware now includes many slow, limited CPUs that allow reasonable battery life in very small, compact devices. Software OTOH is written, as much as is possible, with no concern whatsoever for resource usage. The result is huge, impossibly complex (and therefore not very secure), OSes with often agonizingly slow UIs.
I personally doubt anybody or any group of anybodies is/are clever enough to "fix"/unify Windows.
Maybe if Microsoft had made different decisions in the mid-1990s when they had a compact real mode OS with a usable GUI running atop it, they could have ended up with something unified or unifiable. But that was then and this is now and the intervening two decades are water under the bridge or over the dam or something.
I'd like to be wrong about this, but I doubt I am.
My intuition says that most people do this. Though, I could be wrong.
Well, some of us try to do it. We are, regrettably, impeded by whacked out sysadmins who insist we must use THEIR idea of a strong password -- which always seems to be different from anyone else's idea of a strong password, and/or that we need to change passwords periodically, and/or that we can't reuse passwords.
I sometimes seems that there is an inverse relationship between the actual need for security and the system administrator's perception of the need for security.
But other than the fact that users often have to contend with the idosyncracies of sociopaths who feel that anything that is easy to use is clearly flawed, this seems a pretty good idea. If it gets the attention it deserves, perhaps it might be one small first step toward straightening out the incredible mess that is computer security.
Actually, as a climate skeptic, I've been saying for years that we should all focus on innovative nuclear technologies.
In fairness, some true believers in catastrophic warming warming do support nuclear. In particular NASA's James Hansen -- whatever one may think of his analytic skills -- is an outspoken supporter of replacing fossil fuels with nuclear. However we do need to keep in mind that even a well designed nuclear plant is likely to be managed at times by incompetents -- political appointees, fools, risk takers, or the just plain crazed.. We need nuclear power plant designs that even TEPCO couldn't turn into a regional or global disaster. While such designs are conceivable -- e.g. pebble beds -- they do not currently exist in proven form. And without fail safe designs, large areas of the planet are -- and probably should be -- pretty much off limits to nuclear power.
Is that a solvable problem? Probably. Is anyone trying very hard to solve it? Not that I can see.
A reasonable debate between groups of airheads who have not the slightest idea what they are talking about? That'll be interesting.
Consider that on the one side we have a revealed religion that depends on global climate models that embody all they think they know about climate. The GCMs really do not seem to work. They clearly run way too hot. So that causes a frantic effort to identify what is wrong with the models and fix it? Of course not. The response is to make stuff up, throw excrement, and yell insults at anyone who suggests that maybe there is a need to put a foundation under the "climate science" superstructure.
And there are skeptics who really don't have a theory of their own other than the obvious, and perhaps trivial contention that climate alarmists are ignorant, ill behaved, whack jobs. Never mind that their own behavior frequently is less than exemplary.
And neither side seems to have any conception of the problems entailed in delivering an adequate supply of essentials and luxuries to 10 billion human beings later in this century. Much less any willingness to work at developing realistic solutions to the numerous problems that will be encountered. On the one hand we have a bunch of "green" deus ex machina solutions that probably are going to work poorly when they work at all. On the other there is a belief in the improbable theory that God and an unregulated free market will provide abundance for all without any effort or planning.
Anybody seen any signs of adult behavior in this circus?
Dead on. I haven't used such. My first two questions would be.
1. How easy are they to use for someone whose usage is only an hour or two every few weeks? There's a lot of stuff out there that's great if you use it all the time but are somewhere between annoying and hateful for the casual user.
2. Can you easily mix in and edit text -- including, and especially. code or pseudo-code fragments? This seems to software design tooling, not storyboarding or conventional artwork production.
You'll waste the whole meeting fiddling with the technology and getting used to the UI.
I'm old and retired and far past meeting age (thank god). But my take is.
You'll not only waste the first meeting. Probably much of the first six meetings. And significant chunks of later meetings. And probably you'll need to spend time training any new participants in later meetings.
And... you probably want computers with real keyboards so people can type notes and make corrections and not have to worry about spurious touches doing stupid things.
I've never encountered any sort of computer drawing tool that wasn't excrutiatingly painful when compared to paper and something pencil-like. Doesn't mean one or more don't exist. But usability for graphics in a free wheeling environment really is something you should consider.
Not that what the poster wants isn't desirable. But what is really wanted is probably a process that can be "imported" and adopted to local needs, not a technology you can order 8 of from your hardware monger. In particular one should view any off-the-shelf commercial solution with the same attitude you'd take toward a large dog who is growling at you and foaming a bit around the mouth.
Would salesmen lie to you? You betcha. It is what salesmen do.
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.
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
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?
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.
Slashdot Mirror
Personally, I'm not fond of replacing real world testing completely with simulations.
Exactly. A broad battery of simulations makes sense for regression testing to prove that the 2027 model year software handles all the situations that the 2026 did. But real world testing is required to verify that the system doesn't do nutty things when confronted with unusual conditions -- dust clouds, ice coated wall to wall potholes, a trackless rural road or rarely used off ramp covered with four inches of snow with whiteout conditions (where is the edge of this damn road?)..
Keep in mind that we treat human misjudgments in extreme conditions as unavoidable accidents. But unless I misjudge Homo lawyerensis (a species that regretably perhaps does not appear to be endangered), every significant accident involving a self-driving vehicle is probably going to be the manufacturer's fault.
MSDOS certainly was simple: it was 16-bit, it lacked preemptive multitasking, and each program was limited to 64kB of memory (that other processes were not prevented from overwriting)!
MSDOS also worked perfectly adequately as the centerpiece of Windows 95 and 98. Of course working is important only to users. And who gives a damn about THEM? (Unless they get fed up enough to leave)
Oddly enough Microsoft's stock price stopped rising about the time that NT started to replace Windows 9. And the rather widespread dislike of Microsoft started about that time.
Just coincidence, I'm sure
BTW, the overly complex OS (relative to current low end device capabilities) is only one of the problems MS faces. And probably not the largest. The multitude of poorly documented and idiosyncratic APIs is probably a bigger issue since the principle reason for selecting Windows is likely in many cases to be compatibility with old applications. If Windows 2016 can't support the software some dude wrote for you in 1996 to control your packaging machinery or deal with your peculiar audit requirements, you probably aren't going to buy Windows 2016.
Having about computers BEFORE there was such a thing as computer science, I have to confess, that I have never been able to appreciate the vast benefits of patterning operating systems on those used by 1970s mainframes. Truth be told, they often didn't actually work all that well in the 1970s. Sometimes still don't if you ask me.
Some "advances" in computing really have made things better/easier. Higher level languages with exception handing? Absolutely. File systems vs rigidly allocated mass storage? Terrific. NT vs MSDOS? No Hum. Not in the same class with meaningful advances in computing.
All other things being equal, I would probably go with NT. But all other things don't seem to be so equal. MSDOS was simple and ran well on minimal hardware. NT isn't simple and doesn't seem to run all that well on slow CPUs. We have a couple of EEE PCs around the house running XT and Windows 7. They are both terminally slow. That's not entirely an OS architecture issue I think. Unix often seems to do much better on lightweight hardware (as long as you aren't trying to print). But the NT architecture probably doesn't help and it's always been unclear to me exactly what NT brings to the party on a lightweight personal computer -- which is, after all, what all those itsy devices whose marketplace Microsoft is having trouble selling into are.
Now that hardware has advanced they have a much better shot at architectural unification
Trouble is that the hardware has been marching off in directions often orthagonal (or worse) to the direction software and applications have taken. Hardware now includes many slow, limited CPUs that allow reasonable battery life in very small, compact devices. Software OTOH is written, as much as is possible, with no concern whatsoever for resource usage. The result is huge, impossibly complex (and therefore not very secure), OSes with often agonizingly slow UIs.
I personally doubt anybody or any group of anybodies is/are clever enough to "fix"/unify Windows.
Maybe if Microsoft had made different decisions in the mid-1990s when they had a compact real mode OS with a usable GUI running atop it, they could have ended up with something unified or unifiable. But that was then and this is now and the intervening two decades are water under the bridge or over the dam or something.
I'd like to be wrong about this, but I doubt I am.
My intuition says that most people do this. Though, I could be wrong.
Well, some of us try to do it. We are, regrettably, impeded by whacked out sysadmins who insist we must use THEIR idea of a strong password -- which always seems to be different from anyone else's idea of a strong password, and/or that we need to change passwords periodically, and/or that we can't reuse passwords.
I sometimes seems that there is an inverse relationship between the actual need for security and the system administrator's perception of the need for security.
But other than the fact that users often have to contend with the idosyncracies of sociopaths who feel that anything that is easy to use is clearly flawed, this seems a pretty good idea. If it gets the attention it deserves, perhaps it might be one small first step toward straightening out the incredible mess that is computer security.
Actually, as a climate skeptic, I've been saying for years that we should all focus on innovative nuclear technologies.
In fairness, some true believers in catastrophic warming warming do support nuclear. In particular NASA's James Hansen -- whatever one may think of his analytic skills -- is an outspoken supporter of replacing fossil fuels with nuclear. However we do need to keep in mind that even a well designed nuclear plant is likely to be managed at times by incompetents -- political appointees, fools, risk takers, or the just plain crazed.. We need nuclear power plant designs that even TEPCO couldn't turn into a regional or global disaster. While such designs are conceivable -- e.g. pebble beds -- they do not currently exist in proven form. And without fail safe designs, large areas of the planet are -- and probably should be -- pretty much off limits to nuclear power.
Is that a solvable problem? Probably. Is anyone trying very hard to solve it? Not that I can see.
A reasonable debate between groups of airheads who have not the slightest idea what they are talking about? That'll be interesting.
Consider that on the one side we have a revealed religion that depends on global climate models that embody all they think they know about climate. The GCMs really do not seem to work. They clearly run way too hot. So that causes a frantic effort to identify what is wrong with the models and fix it? Of course not. The response is to make stuff up, throw excrement, and yell insults at anyone who suggests that maybe there is a need to put a foundation under the "climate science" superstructure.
And there are skeptics who really don't have a theory of their own other than the obvious, and perhaps trivial contention that climate alarmists are ignorant, ill behaved, whack jobs. Never mind that their own behavior frequently is less than exemplary.
And neither side seems to have any conception of the problems entailed in delivering an adequate supply of essentials and luxuries to 10 billion human beings later in this century. Much less any willingness to work at developing realistic solutions to the numerous problems that will be encountered. On the one hand we have a bunch of "green" deus ex machina solutions that probably are going to work poorly when they work at all. On the other there is a belief in the improbable theory that God and an unregulated free market will provide abundance for all without any effort or planning.
Anybody seen any signs of adult behavior in this circus?
Dead on. I haven't used such. My first two questions would be.
1. How easy are they to use for someone whose usage is only an hour or two every few weeks? There's a lot of stuff out there that's great if you use it all the time but are somewhere between annoying and hateful for the casual user.
2. Can you easily mix in and edit text -- including, and especially. code or pseudo-code fragments? This seems to software design tooling, not storyboarding or conventional artwork production.
You'll waste the whole meeting fiddling with the technology and getting used to the UI.
I'm old and retired and far past meeting age (thank god). But my take is.
You'll not only waste the first meeting. Probably much of the first six meetings. And significant chunks of later meetings. And probably you'll need to spend time training any new participants in later meetings.
And ... you probably want computers with real keyboards so people can type notes and make corrections and not have to worry about spurious touches doing stupid things.
I've never encountered any sort of computer drawing tool that wasn't excrutiatingly painful when compared to paper and something pencil-like. Doesn't mean one or more don't exist. But usability for graphics in a free wheeling environment really is something you should consider.
Not that what the poster wants isn't desirable. But what is really wanted is probably a process that can be "imported" and adopted to local needs, not a technology you can order 8 of from your hardware monger. In particular one should view any off-the-shelf commercial solution with the same attitude you'd take toward a large dog who is growling at you and foaming a bit around the mouth.
Would salesmen lie to you? You betcha. It is what salesmen do.
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.
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.