What I meant was that there are (countably) infinitely many different configurations for a Turing machine, where by configuration I mean current contents of the tape and state of the machine (and if there is already a definition of that word in use please ignore it).
And the problem is, still, that you therefore must have sufficient room to store what amounts to an arbitrarily large number, and that, still, is not possible.
You do need to have countably infinite storage capacity to compute in general with a TM - almost all programs, terminating or not, exceed any finite storage limit. Easiest to see that if you consider a register machine - for any program there are infinitely many whose output is always the same but which have a load of extra states which just bounce up one (otherwise unused) register to some number exceeding the storage limit, then back to zero.
You never need more than countably infinite storage space - although at first sight there appear to be 2^{\aleph_0} configurations, observe that for any situation which arises in a computation only a finite portion of the tape has actually been through the machine, so that there are only countably many valid configurations.
I was originally trying to point out that the obvious barrier to building an UTM is that you cannot store an arbitrarily large amount of data in the real world. In that case, it does not matter whether you want to view things as infinitely many possible states (of which only finitely many will be used in a computation) or infinitely many finite-state registers / points on tape / whatever, of which only finitely many are used in a computation.
Incidentally, you claim that there can be no universal machine with infinitely many states because no way exists to finitely describe it... well, you managed a nice short definition of the naturals, so you've managed to prove yourself wrong. Furthermore, your objection would apply equally to standard Turing machines if it were accurate.
A 'proper' Turing machine is supposed to be able to take on infinitely many states, OK?
That means that if you want to build one, before you get into how you are going to have the thing operate, you at least have to find a way of coding infinitely many discrete states using some finite amount of matter. Which is not possible: even if you could manipulate matter to the point of using every individual subatomic particle to store a bit of data, there are only finitely many particles and you will have a finite state machine.
Per the Heisenberg uncertainty principle, you cannot try to encode your state as an infinite-precision real which is (part of) the position or whatever of an object either, if you want to build a machine which is always contained in a finite space.
You could build a machine which will extend up to physical limits: stick a radar reflector in space, well away from any gravitational influence (which might be a problem, but...), and build a rocket ship which keeps track of how far away the radar reflector is, in the obvious way, keeps it an exact multiple of 1 metre, and runs a universal program (can do this in silicon logic on board) with that distance as the register. Assume that somehow it is possible to fuel the ship. With a bit of care, you can program things such that this program goes wrong with very low probability (you can allow for relativity, you can't rule out quantum effects deciding to move things suddenly by >0.5m, but it is very very unlikely). That will function as a universal Turing machine whenver you put in a program that does not require you to store any really large numbers. But when you are required to store large numbers you may run up against a physical limit in that you may well find there is an upper limit on the length of a geodesic in space-time, and you will be unable to store bigger numbers.
The problem with this is it works OK if you have been able to think through the whole program in advance, get everything where it should be, give everything the right name. Then your code will be readable with minimal commenting.
In practice you show the PHB a working version, and the PHB goes, ooh, I can't have told you to do *that*, I meant the other flib. So you rewrite the bit of the code dealing with flib, and it becomes less readable.
Repeat x3 (if you're lucky) and you have code that isn't quite so readable, and quite possibly has an automagical function in it somewhere. Then you need comments. Every line is excessive (unless you have done something very magical somewhere), but you probably need more than just this function does... comments.
Good example of this: program an expert system, which amounts to running a sequence of checks on a database. So far, looks like 'put a GUI over the top of whatever comes back from SQL query'. Now, the checks in question are in fact not quite so simple as you might like, and in fact they are a pain to do in SQL. New rules may need adding every so often. PHB appears - thou shalt not require rules to be entered in SQL, sayeth he. So, that would be a rewrite of the checking end of the program. How does the PHB want rules to be entered, then? The PHB would like for rules to be written in something like natural English. The PHB can write an interpreter for that if he wants that. OK, the PHB would like something easier to understand than SQL, but maybe not quite so simple as he originally said.
So, a cunning plan is devised, whereby rules are entered in simple-querycode, but where my code does a lot of parsing rather than having the SQL do this. Speed isn't that important, this code needs to operate in real time and just right now it operates in real time x1000 or so. So I am not too bothered about making fifty database calls where one would do.
PHB appears. Impressed he is, for he can enter rules which almost make sense in English, yet which return the correct results. Sayeth the PHB, thou hast done well, indeed these queries are so simple that even the operators may comprehend them. Thou shalt put in a little dialogue box wherein the operators may type queries of this form at any time, not for rules but merely for their own amusements. Oh, by the way, the operators want to get lots of results out of their queries, not just the one like you've been doing for these rules, and please do it by Friday noon so we can ship it.
ohfuck
So, the function which many moons ago sent SQL to the database for queries, and which returned true or false, had become a function which did Lots of Clever Parsing Stuff, yet still returned true or false. _ONE_ true or false, not many.
But now it must return numbers, or text strings - nicely formatted, please - and not one, but potentially many, and how many shall not be known until the last one arrives. And this shall be done by Friday noon, which it seems to me is about six hours of coding time. So any thought of nice coding goes flying out the window, I copy and paste the true-or-false parser I've got working, rename it, throw in several global variables which frig with the functioning of the recursive bit of the procedure so it can step through several layers of simple-querycode=>SQL and get the right results, put in a string of comments which essentially say, do not touch this code until you have read it five times and know what everything is for, do not touch this code if your hair is pointy, really don't touch this code, please ignore the evil greenish light that hovers over this code, it is truly horrible and tentacular but it works.
No time to try to clean this up for a possible second release version, for the PHB now wants me to do something else in a hurry, not spend most of the next week trying to write code that isn't quite so likely to sit festering, giving off low-grade evil emissions, and just waiting for some poor sod to be told to change this minor thing, so it can suck him in and devour him, or at least make all his attempted changes fail to work in mysterious ways.
Obviously no-one needs a terabyte of removable media storage. Hard discs are reliable, and lusers never delete things they didn't mean to, so these discs would be pretty useless for backing up data.
No-one ever creates several terabytes of data in a day doing particle physics experiments or astronomy, and certainly no-one would want to be able to take copies of the data to a conference, so that couldn't possibly be useful, either.
If you personally are paranoid and want to stop people reading your stuff, you can do perfectly well with RSA using a stupidly large pair of primes.
But anyone interested can still see that you've sent a big encrypted file somewhere. If you are, for example, working in a high-tech research company and you did it from work, then that is probably grounds for immediate dismissal (it'll be in the contract). Whereas if you send a couple of pictures of you+gf, to a mate, it's not suspicious; because lots of people are emailing pictures that are just pictures, anyone trying to brute-force check for steganography has a lot of stuff to work through.
Being as you can encrypt your data before steg'ing it, you're not likely to find a steg-breaking utility, or at least not one that works reliably with any serious attempt to make it hard.
Suppose you == info security guy at $Company. When you see a string of seemingly random bits in a file marked crypto.txt leaving $Company, you may not be able to find out exactly what trade secret your local friendly spy was leaking, but you do know there was a leak and who sent it.
On the other hand, if you see a load of random pictures leaving $Company from lots of employees, then you have to find which picture has hidden data in it before you even know you have a problem.
The point of steganography isn't to pass a message that can't be read, it's to pass a message without alerting anyone to the fact that a message has been passed.
So you would use a microchip to go from RF noise to detecting that close to 2.4Ghz there is a signal. Using a standard chip not designed specially for that purpose. Maybe think about how you would design the circuit to do that?
What in fact is used to tune to 2.4GHz is the crystal it mentions being hidden round the back of the ring, as per standard.
On the other hand, you have a big sanding / grinding job ahead of you to clean and even up the cut edges, unless you want the cyberpunk style. Which the original article suggests is best done using... a dremel.
This procedure is safe, assuming you don't try to speed things up by using 60 volts instead of the suggested 6 to 12 (12V won't hurt you whatever you do, including if you held on to the positive and negative plates in the water), and assuming you don't do it in a confined space where hydrogen / chlorine can build up and be flammable / toxic.
Most of the chlorine produced, in any case, will react with the iron to give iron chlorides which are soluble and not particularly harmful. Dioxins are not going to happen, not unless you dry off the solution, mix the slats you get at the end with some organic matter, and burn it.
I don't see much advantage over a dremel, though, since you're going to end up with a not particularly neat cut that needs tidying up anyway.
Doesn't make much difference what goes on far away from the Sun.
If there was a net charge to the solar wind, then the Sun's net charge would be the opposite sign and be increasing. Things would even out, and it probably wouldn't take several billion years to do so: you'll have an exponential curve, and the time constant most likely isn't huge.
(note: this is probably exactly what has already happened, since electrons are much lighter than protons hence more likely to be kicked off into space)
Simulation of life - not an IT problem. If biologists construct a valid model, then IT guys can simulate it without any trouble.
Global ubiquitous computing - this is a whole suite of related problems, none of which is individually hard.
Memories for life - this is part of the data organisation problem.
Scalable ubiquitous computing - this is part of the scalable complex structure problem.
Architecture of brain and mind - this could be an IT problem. IMO it will be solved by biologists constructing a good model of brain chemistry and giving a bit of detail on brain function, then the mind / software end of things will be obvious. But it's possible that a Very Clever Type might be able to construct a working mind model without this information, in which case they rank up with Newton and Einstein.
Dependable systems evolution / verifying compiler - this shouldn't be included. It's not practically useful: even in theory constructing meaningful assertions is same order of magnitude work as proving the program correct from first principles (Halting Problem), and this is _probably_ about the same amount of work as constructing and checking a truth table for your program - i.e. not feasible.
Non-classical computation - yes.
IMO, you could cut the list down to three genuine IT problems: First: how to order and relate data in large quantities. If you prefer, design a better database with better searching. This problem seems to be fairly tractable, but the further into it you go the harder it gets (natural language queries require AI or close, relevance probably also does, searching efficiency is likely to be an issue, for a start).
Second: how to construct a scalable complex system. Note that the Internet is a crap example - DNS isn't scalable, and search engines, which play a large part in making the internet useful, are not scalable. This problem is actually sort-of solved: the answer is (probably) P2P: but constructing working and privacy-keeping equivalents to http etc. is not going to be easy, and developing a node linking protocol which gives reasonably efficient paths for information but doesn't result in bottlenecking through one machine on some poor sod's desk (or similar) will be hard. Implementing such a model in a useful situation will also be hard, but more a social problem than an IT problem.
Third: the last problem in the BCS list, non-classical computation.
It all seems very nice to blame the govt for monopolies, and sometimes it's right (govt. owned monopolies), but in fact a capitalist system will tend to gravitate towards a small number of large companies, each of which is basically a monopoly in its marketplace. The only reason this doesn't happen more is that there is some government pressure to avoid monopolies.
A monopoly does _not_ mean excessive profits, and if you think it's the definition then you need to read the dictionary. A monopoly means one company has most or all of the market share.
Suppose there were no government interference at all, and MS were using its monopoly position to push prices through the roof (which in fact it isn't). You decide you can do better with, say, word processing, for less money, you enter the market. Then MS has enough money that it can kill you fast by making your product incompatible, using proprietary formats (it does this already), and bringing its prices down to the point where the cost of changing to your product is greater than the cost of the MS product (this is where MS prices are set now). You go out of business.
No government coercion involved.
For what it's worth, what MS have done would fit better with:
MS comes into little town with a bunch of brilliant auto-repair people, undercuts the current mechanic and fits a special device to every car they repair that makes it hard for anyone else to repair that car. The current mechanic is driven out of the market. Then the brilliant auto-repair people move on to the next town, and MS leaves a couple of bodge-job workers to man the garage. The prices stay where they are, but because the bodge-job guys are on minimum wage the garage now makes a profit for MS, and because no-one else can fix cars without doing a lot of extra work to get round the MS device, no-one else can get in the market, even though they would do a better job.
1. Enter market with best developers on the product. 2. Set prices marginally lower than competitors. 3. Bundle their software with other MS products to get market share up ASAP. 4. Use file format which breaks all competitors' features that you haven't copied. 5. Wait for competitors to leave market. 6. Keep the prices where they are, but make a profit by moving all the good developers to another area.
It doesn't actually take all that much of a war chest to undercut on software - once you've paid the developers, burned the CDs, done the advertising, there's nothing else you need to pay. And the first two are small compared to the third. IOW, if you want to enter a market, all you really need is enough money to mount a big ad campaign and you can undercut anyone who isn't giving their software away. Lots of companies can do that. The problem is your software has to be able to read and write MS file format, or no-one will buy it because everyone uses MS. That means you can't put in a new feature unless you can get it to save in MS format - in which case chances are MS have already implemented the feature. So how do you convince someone that your product is better than MS's, especially when the MS product is 'industry standard' and comes in a bundle with a load of other industry standard stuff?
When Microsoft enters a market, it typically does so by bundling its product in with existing stuff it sells which is only vaguely relevant. Like IE with Windows, or the Office range which used to cover word processing and spreadsheets and now does databases, finance, etc. as well.
So if you are already making a web browser, say, and suddenly most of your target market already has a web browser, how do you sell it? You can't just ignore it and keep going on, you go out of business. You have to either knock the price down, or add new and interesting features which MS haven't thought of, or both. So the result is MS entering the market forces prices down and makes competitors innovate.
But. This is not a good thing, because what then happens generally is MS products work on an MS format which isn't easily read by anyone else's product, and the MS product will not read any competitor's format created after the MS product enters the market. The result is that when someone moves to MS, they can transfer all their old documents relatively easily, and it's cheap, so a lot of people make that move.
Now suppose you currently have one of the existing products. You can't read MS files with it, although MS users can read your files. Whether or not you think this is an issue, at some point you need to upgrade. You can either buy the MS product, which will read all your old stuff so you can convert to it, or you can buy the newer version of what you have.
If you buy the newer version of what you have, then you have no trouble at all with converting files, and the new version probably can read MS files, and probably can export them. If it can't do either, you certainly won't buy it: you need to be able to exchange files with MS users.
But, at this point, MS are going all-out to keep their product as up-to-date and slick as possible, and the competitors are having to spend most of their time not adding features but trying to understand the MS format and get all their features to work in that format. So Joe Average looks at the alternatives and goes for the MS product. It gets most of the market within a couple of years. At this point, prices in the market have gone down a lot because companies are trying to sell at any price to stay in business, and there is a lot of innovation because companies are trying to find the thing that makes their product absolutely necessary.
Almost no-one buys these cheaper and better products because their files are not readable by the dominant MS product, and because most people already have a copy of the MS product bundled with Office or similar.
The law as quoted says you can install it (if installation is necessary to be able to run it). It doesn't say you can run it. Being allowed to run it is the consideration.
In any case, if you were correct, then you would expect that there would exist cases where a judge declared an EULA invalid for no consideration. No such exists. But a lot of cases exist where a judge has upheld an EULA. So, obviously you are wrong.
Irrelevant. You don't read the EULA when you buy software anyway, you read it when you run the installer. So your system, if it runs during retail, can only increase the number of clicks required to buy.
Possibly you meant to say that you _should_ read the EULA when you buy. In that case, your system decreases friction by a small amount (letting you avoid reading during purchase sometimes) after increasing it by a large amount (forcing everyone to read the EULA at purchase). This is what we call a net increase in friction. It's about as clever as me deciding I want to throw a hand grenade at you, but then coating it in foam rubber, and claiming that I've reduced harm to you because the foam rubber coat stops you being bruised when the hand grenade hits you. When I could just have decided not to throw the thing in the first place.
Alternatively, you might be trying to say that you want your EULA DB to run on the buyer's machine, when the install script is run. In that case, why on earth do retailers have anything to do with it? Can you clarify which of these you mean, please?
But anyway. If you mean your EULA DB runs on the buyer's machine, then what does it do? If you are Joe Average, then the EULA step of the install procedure consists of clicking I Agree, then Next, and takes about 5 seconds (you were claiming this is generally true and made the agreement bit meaningless). So at best your software saves five seconds per install. However, it can't be that good: if it cuts out both of the clicks, then the buyer certainly never agreed to anything, and the EULA really would be meaningless. So it cuts out one click. Not one click which causes a big HTML page to reload over a slow dial-up connection (the reason why Amazon made such a fuss of one-click shopping), but one click which is processed on the buyer's computer, effectively instantly. Big Wow!
You still haven't told me why software companies will cooperate with your idea, either, and I hope you can see that if a software company chooses not to expose its EULA and add hooks in their install script for your client, then your client cannot possibly work with that company's software.
I have no problems with the technical aspects of your original idea.
However, I still see no justification for your idea that somehow this would save any significant amount of money. Please, tell me where the savings come from - what is this 'market friction' that wastes money now?
You still seem to have this idea that software companies will cooperate. Amazon, eBay and Walmart are not software companies, they are retailers. If they are not given compliant software to sell, they cannot sell compliant software; if they do not sell non-compliant software they lose a lot of money. So, just to start. If you want software companies to cooperate with you, you'd better be able to get Microsoft on board, at least. Will Microsoft decide that from now on it will only use boiler-plate EULAs, and be generally helpful? Well, it might, although it'd almost certainly refuse to do so without being paid for it. We'll ignore the fact that it'd probably try to muscle in on producing your client. On the other hand, Microsoft release a reasonable amount of beta software, and all of those EULAs are different. So you'd have to have a lot of 'good EULA' templates - and someone to decide what is good and what isn't. Anyway. You have Microsoft on board. Now, is anyone else going to come too? Well, only if the EULAs they want to write match Microsoft's fairly well, or you write yet more templates for them. And they're probably going to want money to change their install scripts too - Joe Average has clicked through EULAs for years, won't notice or care that something slightly different is happening with Microsoft kit: and since he's already bought the software anyway even if he does notice he'll still click through. And so on.
And every time you want a new company on board, you still have to find a reason why they should, and the answer will continue to be 'well, if you let me define the EULAs I want to write as being good EULAs, and you pay me'.
Keep saying it if you want. No judge has _ever_ agreed with you, and quite a lot have disagreed.
You might want to tell me what is so special about an EULA in particular that makes it different from any other on-line agreement which you accept by saying you've read it and clicking on the Agree button, or how that differs from a paper contract which you accept by saying you've read it and scribbling on the dotted line.
You might also want to consider that the idea that contracts are legally binding is the only reason we don't still have a barter economy. Also, a contract, essentially, is a law. If you rank things in order, the constitution is most important; it applies to everyone. After that come federal laws. Those apply to most or all people - but they are invalid whenever they contradict the constitution. After that you have state laws, which apply to some or all people in a state, and then local ordinances, which apply to some people in a city, or 'anyone in this square after midnight', or such like. Then you have legal contracts, which apply to the people who sign them. In each case, the only way you are allowed to ignore one law is when a more important law says that law was illegal. So you can only ignore a contract you agreed to if it is not a valid contract for some reason - a law which says you may not do that (I agree to be your slave, for example) or a prior contract (for example if you have a tenancy agreement which says you may not sub-let, then a contract to sub-let your room is not legal)
Slashdot Mirror
I should have looked up the definition, OK.
I should not have used the word state.
What I meant was that there are (countably) infinitely many different configurations for a Turing machine, where by configuration I mean current contents of the tape and state of the machine (and if there is already a definition of that word in use please ignore it).
And the problem is, still, that you therefore must have sufficient room to store what amounts to an arbitrarily large number, and that, still, is not possible.
You do need to have countably infinite storage capacity to compute in general with a TM - almost all programs, terminating or not, exceed any finite storage limit. Easiest to see that if you consider a register machine - for any program there are infinitely many whose output is always the same but which have a load of extra states which just bounce up one (otherwise unused) register to some number exceeding the storage limit, then back to zero.
You never need more than countably infinite storage space - although at first sight there appear to be 2^{\aleph_0} configurations, observe that for any situation which arises in a computation only a finite portion of the tape has actually been through the machine, so that there are only countably many valid configurations.
I was originally trying to point out that the obvious barrier to building an UTM is that you cannot store an arbitrarily large amount of data in the real world. In that case, it does not matter whether you want to view things as infinitely many possible states (of which only finitely many will be used in a computation) or infinitely many finite-state registers / points on tape / whatever, of which only finitely many are used in a computation.
Incidentally, you claim that there can be no universal machine with infinitely many states because no way exists to finitely describe it... well, you managed a nice short definition of the naturals, so you've managed to prove yourself wrong. Furthermore, your objection would apply equally to standard Turing machines if it were accurate.
I'm misusing terminology, I think - too long since I did this...
but it amounts to the same thing. The overall state of the machine, including tape, can take on countably infinitely many values.
A 'proper' Turing machine is supposed to be able to take on infinitely many states, OK?
That means that if you want to build one, before you get into how you are going to have the thing operate, you at least have to find a way of coding infinitely many discrete states using some finite amount of matter. Which is not possible: even if you could manipulate matter to the point of using every individual subatomic particle to store a bit of data, there are only finitely many particles and you will have a finite state machine.
Per the Heisenberg uncertainty principle, you cannot try to encode your state as an infinite-precision real which is (part of) the position or whatever of an object either, if you want to build a machine which is always contained in a finite space.
You could build a machine which will extend up to physical limits: stick a radar reflector in space, well away from any gravitational influence (which might be a problem, but...), and build a rocket ship which keeps track of how far away the radar reflector is, in the obvious way, keeps it an exact multiple of 1 metre, and runs a universal program (can do this in silicon logic on board) with that distance as the register. Assume that somehow it is possible to fuel the ship. With a bit of care, you can program things such that this program goes wrong with very low probability (you can allow for relativity, you can't rule out quantum effects deciding to move things suddenly by >0.5m, but it is very very unlikely). That will function as a universal Turing machine whenver you put in a program that does not require you to store any really large numbers. But when you are required to store large numbers you may run up against a physical limit in that you may well find there is an upper limit on the length of a geodesic in space-time, and you will be unable to store bigger numbers.
The problem with this is it works OK if you have been able to think through the whole program in advance, get everything where it should be, give everything the right name. Then your code will be readable with minimal commenting.
In practice you show the PHB a working version, and the PHB goes, ooh, I can't have told you to do *that*, I meant the other flib. So you rewrite the bit of the code dealing with flib, and it becomes less readable.
Repeat x3 (if you're lucky) and you have code that isn't quite so readable, and quite possibly has an automagical function in it somewhere. Then you need comments. Every line is excessive (unless you have done something very magical somewhere), but you probably need more than just this function does... comments.
Good example of this: program an expert system, which amounts to running a sequence of checks on a database. So far, looks like 'put a GUI over the top of whatever comes back from SQL query'. Now, the checks in question are in fact not quite so simple as you might like, and in fact they are a pain to do in SQL. New rules may need adding every so often. PHB appears - thou shalt not require rules to be entered in SQL, sayeth he. So, that would be a rewrite of the checking end of the program. How does the PHB want rules to be entered, then? The PHB would like for rules to be written in something like natural English. The PHB can write an interpreter for that if he wants that. OK, the PHB would like something easier to understand than SQL, but maybe not quite so simple as he originally said.
So, a cunning plan is devised, whereby rules are entered in simple-querycode, but where my code does a lot of parsing rather than having the SQL do this. Speed isn't that important, this code needs to operate in real time and just right now it operates in real time x1000 or so. So I am not too bothered about making fifty database calls where one would do.
PHB appears. Impressed he is, for he can enter rules which almost make sense in English, yet which return the correct results. Sayeth the PHB, thou hast done well, indeed these queries are so simple that even the operators may comprehend them. Thou shalt put in a little dialogue box wherein the operators may type queries of this form at any time, not for rules but merely for their own amusements. Oh, by the way, the operators want to get lots of results out of their queries, not just the one like you've been doing for these rules, and please do it by Friday noon so we can ship it.
ohfuck
So, the function which many moons ago sent SQL to the database for queries, and which returned true or false, had become a function which did Lots of Clever Parsing Stuff, yet still returned true or false. _ONE_ true or false, not many.
But now it must return numbers, or text strings - nicely formatted, please - and not one, but potentially many, and how many shall not be known until the last one arrives. And this shall be done by Friday noon, which it seems to me is about six hours of coding time. So any thought of nice coding goes flying out the window, I copy and paste the true-or-false parser I've got working, rename it, throw in several global variables which frig with the functioning of the recursive bit of the procedure so it can step through several layers of simple-querycode=>SQL and get the right results, put in a string of comments which essentially say, do not touch this code until you have read it five times and know what everything is for, do not touch this code if your hair is pointy, really don't touch this code, please ignore the evil greenish light that hovers over this code, it is truly horrible and tentacular but it works.
No time to try to clean this up for a possible second release version, for the PHB now wants me to do something else in a hurry, not spend most of the next week trying to write code that isn't quite so likely to sit festering, giving off low-grade evil emissions, and just waiting for some poor sod to be told to change this minor thing, so it can suck him in and devour him, or at least make all his attempted changes fail to work in mysterious ways.
You'd have thought by now someone would have written a LaTeX GUI editor to do that for you...
wait a minute...
they have.
(still quicker to do maths by hand, IMO, and that's what I use LaTeX for, but that's my choice and I'm not bitching about it)
Obviously no-one needs a terabyte of removable media storage. Hard discs are reliable, and lusers never delete things they didn't mean to, so these discs would be pretty useless for backing up data.
No-one ever creates several terabytes of data in a day doing particle physics experiments or astronomy, and certainly no-one would want to be able to take copies of the data to a conference, so that couldn't possibly be useful, either.
Not the point...
If you personally are paranoid and want to stop people reading your stuff, you can do perfectly well with RSA using a stupidly large pair of primes.
But anyone interested can still see that you've sent a big encrypted file somewhere. If you are, for example, working in a high-tech research company and you did it from work, then that is probably grounds for immediate dismissal (it'll be in the contract). Whereas if you send a couple of pictures of you+gf, to a mate, it's not suspicious; because lots of people are emailing pictures that are just pictures, anyone trying to brute-force check for steganography has a lot of stuff to work through.
Being as you can encrypt your data before steg'ing it, you're not likely to find a steg-breaking utility, or at least not one that works reliably with any serious attempt to make it hard.
Suppose you == info security guy at $Company. When you see a string of seemingly random bits in a file marked crypto.txt leaving $Company, you may not be able to find out exactly what trade secret your local friendly spy was leaking, but you do know there was a leak and who sent it.
On the other hand, if you see a load of random pictures leaving $Company from lots of employees, then you have to find which picture has hidden data in it before you even know you have a problem.
The point of steganography isn't to pass a message that can't be read, it's to pass a message without alerting anyone to the fact that a message has been passed.
I bet if you were in court on that you'd be done for duplicating the illegal material, as well as possessing it.
In any case, why are you defending a hypothetical child porn distributor?
If the stuff you encrypt is illegal, like for example child porn...
So you would use a microchip to go from RF noise to detecting that close to 2.4Ghz there is a signal. Using a standard chip not designed specially for that purpose. Maybe think about how you would design the circuit to do that?
What in fact is used to tune to 2.4GHz is the crystal it mentions being hidden round the back of the ring, as per standard.
Well, yes.
There is that.
On the other hand, you have a big sanding / grinding job ahead of you to clean and even up the cut edges, unless you want the cyberpunk style. Which the original article suggests is best done using... a dremel.
This procedure is safe, assuming you don't try to speed things up by using 60 volts instead of the suggested 6 to 12 (12V won't hurt you whatever you do, including if you held on to the positive and negative plates in the water), and assuming you don't do it in a confined space where hydrogen / chlorine can build up and be flammable / toxic.
Most of the chlorine produced, in any case, will react with the iron to give iron chlorides which are soluble and not particularly harmful. Dioxins are not going to happen, not unless you dry off the solution, mix the slats you get at the end with some organic matter, and burn it.
I don't see much advantage over a dremel, though, since you're going to end up with a not particularly neat cut that needs tidying up anyway.
Doesn't make much difference what goes on far away from the Sun.
If there was a net charge to the solar wind, then the Sun's net charge would be the opposite sign and be increasing. Things would even out, and it probably wouldn't take several billion years to do so: you'll have an exponential curve, and the time constant most likely isn't huge.
(note: this is probably exactly what has already happened, since electrons are much lighter than protons hence more likely to be kicked off into space)
Happens occasionally, mainly when the book was never a big hit but had some interesting idea in it. Blade Runner, for example.
someone needs to think a bit more about these.
Simulation of life - not an IT problem. If biologists construct a valid model, then IT guys can simulate it without any trouble.
Global ubiquitous computing - this is a whole suite of related problems, none of which is individually hard.
Memories for life - this is part of the data organisation problem.
Scalable ubiquitous computing - this is part of the scalable complex structure problem.
Architecture of brain and mind - this could be an IT problem. IMO it will be solved by biologists constructing a good model of brain chemistry and giving a bit of detail on brain function, then the mind / software end of things will be obvious. But it's possible that a Very Clever Type might be able to construct a working mind model without this information, in which case they rank up with Newton and Einstein.
Dependable systems evolution / verifying compiler - this shouldn't be included. It's not practically useful: even in theory constructing meaningful assertions is same order of magnitude work as proving the program correct from first principles (Halting Problem), and this is _probably_ about the same amount of work as constructing and checking a truth table for your program - i.e. not feasible.
Non-classical computation - yes.
IMO, you could cut the list down to three genuine IT problems:
First: how to order and relate data in large quantities. If you prefer, design a better database with better searching. This problem seems to be fairly tractable, but the further into it you go the harder it gets (natural language queries require AI or close, relevance probably also does, searching efficiency is likely to be an issue, for a start).
Second: how to construct a scalable complex system. Note that the Internet is a crap example - DNS isn't scalable, and search engines, which play a large part in making the internet useful, are not scalable. This problem is actually sort-of solved: the answer is (probably) P2P: but constructing working and privacy-keeping equivalents to http etc. is not going to be easy, and developing a node linking protocol which gives reasonably efficient paths for information but doesn't result in bottlenecking through one machine on some poor sod's desk (or similar) will be hard. Implementing such a model in a useful situation will also be hard, but more a social problem than an IT problem.
Third: the last problem in the BCS list, non-classical computation.
Some of that is right, a lot of it is crap.
It all seems very nice to blame the govt for monopolies, and sometimes it's right (govt. owned monopolies), but in fact a capitalist system will tend to gravitate towards a small number of large companies, each of which is basically a monopoly in its marketplace. The only reason this doesn't happen more is that there is some government pressure to avoid monopolies.
A monopoly does _not_ mean excessive profits, and if you think it's the definition then you need to read the dictionary. A monopoly means one company has most or all of the market share.
Suppose there were no government interference at all, and MS were using its monopoly position to push prices through the roof (which in fact it isn't). You decide you can do better with, say, word processing, for less money, you enter the market. Then MS has enough money that it can kill you fast by making your product incompatible, using proprietary formats (it does this already), and bringing its prices down to the point where the cost of changing to your product is greater than the cost of the MS product (this is where MS prices are set now). You go out of business.
No government coercion involved.
For what it's worth, what MS have done would fit better with:
MS comes into little town with a bunch of brilliant auto-repair people, undercuts the current mechanic and fits a special device to every car they repair that makes it hard for anyone else to repair that car. The current mechanic is driven out of the market. Then the brilliant auto-repair people move on to the next town, and MS leaves a couple of bodge-job workers to man the garage. The prices stay where they are, but because the bodge-job guys are on minimum wage the garage now makes a profit for MS, and because no-one else can fix cars without doing a lot of extra work to get round the MS device, no-one else can get in the market, even though they would do a better job.
That might work, but it's not what MS do.
They do:
1. Enter market with best developers on the product.
2. Set prices marginally lower than competitors.
3. Bundle their software with other MS products to get market share up ASAP.
4. Use file format which breaks all competitors' features that you haven't copied.
5. Wait for competitors to leave market.
6. Keep the prices where they are, but make a profit by moving all the good developers to another area.
It doesn't actually take all that much of a war chest to undercut on software - once you've paid the developers, burned the CDs, done the advertising, there's nothing else you need to pay. And the first two are small compared to the third. IOW, if you want to enter a market, all you really need is enough money to mount a big ad campaign and you can undercut anyone who isn't giving their software away. Lots of companies can do that. The problem is your software has to be able to read and write MS file format, or no-one will buy it because everyone uses MS. That means you can't put in a new feature unless you can get it to save in MS format - in which case chances are MS have already implemented the feature. So how do you convince someone that your product is better than MS's, especially when the MS product is 'industry standard' and comes in a bundle with a load of other industry standard stuff?
When Microsoft enters a market, it typically does so by bundling its product in with existing stuff it sells which is only vaguely relevant. Like IE with Windows, or the Office range which used to cover word processing and spreadsheets and now does databases, finance, etc. as well.
So if you are already making a web browser, say, and suddenly most of your target market already has a web browser, how do you sell it? You can't just ignore it and keep going on, you go out of business. You have to either knock the price down, or add new and interesting features which MS haven't thought of, or both. So the result is MS entering the market forces prices down and makes competitors innovate.
But. This is not a good thing, because what then happens generally is MS products work on an MS format which isn't easily read by anyone else's product, and the MS product will not read any competitor's format created after the MS product enters the market. The result is that when someone moves to MS, they can transfer all their old documents relatively easily, and it's cheap, so a lot of people make that move.
Now suppose you currently have one of the existing products. You can't read MS files with it, although MS users can read your files. Whether or not you think this is an issue, at some point you need to upgrade. You can either buy the MS product, which will read all your old stuff so you can convert to it, or you can buy the newer version of what you have.
If you buy the newer version of what you have, then you have no trouble at all with converting files, and the new version probably can read MS files, and probably can export them. If it can't do either, you certainly won't buy it: you need to be able to exchange files with MS users.
But, at this point, MS are going all-out to keep their product as up-to-date and slick as possible, and the competitors are having to spend most of their time not adding features but trying to understand the MS format and get all their features to work in that format. So Joe Average looks at the alternatives and goes for the MS product. It gets most of the market within a couple of years. At this point, prices in the market have gone down a lot because companies are trying to sell at any price to stay in business, and there is a lot of innovation because companies are trying to find the thing that makes their product absolutely necessary.
Almost no-one buys these cheaper and better products because their files are not readable by the dominant MS product, and because most people already have a copy of the MS product bundled with Office or similar.
The law as quoted says you can install it (if installation is necessary to be able to run it). It doesn't say you can run it. Being allowed to run it is the consideration.
In any case, if you were correct, then you would expect that there would exist cases where a judge declared an EULA invalid for no consideration. No such exists. But a lot of cases exist where a judge has upheld an EULA. So, obviously you are wrong.
Irrelevant. You don't read the EULA when you buy software anyway, you read it when you run the installer. So your system, if it runs during retail, can only increase the number of clicks required to buy.
Possibly you meant to say that you _should_ read the EULA when you buy. In that case, your system decreases friction by a small amount (letting you avoid reading during purchase sometimes) after increasing it by a large amount (forcing everyone to read the EULA at purchase). This is what we call a net increase in friction. It's about as clever as me deciding I want to throw a hand grenade at you, but then coating it in foam rubber, and claiming that I've reduced harm to you because the foam rubber coat stops you being bruised when the hand grenade hits you. When I could just have decided not to throw the thing in the first place.
Alternatively, you might be trying to say that you want your EULA DB to run on the buyer's machine, when the install script is run. In that case, why on earth do retailers have anything to do with it? Can you clarify which of these you mean, please?
But anyway. If you mean your EULA DB runs on the buyer's machine, then what does it do? If you are Joe Average, then the EULA step of the install procedure consists of clicking I Agree, then Next, and takes about 5 seconds (you were claiming this is generally true and made the agreement bit meaningless). So at best your software saves five seconds per install. However, it can't be that good: if it cuts out both of the clicks, then the buyer certainly never agreed to anything, and the EULA really would be meaningless. So it cuts out one click. Not one click which causes a big HTML page to reload over a slow dial-up connection (the reason why Amazon made such a fuss of one-click shopping), but one click which is processed on the buyer's computer, effectively instantly. Big Wow!
You still haven't told me why software companies will cooperate with your idea, either, and I hope you can see that if a software company chooses not to expose its EULA and add hooks in their install script for your client, then your client cannot possibly work with that company's software.
I have no problems with the technical aspects of your original idea.
However, I still see no justification for your idea that somehow this would save any significant amount of money. Please, tell me where the savings come from - what is this 'market friction' that wastes money now?
You still seem to have this idea that software companies will cooperate. Amazon, eBay and Walmart are not software companies, they are retailers. If they are not given compliant software to sell, they cannot sell compliant software; if they do not sell non-compliant software they lose a lot of money.
So, just to start. If you want software companies to cooperate with you, you'd better be able to get Microsoft on board, at least. Will Microsoft decide that from now on it will only use boiler-plate EULAs, and be generally helpful? Well, it might, although it'd almost certainly refuse to do so without being paid for it. We'll ignore the fact that it'd probably try to muscle in on producing your client. On the other hand, Microsoft release a reasonable amount of beta software, and all of those EULAs are different. So you'd have to have a lot of 'good EULA' templates - and someone to decide what is good and what isn't.
Anyway. You have Microsoft on board. Now, is anyone else going to come too? Well, only if the EULAs they want to write match Microsoft's fairly well, or you write yet more templates for them. And they're probably going to want money to change their install scripts too - Joe Average has clicked through EULAs for years, won't notice or care that something slightly different is happening with Microsoft kit: and since he's already bought the software anyway even if he does notice he'll still click through.
And so on.
And every time you want a new company on board, you still have to find a reason why they should, and the answer will continue to be 'well, if you let me define the EULAs I want to write as being good EULAs, and you pay me'.
Keep saying it if you want. No judge has _ever_ agreed with you, and quite a lot have disagreed.
You might want to tell me what is so special about an EULA in particular that makes it different from any other on-line agreement which you accept by saying you've read it and clicking on the Agree button, or how that differs from a paper contract which you accept by saying you've read it and scribbling on the dotted line.
You might also want to consider that the idea that contracts are legally binding is the only reason we don't still have a barter economy.
Also, a contract, essentially, is a law. If you rank things in order, the constitution is most important; it applies to everyone. After that come federal laws. Those apply to most or all people - but they are invalid whenever they contradict the constitution. After that you have state laws, which apply to some or all people in a state, and then local ordinances, which apply to some people in a city, or 'anyone in this square after midnight', or such like. Then you have legal contracts, which apply to the people who sign them. In each case, the only way you are allowed to ignore one law is when a more important law says that law was illegal. So you can only ignore a contract you agreed to if it is not a valid contract for some reason - a law which says you may not do that (I agree to be your slave, for example) or a prior contract (for example if you have a tenancy agreement which says you may not sub-let, then a contract to sub-let your room is not legal)