Since the article is about US models of cars, the US numbers are appropriate. Since the article claims that this feature is already common in European diesels, I would guess that it is still a win in those cars as well.
These conditions apparently don't show up enough to justify the cost of determining safe operating parameters. Therefore, no flying. It isn't really complicated -- if a bunch of airlines want to get together and pay for the testing, they can fly. Otherwise, they stay on the ground.
I think that if the average person walking around had a 10% chance to be carrying a camera that could do thermal imaging, it would be hard to argue that you had a reasonable expectation of privacy and the police would probably be allowed to use it without a warrant.
If LIDAR cost 100k, I think the law enforcement would still be entitled to use it, but if FLIR cost $100 that would make a difference.
IR cameras and film detect NIR in the 800nm - 1.3 micron range. Your stove heating element that is glowing a dim red will light up brightly in such a device, but it is completely useless for this type of application. IR thermometers and thermal imaging systems for the 0-100F range use much longer wavelengths, around 10 microns.
Note that you can't even make IR film that is any good at thermal wavelengths because it would get exposed sitting in a box. The film would have to be prepared, stored, used, and developed in a cryogenic environment. This may have been done (perhaps for IR astronomy), but you obviously can't just buy a roll of 35mm "thermal" film and pop it in a nikon.
Openfiler's web gui is buggy as hell, its local LDAP server option is poorly documented and provides terrible diagnostic messages when improperly configured, and it has no official support for installing/booting from flash. Never trust a product that wants to charge money for the admin guide.
I only tried FreeNAS briefly, and did end up using openfiler, but I would love to see anything beat openfiler.
He is represented by a public defender, which means he can't afford a new lawyer, and his current lawyer can't afford to put together a respectable case.
GCD is a mechanism to let one central authority dispatch threads across multiple cores, for all running applications (including the OS).
This is what most people talk about, and what is most obvious from the name, but it is not the interesting part of GCD.
The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads. This is only useful because OS X has horrendous per-thread overhead. On Linux, for instance, the correct answer is usually to create as many threads as you have parallel tasks and let the OS scheduler sort it out. Other operating systems (Solaris, Windows) have caught up to Linux on this front, but apparently not OS X. If you can get the overhead of OS threads down to an acceptable level, it is always better to avoid multiple layers of scheduling.
So we've had a defined standard that was, arguably, not the easiest to understand. THEN harddrive manufacturers started their fraud. And THEN people started complaining. So what, and please think about this, would be the right decision here?
This is revisionist at best and really just wrong. Despite all "wisdom" to the contrary, there has never been a universal acceptance of 1 MB = 2^20 bytes on computers. For instance, all of IBMs mainframe hard drives from the 60s and 70s were sold using base-10 prefixes. Early desktop hard drives from the 80s used both. I think the ST506 used base-2, but some other models used base-10. All networking and communications standards (ethernet, modems, PCI, SATA...) use base 10 prefixes for MB/s and Mbit/s. 3.5" floppy disks used NASA-style units where 1 MB = 10^3*2^10. Even while RAM is still almost always measured in base-2 units (due to manufacturing issues making it much easier to produce in power-of-2 sizes -- something which is not true for hard drives) the speed of the memory bus on your CPU is still measured in base-10 units.
It is a *good* idea to have K and M mean the same thing everywhere. A system where a 1 GB/s link transfers 0.93 GB every second is stupid. This is especially important as computers are being used in more and more environments. Should a 1 megapixel camera mean 2^20 pixels? What about CDs with a 44.1 KHz sampling rate?
[quote]Truth is, nothing irreplacable was provided by the GNU project. [/quote]
I can't see you you can possibly think that is relevant. Whether there were other options that *could* have been used doesn't change the fact that a circa 1992 "linux" system was largely a GNU system.
I certainly agree that a modern Linux based desktop is not a GNU OS, but I think it was a perfectly reasonable request in the early 90s. I still call it Linux, mostly because the name is shorter, and I am not about to call it GNU/X11/Gnome/Linux. And the reasons I choose to run Linux over (say) FreeBSD are mostly to do with the kernel and the kernel specific system tools, and not with the userland.
Compiler and toolchain, and all the 'standard' UNIX tools: the shell, the text utils like cat, grep, awk, etc.
Basically, back in the 80s, the FSF, reimplemented what was at that time nearly the entirety of what was called UNIX except the kernel (which was what the HURD project was/is). It was to be the GNU OS. While the kernel was in development, the userspace tools were developed and ported to other UNIX systems like sunos as a replacement for the often deficient historical versions supported by the UNIX vendors.
So when Linus came along and wrote a UNIX-like kernel using gcc, he could load all those programs on and have a mostly functioning UNIX environment. This was the reason RMS objected to calling it just Linux, at that time the majority of the code running on the system was GNU. It was probably a legitimate point at the time. And even if there were a different compiler, without a set of userspace tools that people could freely get and use it is unlikely Linux would have been able to take off.
Now, of course, a huge part of the user experience is provided by X11, the desktop environments, and various graphical appliations. GNOME is part of the GNU project but X.org, KDE, and most of the applications are not. So it isn't really true that GNU software is still the majority of the OS. Of course, the kernel is even less important in terms of the user environment, and despite all the other software around it, GNU utilities are what makes it (not) UNIX.
That is a pretty bad example. C++ references hardly count as references since you can't reassign them. They are really just syntactic sugar to make operator overloading look nice and reduce the number of -> operators. They cannot be used alone to create complex data structures.
A better example would be references in lisp, perl, or java. They solve many of the problems of C/C++ pointers. They can't be out of bounds. They must respect the type safety of the language. They can't point to an invalid or destroyed object due to garbage collection. However, they all support a null reference.
Maybe there is a better way to do this where you don't ever need null references, but I know two things for certain 1) SQL is not it 2) People will still make errors where data they expect to be there is not.
Agilent also offers pretty hefty academic discounts, enough to make their scopes price competitive with the others.
Personally, I have used Agilent and Lecroy midrange scopes (the 500 MHz-1 GHz range) and prefer the Lecroys. Particularly, the Lecroy scopes seem to have more analysis and triggering options that the Agilent only has in the next step up. Also, the lecroy's I have used tended to have more buttons and knobs while the agilent did more with softkeys. That may be simply a factor of the generation (the lecroy's were a few years older), and not an intrinsic difference.
From what I have seen, I much prefer both to the tek scopes in that range, but I haven't really used them.
For low-end scopes (100 MHz), I have only used tek. Lecroy only recently entered that market and I haven't used any of theirs, at that price range the agilents were just too much of a premium.
Actually, the cheap cards you are talking about wouldn't have this problem. Their firmware is not actually stored in flash, but in RAM which is why it must be refreshed on every boot. If you write a bad blob to it, a power cycle fixes it.
Associated technologies is the watchword there. They make their money off of everything that goes around the hypervisor to make it easy for admins to manage dozens or hundreds of VMs across many servers.
One notable exception is NFS and iSCSI which are both frequently used for serving VM disk images and benefit quite a bit from having MTU > block size, typically 4k or 8k. Jumbo frames are a big win for this.
Again, we're now talking about different things. You seemed quite happy with domain verification when it's done right. Now you're sort of indicating that verification using a CA is entirely pointless.
No, i think verification by a CA of *identity* can be very valuable. That is much more than checking domain ownership. At the minimum that requires a name and address, and if there is a business name it should be verified as well. Among other things this provides a chain of accountability--if I get screwed by someone using an SSL certificate I can get enough information to track them down to press charges or whatever. Obviously a CA can't determine whether foobarwidgets.com is actually a legitimate enterprise, but if they tell me it belongs to Bob Smith of Lexington, KY, owner of Foo Widgets, incorporated in the state of Kentucky that actually means something.
The existence of low-cost SSL CAs actually *does* make the entire web less secure, since many browsers (though not FF3, evidentially) treat them the same as validated certificates. This means I only have to game the weakest CA to get a paypal certificate.
FF3 (hopefully others have or will do the same) improves this a lot by using a different UI for domain-only certs vs. validated certs. However, once you do that, I don't see any advantage to not treating self-signed certificates in the same (or similar) way.
Since my bank is not using plain http and would continue to use a signed and verified SSL certificate, that would not happen at all.
The connection to my bank would still be protected against impersonators, plus my communication with slashdot would be protected from passive eavesdropping. While that isn't worth a lot, it is worth something.
I also think it is a bit of a fantasy thinking that you can securely use the internet if your DNS has been taken over, but that is a different discussion.
I've seen this over and over, with nothing to back it up. Which CAs will do this? I'd like to know so that I can test them, and if it's true, remove their certs from my browser.
I got a RapidSSL certificate, and they would allow domain ownership to be verified by any email listed in the whois record or any of about 10 "predefined" email addresses @domainname in question, including root, admin, postmaster, webmaster, and several others.
The only legitimate person to contact is the "administrative contact" in the whois record. Neither the technical contact nor whoever happens to get email sent to webmaster@example.com should be able to get a certificate on their own. Furthermore, the email itself in insecure and any number of people along the way are in a position to intercept the validation email. Since it is a completely automated system, it also vulnerable to trojans, even if the infected computer is on an otherwise "insecure" part of the network network.
But that is beside the point, really. Domain ownership is not a particularly useful thing to prove. Anyone can register a domain. For instance, Bank of America owns bankofamerica.com bankamerica.com and probably several others to reduce the dangers of typo squatting, but they can't anticipate every possible legitimate appearing name much less hard to notice typos.
At the very least an SSL certificate used for commerce should include a physical address and contact person and the CA should validate that those are correct, that they own the domain in question, and that they actually requested the certificate.
Yes, it does. The problem you are seeing is that the person who generated the certificate could be anybody. But the same is true for the cheap CAs--they will sign a certificate of basically anyone who asks. So you know that you are talking to the person they gave the certificate to, but that could be anyone. The $10 certificates are a waste of money since they don't prove anything meaningful.
Just getting users to accept self-signed server certificates is very bad, because it trains them to accept them, and they'll get phished.
I agree. What browsers should do is accept self-signed certificates without prompting and make the UI clearly display the difference between encrypted (has https in the URL but displays no signs of authentication) and authenticated (yellow/green URL bar, padlock closed). Then, drop support for all the discount CAs that provide worthless certificates.
No, the certificates verify that you are talking to whoever the CA gave the certificate to. That's all they do, and that's very important.
That is of no value whatsoever if they will give the certificate to anyone. It is just as true for a self-signed certificate--it verifies you are talking to the person who generated the certificate.
The $10 certificates are a giant boondoggle, a business that shouldn't exist except for misguided policy decisions on the part of browser developers.
SSL isn't meant just for encrypting pages, it's meant for verifying identity also.
As the article says. SSL does both. FF3 in particular makes the first completely unusable for no good reason. The web would unquestionably be more secure if all http servers switched to using self-signed SSL certificates in place of unencrypted connections.
2. buy a cheap ass certificate from godaddy for $10. Your domain registration likely costs this much as well, but we don't complain about that, do we? The service is actually worth $10.
The $10 certificates have essentially no value over a self-signed certificate. The only reason they even exist is that browsers make it so hard to use self-signed certificates.
Without the above, the ff3 presentation is correct, the certificate is bad and should not be trusted.
The correct behavior is to allow self-signed certificates with no warning at all, but not display the yellow bar/padlock that CA verified SSL certificates do. Then they should drop support for all signing authorities that have only an automated check for domain ownership, since they are of next to no value. Warnings should still be generated for expired certificates and probably those signed by unknown CAs.
The simplest example of a quantum computing algorithm is Deutsch's algorithm.
Here is how it works. Consider a simple boolean function b_out = f(b_in). It takes an argument that can be 1 or 0 and returns a 1 or 0. There are four possibilities: always zero, always 1, the identify, and logical not.
Now imagine that I give you a black box that computes 'f'. However, it is very, very slow --maybe internally it is computing some NP-complete problem. If you want to know which of the four functions the box calculates, you need to run it twice, once for zero and once for one.
However, suppose you simply want to find out whether zero and one map to the same or different values, i.e., the parity of f. With classical computers, you are screwed. You still have to run the box twice to find that even though you only want to get a single bit of information.
However, you can do better if the black box I gave you is a quantum implementation of f(x). By feeding in a input state that is a superposition of 0 and 1, I can detect in a single evaluation plus some simple operations whether the function is constant or not. However, in doing so I get no information about the specific value. Effectively I can ask any one-bit question about f(x) as efficiently as a specific value.
It unlikely this will every be useful as stated. While it is known how to efficiently translate every classical computing algorithm into a quantum version it is unlikely a real implementation would be within a factor of 2 in speed or cost. I believe it illustrates the basic idea. The character of other quantum algorithms is similar, you often feed in a superposition of all possible inputs and read a single output which is the specific answer you want with high probability without having to ever compute the values you don't want.
Slashdot Mirror
Since the article is about US models of cars, the US numbers are appropriate. Since the article claims that this feature is already common in European diesels, I would guess that it is still a win in those cars as well.
These conditions apparently don't show up enough to justify the cost of determining safe operating parameters. Therefore, no flying. It isn't really complicated -- if a bunch of airlines want to get together and pay for the testing, they can fly. Otherwise, they stay on the ground.
I think that if the average person walking around had a 10% chance to be carrying a camera that could do thermal imaging, it would be hard to argue that you had a reasonable expectation of privacy and the police would probably be allowed to use it without a warrant.
If LIDAR cost 100k, I think the law enforcement would still be entitled to use it, but if FLIR cost $100 that would make a difference.
Or, learn what you are talking about.
IR cameras and film detect NIR in the 800nm - 1.3 micron range. Your stove heating element that is glowing a dim red will light up brightly in such a device, but it is completely useless for this type of application. IR thermometers and thermal imaging systems for the 0-100F range use much longer wavelengths, around 10 microns.
Note that you can't even make IR film that is any good at thermal wavelengths because it would get exposed sitting in a box. The film would have to be prepared, stored, used, and developed in a cryogenic environment. This may have been done (perhaps for IR astronomy), but you obviously can't just buy a roll of 35mm "thermal" film and pop it in a nikon.
Openfiler's web gui is buggy as hell, its local LDAP server option is poorly documented and provides terrible diagnostic messages when improperly configured, and it has no official support for installing/booting from flash. Never trust a product that wants to charge money for the admin guide.
I only tried FreeNAS briefly, and did end up using openfiler, but I would love to see anything beat openfiler.
He is represented by a public defender, which means he can't afford a new lawyer, and his current lawyer can't afford to put together a respectable case.
This is what most people talk about, and what is most obvious from the name, but it is not the interesting part of GCD.
The interesting part of GCD is blocks and tasks, and it is useful to the extent which it makes expressing parallelism more convenient to the programmer.
The "central management of OS threads" is marketing speak for a N-M scheduler with an OS wide limit on the number of heavyweight threads. This is only useful because OS X has horrendous per-thread overhead. On Linux, for instance, the correct answer is usually to create as many threads as you have parallel tasks and let the OS scheduler sort it out. Other operating systems (Solaris, Windows) have caught up to Linux on this front, but apparently not OS X. If you can get the overhead of OS threads down to an acceptable level, it is always better to avoid multiple layers of scheduling.
This is revisionist at best and really just wrong. Despite all "wisdom" to the contrary, there has never been a universal acceptance of 1 MB = 2^20 bytes on computers. For instance, all of IBMs mainframe hard drives from the 60s and 70s were sold using base-10 prefixes. Early desktop hard drives from the 80s used both. I think the ST506 used base-2, but some other models used base-10. All networking and communications standards (ethernet, modems, PCI, SATA...) use base 10 prefixes for MB/s and Mbit/s. 3.5" floppy disks used NASA-style units where 1 MB = 10^3*2^10. Even while RAM is still almost always measured in base-2 units (due to manufacturing issues making it much easier to produce in power-of-2 sizes -- something which is not true for hard drives) the speed of the memory bus on your CPU is still measured in base-10 units.
It is a *good* idea to have K and M mean the same thing everywhere. A system where a 1 GB/s link transfers 0.93 GB every second is stupid. This is especially important as computers are being used in more and more environments. Should a 1 megapixel camera mean 2^20 pixels? What about CDs with a 44.1 KHz sampling rate?
Why would you say something as silly as that spice netlist format is not a programming language?
[quote]Truth is, nothing irreplacable was provided by the GNU project. [/quote]
I can't see you you can possibly think that is relevant. Whether there were other options that *could* have been used doesn't change the fact that a circa 1992 "linux" system was largely a GNU system.
I certainly agree that a modern Linux based desktop is not a GNU OS, but I think it was a perfectly reasonable request in the early 90s. I still call it Linux, mostly because the name is shorter, and I am not about to call it GNU/X11/Gnome/Linux. And the reasons I choose to run Linux over (say) FreeBSD are mostly to do with the kernel and the kernel specific system tools, and not with the userland.
Compiler and toolchain, and all the 'standard' UNIX tools: the shell, the text utils like cat, grep, awk, etc.
Basically, back in the 80s, the FSF, reimplemented what was at that time nearly the entirety of what was called UNIX except the kernel (which was what the HURD project was/is). It was to be the GNU OS. While the kernel was in development, the userspace tools were developed and ported to other UNIX systems like sunos as a replacement for the often deficient historical versions supported by the UNIX vendors.
So when Linus came along and wrote a UNIX-like kernel using gcc, he could load all those programs on and have a mostly functioning UNIX environment. This was the reason RMS objected to calling it just Linux, at that time the majority of the code running on the system was GNU. It was probably a legitimate point at the time. And even if there were a different compiler, without a set of userspace tools that people could freely get and use it is unlikely Linux would have been able to take off.
Now, of course, a huge part of the user experience is provided by X11, the desktop environments, and various graphical appliations. GNOME is part of the GNU project but X.org, KDE, and most of the applications are not. So it isn't really true that GNU software is still the majority of the OS. Of course, the kernel is even less important in terms of the user environment, and despite all the other software around it, GNU utilities are what makes it (not) UNIX.
That is a pretty bad example. C++ references hardly count as references since you can't reassign them. They are really just syntactic sugar to make operator overloading look nice and reduce the number of -> operators. They cannot be used alone to create complex data structures.
A better example would be references in lisp, perl, or java. They solve many of the problems of C/C++ pointers. They can't be out of bounds. They must respect the type safety of the language. They can't point to an invalid or destroyed object due to garbage collection. However, they all support a null reference.
Maybe there is a better way to do this where you don't ever need null references, but I know two things for certain 1) SQL is not it 2) People will still make errors where data they expect to be there is not.
You think that quantum computers are not able to justify grants or PhDs? What world are you living in?
Yeah, because classical computers were never useful to anyone (or anyone important) until datacenters existed.
And until then, developments that bring us closer are irrelevant? Applications that could give us more reason to develop the technology are pointless?
What exactly is your point here?
Agilent also offers pretty hefty academic discounts, enough to make their scopes price competitive with the others.
Personally, I have used Agilent and Lecroy midrange scopes (the 500 MHz-1 GHz range) and prefer the Lecroys. Particularly, the Lecroy scopes seem to have more analysis and triggering options that the Agilent only has in the next step up. Also, the lecroy's I have used tended to have more buttons and knobs while the agilent did more with softkeys. That may be simply a factor of the generation (the lecroy's were a few years older), and not an intrinsic difference.
From what I have seen, I much prefer both to the tek scopes in that range, but I haven't really used them.
For low-end scopes (100 MHz), I have only used tek. Lecroy only recently entered that market and I haven't used any of theirs, at that price range the agilents were just too much of a premium.
Actually, the cheap cards you are talking about wouldn't have this problem. Their firmware is not actually stored in flash, but in RAM which is why it must be refreshed on every boot. If you write a bad blob to it, a power cycle fixes it.
Associated technologies is the watchword there. They make their money off of everything that goes around the hypervisor to make it easy for admins to manage dozens or hundreds of VMs across many servers.
One notable exception is NFS and iSCSI which are both frequently used for serving VM disk images and benefit quite a bit from having MTU > block size, typically 4k or 8k. Jumbo frames are a big win for this.
No, i think verification by a CA of *identity* can be very valuable. That is much more than checking domain ownership. At the minimum that requires a name and address, and if there is a business name it should be verified as well. Among other things this provides a chain of accountability--if I get screwed by someone using an SSL certificate I can get enough information to track them down to press charges or whatever. Obviously a CA can't determine whether foobarwidgets.com is actually a legitimate enterprise, but if they tell me it belongs to Bob Smith of Lexington, KY, owner of Foo Widgets, incorporated in the state of Kentucky that actually means something.
The existence of low-cost SSL CAs actually *does* make the entire web less secure, since many browsers (though not FF3, evidentially) treat them the same as validated certificates. This means I only have to game the weakest CA to get a paypal certificate.
FF3 (hopefully others have or will do the same) improves this a lot by using a different UI for domain-only certs vs. validated certs. However, once you do that, I don't see any advantage to not treating self-signed certificates in the same (or similar) way.
Since my bank is not using plain http and would continue to use a signed and verified SSL certificate, that would not happen at all.
The connection to my bank would still be protected against impersonators, plus my communication with slashdot would be protected from passive eavesdropping. While that isn't worth a lot, it is worth something.
I also think it is a bit of a fantasy thinking that you can securely use the internet if your DNS has been taken over, but that is a different discussion.
I got a RapidSSL certificate, and they would allow domain ownership to be verified by any email listed in the whois record or any of about 10 "predefined" email addresses @domainname in question, including root, admin, postmaster, webmaster, and several others.
The only legitimate person to contact is the "administrative contact" in the whois record. Neither the technical contact nor whoever happens to get email sent to webmaster@example.com should be able to get a certificate on their own. Furthermore, the email itself in insecure and any number of people along the way are in a position to intercept the validation email. Since it is a completely automated system, it also vulnerable to trojans, even if the infected computer is on an otherwise "insecure" part of the network network.
But that is beside the point, really. Domain ownership is not a particularly useful thing to prove. Anyone can register a domain. For instance, Bank of America owns bankofamerica.com bankamerica.com and probably several others to reduce the dangers of typo squatting, but they can't anticipate every possible legitimate appearing name much less hard to notice typos.
At the very least an SSL certificate used for commerce should include a physical address and contact person and the CA should validate that those are correct, that they own the domain in question, and that they actually requested the certificate.
Yes, it does. The problem you are seeing is that the person who generated the certificate could be anybody. But the same is true for the cheap CAs--they will sign a certificate of basically anyone who asks. So you know that you are talking to the person they gave the certificate to, but that could be anyone. The $10 certificates are a waste of money since they don't prove anything meaningful.
I agree. What browsers should do is accept self-signed certificates without prompting and make the UI clearly display the difference between encrypted (has https in the URL but displays no signs of authentication) and authenticated (yellow/green URL bar, padlock closed). Then, drop support for all the discount CAs that provide worthless certificates.
That is of no value whatsoever if they will give the certificate to anyone. It is just as true for a self-signed certificate--it verifies you are talking to the person who generated the certificate.
The $10 certificates are a giant boondoggle, a business that shouldn't exist except for misguided policy decisions on the part of browser developers.
As the article says. SSL does both. FF3 in particular makes the first completely unusable for no good reason. The web would unquestionably be more secure if all http servers switched to using self-signed SSL certificates in place of unencrypted connections.
The $10 certificates have essentially no value over a self-signed certificate. The only reason they even exist is that browsers make it so hard to use self-signed certificates.
The correct behavior is to allow self-signed certificates with no warning at all, but not display the yellow bar/padlock that CA verified SSL certificates do. Then they should drop support for all signing authorities that have only an automated check for domain ownership, since they are of next to no value. Warnings should still be generated for expired certificates and probably those signed by unknown CAs.
Dude, put the bong down.
The simplest example of a quantum computing algorithm is Deutsch's algorithm.
Here is how it works. Consider a simple boolean function b_out = f(b_in). It takes an argument that can be 1 or 0 and returns a 1 or 0. There are four possibilities: always zero, always 1, the identify, and logical not.
Now imagine that I give you a black box that computes 'f'. However, it is very, very slow --maybe internally it is computing some NP-complete problem. If you want to know which of the four functions the box calculates, you need to run it twice, once for zero and once for one.
However, suppose you simply want to find out whether zero and one map to the same or different values, i.e., the parity of f. With classical computers, you are screwed. You still have to run the box twice to find that even though you only want to get a single bit of information.
However, you can do better if the black box I gave you is a quantum implementation of f(x). By feeding in a input state that is a superposition of 0 and 1, I can detect in a single evaluation plus some simple operations whether the function is constant or not. However, in doing so I get no information about the specific value. Effectively I can ask any one-bit question about f(x) as efficiently as a specific value.
It unlikely this will every be useful as stated. While it is known how to efficiently translate every classical computing algorithm into a quantum version it is unlikely a real implementation would be within a factor of 2 in speed or cost. I believe it illustrates the basic idea. The character of other quantum algorithms is similar, you often feed in a superposition of all possible inputs and read a single output which is the specific answer you want with high probability without having to ever compute the values you don't want.