Yes, a polar solvent works well with polar solute. That is why water (quite polar) disolves salts very well. I thought most organic solvents (benzine, acetone, etc) were not particularly polar, though, so I am not sure how these ionic liquids work compared to the organic solvents.
If your employer needs to keep programmers (as opposed to operators/sysadmins) on call 24/7, then your software is not reliable enough. Even given that they are a hospital.
This is just not true. Any custom software system should have a developer on call whenever there is a sysadmin on call. The sysadmin needs someone to call if there is a problem with the application. Even the most reliable software will occasionally have problems, even if only due to other system failure.
For instance, "The archive log destination filled up, and Oracle hung, so there are 300 wedged application processes, how to I unwedge them safely".
The place I used to work, we had a "development pager" that we passed around and the sysadmin/DBA could page if they needed to. I got beeped usually no more than once a month, unless we were doing a software upgrade and the developers forgot to tell the sysadmins about something. Also, our DBA sucked, and I was better at Oracle than him, so if he was stumped, he would call me.
The way we handled on-call time was pretty informal, but it worked for the low volume of calls we had. We were all on salary, so, we would pass the pager around between three of us, and if someone wanted to go out of town for the weekend, they would just pass it off. If the call volumes were higher, I would have wanted something more rigid, but this wasn't bad.
The sysadmins were also salaried, but I believe their contracts stipulated a certain amount of on call time. They didn't get bonus pay for answering calls, which they probably should have. Also, as sysadmins left for greener pastures, the remaining ones ended up with more on-call time.
Everybody should take heed of what Bruce Schneier has to say about biometric identification. Basically, biometric identification provides excellent identification, but no authentication. Everybody knows that you should use the same password for your ATM pin and slashdot, but what happens when your password is you thumbprint?
Biometric identification might be useful for identifying yourself to a bank teller (or any other human) that can verify that you are present, not acting under duress, and not attempting to foil or bypass the scanning device.
It isn't adequate security for ATM's, computers, or other automated systems, especially for authentication to remote computer systems, where there is no concept of a trusted client.
A large portion of the cocane in the US comes across the US/Mexico border. Just because it usually involves americans to take part, it still needs to cross the border.
And no, the US doesn't *just* watch for drugs comming across the border.We do areal survalence looking for people growing drugs, monitor electrical bills watching for people growing pot hydroponically, search inbound ocean vessels, watch for people buying chemicals to make Meth, and any number of of other tactics.
I happen to think that a large part of the "war on drug"s is irrational, but to suggest that we are naive enough to believe that drugs only come from mexico is just wrong.
Well, the RIAA has a valid point. They have told Napster what songs are copyrighted. From a philisophical and probably legal standpoint, the titles and artists are the defining information, and filenames, encoding format, etc. are just "technical details."
The problem is much more fundamental, and really strikes at the heart of human/computer interaction: computers and humans assign significance to data in totally different ways. What we look at as unimportant details are the only things that matter to the computer. Nearly every attempt to close that gap on anything but the most tightly defined problem has failed miserably.
In short, it is not technically possible for Napster to comply with the ruling. What this means from a legal perspective is unclear to me.
The good news is, there are so many completely unsecured networks out there, that if yours isn't actively encouraging eavesdroppers, you are probably far enough ahead of the curve to be "safe" (at least from script kiddie types. If someone is out to get your, you are sunk).
Not something to rely upon in the long run, more of a sad comment on the current state of wireless privacy.
I belive that many of the attacks require modified hardware/firmware. Not because they are intrinsically difficult, but because the encryption is done in hardware, and the card "automatically" drops encrypted packets when it isn't in crypto mode.
Conceptually, this is the same as only selling ethernet cards that don't support promiscious mode and claiming that makes ethernet "secure". It isn't a big hack to make a scanner yourself, and if the card has a programmable microcontroller it can likely be done with a firmware update.
You can tell only whether there was an eavesdropper after you compare notes with the person on the other end -- using classical light-speed limited communication.
Physically, the effect of the eavesdropper is to destroy the polarization correlation between the two photons. The way you determine this is if Alice and Bob compare checksums of their bits in some fashion. If they have the same results, nobody tampered with the data stream.
You can't really transfer information with entanglement (that I know of). In general, doing so would violate causality by transfering information faster than light. What you can do (and QC does) is exploit entanglement to agree on a set of (random) data that it is physically impossible for an eavesdropper to measure w/o disrupting it.
This random data can be used as a OTP to send real information.
Yeah, that is more or less how things work. generally, you use the key as a one time pad -- XOR it with your message. As long as you never reuse key bytes, you are fine. The evesdropper is checked for by using checksumming over the key data, rather than encoding a test message.
It isn't an intrinsic property per. se., but it always exists (in the lingo, it is called decoherence). Entanglement is a state of two (or more) particles that have some correlation between them. However, since they are seperated, random environmental/thermal fluctuation affect each particle differenly, randomizing the relative phase between the particles and causing the pair to become useless.
Photons only interact weakly with matter, so they tend to be pretty stable, but if you have entangled atoms, for instance, a slight difference in the local electric field can quickly destroy your carefully prepared state. This is the fundamental roadblock on the way to medium scale quantum computing -- QC involves entangled states of many many particles (~5000 to factor 1024 bit RSA, IIRC) over a relatively long period of time (a second or so). The larger a system, the harder to prevent decoherence, which is why every bit is a challenge.
The mere fact that different parts of the brain are active during meditaion is not so significant. Certainly, the motor regions should be nearly quiecent during prolonged meditation. We have different brain patterns when sleeping as well.
The fact that he can alter brain wave patterns to cause people to "feel the presence of God" is another thing entirely, and is rather significant. It puts the experience of the mystical on the same footing as other internal or externally triggered "altered states of conciousness" such as drug trips, frenzys, and clinical depression, excersise highs, and heightened awarness during crises.
<rant>
This is the difference between real science and nonsense. A lot of supposedly scientific work is entirely based on observeed correlations, especially in psycology and other "social sciences" as well as nutrition. While sometimes the results of these observations can be interesting and occasionally useful, they are hardly conclusive. Real science is about twiddling knobs and seeing what happens. Unless the researcher can control the independant variable, no statements of causality can be determined.
In particular, "People who eat 3 servings of meat a day are 30% more likely to suffer from heart disease" (totally made up statistic) does NOT imply "eating meat causes heart disease." The *only* useful content of a statement like that is for assesing risk -- ie. for an insurance company. It provides no information on how to reduce that risk.
</rant>
At least in the past (I haven't paid attention to this for some time) the JVM for most non-Solaris UNIX platforms had no JIT compiler, a poor one, or an unstable one. Both perl/mod_perl and php significantly outperform strictly interpreted Java.
It would be interesting to test mod_perl vs. Java Servlets on a neutral platform (UNIX with a good JIT) mod_perl has a slightly faster archetecture (runs in the server process), but I suspect at that point it comes down to implementation details.
In any case, if what you are concerned about is speed, use a system lets you cache quasi-static pages so it doesn't even hit your application code most times.
In the end, it usually comes down to taste/features rather than speed though. Personally, I like the perl/cgi/servlet approach of having a program that generates output over the JSP/PHP approach that intermixes code and plain HTML. For me, the deciding factor is that Perl's string manipulation rocks, and that is really what generating HTML is all about.
While I am not philisophiscally opposed to censorware in schools,
1) The use of censorware, or any specific requirements on the type of censorware should be entirely up to local district policy. The Federal government should not be mandating or regulating it use.
2) I don't belive any currently available products do their job well enough to be allowed in schools.
3) Experience has shown that policies involving censorware are neither well defiened nor reasonable.
4) Teachers and school librarians are so poorly trained/educated in the use of computers to make good recomendations to school districts or to effectively enforce an acceptable use policy.
In short, I don't believe it is currently wise to implement censorware in schools, and if it ever were, I don't think the federal goverment should have anything to do with it. Therefore I support the EFFs protest.
I also happen to think that censorware doesn't solve an important problem. I don't think that seeing some porn on the internet is going to scar children for life. As much as purveyors of censorware would like to convince you, their software *isn't* going to protect people from meeting pedophiles in chat rooms or irc. While I think the supposition that reading violent neo-nazi propaganda causes school violence isn't without merit, that starts to look very much like free speech to me. If students are deliberately seeking out that kind of material for whatever reason (research, curiosity, teen angst, desire to form a militia), I don't think it is right to censor them. Aside from the philisophical reasons, from a practical standpoint censorware vendors have shown gross incompetence when selecting what material to block, and seem to resort mostly to blocking any potentially controversial material, such informationa about the holocost, women's rights, homosexual rights, religon, and medical information on breast cancer.
People who say things like "The solution is to build better censorware" are usually too drunk of the technilogical progress of the last 30 years to realize that not every problem is a simple matter of engineering. We don't know how to make good censorware, and the chances of someone being able to make good censorware in the next 5-10 years is, IMO, negligible. Certainly a combination of blacklists and whitelists, open or closed, is woefully inadequite, and none of the heuristic methods seem to be any good.
Not true at all. First, there are no ground wires in ethernet cabling. In fact, the spec *specifically* states that no conductors are to be grounded. This is because ground potential can vary in large installations, and you would get ground loops with potentially large currents flowing through your cat5 if you tried it.
Instead of grounding, ethernet uses differential signals. Each direction (send and receive) has a pair of wires. If the wires are at the same voltage, it is a physical "0", if the + pin is 5V higher, it is a physical "1". (I belive it is 5V logic, but am not actually sure). Since the pairs are twisted, any "line noise" will affect both wires the same, and the difference will be the same at the other end. This is also the way differential SCSI, and most multi-drop physical protocols work)
10BaseTx and 100BaseTx require two pairs. Many premade cables don't even have the other two pairs, and the spec allows you to use one or both of the unused pairs as phone or other connections (that is why the wiring diagram skips the center two pins -- those are reserved for phone use). I wired my parents house, and most of the cables are split so one run of Cat5 gives two 100BaseTx ports.
100BaseT4 (a competing 100 Mbit ethernet standard that never took off) requires all 4 pairs, but works with only Cat3 cables, instead of Cat5.
One word of warning: If you run ethernet along exterior walls, consider adding surge supressors to the ethernet. We has a near lightning strike that as near as we can tell grounded through the chimney, inducing large currents in the ethernet cable running right next to it. No physical damage to our house, but it destoyed or damaged 4 motherboards, CPUs, and ethernet cards, a laser printer, and the hub.
Whether the throttling is a good thing is up to debate (and I say it is good: If you don't properly cool your CPU it won't melt down!). However, it appears that Intel *still* mis-represented the power consumption, which is something Intel advocates have been bashing AMD over. In particular, people have claimed that the Athalon will have problems scaling because of its high power consumption. It looks to me like the P4 will face the same problem.
The concepts are totally unrelated. Kernel developers try to make the kernel as secure as possible in the OpenBSD sense, which mostly means "If the spec says an operation isn't allowed, a user can't trick the system into allowing it". ie, "no exploits".
Security modules are about defining new types of policys. You can go a long way on POSIX file permissions, but sometimes you want the extra level of flexiblity that systems like SELinux and LIDS allow. Perhaps they should be called "Security Policy modules" or just "Policy modules", instead.
Check out the selinux and LIDS web pages for more information on what these patches actually provide.
That was jargonspeak for "he says blue if there are an odd number of blue hats in front of him, and red if there are an odd number of red hats in front of him". Or vise versa, as long as everyone knows the plan.
Or, if you meant just say the color of the hat in front of person #10, that is the "trivail" solution in which up to 5/10 die.
The person at the back of the line says what the parity of the 9 hats in front of him is. Person 9 computes the parity of the people in front of him, and deduces his hat color. Each subsequent person knows the parity of the front 9 people, hears the color of all of those behind, and sees those in front of him (except for person 10, who is fucked no matter what). Thus they can all deduce their hat color.
They talk about this at the bottom of the article. It would appear to break the laws of random odds, since the other players hats give you no information about your own. And in fact, if you look carefully, you only guess right 50% of the time. The trick is, when one person guesses wrong, all three do, yet it only counts as one failed trial.
Of the 8 possible hat combinations, 6 of them will have exactly one person answer correctly, and the other 2 will have all 3 people answer incorrectly.
This isn't about Disney saying "W3r3 1337 d00dz" because they have gigabit ethernet, but the fact by carefully designing their network they are getting realtime constraints on ethernet performance only previously available on ATM and other more expensive networks.
The multi-channel audio stuff they talk about is stuff the phone company has been doing for years, but the PC industry has never managed to do sucessfully, which is why high-bandwidth streaming doesn't work even over a fast LAN if there is a moderate amount of traffic.
Firewire is supposed to solve this in the consumer market by vastly over-provisioning bandwidth, but there is only so far that approach scales.
Actually, there is a really easy way to make these networks secure. Put your wireless access point outside of your firewall, then use VPN software on the client to connect to your intranet. You can also filter at your router to prevent people from getting a "free ride" on the internet if you are concerned about that.
That way, you totally bypass the WEP and have a reasonablly well tested security model (VPN) guarding your data.
When I set up 802.11b in my house, that is what I am going to do...
It is belived, but not (as far as I know proven) that a QC is *NOT* a completely general NDFA (thus capable of solving NP in polynomial time). Thus the question is sort of moot in this context.
Second, I believe an algorithm is known that can do lookups in unsorted, unindexed lists in O(log(n)) time. That is certainly an interesting proposition.
Third, encryption *is* a big deal. You or I are not necessarily worried about someone developing a QC to read our email, but governments are.
Finally, there are a number of protocols in quantum cryptography and quantum information that are not general purpose quantum computers, but might be very useful. Also, we don't really know what a quantum computer might be capable of, and won't until we have one built.
Right now, the reason people are building bigger quantum computers is because they want to study them, not because their computing power (even for "easy" quantum problems like finding large prime factors) is going to be usable any time soon.
Basically, you have an interferometer that looks like this:
/--\
||
1--/--/
|
2
where the lower left hand '/' is a beam splitter, and the other/'s and \'s are regular mirrors. Shine a laser in from the left (1), and normally all light comes out the left -- there is perfect destructive interference between the clockwise and counter-clockwise paths to come out port (2).
If you rotate the whole apparatus, you effectively shorten one path and lengthen the other, and from the change in the inteference, you can measure the angular velocity.
Now replace the whole thing with a big loop of fiber optics with a fiber coupler instead of a beam splitter, and you have a light weight, very precise, solid state gyroscope.
Underclocking is also very useful in embedded systems where power or heat are serious problems. If you are lucky, you can take a coppermine CPU, underclock it a lot, and put on a big passive heat sink, and still not over heat. This might be important if you are making a MP3 player for your stereo and you don't want fan noise.
I haven't tried this yet, so I don't actually know if you can do that, but it should be possible.
Slashdot Mirror
Yes, a polar solvent works well with polar solute. That is why water (quite polar) disolves salts very well. I thought most organic solvents (benzine, acetone, etc) were not particularly polar, though, so I am not sure how these ionic liquids work compared to the organic solvents.
This is just not true. Any custom software system should have a developer on call whenever there is a sysadmin on call. The sysadmin needs someone to call if there is a problem with the application. Even the most reliable software will occasionally have problems, even if only due to other system failure.
For instance, "The archive log destination filled up, and Oracle hung, so there are 300 wedged application processes, how to I unwedge them safely".
The place I used to work, we had a "development pager" that we passed around and the sysadmin/DBA could page if they needed to. I got beeped usually no more than once a month, unless we were doing a software upgrade and the developers forgot to tell the sysadmins about something. Also, our DBA sucked, and I was better at Oracle than him, so if he was stumped, he would call me.
The way we handled on-call time was pretty informal, but it worked for the low volume of calls we had. We were all on salary, so, we would pass the pager around between three of us, and if someone wanted to go out of town for the weekend, they would just pass it off. If the call volumes were higher, I would have wanted something more rigid, but this wasn't bad.
The sysadmins were also salaried, but I believe their contracts stipulated a certain amount of on call time. They didn't get bonus pay for answering calls, which they probably should have. Also, as sysadmins left for greener pastures, the remaining ones ended up with more on-call time.
Everybody should take heed of what Bruce Schneier has to say about biometric identification. Basically, biometric identification provides excellent identification, but no authentication. Everybody knows that you should use the same password for your ATM pin and slashdot, but what happens when your password is you thumbprint?
Biometric identification might be useful for identifying yourself to a bank teller (or any other human) that can verify that you are present, not acting under duress, and not attempting to foil or bypass the scanning device.
It isn't adequate security for ATM's, computers, or other automated systems, especially for authentication to remote computer systems, where there is no concept of a trusted client.
A large portion of the cocane in the US comes across the US/Mexico border. Just because it usually involves americans to take part, it still needs to cross the border.
And no, the US doesn't *just* watch for drugs comming across the border.We do areal survalence looking for people growing drugs, monitor electrical bills watching for people growing pot hydroponically, search inbound ocean vessels, watch for people buying chemicals to make Meth, and any number of of other tactics.
I happen to think that a large part of the "war on drug"s is irrational, but to suggest that we are naive enough to believe that drugs only come from mexico is just wrong.
Well, the RIAA has a valid point. They have told Napster what songs are copyrighted. From a philisophical and probably legal standpoint, the titles and artists are the defining information, and filenames, encoding format, etc. are just "technical details."
The problem is much more fundamental, and really strikes at the heart of human/computer interaction: computers and humans assign significance to data in totally different ways. What we look at as unimportant details are the only things that matter to the computer. Nearly every attempt to close that gap on anything but the most tightly defined problem has failed miserably.
In short, it is not technically possible for Napster to comply with the ruling. What this means from a legal perspective is unclear to me.
The good news is, there are so many completely unsecured networks out there, that if yours isn't actively encouraging eavesdroppers, you are probably far enough ahead of the curve to be "safe" (at least from script kiddie types. If someone is out to get your, you are sunk).
Not something to rely upon in the long run, more of a sad comment on the current state of wireless privacy.
I belive that many of the attacks require modified hardware/firmware. Not because they are intrinsically difficult, but because the encryption is done in hardware, and the card "automatically" drops encrypted packets when it isn't in crypto mode.
Conceptually, this is the same as only selling ethernet cards that don't support promiscious mode and claiming that makes ethernet "secure". It isn't a big hack to make a scanner yourself, and if the card has a programmable microcontroller it can likely be done with a firmware update.
You can tell only whether there was an eavesdropper after you compare notes with the person on the other end -- using classical light-speed limited communication.
Physically, the effect of the eavesdropper is to destroy the polarization correlation between the two photons. The way you determine this is if Alice and Bob compare checksums of their bits in some fashion. If they have the same results, nobody tampered with the data stream.
You can't really transfer information with entanglement (that I know of). In general, doing so would violate causality by transfering information faster than light. What you can do (and QC does) is exploit entanglement to agree on a set of (random) data that it is physically impossible for an eavesdropper to measure w/o disrupting it.
This random data can be used as a OTP to send real information.
Yeah, that is more or less how things work. generally, you use the key as a one time pad -- XOR it with your message. As long as you never reuse key bytes, you are fine. The evesdropper is checked for by using checksumming over the key data, rather than encoding a test message.
It isn't an intrinsic property per. se., but it always exists (in the lingo, it is called decoherence). Entanglement is a state of two (or more) particles that have some correlation between them. However, since they are seperated, random environmental/thermal fluctuation affect each particle differenly, randomizing the relative phase between the particles and causing the pair to become useless.
Photons only interact weakly with matter, so they tend to be pretty stable, but if you have entangled atoms, for instance, a slight difference in the local electric field can quickly destroy your carefully prepared state. This is the fundamental roadblock on the way to medium scale quantum computing -- QC involves entangled states of many many particles (~5000 to factor 1024 bit RSA, IIRC) over a relatively long period of time (a second or so). The larger a system, the harder to prevent decoherence, which is why every bit is a challenge.
The mere fact that different parts of the brain are active during meditaion is not so significant. Certainly, the motor regions should be nearly quiecent during prolonged meditation. We have different brain patterns when sleeping as well.
The fact that he can alter brain wave patterns to cause people to "feel the presence of God" is another thing entirely, and is rather significant. It puts the experience of the mystical on the same footing as other internal or externally triggered "altered states of conciousness" such as drug trips, frenzys, and clinical depression, excersise highs, and heightened awarness during crises.
<rant>
This is the difference between real science and nonsense. A lot of supposedly scientific work is entirely based on observeed correlations, especially in psycology and other "social sciences" as well as nutrition. While sometimes the results of these observations can be interesting and occasionally useful, they are hardly conclusive. Real science is about twiddling knobs and seeing what happens. Unless the researcher can control the independant variable, no statements of causality can be determined.
In particular, "People who eat 3 servings of meat a day are 30% more likely to suffer from heart disease" (totally made up statistic) does NOT imply "eating meat causes heart disease." The *only* useful content of a statement like that is for assesing risk -- ie. for an insurance company. It provides no information on how to reduce that risk.
</rant>
At least in the past (I haven't paid attention to this for some time) the JVM for most non-Solaris UNIX platforms had no JIT compiler, a poor one, or an unstable one. Both perl/mod_perl and php significantly outperform strictly interpreted Java.
It would be interesting to test mod_perl vs. Java Servlets on a neutral platform (UNIX with a good JIT) mod_perl has a slightly faster archetecture (runs in the server process), but I suspect at that point it comes down to implementation details.
In any case, if what you are concerned about is speed, use a system lets you cache quasi-static pages so it doesn't even hit your application code most times.
In the end, it usually comes down to taste/features rather than speed though. Personally, I like the perl/cgi/servlet approach of having a program that generates output over the JSP/PHP approach that intermixes code and plain HTML. For me, the deciding factor is that Perl's string manipulation rocks, and that is really what generating HTML is all about.
While I am not philisophiscally opposed to censorware in schools,
1) The use of censorware, or any specific requirements on the type of censorware should be entirely up to local district policy. The Federal government should not be mandating or regulating it use.
2) I don't belive any currently available products do their job well enough to be allowed in schools.
3) Experience has shown that policies involving censorware are neither well defiened nor reasonable.
4) Teachers and school librarians are so poorly trained/educated in the use of computers to make good recomendations to school districts or to effectively enforce an acceptable use policy.
In short, I don't believe it is currently wise to implement censorware in schools, and if it ever were, I don't think the federal goverment should have anything to do with it. Therefore I support the EFFs protest.
I also happen to think that censorware doesn't solve an important problem. I don't think that seeing some porn on the internet is going to scar children for life. As much as purveyors of censorware would like to convince you, their software *isn't* going to protect people from meeting pedophiles in chat rooms or irc. While I think the supposition that reading violent neo-nazi propaganda causes school violence isn't without merit, that starts to look very much like free speech to me. If students are deliberately seeking out that kind of material for whatever reason (research, curiosity, teen angst, desire to form a militia), I don't think it is right to censor them. Aside from the philisophical reasons, from a practical standpoint censorware vendors have shown gross incompetence when selecting what material to block, and seem to resort mostly to blocking any potentially controversial material, such informationa about the holocost, women's rights, homosexual rights, religon, and medical information on breast cancer.
People who say things like "The solution is to build better censorware" are usually too drunk of the technilogical progress of the last 30 years to realize that not every problem is a simple matter of engineering. We don't know how to make good censorware, and the chances of someone being able to make good censorware in the next 5-10 years is, IMO, negligible. Certainly a combination of blacklists and whitelists, open or closed, is woefully inadequite, and none of the heuristic methods seem to be any good.
Not true at all. First, there are no ground wires in ethernet cabling. In fact, the spec *specifically* states that no conductors are to be grounded. This is because ground potential can vary in large installations, and you would get ground loops with potentially large currents flowing through your cat5 if you tried it.
Instead of grounding, ethernet uses differential signals. Each direction (send and receive) has a pair of wires. If the wires are at the same voltage, it is a physical "0", if the + pin is 5V higher, it is a physical "1". (I belive it is 5V logic, but am not actually sure). Since the pairs are twisted, any "line noise" will affect both wires the same, and the difference will be the same at the other end. This is also the way differential SCSI, and most multi-drop physical protocols work)
10BaseTx and 100BaseTx require two pairs. Many premade cables don't even have the other two pairs, and the spec allows you to use one or both of the unused pairs as phone or other connections (that is why the wiring diagram skips the center two pins -- those are reserved for phone use). I wired my parents house, and most of the cables are split so one run of Cat5 gives two 100BaseTx ports.
100BaseT4 (a competing 100 Mbit ethernet standard that never took off) requires all 4 pairs, but works with only Cat3 cables, instead of Cat5.
One word of warning: If you run ethernet along exterior walls, consider adding surge supressors to the ethernet. We has a near lightning strike that as near as we can tell grounded through the chimney, inducing large currents in the ethernet cable running right next to it. No physical damage to our house, but it destoyed or damaged 4 motherboards, CPUs, and ethernet cards, a laser printer, and the hub.
Whether the throttling is a good thing is up to debate (and I say it is good: If you don't properly cool your CPU it won't melt down!). However, it appears that Intel *still* mis-represented the power consumption, which is something Intel advocates have been bashing AMD over. In particular, people have claimed that the Athalon will have problems scaling because of its high power consumption. It looks to me like the P4 will face the same problem.
The concepts are totally unrelated. Kernel developers try to make the kernel as secure as possible in the OpenBSD sense, which mostly means "If the spec says an operation isn't allowed, a user can't trick the system into allowing it". ie, "no exploits".
Security modules are about defining new types of policys. You can go a long way on POSIX file permissions, but sometimes you want the extra level of flexiblity that systems like SELinux and LIDS allow. Perhaps they should be called "Security Policy modules" or just "Policy modules", instead.
Check out the selinux and LIDS web pages for more information on what these patches actually provide.
That was jargonspeak for "he says blue if there are an odd number of blue hats in front of him, and red if there are an odd number of red hats in front of him". Or vise versa, as long as everyone knows the plan.
Or, if you meant just say the color of the hat in front of person #10, that is the "trivail" solution in which up to 5/10 die.
The person at the back of the line says what the parity of the 9 hats in front of him is. Person 9 computes the parity of the people in front of him, and deduces his hat color. Each subsequent person knows the parity of the front 9 people, hears the color of all of those behind, and sees those in front of him (except for person 10, who is fucked no matter what). Thus they can all deduce their hat color.
They talk about this at the bottom of the article. It would appear to break the laws of random odds, since the other players hats give you no information about your own. And in fact, if you look carefully, you only guess right 50% of the time. The trick is, when one person guesses wrong, all three do, yet it only counts as one failed trial.
Of the 8 possible hat combinations, 6 of them will have exactly one person answer correctly, and the other 2 will have all 3 people answer incorrectly.
This isn't about Disney saying "W3r3 1337 d00dz" because they have gigabit ethernet, but the fact by carefully designing their network they are getting realtime constraints on ethernet performance only previously available on ATM and other more expensive networks.
The multi-channel audio stuff they talk about is stuff the phone company has been doing for years, but the PC industry has never managed to do sucessfully, which is why high-bandwidth streaming doesn't work even over a fast LAN if there is a moderate amount of traffic.
Firewire is supposed to solve this in the consumer market by vastly over-provisioning bandwidth, but there is only so far that approach scales.
Actually, there is a really easy way to make these networks secure. Put your wireless access point outside of your firewall, then use VPN software on the client to connect to your intranet. You can also filter at your router to prevent people from getting a "free ride" on the internet if you are concerned about that.
That way, you totally bypass the WEP and have a reasonablly well tested security model (VPN) guarding your data.
When I set up 802.11b in my house, that is what I am going to do...
It is belived, but not (as far as I know proven) that a QC is *NOT* a completely general NDFA (thus capable of solving NP in polynomial time). Thus the question is sort of moot in this context.
Second, I believe an algorithm is known that can do lookups in unsorted, unindexed lists in O(log(n)) time. That is certainly an interesting proposition.
Third, encryption *is* a big deal. You or I are not necessarily worried about someone developing a QC to read our email, but governments are.
Finally, there are a number of protocols in quantum cryptography and quantum information that are not general purpose quantum computers, but might be very useful. Also, we don't really know what a quantum computer might be capable of, and won't until we have one built.
Right now, the reason people are building bigger quantum computers is because they want to study them, not because their computing power (even for "easy" quantum problems like finding large prime factors) is going to be usable any time soon.
Basically, you have an interferometer that looks like this:
/--\ /'s and \'s are regular mirrors. Shine a laser in from the left (1), and normally all light comes out the left -- there is perfect destructive interference between the clockwise and counter-clockwise paths to come out port (2).
||
1--/--/
|
2
where the lower left hand '/' is a beam splitter, and the other
If you rotate the whole apparatus, you effectively shorten one path and lengthen the other, and from the change in the inteference, you can measure the angular velocity.
Now replace the whole thing with a big loop of fiber optics with a fiber coupler instead of a beam splitter, and you have a light weight, very precise, solid state gyroscope.
Commercial aircraft use these, too.
Underclocking is also very useful in embedded systems where power or heat are serious problems. If you are lucky, you can take a coppermine CPU, underclock it a lot, and put on a big passive heat sink, and still not over heat. This might be important if you are making a MP3 player for your stereo and you don't want fan noise.
I haven't tried this yet, so I don't actually know if you can do that, but it should be possible.