Much the same thing happens if you change the option and then restart IE.
WTF?
I guess that aspect of functionality wasn't tested thuroughly, becuase it's not officially supported for MS Sheeple. Silly power user, don't you know you're not supposed to be monkeying with settings? Most of those pulldowns are there just for decorations on the pretty XP title bars.
Thanks for clarifying. We mechanical engineers aren't known for our particle physics. Most of what we get is hearsay.
Obviously thermal oscialtions in atoms are going to screw up any measurements of an atom's wavelength, but I didn't realize that the effects were totally absent. At what point does the particle/wave duality approximation break down? Above a mass of 4 AMUs? Below a velocity of 0.5 C? I'm sure it's more complicated than that, and I ask way too many questions, but I'd be interested in finding out how my 8.01 profs lied to me.
Professor Rivest told us about Adi Shamir's way of "breaking" quantum crypto. I described it better in another post, but basically you send photons into the photon emitter when it's not transmitting and look at the photons comming back in order to learn about the internal state of the transmitter. It's a cheap hack, but I'm not sure I would have thought of it. And of course, there are simple countermeasurees, like photodetectors in your transmitter.
And MS has jumped to fix a bug
that everyone found (notice the GAPING HOLE in Solaris/AIX [slashdot.org] systems
that still isn't patched? Why aren't you going off on that?)
Maybe everyone else noticed that there are emergency patches out for both Solaris and AIX? They haven't gone through the rigoruous IBM and Sun testing yet, but they're tested as well as M$ patches and are available for downlaod from the vendor websites. (Scan through the comments to find the URLs. Trust me, they're there.)
I will agree that the Anti-Microsoft banter goes off the deep end sometimes, but I'm starting to see the Anti-Anti-Microsoft banter get almost as bad.
All this factionalism and zealotry is getting out of hand. To fix this, I hereby found the Anti-Anti-Anti-Microsoft faction. Who's with me?! j/k:-)
So, look for my previous post under this story if you're not sure how quantum key exchange works. I have a brief summer at the bottom of this post to check if you and I are thinking about the same implementation of quantum key exchange. Adi Shamir (I think) came up with a way to break quantum crypto key exchange based on polarised single photons.
Okay, so it's only an attack against uncareful implementations. The easiest way of explaining it is the case of tapping a fiber optic line. You splice th fiber optic line and let all of Alice and Bob's photons pass through your detector. You inject your own polarized photons back towards the transmitter when the transmitter isn't transmitting. (You need to predict the timing of the transmitted photons, but that should be relatively easy.) You look at the polarisation of the photons you sent out after they reflect of the internals of the transmitter. This should leak information about the polarisation of the photon just sent or the photon about to be sent, or if the system is transitioning to send a photon in a different polarisation. Most designers wouldn't think to put a single photon detector in the transmitter, becuase they don't expect photons to be comming back at the transmitter, or assume such things would be inoocuous. Of course, there's always a man-in the middle attack if you don't ahve a good signature algorithm.
A brief summary is that you have a detector that can be set up to correctly detect rectilinearly polarized light or correctly detect diagonally polarized light. One person sends single photons randomly polarized in one of the 4 directions the other person is looking for. Afterward, they figure out which photons were correctly measured and those mesurements are the key bits. Like I said, I explained it better somewhere else in this article.
What is the sound of one photon clapping? (Read below about the double slit experiment if you don't get it.) I also put a little bit about the crypto applications at the bottom of this post.
Look up "Schrodinger's Cat" at everything2 or google. Prepare to have your head explode. It sounds like the physacists have been reading too much zen.
There are a few ways I like to explain it:
Q: does a tree falling in the forest make any sound if nobody's there to hear it?
A: The tree doesn't fall in the forest, but also doesn't not-fall in the forest if nobody's there to hear it.
It's almost as if God is lazy and doesn't figure out what's going on all over the universe until someone checks to see what happened. Most of the time, there's enough watching going on that things happen normally. However, if you set up experiments to be isoled and unobservable enough, strange things happen and you can catch God being lazy.
In the world of quantum, thing can be in a state of quantum superposition. Schrodinger made up a little story to explain the idea. Suppose you are about to keep things from disturbing a cat in a sealed box. And suppose you were able to isolate the Cat from observation. And suppose that you were to place a radioactive source in the box and a time and some poison, such that if the radioactive source underwent decay within a certain ammount of time, the poison would be released, killing the cat. Forget for the moment that we can only achieve this kind of isolation on very small scales.
Now, according to quatum mechanics, the cat's state of being alive or dead is entangled with the state of decay of the radioactive source. The really wierd thing is that the way things work in the quantum world, the radioactive source has both decayed and not decayed. It's a quantum supoerposition. Due to the entanglement, this means that the cat is both dead and not dead at the same time. Only when you observe the contents of the box does the superposition collapse into a definate state. So, as soon as you open the box and look at the cat it has either been hungry for the past hour or dead for the past hour. One second earlier, it has actually been both hungry and dead. It's really goofy. Supposedly Schrodinger later wished he had picked a better story, but now we're stuck with Schrodinger's demented story of a quantum entangled cat.
This is really how things work in the world of quantum... kinda.
The way Feignman (sp?) describes this phenomenon in his book "QED" is through a variation on the classic double slit experiment. In the double slit experiment, you have a monochromatic light source (all of the photons have the same wavelength), and a barrier with two slits in it. Due to the wave properties of all particles*, including photons, the "light waves" go through the split, and come out the other side as two sets of waves that create an interference pattern. In come places the waves line up and create double-bright spots, and other places the waves are 180 degrees out of phase and absolutely no light arrives. Suppose you were to try this experiment with single photon emitter instead of the continous light source, and throw in a way to make sure the photon goes through one of the two slits and is directed toward your photodetector. Obviously the photon goes through one slit or the other, not both. Unfortunately, in this case the obvious is wrong. If you put a photodetector at a point where the photons comming from the two slits cancel eachother out, you find that the single photon somehow goes through both slits simultaneously and cancels itself out! This is strange to say the least. Suppose then you decide to investigate further by taking a detector that will detect if a single particle has passed through it, but not block the single particle. Such detectors supposedly exist. You find that half the time the photon goes through the slit you're watching and half the time it goes through the other slit, bit it always arrives at the far detector. So, ths photon never arrives if you don't check which slit it went though, but if you check which slit it went though, it always arrives. The photon acts diferently when you watch it! I think the example makes more sense if it's described with an electron, since electrons can be attracted to the detector. Feignman may have actually used an electron is his example. It's been a few years since I read QED.
The standard way to interperet this whole thing is that the particle is in a superposition of going left and going right unless you force it to be in one state or the other by measuring it.
The whole crypto aspect comes in when you devise schemes where there are two ways of measuring something. If you measure in one way, you get the right answer, if you measure in the other way, you get complete garbage. The most practical way to do this is with the polarization of a single photon. If you send a photon in a calcite crystal, it takes one path if it's polarized along the crystal grain, and another path is it's polarised perpendicular ot the crystal grain. If the photon comes in polarized 45 degrees to the crystal grain, it has a 50% chance of comming out in either spot. You put a detector at each spot and see which way the photon came out in order to detect polarity. You use this to do secure key exchange in the following way: the sender randomly picks to send each photon polarized in one of four orientations (vertically, hozontally, and two ways diagonally.)
For each photon, the reciever randomly decides to orient his detector rectilinearly or diagonally. After measuring each photon, the reciever tells the sender which of the two detector orientations he used. The sender then tells the reciever which of the two detector orientations should have been used. The correct orientation reads the polarization correctly, the wrong orientation is 45 degrees to the photon's polarization and spits out complete garbage. Since you can's split a photon, you need to measure it one way or the other, not both. After the sender and reciever have talked about the detector orientations, they know which bits were received correctly and use those bits as an encryption key (probably in something like a one-time pad). Note that an attacher can bug the line and observe the photons, but in doing so his calcite crystal ends up aligning the polrization of the photon to be consistant with the measurement. An attacker needs to keep transmitting bits to the reciever, but half the time he's reading garbage bits and re-transmitting garbage bits. The sender and reciever will notice when 25% of their key bits are incorrect and know that they're being snooped on.
* I had to calculate the wavelength of a flying golfball once (thank you MIT freshman physics). The wavelength of any particle is a constant times one over the momentum of the particle. A golf ball has a hell of a lot smaller wavelength
than any observed photon, due to the extremely small ammount of momentum carried by any routinely occuring photon seen on Earth.
While I did just post about finding out how to crack the software, I don't remember if ElmcoSoft was the original group to publish the registry key. (IIRC, my source claimed that ElmcoSoft is giving away the key because they're affraid to sell it in the US anymore. Kind of a "Thanks for scewing Dmitry, let us reciprocate" thing.)
I'm not sure what the profitability of the product is anymore, but "Scew Adobe" and "fight the man" are not valid justifications for stealing from legitimate software companies. Say what you will about unfair pricing. Perhapse it's legitimate to crack the software and cut a check to the authors. In any case, if someone isn't holding a gun to your head to use their software and they'd like money for their software, you should compensate them at least a penny if you actually use their software (as opposed to feeding a curiosity or just trying it out), out of principle. I don't care who you are or what arguments you have about the economy of scarcity being irrelevant. It's just common courtesy.
About the holding a gun to your head thing: I'm not sure how I feel about copyright infringement against monopolies, legal or otherwise.
I'd much prefer that you contribute code or money toward (pay a friend to code) producing a better free competitor to the product you'd like to illegally copy.
I think illegally free software is one of free software's biggest competitors. I think microsoft clamping down on casual copying will help the free software people.
Somewhere I saw the registry key setting you need to make it the full version. Not much of a hack required, at least that's what somone claimed. Look arround. I may have even seen the value on slashdot.
How's that quote go? "First they came for the Jews, but I wasn't a Jew, so I kept silent. Then they came for the Catholics, but I wasn't a Catholic, so I kept silent. Then they came for me, but htere was no one left to hear my protests." -German WWII Protestant minister.
I'm sorry to say it, but it's your moral obligation to look out for the interests of your neighbor. You really shouldn't allow your house to be searched without a warrant. It sets bad precident. Ever heard of Steve Jackson Games? It's only human nature to push your limits in pursuit of your goal.
More practically, it's a very bad design practice to only sabotage something a small ammount. You never really know how badly you've sabotaged it. If you want it to work, design it to work as well as possible. If you want it to fail, make sure there aare more bugs than lines of code. In the middle ground lies chaos. There are always more cases than you thought of. Read about the Therac-25 sometime. Nobody is always as smart as they think they are. It's a fact of life. They can't make their virus checkers only ignore Magic Lantern without explicitly puting in a definition for magic lantern and then telling it to lie to the user. This is dumb, as anyone can then extract Magic Lantern's definition. Any other solution will allow something very similar to Magic lantern to go undetected. It isn't even necessarily a case of just not including a definition. The future of virus/trojan/worm detection is observing malicious patterns. Magic Lantern can't behave that much differently than other malicious code, so future detectors will have to be specifically written to ignore Magic Lantern.
Unfortunately, it only takes a hex editor to change the IP address or DNS name to "phone home", or whatever. Black hats will have coppies of this grabbed by packet sniffers, just hopefully it will be discarded for not having the string "password" in plain text. There's enough sniffing going on, particularly near systems that have been used for illegal purposes. "Oh, I guess his box was cracked, it was some guy in Elbonia remotely comiting the crimes after all. Oh? Packet sniffer installed? Oh well, I guess the Elbonian mafia has Magic Latern too."
Even if there was more sophisticated protection, the reward of an undetectable trojan means that a lot of people will be investing lots of time in acquiring and cracking this thing. You think Sadam or Al Qaeda won't have any uses for an undetectable trojan? Hopefully the FBI starts adding Magic Latern to its own virus definitions, otherwise this thing could backfire. "What do you mean? We're the ones sending out Magic Latern you idiot, it's being stored on some of our machines. What do you mean it's RUNNING on ALL of our machines? Hmm... so you mean to tell me that the illegal Elbonian imiigrants modified it and sent it back? Okay.. note to self... all further notes on the Elbonian connection must not be typed into a computer or mentioned over IP telephones. Hey, can you have 500 reams of loose-leaf lined paper sent over ASAP?"
I've always wondered how well reviewed small government-only software programs are. Will the zip-of-death lock up Carnivore? What about FBI agents that try to open a captured copy of the zip-of-death. HD space exhaustion probably is not a pretty thing to whitness.
Hmm... if they've patented certain methods for DRM, so if the OS is reverse-engineered in order to maintain compatability, then it would be illegal to actually implement the patented DRM enforcement features in the compatability code, right?
This seems like Ford patenting cars that won't speed and then proceding to manufacture them. Granted, M$ is trying to attract content providers and thereby attract consumers. However, they're making it illegal for WINE et al. to implement their protections, so WINE will be legally forced to implement fake DRM library/system calls. I assume the DMCA still allows reverse-engineering for compatability purposes.
You're right, as long as there aren't any new bugs in IIS/Apache/etc. We all know how often webservers have bugs discovered. The next CodeRed wanna be uses this and thousands of people are scewed. Didn't hotmail get hit by CodeRed? What if the next guy to discover an IIS bug decides to devlop a waorm (that spreads by several means, like Nimda) before telling anyone about it? If hotmail and msnbc both get infected, that's a huge distribution base. Most people would click "download" for anything from one of those sites, after all they know not to run the thing. The problem is that once they click "okay" to download, it executes. The stupid user's machine is now spreading the worm If this thing also infects windowsupdate.microsoft.com, then MS has a problem on its hands. Combine this with an automatic DDoS attack on the major virus protection sites, and you have an epidemic with a slow immune response.
THe major problem with something like this is that it increases the optimum destructiveness and propigation rate of worms. Once a worm spreads via major news/email/update sites, it's in the worm's best interest to become as destructive as possible in order to get people to flock to those sites and download things from those "trusted" sites without thinking.
Problems affecting stupid users are much worse than those affecting servers, simply due to the relative population sizes.
By the way, has anyone else wondered if an email trojan that uses 5th or 6th order Markov chains to mimic the language of the local machine would spread faster than our ability do translate warnings into all the world's languages? (SirCam's sucess despite bad English made me think of this. If joe average got something that half made sense in his own language, would he be more tempted to open the attachment in order to make sense of the email?)
I don't mean to single you out. Lots of people are also asking why the FBI is investing so much in copyright infringement. People ask the same thing about why open source programmers are "wasting" their time with some project when a "more noble" or "better" project really needs programmers. The answer lies in specialization. Sure these FBI agents could be used to track down terrorists, but they aren't traned and aren't experienced in counterterrorism. They aren't even trained in computer security investigation (looking for digital terroroists). The FBI attempts to make the most efficient use of the resources it has. The guys specializing in raiding and securing electronic evidence probably had nothing better to do that day. The FBI has a certain number of people with certain kinds of training. Some kinds of training are more expensive and the agents capable of certain kinds of work demand higher salaries. At some point it becoomes innefient to throw too many people on one problem. (The old "too many cooks in the kitchen" problem.) You can somplain that some laws are unjust, and you can complain that the FBI isn't efficient enough, but please don't ask the FBI to become less eficient due to a recent event.
It's easy to lok at a problem from the outside and talk about optimization, but once you get inside and take a good hard look at it, you often find that the situation is closer to optimal than you had thought, For instance, put yourself int the FBI's shoes, criticizing optimization of effort in the OSS community. The FBI could just as well complain that too many people program window managers and create themes (the most common complaint I hear) and that more OSS programmers should work on WINE, Bochs, Plex86, LIDS, OpenOffice, etc. The truth is that
many wm programmers would not work on any project but a wm. (Therefore, they work most efficiently on wms.) Furthermore, if the wm projects were abolished, and their programmers went on to those other projects, they would lose time due to self-training and would not write as well or as quickly as if they were writing window managers. Many people also assume that window managers are a solved problem, and then they complain about Linux being behind Windows in the usability game.
In short, just becuase things don't look optimal to you doesn't mean that they are not close to a local optimum. (Perhapse that local optimum is far from the global optimum, but that transition is a whole other ball of wax, especially when the global optimum shifts rapidly. It's really difficult once you throw in the time variable and unpredictable variables.) If the FBI followed the shifting of the sands too rapidly, it would be an unstable organization, never able to set down long-term goals.
Also, the term "software piracy" is a propaganda trick to cause a mental association with more serious crimes. These people didn't hijack ships via digital means, they coppied CDs. Encourage your friends to call it copyright infringement as well.
On a somewhat-related topic, has anyone out there found any good tools for CD-RW (I like my CDR tools fine) under Linux? What about just being able to get at my old backups on that Win95 Adaptec EZ CD-creator CD-RW I have? (I installed RH 5.2 or some such over Win95 when my roomate got my Win95 partition to eat itself. After all, I had all my important stuff backed up. It just turns out that I can't read my backups.) Is it a standard format, or does Adaptec use their own format?
>For example, there are at least five different window managers and at least four competing browsers, >increasing programming complexity and reducing the pool of available developers.
Huh? Huh?! Didn't they just talk about development tools and device API? What the hell is wrong with these people?
They mean to say that it's difficult to get compatable worm development in heterogeneous enironments that seldom have compatible, redundant, overlapping bugs. Some embedded linux solutions might not even have a web browser and scriptable email solution shove^H^H^H^H comingled. This clearly fragments the worm/trojan/virus development community and makes compatable worms much harder to write. Embedded Linux also lacks such M$ innovations such as VBScript and automatically run macros. You see, a browser really is a development tool, of sorts. Also, browsers are a good example of the positive uses of hidden APIs to keep the Netsca^H^H^H^H^H bad programmers out.
I think it would be hard and expensive to make a bethylizer that isn't easily fooled when there isn't a human watching it. Hook up a balloon through your nose. Air comes in your nose and out your mouth into the sensor. It'll register a little bit of alcohol, but the air hasn't contacted much surface area to pick up acetaldehyde and ethanol vapors. Anything that tries to tell if it's a real person blowing would be fooled, since there is a real person with their mouth on the straw. Put 37 deg C air in the baloon and You're pretty much scot free. A bit uncomfortable, but hard to detect as far as I can see. It just took me 30 seconds to figure that one out. I probably could have figured it out in 30 minutes while intoxicated.
Requiring drivers' liscences? What about 14-year old Jack checking the fence line on a private road while Dad is off getting feed (with his liscence).
What about Mom going into labor and 15-year-old Jill needing to drive her to the small town hospital becuase the ambulance is off treating a heart attack. You mean Mom might not be able to think streight enough to remember where she put her purse when she's in excruciating pain?
Oh.. I was doing something stupid while drunk in the middle of nowhere and need to drive myself to the hospital before I bleed to death, and I don't have a cell phone. I'm sure that never happens.
You could make the case that the headlight and tail lights should blink between dim and bright when the "override" button is used to start the car instead of inserting your smart-card liscence and blowing into the tube. However, I'm sure the farmers don't want to be replacing the headlights in their cars every month from so much power cycling from their kids checking the fences.
The idea sounds good at first, but it's expensive, too easily bypassed, and a real hastle for some very legitimate uses.
Linux is usually less painfull to upgrade. Microsoft security patches and serrvice packs have had a bad track record of breaking existing software. I've heard of plenty of admins patching their development boxes, but being too affraid of getting fired if something broke to patch the production servers.
Just before Microsoft decided to add IIS to their auto update site, a freind of mine got his IIS box hacked because he thought that the Microsoft automatic update covered everything that shipped on his CD, not just the OS. More support from Microsoft means less proffit for MS. Now IIS is on MS's autoupdate site, but only becuase it made marketing sense. Let's face it, 100% of Microsoft's coding is devoted directly or indirectly toward profit. Until recently, only "ehh... good enough" security was the most profitable use of programmer resources. It'll take a little bit of time before Microsoft gets things up to their new standard of security. It remains to be seen what exactly that new standard looks like.
I set up my Debian box to run apt-get update and apt-get upgrade daily. My software is never more than 24 hours out of date. More importantly, I have no fears of upgrade breakage. Autoupdate and up2date do similar things for RedHat.
Okay, so I've only had a couple of lectures on quantum computing, but the were in Prof. Rivest's Network Security class, so the focus was pretty relavent to your question.
The basic idea with quantum computing is that you can do compuations on all of the possible inputs simultaneously. It appears that some of the problems we'd like to solve with quantum computers may not be able to be expressed efficiently with the quantum operations at our disposal. Someone mentioned in another post that quantum computers don't seem to be able to break block ciphers as efficiently as they can factor large numbers.
If everything is working properly, the Qbits probably aren't exactly ones or zeroes until you look at them. (In the world of quantum mechanics, particles act differently when you look at them. Look up Schrodinger's Cat on Google if you're not familiar with the basic idea of quantum.) The state of each qbit is a pair of complex numbers, called amplitudes. The square of a magnitude (vector length squared for the spatial thinkers among you. The dot product of a vector and its complex conjugate for those of you that prefer linear algebra.) is a probability.
The qbit is most likely not totally a 1 or a zero. The qbit is partially a one and partially a zero and these parts are represented as amplitudes. This indertiminant state is called a quantum superposition. In Ket notation we say a qbit is alpha |0> + beta |1> where alpha and beta are those complex amplitudes I mentioned earlier.
Stay with me. I'm almost done with the stuff that makes your head swell.
When you observe the qbit, it magically becomes exactly a one or exactly a zero, with probability determined by the amplitudes. Therefore, the sum of the squares of the magnitudes of alpha and beta always add up to one, sonce the probabilities of the qbit being observed as a zero or one must sum to 100%.
So, what does this all mean? It means that all of your computations are done with the qbits being BOTH zero and one at the same time. (Okay, so you set come of the qbits to specific values in order to control the quantum gates.) This means that with n qbits, it's like doing computation on 2^n data points simultaneously. You set up your computations so that in the end when you look at your qbits, you have a high probability of seeing the correct answer.
There's a big problem keeping very many qbits in quantum superposition for very long. A random neutrino or other minor disturbance has the same effect as looking at the qbits in mid computation.
but even on Unix/Linux nobody can stop root from reading a file, right?
No, most of the loopback and NFS file server solutions require root to "get medieval on your ass" and extract the key from between your ears in order to read the files, or even mount the filesystem.
I agree that key recovery is a Good Thing(tm). Most data important enough to be encrypted is important enough to justify strong recovery methods.
I'd really like to see Shoup's secret sharing algorythm used for key recovery. Shoup figured out a way to split up a secret RSA key into m secret shares such that people controlling n of the shares must cooperate in order do normal RSA decryption in a special manner. The really neat thing is that nobody learns anything about anyoune else's secret share, even after the distributed computation is performed. Each participant creates a special sub-decryption based on their secret share, as well as a zero-knowledge proof of the validity of their sub-decryption (so you can tell if somebody is trying to "poison" the calculation with a fake sub-decryption). Once n sub-decrptions are available, anyone with acess to them can combine them in a special way. The math is a bit involved, but given only Shoup's paper, it only took two of us working for three nights to code it up as a homework assignment in Prof. Rivest's network security class. Both m and n are arbitrarily set when the secret shares are geberated.
Given Shoup's scheme, you could make it so that 5 of your 20 admins would need to consent/be bought/get hacked in order to recover your key. The best part is that the end result is normal everyday RSA decryption, so absolutely no changes need to be made on the encrypting end. (IIRC, the encryption exponent needs to be a prime number larger than m, or 2m or some such, but this is not a problem for most implementations. 3, 7, 17, and 2^16+1 are the most common public exponents for RSA, as these exponents result in pretty fast exponentiation. Sometimes the encryption exponent is hard coded into the software.)
The biggest problem with fuel cells in airplanes should be the weight and bulk of the entire system. This is especially true for small aircraft. However, fuel cells provide many befets, especially compared to the piston engines used in sport aircraft.
The article mentions that fuel cells are twice as efficient as heat engines. I thought the efficiency gap was larger. In any case, the laws of thermodynamics place an upper limit on the efficiency of a heat engine (such as a turbine or piston engine). This upper limit is known asw the Carnot efficiency. It is determined by the ambient temperature and the temperature of combustion. 30% is a decent estimate of the Carnot efficiency for a gasoline engine with the ambient temperature about room temperature. I thought fuel cells were about 80% efficient, but then again I'm on a coding break at 5 a.m.
The MGM brushless DC motor developed at NTU in Australia has an efficiency around 99%.
The main advantages of fuel cells for sport aviation are the extremely high efficiencies and the good reliability of the components. Electrical components and non-moving mechanical components have much higher reliability/cost ratio than their moving counterparts. I've held aircraft pistons with valves imbedded in them. Some people much prefer the Wankel rotary engine in aircraft for its simplicity. Turbines are much better in terms of reliability, but their cost is much higher. One should also consider maintenance costs. An aircraft piston engine typically needs to completely overhauled every 20,000 hours of operation to ensure reliability. Fuel cell inspection and overhaul involves many fewer parts and is probably much cheaper and probably needs to be done less frequently. The same should be true for electric motors.
Another important factor in using electric motors is that the propellers can be designed more optimally if they don't have to deal with the large accelerations and decelerations that a 6-cylinder piston engine produces 3 times per revolution. Piston engines (even with flywheels) are very rough running, and propellers are beefed up so that they don't tear or shake appart under these loads. Any time you have to beef something up, you end up increasing the cost, weight, and/or innefiencies.
Let's not forget that most sport aircraft require 110 octane "low lead" fuel that is expensive and releases polluting lead compounds into the environment.
More simply, instuction sets are designed based on a set of asumptions. The x86 instruction set was based on a set of assumptions that was true 20 years ago. x86 assumes that memory is expensive and compilers don't optimize well, so it's got lots of nifty little optimized instructions for doing common (and not so common) tasks and uses variable length instructions to make the code more compact.
RISK instruction sets assume you don't mind having slightly larger code segmets if it means that most of your instructions execute in one clock cycle and you can up your clock rate (this is why the pentium family uses RISC cores). It also assumes you don't want to pay in transistors (and power and heat) for rarely used instructions. It also assumes you have compilers that a good enough so that you don't pay too high a penalty for not having those scan opcodes, having to work with only a couple of addressing modes, etc.
VLIW takes this one step further. You don't mind increasing your code size because it means that your compiler has lots of time (comparatively) to figure out how to do multiple simultaneous issues in order to maximize your performance per transistor by explicity putting each issue into the verly long instruction. This assumes that you have very smart compilers. Unfortunately, it also means that your instructions are big. If clock multipliers continue to climb, you may see VLIW instruction sets, but decompressors on the die in order to increase the appearent memory bandwidth.
Note that this progression in instruction sets represents a progressive moving of certain aspects of the CPU somplexity from the CPU core into the compiler. This allows the limited die realestate to be used for more ALUs, more Cache, smarter branch prediction, "SMP on a chip", etc. while continuing to allow the price of CPUs to fall.
You can do on-chip emulation of the legacy insstruction sets (like on the P4 and even the Itanium), but it's baggage you have to drag arround even when running your native code. Software emulation of the legacy hardware seems more appropriate. If we all switched to some VILW CPUs now, in another 3 years (being pessimistic), Bochs (or another emulator) running on those CPUs would run the legacy code as fast as today's machines, and would run native code much faster.
You would have to re-engineer the instruction set in order to add more registers. You would break backward compatability or make a totally new set of really long instructions that use the new registers. Both solutions have no advantage if you're still going to call it x86.
It's just a really klugy instruction set. Floating point was added after the fact. IIRC, you have to multiply something in EAX by something pointed to by ESX or some such. This means you end up doing lots of needless loads and stores and loads and stores if, for instance, you're dealing with even a small system of polynomial equations.
Your modern x86 CPUs can do "register aliasing" to try and overcome some of this register thrashing and to allow more parallelism, but aliasing circitry takes up realistate.
Allowing self-modifying code is also a pain in the ass (PPC simply does not allow it) if you're going to try and run the instruction set non-natively (such as on the P4 core). Self-modifying code will thrash the P4's "translation cache". Memory pages have three permissions (read, write, execute) just like Unix files. However, several of the eight combinations are not allowed by the instruction set. This causes some minor security problems. (I forget which modes cannot be set. You can argue that some of them are useless as the x86 architects did, but there are some non-obvious situations where you might want some of the stranger modes.)
People also complain that the x86 has too many addressing modes. IMHO, they should design instruction sets to be simple and allow for simple emulation. They know that they'll be emulating it on a more advanced core later down the line or shipping with an emulator in the BIOS or some such, so they might as well make their lives easier. IBM had the right idea with OS/390. Basically they designed the hardware and low level system such that the user never saw any code running on bare metal. The "OS" that the user saw was running in something like VMWare. Linux for S/390 runs in an OS/390 partition (basically a virtual machine) and never on the bare CPU. This has lots of advantages for security, stability, modularity, isolation, and maintainability, as well as ease of migration on to the next generation.
There are reasons Intel is migrating from x86 on the high-end CPUs. Don't get me wrong, I'm a big AMD fan, but I think sledgehammer is going in the wrong direction. I woould much prefer that AMD made a PPC, SPARC, ARM, or MIPS instruction set cpu with on-die x86 emulation. We've been doing x86 emulation on a RISC core since the original Pentium chip. It wouldn't take much realistate to expose the RISC or VLIW instruction set as well.
If that were the case, you'd almost definately see x86 linux binaries running directly on PPC Linux. The boot sequence, memory management, etc. would necessitate dramatic kernel differences, but there would be userland binary compatability.
PPC has M68k emulation right on the die, at least the older chips did. That's probably what you're thinking of. This allowed MacOS to slowly migrate to PPC native code. M68k is CISC architecturre. x86 is a CISC architecture. PPC is a RISC architecture.
<aside>
It's good to see Intel's flagship CPU running a VLIW instruction set, with x86 emulation on die.
We've been dragging arround the legacy x86 instruction set for a few decades now. x86 instructions are pretty compact, but they have a serious lack of registers. There's a lot of trickery going on in the Athlon XP and P4 in order to overcome the instruction set's weaknesses. Less trickery = less power consumption and/or better cost/performance. Personally, I'd like to see CPUs with only 2 or 3 ALUs per "CPU" and "SMP on a chip" since it's hard to average more than 2.5 issues per clock cycle. 90% of the time you've got a few ALUs that you've paid for just sitting there. Unfortunately, most of the bachmarks and apps out there are a single threaded single process, so you wouldn't see much of a performance increase until people started writing multithreaded apps. Of course, most server apps use a pool of processes to handle requests, or fork off a new process for each new request. Servers and multi-user machines would imediately see an increase in performance. VLIW is designed to really cut down on idle ALUs by making multiple issues explicit in the instruction set and moving all of the trickery into the compiler. VLIW is kind of like a RISC revival. It's about getting back to simpler chips, made possible by better compilers and higher appearent memory bandwidth.</aside>
A feature I'd really like to see is per-host encryption keys. That way, businesses don't have to give the master network key to every guest that uses the network.
It would really be nice if IPv6 had mandatory encryption. It just seems to me that encryption should be implememnted above the link layer if you want good security. Link layer encryption is a nice feature, but it's not the optimal solution, IMHO.
If it isn't 3DES or an AES finalist in OCB mode (or CBC/CFB mode with a good Message Authentication Code), I'd be very skeptical. 802.11b manufacturers have shown an inability to provide good initialization vector generators, so counter modes and OFB modes are extremely suspect. ECB mode really doesn't hide message patterns well.
Last I heard, the 802.11e working group was planning on using AES in OCB mode. Unfortunately, OCB mode is patent encumbered. On the plus side, it's really good mathematically. Provable confidentiality and authenticity with very little overhead, assuming the underlying block cipher has certain properties.
They used to think you couldn't get cofidentiality plus authenticity without approximately doubling your processor load. But I've seen the proof to the contrary. It looks pretty convincing. One of the best things that even if someone scews up and uses constsnt IVs, you's still better off than ECB mode.
There's always that little something about games written by Nintendo. Nintendo has never been about pushing the hardware to the limits, that's why they chose the Gecko instead of a Power4 or G4 chip (all three are in the PPC family).
People seem to be focusing on technical comparisons between the hardware platforms. They forget that Nintendo realizes that it doesn't need to win megapolygon benchmarks with its games. Super Mario Cart would be almost as fun on my 8-bit, 16-color, sprie graphics Ninendo. Nintendo is very good at distilling the essence out of games and refining that game experience,
Just as Microsoft have their usability experts, Nintendo seems to have their playability experts. You don't need great graphics to make a great Nintendo game. People still play the original Super Mario Brothers from time to time. Far fewer people still play even Quake I. Maybe it's nostalgia, but I honestly think that nobody beats Nintendo when it comes to timeless games. Atari had a few really great games, but I think history will show Nintendo to be the king of timeless games.
Slashdot Mirror
WTF?
I guess that aspect of functionality wasn't tested thuroughly, becuase it's not officially supported for MS Sheeple. Silly power user, don't you know you're not supposed to be monkeying with settings? Most of those pulldowns are there just for decorations on the pretty XP title bars.
Obviously thermal oscialtions in atoms are going to screw up any measurements of an atom's wavelength, but I didn't realize that the effects were totally absent. At what point does the particle/wave duality approximation break down? Above a mass of 4 AMUs? Below a velocity of 0.5 C? I'm sure it's more complicated than that, and I ask way too many questions, but I'd be interested in finding out how my 8.01 profs lied to me.
Professor Rivest told us about Adi Shamir's way of "breaking" quantum crypto. I described it better in another post, but basically you send photons into the photon emitter when it's not transmitting and look at the photons comming back in order to learn about the internal state of the transmitter. It's a cheap hack, but I'm not sure I would have thought of it. And of course, there are simple countermeasurees, like photodetectors in your transmitter.
Maybe everyone else noticed that there are emergency patches out for both Solaris and AIX? They haven't gone through the rigoruous IBM and Sun testing yet, but they're tested as well as M$ patches and are available for downlaod from the vendor websites. (Scan through the comments to find the URLs. Trust me, they're there.)
I will agree that the Anti-Microsoft banter goes off the deep end sometimes, but I'm starting to see the Anti-Anti-Microsoft banter get almost as bad.
All this factionalism and zealotry is getting out of hand. To fix this, I hereby found the Anti-Anti-Anti-Microsoft faction. Who's with me?! j/k :-)
Okay, so it's only an attack against uncareful implementations. The easiest way of explaining it is the case of tapping a fiber optic line. You splice th fiber optic line and let all of Alice and Bob's photons pass through your detector. You inject your own polarized photons back towards the transmitter when the transmitter isn't transmitting. (You need to predict the timing of the transmitted photons, but that should be relatively easy.) You look at the polarisation of the photons you sent out after they reflect of the internals of the transmitter. This should leak information about the polarisation of the photon just sent or the photon about to be sent, or if the system is transitioning to send a photon in a different polarisation. Most designers wouldn't think to put a single photon detector in the transmitter, becuase they don't expect photons to be comming back at the transmitter, or assume such things would be inoocuous. Of course, there's always a man-in the middle attack if you don't ahve a good signature algorithm.
A brief summary is that you have a detector that can be set up to correctly detect rectilinearly polarized light or correctly detect diagonally polarized light. One person sends single photons randomly polarized in one of the 4 directions the other person is looking for. Afterward, they figure out which photons were correctly measured and those mesurements are the key bits. Like I said, I explained it better somewhere else in this article.
Look up "Schrodinger's Cat" at everything2 or google. Prepare to have your head explode. It sounds like the physacists have been reading too much zen.
There are a few ways I like to explain it:
Q: does a tree falling in the forest make any sound if nobody's there to hear it?
A: The tree doesn't fall in the forest, but also doesn't not-fall in the forest if nobody's there to hear it.
It's almost as if God is lazy and doesn't figure out what's going on all over the universe until someone checks to see what happened. Most of the time, there's enough watching going on that things happen normally. However, if you set up experiments to be isoled and unobservable enough, strange things happen and you can catch God being lazy.
In the world of quantum, thing can be in a state of quantum superposition. Schrodinger made up a little story to explain the idea. Suppose you are about to keep things from disturbing a cat in a sealed box. And suppose you were able to isolate the Cat from observation. And suppose that you were to place a radioactive source in the box and a time and some poison, such that if the radioactive source underwent decay within a certain ammount of time, the poison would be released, killing the cat. Forget for the moment that we can only achieve this kind of isolation on very small scales.
Now, according to quatum mechanics, the cat's state of being alive or dead is entangled with the state of decay of the radioactive source. The really wierd thing is that the way things work in the quantum world, the radioactive source has both decayed and not decayed. It's a quantum supoerposition. Due to the entanglement, this means that the cat is both dead and not dead at the same time. Only when you observe the contents of the box does the superposition collapse into a definate state. So, as soon as you open the box and look at the cat it has either been hungry for the past hour or dead for the past hour. One second earlier, it has actually been both hungry and dead. It's really goofy. Supposedly Schrodinger later wished he had picked a better story, but now we're stuck with Schrodinger's demented story of a quantum entangled cat.
This is really how things work in the world of quantum... kinda.
The way Feignman (sp?) describes this phenomenon in his book "QED" is through a variation on the classic double slit experiment. In the double slit experiment, you have a monochromatic light source (all of the photons have the same wavelength), and a barrier with two slits in it. Due to the wave properties of all particles*, including photons, the "light waves" go through the split, and come out the other side as two sets of waves that create an interference pattern. In come places the waves line up and create double-bright spots, and other places the waves are 180 degrees out of phase and absolutely no light arrives. Suppose you were to try this experiment with single photon emitter instead of the continous light source, and throw in a way to make sure the photon goes through one of the two slits and is directed toward your photodetector. Obviously the photon goes through one slit or the other, not both. Unfortunately, in this case the obvious is wrong. If you put a photodetector at a point where the photons comming from the two slits cancel eachother out, you find that the single photon somehow goes through both slits simultaneously and cancels itself out! This is strange to say the least. Suppose then you decide to investigate further by taking a detector that will detect if a single particle has passed through it, but not block the single particle. Such detectors supposedly exist. You find that half the time the photon goes through the slit you're watching and half the time it goes through the other slit, bit it always arrives at the far detector. So, ths photon never arrives if you don't check which slit it went though, but if you check which slit it went though, it always arrives. The photon acts diferently when you watch it! I think the example makes more sense if it's described with an electron, since electrons can be attracted to the detector. Feignman may have actually used an electron is his example. It's been a few years since I read QED.
The standard way to interperet this whole thing is that the particle is in a superposition of going left and going right unless you force it to be in one state or the other by measuring it.
The whole crypto aspect comes in when you devise schemes where there are two ways of measuring something. If you measure in one way, you get the right answer, if you measure in the other way, you get complete garbage. The most practical way to do this is with the polarization of a single photon. If you send a photon in a calcite crystal, it takes one path if it's polarized along the crystal grain, and another path is it's polarised perpendicular ot the crystal grain. If the photon comes in polarized 45 degrees to the crystal grain, it has a 50% chance of comming out in either spot. You put a detector at each spot and see which way the photon came out in order to detect polarity. You use this to do secure key exchange in the following way: the sender randomly picks to send each photon polarized in one of four orientations (vertically, hozontally, and two ways diagonally.) For each photon, the reciever randomly decides to orient his detector rectilinearly or diagonally. After measuring each photon, the reciever tells the sender which of the two detector orientations he used. The sender then tells the reciever which of the two detector orientations should have been used. The correct orientation reads the polarization correctly, the wrong orientation is 45 degrees to the photon's polarization and spits out complete garbage. Since you can's split a photon, you need to measure it one way or the other, not both. After the sender and reciever have talked about the detector orientations, they know which bits were received correctly and use those bits as an encryption key (probably in something like a one-time pad). Note that an attacher can bug the line and observe the photons, but in doing so his calcite crystal ends up aligning the polrization of the photon to be consistant with the measurement. An attacker needs to keep transmitting bits to the reciever, but half the time he's reading garbage bits and re-transmitting garbage bits. The sender and reciever will notice when 25% of their key bits are incorrect and know that they're being snooped on.
* I had to calculate the wavelength of a flying golfball once (thank you MIT freshman physics). The wavelength of any particle is a constant times one over the momentum of the particle. A golf ball has a hell of a lot smaller wavelength than any observed photon, due to the extremely small ammount of momentum carried by any routinely occuring photon seen on Earth.
I'm not sure what the profitability of the product is anymore, but "Scew Adobe" and "fight the man" are not valid justifications for stealing from legitimate software companies. Say what you will about unfair pricing. Perhapse it's legitimate to crack the software and cut a check to the authors. In any case, if someone isn't holding a gun to your head to use their software and they'd like money for their software, you should compensate them at least a penny if you actually use their software (as opposed to feeding a curiosity or just trying it out), out of principle. I don't care who you are or what arguments you have about the economy of scarcity being irrelevant. It's just common courtesy.
About the holding a gun to your head thing: I'm not sure how I feel about copyright infringement against monopolies, legal or otherwise.
I'd much prefer that you contribute code or money toward (pay a friend to code) producing a better free competitor to the product you'd like to illegally copy.
I think illegally free software is one of free software's biggest competitors. I think microsoft clamping down on casual copying will help the free software people.
Somewhere I saw the registry key setting you need to make it the full version. Not much of a hack required, at least that's what somone claimed. Look arround. I may have even seen the value on slashdot.
More practically, it's a very bad design practice to only sabotage something a small ammount. You never really know how badly you've sabotaged it. If you want it to work, design it to work as well as possible. If you want it to fail, make sure there aare more bugs than lines of code. In the middle ground lies chaos. There are always more cases than you thought of. Read about the Therac-25 sometime. Nobody is always as smart as they think they are. It's a fact of life. They can't make their virus checkers only ignore Magic Lantern without explicitly puting in a definition for magic lantern and then telling it to lie to the user. This is dumb, as anyone can then extract Magic Lantern's definition. Any other solution will allow something very similar to Magic lantern to go undetected. It isn't even necessarily a case of just not including a definition. The future of virus/trojan/worm detection is observing malicious patterns. Magic Lantern can't behave that much differently than other malicious code, so future detectors will have to be specifically written to ignore Magic Lantern.
Unfortunately, it only takes a hex editor to change the IP address or DNS name to "phone home", or whatever. Black hats will have coppies of this grabbed by packet sniffers, just hopefully it will be discarded for not having the string "password" in plain text. There's enough sniffing going on, particularly near systems that have been used for illegal purposes. "Oh, I guess his box was cracked, it was some guy in Elbonia remotely comiting the crimes after all. Oh? Packet sniffer installed? Oh well, I guess the Elbonian mafia has Magic Latern too."
Even if there was more sophisticated protection, the reward of an undetectable trojan means that a lot of people will be investing lots of time in acquiring and cracking this thing. You think Sadam or Al Qaeda won't have any uses for an undetectable trojan? Hopefully the FBI starts adding Magic Latern to its own virus definitions, otherwise this thing could backfire. "What do you mean? We're the ones sending out Magic Latern you idiot, it's being stored on some of our machines. What do you mean it's RUNNING on ALL of our machines? Hmm... so you mean to tell me that the illegal Elbonian imiigrants modified it and sent it back? Okay.. note to self... all further notes on the Elbonian connection must not be typed into a computer or mentioned over IP telephones. Hey, can you have 500 reams of loose-leaf lined paper sent over ASAP?"
I've always wondered how well reviewed small government-only software programs are. Will the zip-of-death lock up Carnivore? What about FBI agents that try to open a captured copy of the zip-of-death. HD space exhaustion probably is not a pretty thing to whitness.
This seems like Ford patenting cars that won't speed and then proceding to manufacture them. Granted, M$ is trying to attract content providers and thereby attract consumers. However, they're making it illegal for WINE et al. to implement their protections, so WINE will be legally forced to implement fake DRM library/system calls. I assume the DMCA still allows reverse-engineering for compatability purposes.
THe major problem with something like this is that it increases the optimum destructiveness and propigation rate of worms. Once a worm spreads via major news/email/update sites, it's in the worm's best interest to become as destructive as possible in order to get people to flock to those sites and download things from those "trusted" sites without thinking.
Problems affecting stupid users are much worse than those affecting servers, simply due to the relative population sizes.
By the way, has anyone else wondered if an email trojan that uses 5th or 6th order Markov chains to mimic the language of the local machine would spread faster than our ability do translate warnings into all the world's languages? (SirCam's sucess despite bad English made me think of this. If joe average got something that half made sense in his own language, would he be more tempted to open the attachment in order to make sense of the email?)
It's easy to lok at a problem from the outside and talk about optimization, but once you get inside and take a good hard look at it, you often find that the situation is closer to optimal than you had thought, For instance, put yourself int the FBI's shoes, criticizing optimization of effort in the OSS community. The FBI could just as well complain that too many people program window managers and create themes (the most common complaint I hear) and that more OSS programmers should work on WINE, Bochs, Plex86, LIDS, OpenOffice, etc. The truth is that many wm programmers would not work on any project but a wm. (Therefore, they work most efficiently on wms.) Furthermore, if the wm projects were abolished, and their programmers went on to those other projects, they would lose time due to self-training and would not write as well or as quickly as if they were writing window managers. Many people also assume that window managers are a solved problem, and then they complain about Linux being behind Windows in the usability game.
In short, just becuase things don't look optimal to you doesn't mean that they are not close to a local optimum. (Perhapse that local optimum is far from the global optimum, but that transition is a whole other ball of wax, especially when the global optimum shifts rapidly. It's really difficult once you throw in the time variable and unpredictable variables.) If the FBI followed the shifting of the sands too rapidly, it would be an unstable organization, never able to set down long-term goals.
Also, the term "software piracy" is a propaganda trick to cause a mental association with more serious crimes. These people didn't hijack ships via digital means, they coppied CDs. Encourage your friends to call it copyright infringement as well.
On a somewhat-related topic, has anyone out there found any good tools for CD-RW (I like my CDR tools fine) under Linux? What about just being able to get at my old backups on that Win95 Adaptec EZ CD-creator CD-RW I have? (I installed RH 5.2 or some such over Win95 when my roomate got my Win95 partition to eat itself. After all, I had all my important stuff backed up. It just turns out that I can't read my backups.) Is it a standard format, or does Adaptec use their own format?
Q:What do they call a person that uses floppies for backups?
A:A frantic wreck.
>increasing programming complexity and reducing the pool of available developers.
Huh? Huh?! Didn't they just talk about development tools and device API? What the hell is wrong with these people?
They mean to say that it's difficult to get compatable worm development in heterogeneous enironments that seldom have compatible, redundant, overlapping bugs. Some embedded linux solutions might not even have a web browser and scriptable email solution shove^H^H^H^H comingled. This clearly fragments the worm/trojan/virus development community and makes compatable worms much harder to write. Embedded Linux also lacks such M$ innovations such as VBScript and automatically run macros. You see, a browser really is a development tool, of sorts. Also, browsers are a good example of the positive uses of hidden APIs to keep the Netsca^H^H^H^H^H bad programmers out.
Requiring drivers' liscences? What about 14-year old Jack checking the fence line on a private road while Dad is off getting feed (with his liscence).
What about Mom going into labor and 15-year-old Jill needing to drive her to the small town hospital becuase the ambulance is off treating a heart attack. You mean Mom might not be able to think streight enough to remember where she put her purse when she's in excruciating pain?
Oh.. I was doing something stupid while drunk in the middle of nowhere and need to drive myself to the hospital before I bleed to death, and I don't have a cell phone. I'm sure that never happens.
You could make the case that the headlight and tail lights should blink between dim and bright when the "override" button is used to start the car instead of inserting your smart-card liscence and blowing into the tube. However, I'm sure the farmers don't want to be replacing the headlights in their cars every month from so much power cycling from their kids checking the fences.
The idea sounds good at first, but it's expensive, too easily bypassed, and a real hastle for some very legitimate uses.
Just before Microsoft decided to add IIS to their auto update site, a freind of mine got his IIS box hacked because he thought that the Microsoft automatic update covered everything that shipped on his CD, not just the OS. More support from Microsoft means less proffit for MS. Now IIS is on MS's autoupdate site, but only becuase it made marketing sense. Let's face it, 100% of Microsoft's coding is devoted directly or indirectly toward profit. Until recently, only "ehh... good enough" security was the most profitable use of programmer resources. It'll take a little bit of time before Microsoft gets things up to their new standard of security. It remains to be seen what exactly that new standard looks like.
I set up my Debian box to run apt-get update and apt-get upgrade daily. My software is never more than 24 hours out of date. More importantly, I have no fears of upgrade breakage. Autoupdate and up2date do similar things for RedHat.
The basic idea with quantum computing is that you can do compuations on all of the possible inputs simultaneously. It appears that some of the problems we'd like to solve with quantum computers may not be able to be expressed efficiently with the quantum operations at our disposal. Someone mentioned in another post that quantum computers don't seem to be able to break block ciphers as efficiently as they can factor large numbers.
If everything is working properly, the Qbits probably aren't exactly ones or zeroes until you look at them. (In the world of quantum mechanics, particles act differently when you look at them. Look up Schrodinger's Cat on Google if you're not familiar with the basic idea of quantum.) The state of each qbit is a pair of complex numbers, called amplitudes. The square of a magnitude (vector length squared for the spatial thinkers among you. The dot product of a vector and its complex conjugate for those of you that prefer linear algebra.) is a probability.
The qbit is most likely not totally a 1 or a zero. The qbit is partially a one and partially a zero and these parts are represented as amplitudes. This indertiminant state is called a quantum superposition. In Ket notation we say a qbit is alpha |0> + beta |1> where alpha and beta are those complex amplitudes I mentioned earlier.
Stay with me. I'm almost done with the stuff that makes your head swell.
When you observe the qbit, it magically becomes exactly a one or exactly a zero, with probability determined by the amplitudes. Therefore, the sum of the squares of the magnitudes of alpha and beta always add up to one, sonce the probabilities of the qbit being observed as a zero or one must sum to 100%.
So, what does this all mean? It means that all of your computations are done with the qbits being BOTH zero and one at the same time. (Okay, so you set come of the qbits to specific values in order to control the quantum gates.) This means that with n qbits, it's like doing computation on 2^n data points simultaneously. You set up your computations so that in the end when you look at your qbits, you have a high probability of seeing the correct answer.
There's a big problem keeping very many qbits in quantum superposition for very long. A random neutrino or other minor disturbance has the same effect as looking at the qbits in mid computation.
No, most of the loopback and NFS file server solutions require root to "get medieval on your ass" and extract the key from between your ears in order to read the files, or even mount the filesystem.
I agree that key recovery is a Good Thing(tm). Most data important enough to be encrypted is important enough to justify strong recovery methods.
I'd really like to see Shoup's secret sharing algorythm used for key recovery. Shoup figured out a way to split up a secret RSA key into m secret shares such that people controlling n of the shares must cooperate in order do normal RSA decryption in a special manner. The really neat thing is that nobody learns anything about anyoune else's secret share, even after the distributed computation is performed. Each participant creates a special sub-decryption based on their secret share, as well as a zero-knowledge proof of the validity of their sub-decryption (so you can tell if somebody is trying to "poison" the calculation with a fake sub-decryption). Once n sub-decrptions are available, anyone with acess to them can combine them in a special way. The math is a bit involved, but given only Shoup's paper, it only took two of us working for three nights to code it up as a homework assignment in Prof. Rivest's network security class. Both m and n are arbitrarily set when the secret shares are geberated.
Given Shoup's scheme, you could make it so that 5 of your 20 admins would need to consent/be bought/get hacked in order to recover your key. The best part is that the end result is normal everyday RSA decryption, so absolutely no changes need to be made on the encrypting end. (IIRC, the encryption exponent needs to be a prime number larger than m, or 2m or some such, but this is not a problem for most implementations. 3, 7, 17, and 2^16+1 are the most common public exponents for RSA, as these exponents result in pretty fast exponentiation. Sometimes the encryption exponent is hard coded into the software.)
Hehe... forgot to proof read the subject line. It's 5 a.m. give me a break.
The article mentions that fuel cells are twice as efficient as heat engines. I thought the efficiency gap was larger. In any case, the laws of thermodynamics place an upper limit on the efficiency of a heat engine (such as a turbine or piston engine). This upper limit is known asw the Carnot efficiency. It is determined by the ambient temperature and the temperature of combustion. 30% is a decent estimate of the Carnot efficiency for a gasoline engine with the ambient temperature about room temperature. I thought fuel cells were about 80% efficient, but then again I'm on a coding break at 5 a.m.
The MGM brushless DC motor developed at NTU in Australia has an efficiency around 99%.
The main advantages of fuel cells for sport aviation are the extremely high efficiencies and the good reliability of the components. Electrical components and non-moving mechanical components have much higher reliability/cost ratio than their moving counterparts. I've held aircraft pistons with valves imbedded in them. Some people much prefer the Wankel rotary engine in aircraft for its simplicity. Turbines are much better in terms of reliability, but their cost is much higher. One should also consider maintenance costs. An aircraft piston engine typically needs to completely overhauled every 20,000 hours of operation to ensure reliability. Fuel cell inspection and overhaul involves many fewer parts and is probably much cheaper and probably needs to be done less frequently. The same should be true for electric motors.
Another important factor in using electric motors is that the propellers can be designed more optimally if they don't have to deal with the large accelerations and decelerations that a 6-cylinder piston engine produces 3 times per revolution. Piston engines (even with flywheels) are very rough running, and propellers are beefed up so that they don't tear or shake appart under these loads. Any time you have to beef something up, you end up increasing the cost, weight, and/or innefiencies.
Let's not forget that most sport aircraft require 110 octane "low lead" fuel that is expensive and releases polluting lead compounds into the environment.
RISK instruction sets assume you don't mind having slightly larger code segmets if it means that most of your instructions execute in one clock cycle and you can up your clock rate (this is why the pentium family uses RISC cores). It also assumes you don't want to pay in transistors (and power and heat) for rarely used instructions. It also assumes you have compilers that a good enough so that you don't pay too high a penalty for not having those scan opcodes, having to work with only a couple of addressing modes, etc.
VLIW takes this one step further. You don't mind increasing your code size because it means that your compiler has lots of time (comparatively) to figure out how to do multiple simultaneous issues in order to maximize your performance per transistor by explicity putting each issue into the verly long instruction. This assumes that you have very smart compilers. Unfortunately, it also means that your instructions are big. If clock multipliers continue to climb, you may see VLIW instruction sets, but decompressors on the die in order to increase the appearent memory bandwidth.
Note that this progression in instruction sets represents a progressive moving of certain aspects of the CPU somplexity from the CPU core into the compiler. This allows the limited die realestate to be used for more ALUs, more Cache, smarter branch prediction, "SMP on a chip", etc. while continuing to allow the price of CPUs to fall.
You can do on-chip emulation of the legacy insstruction sets (like on the P4 and even the Itanium), but it's baggage you have to drag arround even when running your native code. Software emulation of the legacy hardware seems more appropriate. If we all switched to some VILW CPUs now, in another 3 years (being pessimistic), Bochs (or another emulator) running on those CPUs would run the legacy code as fast as today's machines, and would run native code much faster.
It's just a really klugy instruction set. Floating point was added after the fact. IIRC, you have to multiply something in EAX by something pointed to by ESX or some such. This means you end up doing lots of needless loads and stores and loads and stores if, for instance, you're dealing with even a small system of polynomial equations.
Your modern x86 CPUs can do "register aliasing" to try and overcome some of this register thrashing and to allow more parallelism, but aliasing circitry takes up realistate.
Allowing self-modifying code is also a pain in the ass (PPC simply does not allow it) if you're going to try and run the instruction set non-natively (such as on the P4 core). Self-modifying code will thrash the P4's "translation cache". Memory pages have three permissions (read, write, execute) just like Unix files. However, several of the eight combinations are not allowed by the instruction set. This causes some minor security problems. (I forget which modes cannot be set. You can argue that some of them are useless as the x86 architects did, but there are some non-obvious situations where you might want some of the stranger modes.)
People also complain that the x86 has too many addressing modes. IMHO, they should design instruction sets to be simple and allow for simple emulation. They know that they'll be emulating it on a more advanced core later down the line or shipping with an emulator in the BIOS or some such, so they might as well make their lives easier. IBM had the right idea with OS/390. Basically they designed the hardware and low level system such that the user never saw any code running on bare metal. The "OS" that the user saw was running in something like VMWare. Linux for S/390 runs in an OS/390 partition (basically a virtual machine) and never on the bare CPU. This has lots of advantages for security, stability, modularity, isolation, and maintainability, as well as ease of migration on to the next generation.
There are reasons Intel is migrating from x86 on the high-end CPUs. Don't get me wrong, I'm a big AMD fan, but I think sledgehammer is going in the wrong direction. I woould much prefer that AMD made a PPC, SPARC, ARM, or MIPS instruction set cpu with on-die x86 emulation. We've been doing x86 emulation on a RISC core since the original Pentium chip. It wouldn't take much realistate to expose the RISC or VLIW instruction set as well.
PPC has M68k emulation right on the die, at least the older chips did. That's probably what you're thinking of. This allowed MacOS to slowly migrate to PPC native code. M68k is CISC architecturre. x86 is a CISC architecture. PPC is a RISC architecture.
<aside>
It's good to see Intel's flagship CPU running a VLIW instruction set, with x86 emulation on die.
We've been dragging arround the legacy x86 instruction set for a few decades now. x86 instructions are pretty compact, but they have a serious lack of registers. There's a lot of trickery going on in the Athlon XP and P4 in order to overcome the instruction set's weaknesses. Less trickery = less power consumption and/or better cost/performance. Personally, I'd like to see CPUs with only 2 or 3 ALUs per "CPU" and "SMP on a chip" since it's hard to average more than 2.5 issues per clock cycle. 90% of the time you've got a few ALUs that you've paid for just sitting there. Unfortunately, most of the bachmarks and apps out there are a single threaded single process, so you wouldn't see much of a performance increase until people started writing multithreaded apps. Of course, most server apps use a pool of processes to handle requests, or fork off a new process for each new request. Servers and multi-user machines would imediately see an increase in performance. VLIW is designed to really cut down on idle ALUs by making multiple issues explicit in the instruction set and moving all of the trickery into the compiler. VLIW is kind of like a RISC revival. It's about getting back to simpler chips, made possible by better compilers and higher appearent memory bandwidth.</aside>
It would really be nice if IPv6 had mandatory encryption. It just seems to me that encryption should be implememnted above the link layer if you want good security. Link layer encryption is a nice feature, but it's not the optimal solution, IMHO.
If it isn't 3DES or an AES finalist in OCB mode (or CBC/CFB mode with a good Message Authentication Code), I'd be very skeptical. 802.11b manufacturers have shown an inability to provide good initialization vector generators, so counter modes and OFB modes are extremely suspect. ECB mode really doesn't hide message patterns well.
Last I heard, the 802.11e working group was planning on using AES in OCB mode. Unfortunately, OCB mode is patent encumbered. On the plus side, it's really good mathematically. Provable confidentiality and authenticity with very little overhead, assuming the underlying block cipher has certain properties.
They used to think you couldn't get cofidentiality plus authenticity without approximately doubling your processor load. But I've seen the proof to the contrary. It looks pretty convincing. One of the best things that even if someone scews up and uses constsnt IVs, you's still better off than ECB mode.
People seem to be focusing on technical comparisons between the hardware platforms. They forget that Nintendo realizes that it doesn't need to win megapolygon benchmarks with its games. Super Mario Cart would be almost as fun on my 8-bit, 16-color, sprie graphics Ninendo. Nintendo is very good at distilling the essence out of games and refining that game experience,
Just as Microsoft have their usability experts, Nintendo seems to have their playability experts. You don't need great graphics to make a great Nintendo game. People still play the original Super Mario Brothers from time to time. Far fewer people still play even Quake I. Maybe it's nostalgia, but I honestly think that nobody beats Nintendo when it comes to timeless games. Atari had a few really great games, but I think history will show Nintendo to be the king of timeless games.