This is hardly a novel concept. It is known as differential GPS and is widely used in marine navigation, and has been for years. The idea is that a fixed location station broadcasts what it is receiving from GPS, allowing other stations to correct for errors. One broadcasts both the digital data and the signal phase, allowing very high accuracy. It has been proposed for aviation, and I believe is in use for some landing systems.
Rather than imagining a conspiracy by the U.S. aerospace lobby to prevent a foreign technology from coming in (when, after all, consumers all over the US are already using an equivalent technology), realize that the vested interest against such a system is the air traffic control system, in the U.S the FAA. The FAA has, over the decades, significantly increased its air traffic control responsibilities, to the detriment of general aviation. They have a large bureaucratic fiefdom at stake here that they do not want to lose.
The problem with extrapolating effects from microwave radiation is that, although it is "radiation", it is non-ionizing radiation. In other words, the photon energy is too low to strip electrons from atoms. Thus it can only cause heating, and low levels at that. Sure, it is slightly possible that resonance effects may cause differential heating that could cause a slight problem, but I doubt there is any *significant* risk here. This subject has been studied for many decades, and there is no significant evidence that RF exposure at levels much higher than you get from a cell phone has any negative effects.
If you want to worry about something, worry about how your driving skills decrease while you are using the microwave. The risk is orders of magnitude higher.
You can achieve very high spectral efficiencies if you use very high power. To send 2 bits/hz, just send the plain old signal single sideband AM (the bandwidth of a 1kbps baseband signal is 500hz). To send 4 bits/hz, you could (as an example), use four different voltage levels. For5 bits/Hz, use 8 levels, etc. Furthermore, you can modulate phase and amplitude independently. Doubling the data rate again.
There are a myriad of modulation schemes (and related coding schemes) for achieving spectral efficiency. Basically, beyond the simple stuff (filter off the extra sideband, use phase AND amplitude), they achieve that efficiency by encoding data in more subtle aspects of the signal (read: more noise sensitive). This VMSK/2 scheme appears to be one which generates smaller sidebands by modulating the signal less. As such, it requires higher power to achieve it's spectral efficienty (ignore the claims of lower power - that's *per carrier* in the signal, but they use more carriers).
Note also that increased spectral efficiency is only part of the issue. In the modern cellular world, you need increased efficiency in terms of bits per Hz per square kilometer (i.e. you share the frequencies over an area). A requirement for higher power (which really means a requirement for higher signal-to-noise ratio) reduces the areal sharing that you can achieve.
Ultimately, you can't beat Shannon's laws. If you can, you can also make perpetual motion machines and free energy (yeah, it's a stretch, but the connection is there).
Since this company is selling multilevel marketing, I am more than a bit suspicious of any claims. Multilevel marketing schemes are too often fraudulent and based on overblown claims. I am not saying these guys are wrong, just that their approach is suspicious.
As far as comments on here on FM signal bandwidth... FM stations use a 200kHz wide channel. A stereo signal uses a composite of simple FM for the Left+Right signal, and a subcarrier at 42kHz carrying Left-Right. There is still room left in the spectrum for an additional subcarrier (or more) - which is where you find service such as Muzak. Plain old FM mono is a *spread-spectrum* modulation scheme, in that the RF signal is occupies significantly more bandwidth than the modulating signal.
The librarian association which puts out recommended book lists already engages in significant censorship. Their lists are strongly biased towards modern political correctness, and leave out almost all works by libertarian and conservative authors or about traditional religion. THIS is a form of censorship that is just as bad as internet filters on their computers. In spit of this broad trend, I hear little from "sophisticated" with-it net-heads about what this issue.
Our local Phoenix, AZ library has such a bias. If you want hundreds of books on such politically correct causes as alternative sexual preferences, or wiccan religion, you can find them there. But try finding books by well respected conservative writers. We have donated books by same, only to find them on the un-needed books sale without ever having been on the shelves.
Net censorship is not the only censorship. And the religious right are not the only major censors around.
The 800 and 1900 MHZ use both CDMA *and* TDMA, and the 800 also use analog.
The lack of standards in the US market has had the benefit to the world of allowing CDMA, a technology which would not have ever succeeded in a regulatory approach, to prove its value. Unfortunately, the rest of the world will go to it (in GSM) while the US continues with all sorts of different "standards." My carrier (Verizon) offers unlimited roaming (in their service areas, which doesn't help much when I am tornado chasing) - but ONLY if I have a 3 mode (yes, THREE mode) phone - that is, a phone that can do three standards!
The US has the following standards in use:
Analog 800
CDMA 800 (which I use)
TDMA 800 (I think this is in use)
CDMA 1900
TDMA 1900
GSM
Furthermore, in order to hold onto market share, the carriers make it difficult for one to use a COMPATIBLE phone if it isn't the same model that they sell. Thus they lock you in by your investment in hardware. I have an old CDMA 1900 phone laying around because I switched from Sprint to Verizon (to get a no longer offered true nationwide no roaming plan).
When you add in accessories you may buy (I have a speakerphone and an expensive Qualcomm modem card), it is quite a mess.
I think the article cited probably does a poor job of explaining the ideas. But there is a way to look at this that is, in a sense, similar to the "anthropic principle."
The anthropic principle addresses the issue of how the laws of the universe happen to be "just right" to create a system in which our form of life can evolve. Tiny variations in physical constants would make such life impossible. Thus the very values of the constants are improbable, which presents a challenge. One answer is that of all the zillions of possible universes, we can only exist and ask such questions in the one that gets the values right.
Quantum evolution could be viewed in a similar manner.
First, a short explanation of the "multiverse" as I understand the concept.
Every time an quantum event occurs, it is a "choice" among possible events: the electron either did or did not tunnel; the nucleus did or did not engage in a certain decay. Thus every one of these events "forks" the universe into two or more universes. In one universe, the electron tunneled, while in the other one, it did not. The number of these events is enormous, of course, since every macroscopic event is composed of huge numbers of these quantum choices. The number of universes in the multiverse is thus immense, as each choice increases the number of universes by the product of how many universes it occurs in times the number of outcomes.
Going back to quantum evolution and the anthropic principle, it could be stated that:
We exist in the universes of the multiverse where the "correct" evolutionary events happened.
The arguments that there do not exist enough trials (random choices) for evolution to have achieved the current result are based on *one* universe. But in the multiverse quantum view, this number of universes is multiplied immensely, greatly improving the probabilities.
It is not necessary to translate the prior art into "patent" language. In fact, "patent language" is not required in a patent at all. Take a look at some FCC patents on radio direction finding for an example. If the language makes it totally clear how to create the "invention" to someone competent in the field (in this case software), it should be enough to be usable as prior art.
The problem with this whole issue is that the issuance of a patent by the USPTO carries a legal implication that the patent is correct. That is, you have to challenge it in court in order to get rid of the darned thing. And that's expensive! So as long as the USPTO continues to fail in their responsibility to adequately vet these patents, companies will acquire them and use them for leverage - even if they are invalid!
The result: large software companies will be able to stifle the new guy, while not hurting each other. They will have a stable of patents to cross-license to each other, but us poor schmucks who cannot afford to patent a bunch of obvious ideas will be lawyer-bait to them.
This dangerous trend could cripple the creative engine that has given us so much - the software entrepreneur!
The models used in meteorology have no sophisticated techniques other than pure numerical analysis. They are based on fundamental physics equations and do not have significant heuristics or neural nets.
They are finite element simulators. The atmosphere is divided into 3 dimensional sections of a certain (fairly low) resolution (32km is the best I know of for a synoptic model). Input data is way too sparse, so they are initialized (called analysis in meteorological terms) with that data, interpolations, etc. The equations of fluid dynamics, thermodynamics, radiation, etc are evaluated for each cell (and its neighbor interactions) producing a new state. This is iterated.
While chaos puts upper limits on accurate forecasts, there are far more mundane issues that cause the most problems. Lack of data is the worst - especially upper air and oceanic data. Upper air data is sampled over the US at 400km grid points twice a day. Samples over the ocean are missing. Additional upper air data is provided from instruments on commercial aircraft, which telemeter that data for flight operations. Satellite remote sensing can provide some missing data, but it is very hard to get accurate data on different layers of the atmosphere itself - especially from geosynchronous orbit, which is the only place that has continuous wide-area coverage.
You can see the satellite derived examples at url's like:
Additional problems are caused by lack of computational power. Even if fine grained data was available, the models require relatively large grid sizes in order to be able to compute the weather faster than it is actually happening!
Models also are poor in handling terrain, often using "cheats" in parameters rather than physics and fine grained modelling to adapt. Terrain has significant effects on the weather in much of the west, and those effects extend to the larger scale systems.
Also, long range models must be global in scope, and the difficulties I have described in US data are much more severe in many other parts of the world.
The new computer was touted as being able to forecast weather down to the "county" size up to 14 days. That is completely absurd, given the difficulties cited above. In fact, small scale forecasting (meso-scale) does not exist in the forecast models (although there are small scale models used for understanding as opposed to forecasting). Forecasting of certain kinds of severe weather is very difficult, and today has many unknowns about the mechanisms. For example, when the national doppler system was set up, it was believed that almost all tornados came from supercell thunderstorms, and that most supercells with particular characteristics produce tornados. As it turns out, this is wrong. Something like 50% of tornados (higher percentage of damaging tornados) are produced by classical supercells, but most supercells do not produce tornados. Thus today there is a high false warning rate on radar-generated tornado warnings (one reason that spotters are still very important), and also a significant false negative rate (missed warnings).
Recent research indicates that small scale atmospheric features at or near the surface have significant impact on tornadogenesis, and they cannot be seen (or seen well) by the radar or picked up by the normal data networks.
Finally, to illustrate the difficulty in forecasting truly severe weather, consider the deadly Oklahoma tornado outbreak of May 3, 1999. It was not apparent that the risk of tornados was high until that day, and the level that the outbreak would generate was not apparent until just a few hours before the event. Models were able to show that morning that there was a potential for tornados, but it took real time analysis of real time data by meteorologists in order to do the actual forecast. Disclaimer: I am not a meteorologist, but I am a tornado chaser who pays attention to what the real experts are saying and doing.
To use a radio analogy, AOL is the "CB" of the internet. In the radio world, it used to be necessary to study the technology in order to get a ham license and get on the air. When CB came along, anyone could do so, and millions did. The results were similar to that of AOL - new capabilities that could be enjoyed by many, but lots of "pollution" by less than savory individuals.
I know a number of AOL users who have virtually no knowledge of either the internet or computers. AOL, through it's hand holding consumer oriented approach gives them what they need to take advantage of the net. Without AOL or others like them, the net would remain a tool and toy for us netgeeks and computer professionals.
The WTO is already behind it. The US already signed treaties adopting international patent standards (such as 20 year from invention rather than 17 year from issue patent lifetimes).
As an early user and supporter of Java, I can understand why Microsoft might drop it. Java simply does not fit into large and important portions of the computer world.
Furthermore, that lack of fit significantly reduces it's usefullness in many important real-world problems.
[Aside: the traditional world (legacy and business applications world so sneered at by geekdom) needs something like Java. For those who say "screw the traditional world" I would say... that's fine for you... but most of the value in today's software systems is in those legacy systems and will be for a long time. The Airline Reservation Systems, for example, were designed in mid 60's, coded in 360 assembly language, and are still the highest performing and most valuable OLTP systems in the civilian world.
Java started as a standalone software universe - originally intended to be an OS and a language for set top boxes (anyone who says it was a web innovation is clueless). Thus there were no concerns about inter-language interfaces - any other language was in a different computer and you interfaced via communications. Furthermore, this orientation towards a special purpose environment (embedded systems with a single vendor for all infrastructure software - language and OS) is hardly suitable for the general purpose world in which most of us would like to be able to use Java.
Many complex systems, and virtually all legacy systems, require languages to have straightforward linkages to each other. I suspect this is one of the reasons for the success of C++ - you get an object oriented language that drops gracefully into programs written in another language. But, one cannot do that gracefully when one of the languages runs in it's own virtual machine, and perceives itself to be the allocator of all resources (CPU, memory, etc). The latter approach violates principles long known to be useful in complex, long-lived systems.
For example, in our Unix environment we want to write new library functions in Java. Sorry.... doesn't work if you want to call them from C or C++ or any other programming language! Those functions live in their own JVM universe.
Microsoft, which really did innovate (in a blundering long term sort of way) with their component architecture, has trouble fitting Java into their model.
Also, since Java is owned by Sun, and Scott McNealy makes lots of noise about displacing Microsoft, Java has become a football in a game of macho posturing. This, combined with Sun's natural motivation to control it's own invention, creates poor incentives for the creation of a standard tool - especially one which is general purpose. It also leaves it's users just as dependent on a single vendor (Sun) as they are with their previous vendor (The Borg in Seattle).
Let's look at another issue: Java in browsers. Some years back I was erroneously led to believe (by all the hype, and by my own wishes) that Java was a great way to embed applications in the most ubiquitous of machine independent environments: the browser.
But look around... how many good apps are done that way? Not many. In fact, Sun *actively* discouraged the use of Java applets, informing user's that distributed applications should include installed Java applications, not applets. Sun and Netscape failed to create the real Microsoft killer (which Brad Silverberg of Microsoft also wanted to create, BTW) - a browser that was a *good* environment for sophisticated GUI applications. Sun wanted one to use it's GUI (which is not gracefully embedded in browsers... try printing an HTML page with an applet in it!). Netscape had other fish to fry. Nobody (except Microsoft, which was much smarter about this) recognized that real humans (as opposed to Silicon Valley geeks with T-1's to their homes) couldn't download applet's in a flash, and Java geeks didn't seem to understand that sophisticated applications take a *lot* of code - especially in big libraries. Of course, the Java propaganda about tiny applet's increased that confusion. Finally, the event handling and DOM models of the browser's were pathetic. Even today, IE5 (currently the most advanced widely available browser) is so buggy and incomplete that it is a nightmare environment for embedded apps.
So... Java on the web has been mostly reduced to cute little applets that animate a graphic or some other low-value features. Most major internet sites don't use it at all.
At the same time, Java doesn't fit inside of multi-language processes, so it isn't there.
The result... Java is a specialized tool... it works best when it works only with other Java. It is exclusive and closed, not inclusive and open. It is a very good and pleasing language, in a relatively weak environment.
And all of that is a great shame. I *want* the advantages of Java. I *want* to code in Java, not C or C++ or JavaScript or XSL or Perl or....
But I cannot always wear the Java straightjacket that is required to make good use of Java!
Finally, I should comment that Java is being used to create very good applications. If one is able and willing to use Java under it's own terms, it is a powerful (if immature) tool and well worth a lot of enthusiam. But only If....
When you agree to the End User License Agreement (EULA), which you must in order to use the product, you waive your rights to sue on any sort of quality grounds.
Until a lawyer with cojones tests the argument that EULA is an invalid contract because you have *no choice* but to agree to it (i.e. the contract was made under duress), nothing will happen here.
I am not a lawyer, but it seems to me that the "no choice" argument is true enough (in light of the monopoly) that it should be able to break the EULA. In fact, it might be possible to take on the whole industry this way, since EULA's in general are terribly abusive.
No. Patent law is very clear on this. Only the inventor can patent a discovery. There may be issues about who is the real inventory, but evidence (publications, witnessed lab books, etc) are used to resolve that if it comes up.
Microsoft's real monopoly is in their API's (and the applications captive to it).
As far as X86 captivity, note that NT runs on the ALPHA as well as the Intel.
The cost of porting Windoze or NT to a non-Intel platform is not likely to be very significant to Microsoft. Likewise, applications (if properly coded, and not super high performance assembly language games can be fairly easily ported.
At my company, we long ago developed an OS API (which ran on top of whatever OS it was on) and lots of applications that are still runing on it. We have ported it to all manner of platforms, and it usually isn't a big deal. We went from an Intel platform to an RS6000 in two days, with hundreds of thousands of lines of code.
The *kernel* portion of an OS is the main area where porting has to be done... in a well designed OS most hardware dependencies are isolated into the Kernel.
Microsoft's "integration" of IE4/5 is hardly an argument for allowing them to continue their current practice of stuffing all sorts of applications into their "Operating System."
In fact, Microsoft has slowly changed the meaning of "Operating System" to be "Any bag of software that happens to have a kernel hidden somewhere within it."
Only a marketeer consider any bag of software containing a kernel to be an OS.
By confusing the meaning of the term "Operating System,"Microsoft is able to mislabel some of their monopolistic practices as "innovating" what should be application into the operating system.
An OS is fundamentally a facility which provides applications programs access to common resources via an API. Good software practice keeps the API relatively simple. Additional layers of functionality are then built *on top of the API* - not inside of the OS. Microsoft, on the other hand, defines the "operating system" as whatever ships under the operating system license.
If we deconstruct a Windows system, we find:
A kernel - the low level portion of the system which (in theory) provides secure allocation of resources such as CPU, memory and more abstract things.
A GUI - an applications library which provides graphical user interface functions. This is what most people think of when they envision "Windows." It is not an OS.
Utilities - applications which provide utility functions for users of the OS. These normally "are" considered part of an OS even if they are outside the kernel API.
Applications - all sorts of other programs which use the API, such as SQL Server, Word, IE, etc.
I just hope the world gets over the intentionally muddled definition of an "Operating System" that Microsoft puts forth.
Since it has been found that Microsoft has a monopoly on Windows, one can argue that the EULA is not a voluntary contract. Any involuntary contract is not valid.
Any time now, I expect a class action lawyer slime to nail Microsoft on that principle, making them liable for all of the bugs and security problems that their EULA supposedly protects them from.
In any modern system, the API means more than just operating system calls. To me, it includes the formats and protocols. More precisely, it involves any interface whereby clients request services, whether it be by subroutine call, ODBC, XML, HTTP, proprietary combinations of formats, protocols, etc.
It is about time that someone mentioned the natural monopoly aspect of this issue! The natural monopoly is what enables Microsoft to increase its market share while delivering inferior product. The natural monopoly is the crux of the issue.
By comparison, the behavior of Microsoft (and the related punishment) is not very important, at least in terms of the future of our industry. If Bill hadn't achieved the monopoly and used the monopolistic tactics thus available to him, someone else would have. Punishing Bill and his stockholders may be appropriate, but dealing with the natural monopoly is the only important issue here.
A natural monopoly arises when competition is far less efficient than a monopoly, creating huge barriers of entry and enormous incentives to merge. Examples of this include water delivery to homes, cable television (pre-RF competition), and power distribution. In these cases, the duplication of expense necessary for competition simply makes no economic sense. Thus in a free market only one system will survive, whether by merger or slaughter. Nobody expects a free market in municipal water systems, and experience has shown that cable will merge rather than compete with other cable. Even in the climate of deregulation of electric power, nobody is foolish enough to deregulate the delivery of power.
If we look at today's situation with operating systems, we see the same economic situation. More OS API's translate directly into increased costs to application producers. Those producers thus must choose what platforms they will support. Their decision will be heavily influenced by the popularity of the competing platforms. But the popularity of those platforms is strongly influenced by the number of available applications. This creates a positive feedback situation which will naturally "lock-up" on one OS API. This creates an enormous barrier to entry. This was well documented in the findings.
We would all like to believe that software engineering will overcome this phenomenon, but there is little evidence that it will in the near future. There are many approaches: standard API's, "write once, run everywhere," open source, standards committes, etc. But the real world of automating human systems does not allow such simplistic, if sometimes elegant approaches to conquer the more powerful natural monopoly drivers. Until technology advances in a manner that removes the cause of OS natural monopoly, we must deal with that monopoly as it is.
I would cast my vote for vertical dismemberment of Microsoft. Microsoft's practice of defining almost every product into the "operating system" should be prohibited. SQL Server, IE, Office 2000, etc should be kept out of the OS (as computer science would recommend in any case) and should be owned by a company other than the one which controls the OS and its API.
Thus Bill's Database Inc.can go head-to-head with Larry's Other Database Inc, etc.
Whether Bill's Buggy OS Inc needs further regulation is a more complex matter, on which my own opinions oscillate at least once per day.
While there has been much fuss about the finding that Microsoft is a monopoly (duh), and the government has been loudly promising punishment, I think there is a critical issue being ignored: Is Windows an example of a natural monopoly?
A natural monopoly is one where the economics of a situation, independent of the behavior of the players, forces evolution into a monopoly situation. Ultimately this is because competition in those areas is extremely inefficient economically. Examples include water distribution in a city, wired-line telephone service, and (to a lesser extent) cable TV.
Natural monopolies are usually heavily regulated because they develop the characteristics of monopoly: predatory, anti-innovation, over-priced and under-efficient, and slow to change.
The history of computer operating systems seems to support the idea that they are also natural monopolies. In the last 35 years (my period of experience in the field), I know of almost no cases where, for one kind of hardware, there were more than one operating system that ran a large number of applications. MSDOS, and later Windoze, are just the latest example: if you want a diversity of PC applications, other than a few specialty ones, you need a Wintel system. If you want to make money selling software, and you are not selling a niche product, you will no doubt develop it first for Windoze. It may never be worth your while (as a business) to port it to LinBeBSSolix - even if that would be far more satisfying.
This sort of consideration leads to a positive feedback effect. The application developer targets his limited development resources to the platform with the largest potential customer base. As many application developers do this, the "favored platform" nature of the OS increases. Thus even without predatory practices, Microsoft or some company like them would most likely become the operating system monopoly.
Historically, this was also true of IBM DOS and later IBM OS-360 and later MVS. If you had a mainframe application need, you had to buy that operating sytem (even if you could buy the machine from Hitachi or someone else) to run it on. And this was for the same reason: OS-360 became the leader, and (on mainframes) it still is - 30 years later!
The feedback effect to select a single platform is powerful. It may also be beneficial - for the most part it is more efficient for the world to focus on the development of applications for one platform. Of course, it tends to limit innovation, especially with Microsoft's practice of bundling their own applications to their monopoly system, and copying (or sometimes buying) superior 3rd party technology when it comes along.
If, in fact, OS's are natural monopolies (and they have been and will be for a while), then one should consider "common carrier" or "utility" types of regulation for them. I would like to see Microsoft split into multiple companies - one for Windwos/DOS, and others for applications, service businesses, etc. Besides, based on history (Standard Oil is a good example), it will make my Microsoft stock go way up (although that is a mere side effect).
I have been wondering why the ABM approach these days is to ram the incoming target with an interceptor, destroying that target by the high kinetic energy of a multiple km/sec collision.
It would seem that this would make aiming harder than the older method used by the Patriot and other anti-aircraft/anti-missile systems. Those systems use an explosive, detonated at closest approach, to throw a spray of high velocity projectiles at the incoming target. This "shotgun" approach would seem to me to have a higher kill probability. In the past, we had thousands of nuclear armed interceptors, so the same issue applies to that technology. For example, fleet defense doctrine against massed aircraft attack was to use nuclear missiles to destroy the aircraft... and almost every US combatant, in the past, carried these missiles!
So, does anyone know why they now use kinetic kill with a single maneuverable projectile?
The Russians already have a working and recently (80's) upgraded ABM system. It is no surprise that they object to this system.
I do not believe that any ABM system in the forseeable future will be able to destabilize the nuclear "balance of terror" because it would have to work almost perfectly to avoid unacceptable damage, and that is not going to happen.
However, it has a stabilizing effect by increasing the uncertainty of success of a first strike. For a first strike to be successful, it must destroy most (really, almost all) of the target country's retaliatory force. If only a couple of MIRV'ed missiles were left after a first strike, it would be enough to play havoc on the attacker's cities.
The encryption scheme, claimed as "unbreakable", in fact is subject to very standard cracking techniques. One time key schemes have been broken many times - by attacking the source of the one time pad. For example, historical schemes have used paragraphs from obscure books. Attacks consist of: (1) looking for the paragraph, or (2) using the non-randomness (low entropy) of human language to statistically crack the code.
The latter approach should work pretty well with an audio source (a sound card is used by the programs describe). Audio is usually highly non-random. It depends on what is connected to the audio board. If it is environmental noise, it will probably have certain frequencies emphasized. If it is music, it is already highly structured (except, perhaps, for certain modern rock "music" which seems to me to be almost flat spectrum:-). Voice is likewise highly structured.
Given that the authors claim it is unbreakable, I would immediately suspect that they are cryptographic novices, and thus be suspicious of the details of their algorithms in addition to their poor choice of randomness.
If they had used a semirandom source (like audio or key click timings or something), and THEN used a solid cypher to encrypt it to produce the one-time key, I would be much happier.
Slashdot Mirror
Civilian aircraft in the US are NOT required to carry transponders, except when in controlled airspace.
Rather than imagining a conspiracy by the U.S. aerospace lobby to prevent a foreign technology from coming in (when, after all, consumers all over the US are already using an equivalent technology), realize that the vested interest against such a system is the air traffic control system, in the U.S the FAA. The FAA has, over the decades, significantly increased its air traffic control responsibilities, to the detriment of general aviation. They have a large bureaucratic fiefdom at stake here that they do not want to lose.
The problem with extrapolating effects from microwave radiation is that, although it is "radiation", it is non-ionizing radiation. In other words, the photon energy is too low to strip electrons from atoms. Thus it can only cause heating, and low levels at that. Sure, it is slightly possible that resonance effects may cause differential heating that could cause a slight problem, but I doubt there is any *significant* risk here. This subject has been studied for many decades, and there is no significant evidence that RF exposure at levels much higher than you get from a cell phone has any negative effects.
If you want to worry about something, worry about how your driving skills decrease while you are using the microwave. The risk is orders of magnitude higher.
You can achieve very high spectral efficiencies if you use very high power. To send 2 bits/hz, just send the plain old signal single sideband AM (the bandwidth of a 1kbps baseband signal is 500hz). To send 4 bits/hz, you could (as an example), use four different voltage levels. For5 bits/Hz, use 8 levels, etc. Furthermore, you can modulate phase and amplitude independently. Doubling the data rate again.
There are a myriad of modulation schemes (and related coding schemes) for achieving spectral efficiency. Basically, beyond the simple stuff (filter off the extra sideband, use phase AND amplitude), they achieve that efficiency by encoding data in more subtle aspects of the signal (read: more noise sensitive). This VMSK/2 scheme appears to be one which generates smaller sidebands by modulating the signal less. As such, it requires higher power to achieve it's spectral efficienty (ignore the claims of lower power - that's *per carrier* in the signal, but they use more carriers).
Note also that increased spectral efficiency is only part of the issue. In the modern cellular world, you need increased efficiency in terms of bits per Hz per square kilometer (i.e. you share the frequencies over an area). A requirement for higher power (which really means a requirement for higher signal-to-noise ratio) reduces the areal sharing that you can achieve.
Ultimately, you can't beat Shannon's laws. If you can, you can also make perpetual motion machines and free energy (yeah, it's a stretch, but the connection is there).
Since this company is selling multilevel marketing, I am more than a bit suspicious of any claims. Multilevel marketing schemes are too often fraudulent and based on overblown claims. I am not saying these guys are wrong, just that their approach is suspicious.
As far as comments on here on FM signal bandwidth... FM stations use a 200kHz wide channel. A stereo signal uses a composite of simple FM for the Left+Right signal, and a subcarrier at 42kHz carrying Left-Right. There is still room left in the spectrum for an additional subcarrier (or more) - which is where you find service such as Muzak. Plain old FM mono is a *spread-spectrum* modulation scheme, in that the RF signal is occupies significantly more bandwidth than the modulating signal.
The librarian association which puts out recommended book lists already engages in significant censorship. Their lists are strongly biased towards modern political correctness, and leave out almost all works by libertarian and conservative authors or about traditional religion. THIS is a form of censorship that is just as bad as internet filters on their computers. In spit of this broad trend, I hear little from "sophisticated" with-it net-heads about what this issue.
Our local Phoenix, AZ library has such a bias. If you want hundreds of books on such politically correct causes as alternative sexual preferences, or wiccan religion, you can find them there. But try finding books by well respected conservative writers. We have donated books by same, only to find them on the un-needed books sale without ever having been on the shelves.
Net censorship is not the only censorship. And the religious right are not the only major censors around.
The 800 and 1900 MHZ use both CDMA *and* TDMA, and the 800 also use analog.
The lack of standards in the US market has had the benefit to the world of allowing CDMA, a technology which would not have ever succeeded in a regulatory approach, to prove its value. Unfortunately, the rest of the world will go to it (in GSM) while the US continues with all sorts of different "standards." My carrier (Verizon) offers unlimited roaming (in their service areas, which doesn't help much when I am tornado chasing) - but ONLY if I have a 3 mode (yes, THREE mode) phone - that is, a phone that can do three standards!
The US has the following standards in use:
Analog 800
CDMA 800 (which I use)
TDMA 800 (I think this is in use)
CDMA 1900
TDMA 1900
GSM
Furthermore, in order to hold onto market share, the carriers make it difficult for one to use a COMPATIBLE phone if it isn't the same model that they sell. Thus they lock you in by your investment in hardware. I have an old CDMA 1900 phone laying around because I switched from Sprint to Verizon (to get a no longer offered true nationwide no roaming plan).
When you add in accessories you may buy (I have a speakerphone and an expensive Qualcomm modem card), it is quite a mess.
I think the article cited probably does a poor job of explaining the ideas. But there is a way to look at this that is, in a sense, similar to the "anthropic principle."
The anthropic principle addresses the issue of how the laws of the universe happen to be "just right" to create a system in which our form of life can evolve. Tiny variations in physical constants would make such life impossible. Thus the very values of the constants are improbable, which presents a challenge. One answer is that of all the zillions of possible universes, we can only exist and ask such questions in the one that gets the values right.
Quantum evolution could be viewed in a similar manner.
First, a short explanation of the "multiverse" as I understand the concept.
Every time an quantum event occurs, it is a "choice" among possible events: the electron either did or did not tunnel; the nucleus did or did not engage in a certain decay. Thus every one of these events "forks" the universe into two or more universes. In one universe, the electron tunneled, while in the other one, it did not. The number of these events is enormous, of course, since every macroscopic event is composed of huge numbers of these quantum choices. The number of universes in the multiverse is thus immense, as each choice increases the number of universes by the product of how many universes it occurs in times the number of outcomes.
Going back to quantum evolution and the anthropic principle, it could be stated that:
We exist in the universes of the multiverse where the "correct" evolutionary events happened.
The arguments that there do not exist enough trials (random choices) for evolution to have achieved the current result are based on *one* universe. But in the multiverse quantum view, this number of universes is multiplied immensely, greatly improving the probabilities.
It is not necessary to translate the prior art into "patent" language. In fact, "patent language" is not required in a patent at all. Take a look at some FCC patents on radio direction finding for an example. If the language makes it totally clear how to create the "invention" to someone competent in the field (in this case software), it should be enough to be usable as prior art.
The problem with this whole issue is that the issuance of a patent by the USPTO carries a legal implication that the patent is correct. That is, you have to challenge it in court in order to get rid of the darned thing. And that's expensive! So as long as the USPTO continues to fail in their responsibility to adequately vet these patents, companies will acquire them and use them for leverage - even if they are invalid!
The result: large software companies will be able to stifle the new guy, while not hurting each other. They will have a stable of patents to cross-license to each other, but us poor schmucks who cannot afford to patent a bunch of obvious ideas will be lawyer-bait to them.
This dangerous trend could cripple the creative engine that has given us so much - the software entrepreneur!
The models used in meteorology have no sophisticated techniques other than pure numerical analysis. They are based on fundamental physics equations and do not have significant heuristics or neural nets.
/ gifs/caspac.gif / skewt/gifs/kphx.gif s /trwnd96.gif s npw.gif
They are finite element simulators. The atmosphere is divided into 3 dimensional sections of a certain (fairly low) resolution (32km is the best I know of for a synoptic model). Input data is way too sparse, so they are initialized (called analysis in meteorological terms) with that data, interpolations, etc. The equations of fluid dynamics, thermodynamics, radiation, etc are evaluated for each cell (and its neighbor interactions) producing a new state. This is iterated.
While chaos puts upper limits on accurate forecasts, there are far more mundane issues that cause the most problems. Lack of data is the worst - especially upper air and oceanic data. Upper air data is sampled over the US at 400km grid points twice a day. Samples over the ocean are missing. Additional upper air data is provided from instruments on commercial aircraft, which telemeter that data for flight operations. Satellite remote sensing can provide some missing data, but it is very hard to get accurate data on different layers of the atmosphere itself - especially from geosynchronous orbit, which is the only place that has continuous wide-area coverage.
You can see the satellite derived examples at url's like:
http://orbit-net.nesdis.noaa.gov/goes/soundings
http://orbit-net.nesdis.noaa.gov/goes/soundings
http://orbit-net.nesdis.noaa.gov/goes/winds/gif
http://cimss.ssec.wisc.edu/goes/realtime/latest
Additional problems are caused by lack of computational power. Even if fine grained data was available, the models require relatively large grid sizes in order to be able to compute the weather faster than it is actually happening!
Models also are poor in handling terrain, often using "cheats" in parameters rather than physics and fine grained modelling to adapt. Terrain has significant effects on the weather in much of the west, and those effects extend to the larger scale systems.
Also, long range models must be global in scope, and the difficulties I have described in US data are much more severe in many other parts of the world.
The new computer was touted as being able to forecast weather down to the "county" size up to 14 days. That is completely absurd, given the difficulties cited above. In fact, small scale forecasting (meso-scale) does not exist in the forecast models (although there are small scale models used for understanding as opposed to forecasting). Forecasting of certain kinds of severe weather is very difficult, and today has many unknowns about the mechanisms. For example, when the national doppler system was set up, it was believed that almost all tornados came from supercell thunderstorms, and that most supercells with particular characteristics produce tornados. As it turns out, this is wrong. Something like 50% of tornados (higher percentage of damaging tornados) are produced by classical supercells, but most supercells do not produce tornados. Thus today there is a high false warning rate on radar-generated tornado warnings (one reason that spotters are still very important), and also a significant false negative rate (missed warnings).
Recent research indicates that small scale atmospheric features at or near the surface have significant impact on tornadogenesis, and they cannot be seen (or seen well) by the radar or picked up by the normal data networks.
Finally, to illustrate the difficulty in forecasting truly severe weather, consider the deadly Oklahoma tornado outbreak of May 3, 1999. It was not apparent that the risk of tornados was high until that day, and the level that the outbreak would generate was not apparent until just a few hours before the event. Models were able to show that morning that there was a potential for tornados, but it took real time analysis of real time data by meteorologists in order to do the actual forecast.
Disclaimer: I am not a meteorologist, but I am a tornado chaser who pays attention to what the real experts are saying and doing.
To use a radio analogy, AOL is the "CB" of the internet. In the radio world, it used to be necessary to study the technology in order to get a ham license and get on the air. When CB came along, anyone could do so, and millions did. The results were similar to that of AOL - new capabilities that could be enjoyed by many, but lots of "pollution" by less than savory individuals.
I know a number of AOL users who have virtually no knowledge of either the internet or computers. AOL, through it's hand holding consumer oriented approach gives them what they need to take advantage of the net. Without AOL or others like them, the net would remain a tool and toy for us netgeeks and computer professionals.
The WTO is already behind it. The US already signed treaties adopting international patent standards (such as 20 year from invention rather than 17 year from issue patent lifetimes).
Furthermore, that lack of fit significantly reduces it's usefullness in many important real-world problems.
[Aside: the traditional world (legacy and business applications world so sneered at by geekdom) needs something like Java. For those who say "screw the traditional world" I would say... that's fine for you... but most of the value in today's software systems is in those legacy systems and will be for a long time. The Airline Reservation Systems, for example, were designed in mid 60's, coded in 360 assembly language, and are still the highest performing and most valuable OLTP systems in the civilian world.
Java started as a standalone software universe - originally intended to be an OS and a language for set top boxes (anyone who says it was a web innovation is clueless). Thus there were no concerns about inter-language interfaces - any other language was in a different computer and you interfaced via communications. Furthermore, this orientation towards a special purpose environment (embedded systems with a single vendor for all infrastructure software - language and OS) is hardly suitable for the general purpose world in which most of us would like to be able to use Java.
Many complex systems, and virtually all legacy systems, require languages to have straightforward linkages to each other. I suspect this is one of the reasons for the success of C++ - you get an object oriented language that drops gracefully into programs written in another language. But, one cannot do that gracefully when one of the languages runs in it's own virtual machine, and perceives itself to be the allocator of all resources (CPU, memory, etc). The latter approach violates principles long known to be useful in complex, long-lived systems.
For example, in our Unix environment we want to write new library functions in Java. Sorry.... doesn't work if you want to call them from C or C++ or any other programming language! Those functions live in their own JVM universe.
Microsoft, which really did innovate (in a blundering long term sort of way) with their component architecture, has trouble fitting Java into their model.
Also, since Java is owned by Sun, and Scott McNealy makes lots of noise about displacing Microsoft, Java has become a football in a game of macho posturing. This, combined with Sun's natural motivation to control it's own invention, creates poor incentives for the creation of a standard tool - especially one which is general purpose. It also leaves it's users just as dependent on a single vendor (Sun) as they are with their previous vendor (The Borg in Seattle).
Let's look at another issue: Java in browsers. Some years back I was erroneously led to believe (by all the hype, and by my own wishes) that Java was a great way to embed applications in the most ubiquitous of machine independent environments: the browser.
But look around... how many good apps are done that way? Not many. In fact, Sun *actively* discouraged the use of Java applets, informing user's that distributed applications should include installed Java applications, not applets. Sun and Netscape failed to create the real Microsoft killer (which Brad Silverberg of Microsoft also wanted to create, BTW) - a browser that was a *good* environment for sophisticated GUI applications. Sun wanted one to use it's GUI (which is not gracefully embedded in browsers... try printing an HTML page with an applet in it!). Netscape had other fish to fry. Nobody (except Microsoft, which was much smarter about this) recognized that real humans (as opposed to Silicon Valley geeks with T-1's to their homes) couldn't download applet's in a flash, and Java geeks didn't seem to understand that sophisticated applications take a *lot* of code - especially in big libraries. Of course, the Java propaganda about tiny applet's increased that confusion. Finally, the event handling and DOM models of the browser's were pathetic. Even today, IE5 (currently the most advanced widely available browser) is so buggy and incomplete that it is a nightmare environment for embedded apps.
So... Java on the web has been mostly reduced to cute little applets that animate a graphic or some other low-value features. Most major internet sites don't use it at all.
At the same time, Java doesn't fit inside of multi-language processes, so it isn't there.
The result... Java is a specialized tool... it works best when it works only with other Java. It is exclusive and closed, not inclusive and open. It is a very good and pleasing language, in a relatively weak environment.
And all of that is a great shame. I *want* the advantages of Java. I *want* to code in Java, not C or C++ or JavaScript or XSL or Perl or ....
But I cannot always wear the Java straightjacket that is required to make good use of Java!
Finally, I should comment that Java is being used to create very good applications. If one is able and willing to use Java under it's own terms, it is a powerful (if immature) tool and well worth a lot of enthusiam. But only If....
mesocyclonesd@tinyvital.com
When you agree to the End User License Agreement (EULA), which you must in order to use the product, you waive your rights to sue on any sort of quality grounds.
Until a lawyer with cojones tests the argument that EULA is an invalid contract because you have *no choice* but to agree to it (i.e. the contract was made under duress), nothing will happen here.
I am not a lawyer, but it seems to me that the "no choice" argument is true enough (in light of the monopoly) that it should be able to break the EULA. In fact, it might be possible to take on the whole industry this way, since EULA's in general are terribly abusive.
No. Patent law is very clear on this. Only the inventor can patent a discovery. There may be issues about who is the real inventory, but evidence (publications, witnessed lab books, etc) are used to resolve that if it comes up.
Microsoft's real monopoly is in their API's (and the applications captive to it).
As far as X86 captivity, note that NT runs on the ALPHA as well as the Intel.
The cost of porting Windoze or NT to a non-Intel platform is not likely to be very significant to Microsoft. Likewise, applications (if properly coded, and not super high performance assembly language games can be fairly easily ported.
At my company, we long ago developed an OS API (which ran on top of whatever OS it was on) and lots of applications that are still runing on it. We have ported it to all manner of platforms, and it usually isn't a big deal. We went from an Intel platform to an RS6000 in two days, with hundreds of thousands of lines of code.
The *kernel* portion of an OS is the main area where porting has to be done... in a well designed OS most hardware dependencies are isolated into the Kernel.
In fact, Microsoft has slowly changed the meaning of "Operating System" to be "Any bag of software that happens to have a kernel hidden somewhere within it."
Only a marketeer consider any bag of software containing a kernel to be an OS.
By confusing the meaning of the term "Operating System,"Microsoft is able to mislabel some of their monopolistic practices as "innovating" what should be application into the operating system.
An OS is fundamentally a facility which provides applications programs access to common resources via an API. Good software practice keeps the API relatively simple. Additional layers of functionality are then built *on top of the API* - not inside of the OS. Microsoft, on the other hand, defines the "operating system" as whatever ships under the operating system license.
If we deconstruct a Windows system, we find:
I just hope the world gets over the intentionally muddled definition of an "Operating System" that Microsoft puts forth.
Since it has been found that Microsoft has a monopoly on Windows, one can argue that the EULA is not a voluntary contract. Any involuntary contract is not valid.
Any time now, I expect a class action lawyer slime to nail Microsoft on that principle, making them liable for all of the bugs and security problems that their EULA supposedly protects them from.
In any modern system, the API means more than just operating system calls. To me, it includes the formats and protocols. More precisely, it involves any interface whereby clients request services, whether it be by subroutine call, ODBC, XML, HTTP, proprietary combinations of formats, protocols, etc.
It is about time that someone mentioned the natural monopoly aspect of this issue! The natural monopoly is what enables Microsoft to increase its market share while delivering inferior product. The natural monopoly is the crux of the issue.
By comparison, the behavior of Microsoft (and the related punishment) is not very important, at least in terms of the future of our industry. If Bill hadn't achieved the monopoly and used the monopolistic tactics thus available to him, someone else would have. Punishing Bill and his stockholders may be appropriate, but dealing with the natural monopoly is the only important issue here.
A natural monopoly arises when competition is far less efficient than a monopoly, creating huge barriers of entry and enormous incentives to merge. Examples of this include water delivery to homes, cable television (pre-RF competition), and power distribution. In these cases, the duplication of expense necessary for competition simply makes no economic sense. Thus in a free market only one system will survive, whether by merger or slaughter. Nobody expects a free market in municipal water systems, and experience has shown that cable will merge rather than compete with other cable. Even in the climate of deregulation of electric power, nobody is foolish enough to deregulate the delivery of power.
If we look at today's situation with operating systems, we see the same economic situation. More OS API's translate directly into increased costs to application producers. Those producers thus must choose what platforms they will support. Their decision will be heavily influenced by the popularity of the competing platforms. But the popularity of those platforms is strongly influenced by the number of available applications. This creates a positive feedback situation which will naturally "lock-up" on one OS API. This creates an enormous barrier to entry. This was well documented in the findings.
We would all like to believe that software engineering will overcome this phenomenon, but there is little evidence that it will in the near future. There are many approaches: standard API's, "write once, run everywhere," open source, standards committes, etc. But the real world of automating human systems does not allow such simplistic, if sometimes elegant approaches to conquer the more powerful natural monopoly drivers. Until technology advances in a manner that removes the cause of OS natural monopoly, we must deal with that monopoly as it is.
I would cast my vote for vertical dismemberment of Microsoft. Microsoft's practice of defining almost every product into the "operating system" should be prohibited. SQL Server, IE, Office 2000, etc should be kept out of the OS (as computer science would recommend in any case) and should be owned by a company other than the one which controls the OS and its API.
Thus Bill's Database Inc.can go head-to-head with Larry's Other Database Inc, etc.
Whether Bill's Buggy OS Inc needs further regulation is a more complex matter, on which my own opinions oscillate at least once per day.
John Moore sd@tinyvital.com
While there has been much fuss about the finding that Microsoft is a monopoly (duh), and the government has been loudly promising punishment, I think there is a critical issue being ignored: Is Windows an example of a natural monopoly?
A natural monopoly is one where the economics of a situation, independent of the behavior of the players, forces evolution into a monopoly situation. Ultimately this is because competition in those areas is extremely inefficient economically. Examples include water distribution in a city, wired-line telephone service, and (to a lesser extent) cable TV.
Natural monopolies are usually heavily regulated because they develop the characteristics of monopoly: predatory, anti-innovation, over-priced and under-efficient, and slow to change.
The history of computer operating systems seems to support the idea that they are also natural monopolies. In the last 35 years (my period of experience in the field), I know of almost no cases where, for one kind of hardware, there were more than one operating system that ran a large number of applications. MSDOS, and later Windoze, are just the latest example: if you want a diversity of PC applications, other than a few specialty ones, you need a Wintel system. If you want to make money selling software, and you are not selling a niche product, you will no doubt develop it first for Windoze. It may never be worth your while (as a business) to port it to LinBeBSSolix - even if that would be far more satisfying.
This sort of consideration leads to a positive feedback effect. The application developer targets his limited development resources to the platform with the largest potential customer base. As many application developers do this, the "favored platform" nature of the OS increases. Thus even without predatory practices, Microsoft or some company like them would most likely become the operating system monopoly.
Historically, this was also true of IBM DOS and later IBM OS-360 and later MVS. If you had a mainframe application need, you had to buy that operating sytem (even if you could buy the machine from Hitachi or someone else) to run it on. And this was for the same reason: OS-360 became the leader, and (on mainframes) it still is - 30 years later!
The feedback effect to select a single platform is powerful. It may also be beneficial - for the most part it is more efficient for the world to focus on the development of applications for one platform. Of course, it tends to limit innovation, especially with Microsoft's practice of bundling their own applications to their monopoly system, and copying (or sometimes buying) superior 3rd party technology when it comes along.
If, in fact, OS's are natural monopolies (and they have been and will be for a while), then one should consider "common carrier" or "utility" types of regulation for them. I would like to see Microsoft split into multiple companies - one for Windwos/DOS, and others for applications, service businesses, etc. Besides, based on history (Standard Oil is a good example), it will make my Microsoft stock go way up (although that is a mere side effect).
I have been wondering why the ABM approach these days is to ram the incoming target with an interceptor, destroying that target by the high kinetic energy of a multiple km/sec collision.
It would seem that this would make aiming harder than the older method used by the Patriot and other anti-aircraft/anti-missile systems. Those systems use an explosive, detonated at closest approach, to throw a spray of high velocity projectiles at the incoming target. This "shotgun" approach would seem to me to have a higher kill probability. In the past, we had thousands of nuclear armed interceptors, so the same issue applies to that technology. For example, fleet defense doctrine against massed aircraft attack was to use nuclear missiles to destroy the aircraft... and almost every US combatant, in the past, carried these missiles!
So, does anyone know why they now use kinetic kill with a single maneuverable projectile?
The Russians already have a working and recently (80's) upgraded ABM system. It is no surprise that they object to this system.
I do not believe that any ABM system in the forseeable future will be able to destabilize the nuclear "balance of terror" because it would have to work almost perfectly to avoid unacceptable damage, and that is not going to happen.
However, it has a stabilizing effect by increasing the uncertainty of success of a first strike. For a first strike to be successful, it must destroy most (really, almost all) of the target country's retaliatory force. If only a couple of MIRV'ed missiles were left after a first strike, it would be enough to play havoc on the attacker's cities.
Based on their past behavior with satellite technology, at least having Dept. of Commerce review things would open up one huge market: China. :-)
The encryption scheme, claimed as "unbreakable", in fact is subject to very standard cracking techniques. One time key schemes have been broken many times - by attacking the source of the one time pad. For example, historical schemes have used paragraphs from obscure books. Attacks consist of: (1) looking for the paragraph, or (2) using the non-randomness (low entropy) of human language to statistically crack the code.
:-). Voice is likewise highly structured.
The latter approach should work pretty well with an audio source (a sound card is used by the programs describe). Audio is usually highly non-random. It depends on what is connected to the audio board. If it is environmental noise, it will probably have certain frequencies emphasized. If it is music, it is already highly structured (except, perhaps, for certain modern rock "music" which seems to me to be almost flat spectrum
Given that the authors claim it is unbreakable, I would immediately suspect that they are cryptographic novices, and thus be suspicious of the details of their algorithms in addition to their poor choice of randomness.
If they had used a semirandom source (like audio or key click timings or something), and THEN used a solid cypher to encrypt it to produce the one-time key, I would be much happier.