That would require observing the Alice / Bob results first, thus "changing" the Victor photons before he can do anything.

The traditional way would have been currency devaluation, then massive inflation. The effect would have been to reduce expenditures uniformly through the entire economy, stabilising at a new, sustainable level - in effect, people would remain employed, but be paid less. Adopting the Euro meant this couldn't happen, so instead a large section of the population is selected to be paid zero or have benefits cut, while the rest retain their salaries.

There would still have been aftershocks of unemployment the old way, but nothing like what has happened in this case. It's kind of like a large tank of water, in one case you drain a third of it, in the other you make a chunk disappear - it may be the same amount, but in the latter case the waves caused by the rushing water causes more damage than removing it.

That's not to say currency union can't work well. The U.S did it for over two centuries. But it results in a loss of sovereignty as local governments are limited in what they can do, either voluntarily, or involuntarily when an economy implodes and needs rescuing (like Greece - I think this happened in post-revolution U.S.A as well, setting the standard for federal-state relationships almost from the beginning).

The CoCo was an attempt to salvage a product to provide a low cost "videotex" terminal for farmers called AgVision (this is why the background was green, to seem "farm"-y). The product failed (farmers didn't think this "electrical net working" thing had anything to add to farming, or maybe the services like prices or weather reports just weren't worth the subscription price), but the cost reduction work by Motorola (which is why the 6809 was used) inspired also developing a home computer.

Actually, that is the reason given for the changes. Specifically, the language is "known" to be so racist that it puts people off of reading it (and parents prevent their children as well). A "safe" version would remove that tabboo and more people would read it and realise it's not racist. The original still exists, for those who, now knowing better, want to read it and see what the difference is.

Here's something to consider - what if it's not "things" that become intelligent? What if intelligence becomes emergent from everyday activities?

Specifically, business. Ever since the first time-and-motion studies and assembly lines, businesses have been trying to codify and standardise best practices for more and more higher level activities. Generally this is in the form of "assistance" to remove the repetitive or redundant wading through raw data or shuffling paper. For example, do you know anyone with a physical "In-box" these days? It's all email - company memos are no longer typed pages, questions get sent and answered globally, etc. Similarly groupware and wikis let people collaborate without time-consuming meetings that get off-track and miss the point anyway. More recently data mining and business intelligence applications have been taking the fuzzy human judgement out of routine decisions. Loan applications are approved electronically in a fraction of the time they used to be, for simple cases.

More and more decision activities are being turned over to software - because they're boring, and because the software does a better job, for the most part (minus a few global stock market crashes as the bugs get worked out). At the same time, lower level activities are still being automated. It's been said that today "all companies are software companies, they just don't know it yet". Many companies get their software packaged from elsewhere - in which case, they're really being run by the software suppliers, they're just going through the motions. Or they don't, and get overtaken by companies which benefit from innovative ideas from all over the planet added to the software.

So when a business software infrastructure has the complexity to make complex decisions better than the people running the company, because it has far more data than a human could process in a lifetime, does it become "intelligent"? If not immediately, how about down the road? If software run companies outperform human run ones, so that the latter go out of business or get bought out, who would notice? Given that humans still get the money and write the announcements and graphically design the web site for other humans.

If that sofware becomes intelligent, then where is the intelligent "machine"? It's spread out across the world, on constantly interchangable machines, storage, networks. Maybe rented from one day to the next, the software might scoot around different servers and companies often enough nobody can tell just where it resides (you know about 90% or your atoms and molecules are replaced annually, but you're still "you").

Intelligent machines may eventually happen, as iPhones with Siri or hospital computers with Watson. But I'm pretty sure intelligence in the form of corporations is inevitable (Charles Stross's book "Accelerando" examines what this type of scenarion might be like - in one case, the main characters negotiate with a Ponzi Scheme in corporation form).

The government spent millions on technology, then shut it down after the Soviet spies stole it, so the USSR had the technology and Canada (who paid for it) didn't? Is that the sort of thing that passes for logic in your mind?

Cutting costs for production often shows up elsewhere. In the Arrow's case, maintenance was an afterthought, sometimes requiring unscrewing entire panels. Lining up the holes to re-fasten them was nearly impossible with the tension changed. Also it had major landing gear problems. It was an amazing jet, but a lot of its shortcomings were somewhat whitewashed in order to win support to continue the program.

I think the real problem is trying to measure code readability. Policies and coding standards try to address the issue while avoiding it by mandating frills that they think will kind or "imply" readability - function length, number of spaces in parentheses, badly defined Hungarian notation (dead, thankfully), Javadoc or similar commenting standards, and so on. But there's no getting around the fact that the only way to measure code readability is to read it.

This means that you need to put code review at the centre of the process. Not necessarily anything heavyweight, but just require that one other developer reads and understands the code (and points out any obvious flaws) before committing - with the limit that any questions the reviewer has should only be answered by changes in the code, because a question implies a readability problem. The developer can add comments, or rename variables, or restructure the code to make it clearer, but the end result should be readable code with fewer bugs (bugs live in hard-to-understand code, simply adding some intermediate variables to a complex formula can make them go away).

As long as the code review itself doesn't get bogged down with issues of How The World Should Indent and things like that - that's always a risk with developers looking at each others code.

There is a different mindset between Japanese companies, such as FujiFilm, and American ones like Kodak. Japanese companies usually try to diversify at all times (not when in decline), so FujiFilm expanded from film to photocopiers, displays, and anything else they could (within Japan, large companies are often extremely diversified. Nintendo once ran taxis, Mitsubishi Electric makes elevators and televisions, Yamaha makes music keyboards and motorcycles). American companies have the phrase "core competency" as a mantra, and will often sell off profitable divisions (the entire technical equipment side of HP) or even wind them down if they're not profitable enough (HP calculators). The name for this is "unlocking shareholder value", and maybe it does, but it tends to weaken companies which no longer have the flexibility to adapt to market changes. Rather than one division growing while another shrinks, one spun-off company grows while another goes bankrupt.

First, you wouldn't want to do that through a large list, only a small list. Also, a well designed interface would allow you to more powerful search tools that could be much faster (tree that expands as you type, giving you shortcuts to jump to or prune branches). I think that means you've missed the point.

The point is you're still thinking "text and only text" as the output from any command. Text based key completions (tab, arrow key, etc) are terribly old these days. I think you could find something like that on the old text-based Lotus 1-2-3, if not early word processor spelling checkers. "Modern" isn't a two decade old technology.

A lot of "words" on a command line have an implied object, the obvious example being the file names printed by "ls" - each file name implies there's a file. You can run "ls" again with a "-l" to see more attributes of the file, like size and permissions. You can use "more" to view the contents. And so on. By contrast, a GUI file manager shows you a representation of the file that you can manipulate, to list size and attributes, click to open, rename, and so on. The file appears on screen once, in a human readable form, you don't have to open a new view every time you want to see an attribute like you do with "ls".

So imagine a system where you could type "ls some_app/data" and get a huge list of files, but then decide to "select age > this month" to highlight only older files, then add more selects to add more criteria, sort by size, etc. Say you find the file you want, and want to view it, but don't know the name of the viewer command installed on this system (or if it has one), but you can click on the file to bring up a menu and select "view" to see your options.

To do something like that now you'd have to do your "ls" in a CLI, then open up a GUI file manager to the same directory to click on it. The question is, why can't "ls" output complete file objects to your window, instead of just one limited form (7 bit ASCII) of one single attribute (the name) of those objects? They don't need to look much different until you start clicking on them, you could keep doing things the CLI way until you need something more.

I hope that's clearer about why tab completion of text is insignificant compared to what could be done with CLI/GUI integration. That's one example, you should be able to imagine others (revision control system, system stats, debugging a crashed program).

I think there's still a disconnect between GUI and CLI at a more fundamental level - people think of CLI as meaning text and only text, and GUI as only graphics (despite labels, fields, etc. being textual). Most (or every, if possible) UI item should be interactable (is that a word?) by keyboard or GUI, but for an example I'll start with a command line - when you run a command, it should create one or more interactable objects as the output. In a lot of cases (say, "cp" or "rm"), it could be an exit code that just shows up as a widget next to the prompt on the next line. If you want to know more, you can click on it to get execution details like execution time or whatever - normally stuff you're not interested in, so it stays out of you way. If something went wrong, the object displays an error message, with widgets for diagnostics - anything from a stack trace or signal received to rerunning the command with a debugger attached.

A lot of commands would produce output objects. A "mkdir" like command would create a folder icon you could click on to open, move, rename, etc. "ls" could create an explosion of objects in your terminal window that you can manipulate just like you had clicked on a folder or selected files to view separately.

You might not scroll back through your output so much as flip back to previous window states, like the "Time Machine" interface on Mac OS X. IN each case, you could modify and re-run your command, it would fork into another tree of results. You could navigate these result trees until they expire, like web pages.

As for all the complicated options that some commands have, something like the <tab> key would create a command chooser (all commands matching the first letters you typed) that you could arrow through or click on. Once the command was selected, another <tab> could cause the command to create an option configurator (like the Windows PowerShell does).

And that's just some initial thoughts. Smarter people can probably come up with genuinely good ideas. Sadly, I've seen little of this even tried.

I described above the idea of including a DNS hostname in a normal host string. I like that because it only needs client library changes, DNS can stay the same, and those setting up alternative DNS hosts only need to include a few censored names, not the entire DNS database. If I had a few days, I'd whip a demo up myself, but that's not going to happen for a while.

I haven't had time to try this, but there's no reason not to include a DNS host in the hostname, to use as a resolver. An example to explain, imagine "oppressed-group.org" is blocked, but "freeworld.net" hosts a DNS with a list of blocked domain names (just some, doesn't have to be the entire DNS database), you could specify "oppressed-group.org(freeworld.net)" (or give the IP address of the DNS server). It could be chained with as many additional DNS servers as it takes (as in "host(dns2)(dns1)").

In the end, the servers see everything normally, the root DNS and other servers are unchanged, the only change is in the client code that does the lookup.

Alternative syntax could go in the other direction, using "/" or "!" (bring back bang paths!), looking like "freeworld.net!oppressed-group.org".

The "Kentucky Fried Movie" 'Fistful of Yen' parody of "Enter the Dragon" featured guards named: Hung Well, Long Wang, and Enormous Genitals.

IBM generally sells business solutions and technology - the latter sometimes as patent licenses, sometimes developing products and selling them off. For example, the popular "swiping" method of keyboard entry on smartphones came from ""ShapeWriter" (previously SHARK), an IBM product they sold to another company to commercialise.

I'm sure there are a lot of assets in WebOS that could be developed. For example, what if you go a step beyond Apple's Siri, and integrate a smartphone interface with the deep AI of IBM's Watson Jeopardy champion (currently being commercialised for optimising medical treatment in the health insurance industry)? Sell or license that product to application developers for everything from intelligent tourist guides to on site first aid agents, who sell their wares on Android, iTunes, Blackberry or Microsoft app stores.

Lots of possibilities for a firm with cutting edge research and development. Like HP used to be, once.