Knuth is clearly very smart, and his books have a lot of neat nuggets in them. But I think both the perspective and the presentation are very old-fashioned. I'm not just talking about MIX or his pseudocode, but also the kinds of problems he chooses and the depth to which he covers topics that really aren't relevant to most people anymore.
Knuth's volumes probably should be on your bookshelf. But for learning about algorithms, I think you are better served with a more modern textbook, which focuses on teaching techniques and approaches. And for any particular specialty (string matching, combinatorial algorithms, etc.), there are also lots of books that are more relevant and more complete.
It's an interesting question you raise there: did you actually buy bandwidth?
Yes, that is what my TOS say. If yours don't, they should.
Unfortunately, it is their problem when they start receiving huge numbers of abuse calls because you left your box open.
You are confusing what is with what should be. Of course, this is the way things are right now. I'm arguing that it shouldn't be. The access provider should be a carrier, with no responsibility for what travels over their wires, other than making sure that the IP headers are correct. What happens right now is that ISPs stick their fingers in all sorts of content controls, but the one thing they don't do and the one thing that they actually should control is that every packet is identified correctly.
do you think asymmetry fell from the sky???
on
Broadband Crackdown
·
· Score: 2
With many modern broadband technologies, there is no technical reason for any asymmetry. In fact, you could even change the allocation dynamically. The reason for the existing asymmetry is simply that companies decided on that. It's probably part marketing ("there is no demand for anything else") and part deliberate long-term strategy ("we don't want end-users to create and distribute much content").
Re:I've read my TOS and it sucks.
on
Broadband Crackdown
·
· Score: 3, Insightful
Because 99.9% of security issues comes from someone running an unpatched redhat box at home.
Even if that were true, so what? I bought bandwidth from my ISP and I expect them to deliver that bandwidth. If my machine has a security problem and starts attacking other sites on the Internet, that should be my problem, not my broadband provider's problem. My broadband provider may choose to limit my outgoing and incoming bandwidth to a previously contractually agreed-upon minimum, but no further.
By your reasoning, the telephone companies should listen in on our telephone conversations to make sure we don't do anything illegal and don't make prank calls. Wisely, we have chosen not to place that authority in them, and we should take a similar approach to security with broadband providers.
Seriously people... Most, if not all, broadband providers prohibit running servers from home accounts
And what exactly is a "server"? Is accessing your Pilot calendar remotely using a server? Is using an FTP client a server? What about identd? What about my PC vendor's remote Windows support system? Is running a client connection to establish a VPN to some other host on the Internet and poking out a server socket on that machine "running a server"? Let's be concrete please, because my TOS don't actually say. They are so vague that the provider can make up what they mean whenever they like.
And especially don't start with the geek indignation, because consumer broadband is not meant, nor sold, under the pretense of running home servers.
That would be true if broadband providers fully owned all the rights of way and infrastructure. They don't. They tear up public streets and use public spectrum only because the communities where they deliver service let them. They can be kicked out if they don't satisfy the needs of the community. And peer-to-peer and servers are crucially important in particular for non-commercial and non-profit uses.
Furthermore, for broadband providers to try to control whether you may run a "server" is the beginning of content controls. The next thing you know, you'll only be able to connect to the commercial sites of your provider's choosing.
Broadband providers should be legally required to provide universal Internet connectivity and set rates and limitations based on bandwidth and volume only. Possibly, there might be two rate structures, one for non-commercial and another for commercial customers. But providers should have no business deciding what content or packets travel over their networks, as long as the packets are properly addressed and their format is according to spec.
Nevertheless, when it comes to face recognition software, we know that it is nowhere near as reliable as person identification by humans. Note that humans have a lot more information available to them than just the facial appearance, including a lot of biographical facts about most of the people they interact with day-to-day.
Yup, it does. However, what matters to me is not the probability that a person/machine misrecognizes me, but the probability that I am misrecognized on any given day. And even if machines were as good as people at recognizing people (which they aren't), that latter probability is still a lot higher because the machines (purposely) scan and report on much larger populations.
By your logic, someone with poorer-than-average eyesight should not be allowed to identify a criminal, just because the chances of misidentification are a little higher than if the eyewitness was Superman.
Eyewitnesses identifications should, in many cases, not be sufficient for a conviction--they are too unreliable. Unfortunately, the legal system is way out of step with science in this regard.
Our legal system, policing, penalties, and social activities are all careful balances of probabilities and risks. If you add universal surveillance, you dramatically change one part of the equation without compensating elsewhere.
In this case, for example, I think it wouldn't work even if the rate of false positives was no higher than it is for "Wanted" posters. Because the number of individuals scanned is so much higher, the absolute number of positive matches would be much higher. As a consequence, even if the rate of false positives is the same, the probability for you (or anybody else) of being misidentified increase dramatically because of the higher numbers. Is that acceptable? I don't think so. And are you going to increase the number of police pursuing these leads? Who is going to pay for that?
Furthermore, even the rate (not just the absolute numbers) of false positives is likely to be much higher, because with "Wanted" posters, people do the recognition and they take into account other knowledge they have about the person besides appearances.
Well, for applications where the traffic isn't too high, a workstation with a software VPN solution. That clearly is not a good solution for many installations, but it is easy to set up and shows that technically, there is nothing complex about it. I don't know of any high-end hardware solutions that is designed to handle such a configuration. (I'm also not sure it's really a good way of setting up a VPN, but that's another issue.)
Let me ask you the corresponding question. With MPLS, how do you handle encryption? Do you just not bother? Do you do it in software? Or do you use hardware? How do you distribute keys and how do you revoke them? How do you install those keys on your encryption hardware if you are using hardware?
So, the question is: why is the industry pushing MPLS rather than offering better VPNs? Probably MPLS is really being deployed because it addresses another problem, and this is just another service that can be offered using it. No doubt, users find it convenient given that devices with equivalent/better VPN-based functionality aren't being sold (as widely?). Communications providers may like that it creates a "closer relationship" with their customer (i.e., you probably won't switch as easily). Hardware manufacturers may see an opportunity to sell a lot more boxes. I don't know exactly what the reason is, that's what I'm trying to understand (thanks--the discussion so far has helped). In any case, I'd hold on to my wallet:-)
Yes, VPNs don't have a widely used protocol for dynamically distributing their configuration information. That's probably because people haven't traditionally used VPNs in that way and because VPN configuration is a much simpler problem than updating Internet routing information and can be addressed pretty well without a special protocol.
Now, let's say that VPN configuration was as complex as Internet routing. Why develop MPLS when all you you want is a dynamic update of VPN configuration information? Why do all the routers in between the VPN endpoints need to do something different? And, as I indicated, you still have the (dynamic) key distribution problem, unless you send plaintext data outside your network (shudder).
Wouldn't there be high management overhead to reproduce with IPSEC tunnels?
I don't see why. With a VPN, each participant needs to know the public keys, gateways, and subnets of all the others it wants to talk to directly. You can distribute and update that information automatically from a central, public site as a single file and have it installed on each satellite system automatically. How much easier can it get?
MPLS somewhere requires at least the same amount of information. Now, maybe your communications provider uses their internal customer/equipment database to hide this from you, but the bookkeeping is still happening, and presumably you are paying for the convenience. Furthermore, since your provider isn't doing encryption for you with MPLS, you still have the same key distribution problem, so you end up doing the distribution yourself anyway, at least if you want any kind of security.
So, overall, I still don't get it. In terms of total effort, MPLS seems no easier to set up and use than a VPN to me. It's shifting some of the work around, but its lack of encryption means that you end up duplicating effort anyway.
MPLS VPNs are just as secure (or not) as Frame Relay, which is used by most enterprise private networks (the provider runs the Frame Relay part).
That doesn't sound particularly reassuring, since it relies on physical security, integrity of your infrastructure, and trust in your provider if you outsource. For example, if anybody breaks into some machine that's part of your infrastructure, they can potentially get access to all the traffic going through that router.
it's a lot harder to run a huge IPSec VPN than an MPLS VPN
I still don't understand what you mean by this. What is there "to run" with a VPN? For a VPN, you need to know the gateways, subnets, and public keys of anybody you want to talk to (if you don't want encryption, you don't need the keys), and you don't have to think about transports or routing at all since that is taken care of by the existing Internet infrastructure. It seems to me that MPLS requires you to worry about additional things. So, I really don't see how MPLS makes things simpler for anybody when it comes to VPNs.
As I understand it, using MPLS to set up IP tunnels eliminates encryption. That means you just don't get the same security as with a VPN--you are missing the "P" in "VPN".
I also don't quite understand why you say that a "300 site IPSEC Tunnel VPN" would be harder to manage. It seems that if you have a public key infrastructure (and you need that anyway), any two sites can easily and securely identify themselves to each other and set up a VPN between them if they choose; there should be no need for any central administration or management at all, at least if you have reasonably good software at the endpoints.
The question of the behavior of different materials in this experiment seems of paramount importance. It seems odd that the paper has so little actual data--no precise description of the materials used, no separate measurements for different materials, no error bars, no statistical analysis.
Some random thoughts... There are no photographs of the experimental setup--why not? Has anybody other than the authors witnessed this? Why didn't anybody else review the experimental setup and get acknowledged? What material were they using for hanging the target? If it's a thin wire, conductive, that could be an explanation. Despite their claimed precautions, sound and vibration might also be possibilities.
It's curious. Once it gets witnessed and reproduced, it starts getting interesting. Until then, it could be a hoax, it could be self-deception, or any of a number of subtle mistakes. If it's real, it would be great, of course.
Does this mean screen grabbers are now illegal circumvention devices under the DMCA? There are screen grabbers that will automatically scroll through a window and will store the complete content in a file.
What bogus idea will Adobe come up with next that will result in yet more technology becoming illegal?
Microsoft is focused on getting XP out in October, and they are rationally playing for as much time as they can. To me, that looks completely Machiavellian, uninterested in justice, and devoid of conscience, just like you would expect a profit-maximizing non-human entity to behave. Keep this in mind when you give that entity your credit card number or entrust it with personal information. Scary.
Microsoft's authentication and directory structure is already changing wildly with current and upcoming releases. Making SMB incompatible would just be more of the same.
How do they get their customers to switch? By having lots of little network effects going, keeping backwards compatibility for a while, and tying everything together. So, you upgrade to the next version of office to be able to communicate with your customers. Well, that means upgrading to the next version of Windows, but that's not too bad, since you don't really need to use the new protocols. Well, after another round or two, you do, and you end up running software and protocols you never wanted. That's the danger of having one company do everything; break Microsoft up.
Yup...but can you point to a web-based installer prior to 1998?
People downloaded DOOM updates over the web before then, and Linux bug fixes, and lots of other stuff. How do you think people most people got their web browsers and security updates to it (many of them)? How do you think the NCSA web server was distributed? The first downloads happened over FTP (a web protocol) or a number of web-like protocols. Subsequent updates/downloads happened over the web. It took years for that kind of software to get distributed any other way.
I'm not necessarily defending the scope or righteousness of the patent system in general,
Oh, yes, you are; otherwise, you wouldn't make such random comments in response to a discussion about the problems with a specific comment. And like many people who do that sort of thing, you either don't have a clue about what has happened over the last 50 years in computer science or the computer industry, or you just conveniently choose to ignore it for demagogic reasons. Either way, your kind of response is as predictable as it is tiresome.
Well, for a nice system that does this, go to enhydra.org. The content is in XML, and presentation/logic in Java. Other XML-based systems are examples of this as well. There are also a number of non-XML "template processors" that are widely used.
$5M from DARPA, $50M from venture investments. Berners-Lee, Dertouzos, and a bunch of MIT professors sure have selling power. And all of that for doing what current web standards are already doing, just with a more Lisp-ish syntax. It would sure be lucrative to replace a messy open standard with a messy proprietary one.
Lucky for us, and too bad for them it won't fly. People who have actually worked on large-scale web development already know that mixing code and content in this way is a maintenance headache. And the others seem reasonably happy with JavaScript and VBScript.
I believe the patent is an example of the kinds of bad patents granted these days: technology that was already obvious to people decades ago and even used in some commercial systems, but not patented at the time because the patent system doesn't allow it and not written up at the time because it was too trivial.
It doesn't matter whether this patent is used to protect free software or whether the inventor allows GPL'ed software to use it, it is still a bad patent. It also doesn't matter that commercial entities are using patents that are just as bogus.
Now, a portfolio of good, strong patents used in this way might, in fact, help free software.
Slashdot Mirror
Knuth's volumes probably should be on your bookshelf. But for learning about algorithms, I think you are better served with a more modern textbook, which focuses on teaching techniques and approaches. And for any particular specialty (string matching, combinatorial algorithms, etc.), there are also lots of books that are more relevant and more complete.
Current state:
- Broadband provider may fail to deliver minimum bandwidth.
- One misbehaved user can use up all available bandwidth.
- Broadband provider fails to enforce correct IP addressing, facilitating DOS attacks.
- Broadband provider attempts to control the content of packets.
- Customers don't get a well-defined product and have to live with arbitrary restrictions as their broadband provider flounders.
Desired state:- Broadband provider delivers minimum bandwidth (more is optional).
- Broadband provider enforces upper limits on bandwidth.
- Broadband provider enforces correct IP addressing.
- Broadband provider is oblivious to content of packets.
- Customers get a well-defined, predictable product at a well-defined, predictable price.
Easy, isn't it?Yes, that is what my TOS say. If yours don't, they should.
Unfortunately, it is their problem when they start receiving huge numbers of abuse calls because you left your box open.
You are confusing what is with what should be. Of course, this is the way things are right now. I'm arguing that it shouldn't be. The access provider should be a carrier, with no responsibility for what travels over their wires, other than making sure that the IP headers are correct. What happens right now is that ISPs stick their fingers in all sorts of content controls, but the one thing they don't do and the one thing that they actually should control is that every packet is identified correctly.
With many modern broadband technologies, there is no technical reason for any asymmetry. In fact, you could even change the allocation dynamically. The reason for the existing asymmetry is simply that companies decided on that. It's probably part marketing ("there is no demand for anything else") and part deliberate long-term strategy ("we don't want end-users to create and distribute much content").
Even if that were true, so what? I bought bandwidth from my ISP and I expect them to deliver that bandwidth. If my machine has a security problem and starts attacking other sites on the Internet, that should be my problem, not my broadband provider's problem. My broadband provider may choose to limit my outgoing and incoming bandwidth to a previously contractually agreed-upon minimum, but no further.
By your reasoning, the telephone companies should listen in on our telephone conversations to make sure we don't do anything illegal and don't make prank calls. Wisely, we have chosen not to place that authority in them, and we should take a similar approach to security with broadband providers.
And what exactly is a "server"? Is accessing your Pilot calendar remotely using a server? Is using an FTP client a server? What about identd? What about my PC vendor's remote Windows support system? Is running a client connection to establish a VPN to some other host on the Internet and poking out a server socket on that machine "running a server"? Let's be concrete please, because my TOS don't actually say. They are so vague that the provider can make up what they mean whenever they like.
And especially don't start with the geek indignation, because consumer broadband is not meant, nor sold, under the pretense of running home servers.
That would be true if broadband providers fully owned all the rights of way and infrastructure. They don't. They tear up public streets and use public spectrum only because the communities where they deliver service let them. They can be kicked out if they don't satisfy the needs of the community. And peer-to-peer and servers are crucially important in particular for non-commercial and non-profit uses.
Furthermore, for broadband providers to try to control whether you may run a "server" is the beginning of content controls. The next thing you know, you'll only be able to connect to the commercial sites of your provider's choosing.
Broadband providers should be legally required to provide universal Internet connectivity and set rates and limitations based on bandwidth and volume only. Possibly, there might be two rate structures, one for non-commercial and another for commercial customers. But providers should have no business deciding what content or packets travel over their networks, as long as the packets are properly addressed and their format is according to spec.
Nevertheless, when it comes to face recognition software, we know that it is nowhere near as reliable as person identification by humans. Note that humans have a lot more information available to them than just the facial appearance, including a lot of biographical facts about most of the people they interact with day-to-day.
Yup, it does. However, what matters to me is not the probability that a person/machine misrecognizes me, but the probability that I am misrecognized on any given day. And even if machines were as good as people at recognizing people (which they aren't), that latter probability is still a lot higher because the machines (purposely) scan and report on much larger populations.
By your logic, someone with poorer-than-average eyesight should not be allowed to identify a criminal, just because the chances of misidentification are a little higher than if the eyewitness was Superman.
Eyewitnesses identifications should, in many cases, not be sufficient for a conviction--they are too unreliable. Unfortunately, the legal system is way out of step with science in this regard.
In this case, for example, I think it wouldn't work even if the rate of false positives was no higher than it is for "Wanted" posters. Because the number of individuals scanned is so much higher, the absolute number of positive matches would be much higher. As a consequence, even if the rate of false positives is the same, the probability for you (or anybody else) of being misidentified increase dramatically because of the higher numbers. Is that acceptable? I don't think so. And are you going to increase the number of police pursuing these leads? Who is going to pay for that?
Furthermore, even the rate (not just the absolute numbers) of false positives is likely to be much higher, because with "Wanted" posters, people do the recognition and they take into account other knowledge they have about the person besides appearances.
Let me ask you the corresponding question. With MPLS, how do you handle encryption? Do you just not bother? Do you do it in software? Or do you use hardware? How do you distribute keys and how do you revoke them? How do you install those keys on your encryption hardware if you are using hardware?
So, the question is: why is the industry pushing MPLS rather than offering better VPNs? Probably MPLS is really being deployed because it addresses another problem, and this is just another service that can be offered using it. No doubt, users find it convenient given that devices with equivalent/better VPN-based functionality aren't being sold (as widely?). Communications providers may like that it creates a "closer relationship" with their customer (i.e., you probably won't switch as easily). Hardware manufacturers may see an opportunity to sell a lot more boxes. I don't know exactly what the reason is, that's what I'm trying to understand (thanks--the discussion so far has helped). In any case, I'd hold on to my wallet :-)
Now, let's say that VPN configuration was as complex as Internet routing. Why develop MPLS when all you you want is a dynamic update of VPN configuration information? Why do all the routers in between the VPN endpoints need to do something different? And, as I indicated, you still have the (dynamic) key distribution problem, unless you send plaintext data outside your network (shudder).
I don't take it to be a standard as much as a simple statement of fact: this is what you need to do to convince others.
Thanks for pointing this out; I caught it on the second reading. Now, can you tell me what metal the "metal spheres" were made of?
I don't see why. With a VPN, each participant needs to know the public keys, gateways, and subnets of all the others it wants to talk to directly. You can distribute and update that information automatically from a central, public site as a single file and have it installed on each satellite system automatically. How much easier can it get?
MPLS somewhere requires at least the same amount of information. Now, maybe your communications provider uses their internal customer/equipment database to hide this from you, but the bookkeeping is still happening, and presumably you are paying for the convenience. Furthermore, since your provider isn't doing encryption for you with MPLS, you still have the same key distribution problem, so you end up doing the distribution yourself anyway, at least if you want any kind of security.
So, overall, I still don't get it. In terms of total effort, MPLS seems no easier to set up and use than a VPN to me. It's shifting some of the work around, but its lack of encryption means that you end up duplicating effort anyway.
That doesn't sound particularly reassuring, since it relies on physical security, integrity of your infrastructure, and trust in your provider if you outsource. For example, if anybody breaks into some machine that's part of your infrastructure, they can potentially get access to all the traffic going through that router.
it's a lot harder to run a huge IPSec VPN than an MPLS VPN
I still don't understand what you mean by this. What is there "to run" with a VPN? For a VPN, you need to know the gateways, subnets, and public keys of anybody you want to talk to (if you don't want encryption, you don't need the keys), and you don't have to think about transports or routing at all since that is taken care of by the existing Internet infrastructure. It seems to me that MPLS requires you to worry about additional things. So, I really don't see how MPLS makes things simpler for anybody when it comes to VPNs.
I also don't quite understand why you say that a "300 site IPSEC Tunnel VPN" would be harder to manage. It seems that if you have a public key infrastructure (and you need that anyway), any two sites can easily and securely identify themselves to each other and set up a VPN between them if they choose; there should be no need for any central administration or management at all, at least if you have reasonably good software at the endpoints.
The question of the behavior of different materials in this experiment seems of paramount importance. It seems odd that the paper has so little actual data--no precise description of the materials used, no separate measurements for different materials, no error bars, no statistical analysis.
It's curious. Once it gets witnessed and reproduced, it starts getting interesting. Until then, it could be a hoax, it could be self-deception, or any of a number of subtle mistakes. If it's real, it would be great, of course.
What bogus idea will Adobe come up with next that will result in yet more technology becoming illegal?
Microsoft is focused on getting XP out in October, and they are rationally playing for as much time as they can. To me, that looks completely Machiavellian, uninterested in justice, and devoid of conscience, just like you would expect a profit-maximizing non-human entity to behave. Keep this in mind when you give that entity your credit card number or entrust it with personal information. Scary.
How do they get their customers to switch? By having lots of little network effects going, keeping backwards compatibility for a while, and tying everything together. So, you upgrade to the next version of office to be able to communicate with your customers. Well, that means upgrading to the next version of Windows, but that's not too bad, since you don't really need to use the new protocols. Well, after another round or two, you do, and you end up running software and protocols you never wanted. That's the danger of having one company do everything; break Microsoft up.
People downloaded DOOM updates over the web before then, and Linux bug fixes, and lots of other stuff. How do you think people most people got their web browsers and security updates to it (many of them)? How do you think the NCSA web server was distributed? The first downloads happened over FTP (a web protocol) or a number of web-like protocols. Subsequent updates/downloads happened over the web. It took years for that kind of software to get distributed any other way.
I'm not necessarily defending the scope or righteousness of the patent system in general,
Oh, yes, you are; otherwise, you wouldn't make such random comments in response to a discussion about the problems with a specific comment. And like many people who do that sort of thing, you either don't have a clue about what has happened over the last 50 years in computer science or the computer industry, or you just conveniently choose to ignore it for demagogic reasons. Either way, your kind of response is as predictable as it is tiresome.
Well, for a nice system that does this, go to enhydra.org. The content is in XML, and presentation/logic in Java. Other XML-based systems are examples of this as well. There are also a number of non-XML "template processors" that are widely used.
Lucky for us, and too bad for them it won't fly. People who have actually worked on large-scale web development already know that mixing code and content in this way is a maintenance headache. And the others seem reasonably happy with JavaScript and VBScript.
It doesn't matter whether this patent is used to protect free software or whether the inventor allows GPL'ed software to use it, it is still a bad patent. It also doesn't matter that commercial entities are using patents that are just as bogus.
Now, a portfolio of good, strong patents used in this way might, in fact, help free software.