Prior to this patent coming to light it had been suggested that it was time to do something different with regard to DNS.
John Klensin, the chairman of the IAB, presented to the IDNwg in December, at which time he dropped what I would describe as an intellectual bomb, by saying that the international train had already left the station, and that IDN shouldn't hurry to get a temporary solution or incremental fix out the door. Instead, he said that the IETF should strongly consider a real directory-based solution. He's probably right.
While it is patently obvious how to encode domain names, what someone in a foreign country would see is gibberish.tld. That's not what you want someone to see. You would rather have people see your domain name translated into languages they understand.
Of course, a real directory would be nice, but we've tried it several times before, and without much success. Remember about two years ago, directories were all the buzz? Now where are they?
Also, as most here know, this is an area where politics and economics really make things ugly. So no matter what system we come up with, we'll see companies like Verisign do their best to winning another land grab.
GNUtella is an example of application layer multicast, and it has all those nasty problems.
There are two fundamental issues:
1. How do you find the nearest copy of X?
2. How do you know that it's the right X?
GNUtella could be greatly improved if there were a way to stop a search once you have found what you're looking for. There are two ways to accomplish that goal. The first is to send out some sort of "cancel" that gets queueing priority. At best you'll get a single order of magnitude improvement. And you probably need 5-6 orders, and maybe more.
The other way to cut the search off is to change the model so that instead of multicasting queries to all parties one multicasts content availability. Content is relatively stable and CPU cycles are cheap. Push to query processing as close to the client - preferably TO the client who makes it. By doing so you save me and you from an explanation why (#2) above is a big deal.
1. It only takes 4 justices to grant cert. to the Supreme Court.
2. The prevailing thinking (better left to those who claim to read palms) is that the appeals court below will rule in Microsoft's favor.
3. If that indeed turns out to be the case, at WORST Rehnquist's vote doesn't count at all in a 4:4 tie. At best he could be the tie breaker in favor of the government.
To recap, here are the issues that one has to consider in evaluating the CJ's actions:
First, he *did* disclose, and that's good because it means we can investigate whether or not he actually had a conflict of interest.
Second, if we are unable to determine whether or not he has a conflict, then he should recuse himself under the "appearance" clause.
Third, there are only 9 justices and as he wrote there is no one to fill is seat for this case. It is a justice's responsibility to participate in as many decisions as he ethically can, and on his ethics he is due more than just the benefit of the doubt, having served the country on the Court for nearly 30 years.
So I think there needs to be a bit more airing of the facts, but I'm inclined to be pleased by his decision in the end.
The problem with the orange book rating system is that it is old, decrepid, and irrelevant. For instance, to do C level testing you were supposed to have assembly language coding experience. How many people reading this note have much assembly experience?
Also, use of ACLs or labels in today's world is pretty much irrelevant to the consumer. They're a nice add on for servers, but that's the best you could say.
A seal of approval is only as useful as its meaning. A good seal of approval will have some abstract meaning like "hard to break in", and then concrete measures that define that abstract term. Over time, the concrete measures should be updated (i.e., one could lose one's rating).
For instance, If I were to design a security stamp of approval of "reasonably secure" my stamp would mean the following:
1. Source openly available
Without source only the hackers can find the problems.
1a. The system must be documented. None of this hard to write/hard to read crap.
2. The code must have been reviewed either by a person or a program to show that common failures are avoided (such as a failure to check bounds). In short, no use of gets() and it must pass lint. Java has a clear advantage here over both C and perl, by the way. I wouldn't let C touch a system that really needed to be secure. Useful as pointers are, blown pointers and buffers happen (in C).
3. BY DEFAULT the system must not allow administrative access via unencrypted or unauthenticated means. No::s in the password field with a real shell allowed, telnet, rlogin, and most of inetd disabled. Similarly, X must not allow remote screens by default.
4. BY DEFAULT, the only Internet protocol MUST be IP (no IPX, Appletalk, DECNET, etc). and daemons MUST be disabled or inaccessible to the outside (including routed, dhcpd, sendmail, and X). NO file system protocols, thank you very much!
5. Any sort of applet technology requires authentication (i.e., signatures) and authorization.
If you are doing the counting for your own purposes, and you want very accurate statistics, you should consider doing two things:
1. Use cookies to identify each browser. You want to do this anyway in order to track sessions, and for reliability purposes. Now say what you will about cookies, but their proper use would be a good thing for everyone (yes, and world peace is a great goal, I know). I would solve this by querying the browser and then pleading with the individual to allow cookies through by promising good behavior (and following through on that promise, unlike Amazon). It won't be perfect but it would be closer to enumeration than sampling.
2. Reconcile that data with unique IP addresses (i.e. if the browser won't allow you to set a cookie, consider counting at least that ip address).
Again the counting mechanisms won't be perfect, and it would be useful to do this to validate the statistical methods.
Could it possibly be that copying someone else's work without there permission is actually WRONG while at the same time recognizing that the RIAA are in fact scum? Nahh... has to be one or the other..
Your point (b) is irrelevant since most enterprises don't need a multigigabit router to get to the Internet. A Cisco can do very close to line rate up to about OC3 in either a 7500 or 7200. Also see Turbo ACLs, which cost O(c), and are available on GSRs, 7500s and 7200s.
Were I an enterprise administrator I would be a little concerned about GNUtella, since silly people can download binaries with all sorts of fun stuff. Even though they may find other ways to infect their disks, as an enterprise administrator I might be inclined to at least make it inconvenient for them to do so.
Either you or they should run an intrusion detection system. In the case of DOS or DDOS, your provider must be able to trace back the source of the attack. That means that you need a good procedure with them, and they need good procedures with their upstreams.
Don't just trust them. Ask for references in this area, or copies of those procedures.
So if you had your choice of where to download a file, knowing that it was legitimate for you to do so, would you rather get that file from some random shmo or would you rather get it from the source?
What we have hear is a silly marketing idea to save the distribution company the cost of distribution, i.e., Bandwidth and lots of it!
Only it won't work. First, as a consumer I have quality requirements. If I'm going to download a 1.5 hour movie that is upwards of several hundred megabytes I'll want to know that there is sufficient bandwidth to do the job.
Next, I want to know who I'm downloading from, without having to either hack my own version of GNUtella or constantly do netstats to figure it out. In fact I'd like a digital signature, please. Let's see how often that can actually work with GNUtella, given the number of truncated files.
Now the one thing GNUtella DOES have going for it is that it is completely restartable. HTTP is not, and I know of no semantics in an FTP URL to allow for restart.
The article makes some very good points, but doesn't go into detail about the fundamentals of M&A, and how they would apply in this case. No doubt there will be consolidation in the Linux market.
Here are four key points for mergers:
1 Size Matters
The hardest mergers are those of companies of equal size. These mergers require both companies to grow by 100%, and usually outgrow lots of internal processes. In addition, there's a lot of duplication of functionality within the new company that needs to be resolved (and that's painful).
How does this apply to Linux companies?
Some of the companies out there are very much home grown, and use home grown processes meant to get them through startup phase without large expenditures (read: they hacked something together). If two such companies merge, they are in trouble, and they will be absorbed by a third company later.
2 Physical locality matters
The article points this out. If you have two units that have their engineering staffs in the same location that's a lot easier to get them to work together and communicate. On the other hand, two former competitors separated by a continent could end up continuing their competition internally, especially if management doesn't lead (this is commonplace).
3 Nitch Functionality/Coverage
Again, the article mentioned this, and it's most easily understood- the smaller the duplication the easier the merger. The Red Hat/Cygnus deal looks good from this perpsective. This means, however, that two linux companies that have divergent source code bases are going to have a hard time. Watch for this as the deals come together.
4 Cultural Fit
On the surface, people who work in the OS world have some basic philosophies in common. But that's not enough by itself. Other issues include coding and reviewing style, customer support paths, patch philosophy, functionality vs. reliability (when do you release?). How many *nixes are out there because of disagreements amongst smart people?
robwicks is right on! Given the choice between taking these sites in and using them to PROMOTE Iron Chef, they instead have decided to alienate loyal fans. Remember alt.tv.twin-peaks? Who shot JR? Here was an opportunity to advance Iron Chef into Americana (if you will excuse the expression) and they blow it. What morons.
We're going to see a lot of QoS games on the Internet in the next few years. Most of these games are likely going to be tied with Voice offerings (there are a few companies out there doing this now). It's fairly straight forward to do QoS for voice, since largely speaking that's a UDP application, and you merely police the input at a certain rate and do some sort of admission control (ala RSVP).
It's quite something else to do this for TCP. What does it mean if you drop a high priority packet? In a UDP world something has probably gone wrong. But with TCP dropping is just part of the slow start game, and likely to happen under changing conditions, since TCP rates are variable. This raises the question- how does one measure such a service? By drops? Or is it all done via 3rd parties, like keynote?
My point is that governments can have a positive impact, and further, that they can in fact create markets through their tremendous spending and regulatory powers. And it doesn't have to be the US government. One can argue about their efficiency, but that is different from the impact.
The human genome project is another example where the government took a seemingly impossible task and saw it through.
Part of this had to do with the barriers of entry to market. The same sort of analysis can be applied to Costa Rica. Even though it may seem like a usurping of private enterprise, if private enterprise sees barriers that are too high, a government interest to intervene in that market cannot dismissed without serious consideration.
The real question is whether the government of Costa Rica will recognize the appropriate time to divest itself of such a service.
We technologists seem to forget that government can play a positive role in our lives.
For example, the reason you have a phone that can call across the country is that the government gave AT&T a monopoly. And while it wasn't the best for customer service, AT&T did provide a phone to everyone who could afford it (eventually just about everyone). A monopoly can be viewed as a government extension. And since Costa Rica doesn't have to create the technology or standards, they can jumpstart their usage of the Internet this way.
Similarly, the Internet itself was a government and university effort 20 years. The web came out of the government.
This is not to say that shortages of PCs (or pencils, for that matter) can be solved with Internet connectivity. But if it's part of a balanced program, it could be done. And of course, nothing is actually free when a government provides it.
While that statement may be true, fundamentally it is the end points doing the communicating that are the interesting part, be they lap toys, palm tops, or people.
In answering this question one has to ask, what drives technology? The answer has universally been sex and money.
And since money is merely the vehicle to sex, what the next step in the Internet sexual revolution? And how much bandwidth will it take? Who was it that proposed National TeleDildonics?
Remember, by treaty, internationally you can only use the ham frequences for two way communications of a technical, personal, or unimportant nature.
And no encryption is allowed either. Not cypherpunk friendly.
Employer Provided - Employer makes the rules
on
Universal Access
·
· Score: 1
To expand on Chum's comments just a bit, when you use your employer's net connection you may have to sign an acceptable use policy. Such policies may include statements like "business only" to "no porn" to the very light "nothing illegal" (I guess we could now tie at least 3/. stories together here;-) There may also be unwanted firewalls and NATs in your way.
So just how universal is the access? There are "free" sites that advertise you to tears, but for someone who has nothing, maybe it's better than nothing.
Oh incidentally, there are companies out there that are attempting to design protocols so that more targeted advertisement can be performed locally.
Which operating systems forward source routed packets or tunnel packets without explicitly being configured to do that?
You misunderstand. I didn't say they weren't configured to route. All it takes is a device that source routes (and that includes most routing devices by default).
Meyer's article contains a collection of pot shots aimed at RMS and his tactics. He as much as says so, several times. It's easy to take such shots, but not terribly useful.
A far more worthwhile yet difficult study would be to see how free software has actually impacted the state of the art. After all, it's one thing to act based on faith (since such longitudinal studies don't exist), and something quite different to act with some factual basis for an expected result. I'll spare you a long list of examples, but consider Perl or gcc.
Actually, you might not actually have to break into a nearby host, but merely rely on it to forward a source routed packet or a tunnel (GRE/L2TP, for instance).
If you are talking about using private address space (or any assignment of addresses) and the routing system as a form of security, it's weak security at best. Your message (and others) implied that.
This is a common misconception, propagated by people usually selling something.
Jordy is wrong - in some ways, and perhaps right in others. The two big examples sited, however, are not entirely fair and deserve a response.
Disclosure- I work for Cisco, but I don't speak for them.
It is certainly true that Cisco doesn't put out code without demonstrated demand, and multicast is a perfect example. I know. I asked Len Bosak to do multicast in 1990. Cisco likes making money. Big shock.
However, anyone who has been at the IETF for the last few years knows that Cisco has contributed a lot to both the standards and the state of the art. The reason that multicast is disabled by default is that there are two standards for multicast routing- DVMRP and PIM. To make matters more screwy there are two different types of PIM - sparse and dense. None of these play well with each other by default. Hence, The Principle of Least Astonishment dictates that we not enable anything until the standards settle down a bit. (If you're turning on anything, btw, go with PIM sparse).
Add to that areas where service providers are rightfully nervous. This relates to interdomain multicast (IDR), and the use of MBGP and MSDP. This stuff is still pretty fresh code. Not to mention that many ISPs don't know how to measure and plan for multicast services. The only thing that will help them is gradual deployments so they can get operational experience.
Regarding IPv6, we're all going there, slowly but surely. We need some customers to use it. Want it? Ask for it. We've actually had images you can play with for years. But the routing software isn't the only issue. There is a vast support infrastructure that is tied to IPv4 right now, such as HPOV, your preferred commercial databases, most free (or any other) code. To paraphrase the great William Shatner:
IPv4 is BIG! Really BIG!
Said in another way, the installed base of IPv4 is over 100 million people and has been for some time. Moving to a new version will take time and great care, things break all over the place.
Finally, on proprietary standards, all I ask is that you simply count the number of Cisco employees who attend IETF, and then look at the quality of the output of the groups they're in.
And this is the difference between Cisco and Microsoft, IMHO. Our APIs, if you will, are protocols such as IP, RIP, OSPF, BGP, IS-IS, SNMP, HTTP (to some extent), COPS, and RSVP, all protocols that were done in the open, in full view of the public, with public participation.
Several people have tied the notion of Network Address Translation and the use of private IP address space to firewalls.
The use of private address space in itself offers little if any security!
All that is required to break in to a site using RFC-1918 space is a compromised account on a system that has local routing knowledge. That could be a router or a nearby server.
The issue with H.323 and VoIP is the underlying quality of transport between the two endpoints. Voice has a tolerance of about 200ms delay. Beyond that you start getting echo. The technology is pretty much there to ensure that you get good quality from anywhere on earth, but ISPs are still attempting to build services for it. Essentially it requires either diffserv or intserv, and intserv isn't happening on the Internet anytime soon. But it can happen on a corporate WAN. Also, many ISPs overprovision, such that if you own both end points to a provider you can turn on things like WRED or MDRR or FRF.12 and away you go. Remember that interleaving of large packets with voice requires special treatment, though. Later versions of Ciscos will do this.
IRIX 5.3 will run fine on MIPS R4K hardware; specifically on Indigo, Indy, and Challenge hardware, as well as R3K platforms. Some later CPUs may require specific patches to operate properly.
Slashdot Mirror
Prior to this patent coming to light it had been suggested that it was time to do something different with regard to DNS.
John Klensin, the chairman of the IAB, presented to the IDNwg in December, at which time he dropped what I would describe as an intellectual bomb, by saying that the international train had already left the station, and that IDN shouldn't hurry to get a temporary solution or incremental fix out the door. Instead, he said that the IETF should strongly consider a real directory-based solution. He's probably right.
While it is patently obvious how to encode domain names, what someone in a foreign country would see is gibberish.tld. That's not what you want someone to see. You would rather have people see your domain name translated into languages they understand.
Of course, a real directory would be nice, but we've tried it several times before, and without much success. Remember about two years ago, directories were all the buzz? Now where are they?
Also, as most here know, this is an area where politics and economics really make things ugly. So no matter what system we come up with, we'll see companies like Verisign do their best to winning another land grab.
GNUtella is an example of application layer multicast, and it has all those nasty problems.
There are two fundamental issues:
1. How do you find the nearest copy of X?
2. How do you know that it's the right X?
GNUtella could be greatly improved if there were a way to stop a search once you have found what you're looking for. There are two ways to accomplish that goal. The first is to send out some sort of "cancel" that gets queueing priority. At best you'll get a single order of magnitude improvement. And you probably need 5-6 orders, and maybe more.
The other way to cut the search off is to change the model so that instead of multicasting queries to all parties one multicasts content availability. Content is relatively stable and CPU cycles are cheap. Push to query processing as close to the client - preferably TO the client who makes it. By doing so you save me and you from an explanation why (#2) above is a big deal.
Consider the following:
1. It only takes 4 justices to grant cert. to the Supreme Court.
2. The prevailing thinking (better left to those who claim to read palms) is that the appeals court below will rule in Microsoft's favor.
3. If that indeed turns out to be the case, at WORST Rehnquist's vote doesn't count at all in a 4:4 tie. At best he could be the tie breaker in favor of the government.
To recap, here are the issues that one has to consider in evaluating the CJ's actions:
First, he *did* disclose, and that's good because it means we can investigate whether or not he actually had a conflict of interest.
Second, if we are unable to determine whether or not he has a conflict, then he should recuse himself under the "appearance" clause.
Third, there are only 9 justices and as he wrote there is no one to fill is seat for this case. It is a justice's responsibility to participate in as many decisions as he ethically can, and on his ethics he is due more than just the benefit of the doubt, having served the country on the Court for nearly 30 years.
So I think there needs to be a bit more airing of the facts, but I'm inclined to be pleased by his decision in the end.
The problem with the orange book rating system is that it is old, decrepid, and irrelevant. For instance, to do C level testing you were supposed to have assembly language coding experience. How many people reading this note have much assembly experience?
::s in the password field with a real shell allowed, telnet, rlogin, and most of inetd disabled. Similarly, X must not allow remote screens by default.
Also, use of ACLs or labels in today's world is pretty much irrelevant to the consumer. They're a nice add on for servers, but that's the best you could say.
A seal of approval is only as useful as its meaning. A good seal of approval will have some abstract meaning like "hard to break in", and then concrete measures that define that abstract term. Over time, the concrete measures should be updated (i.e., one could lose one's rating).
For instance, If I were to design a security stamp of approval of "reasonably secure" my stamp would mean the following:
1. Source openly available
Without source only the hackers can find the problems.
1a. The system must be documented. None of this hard to write/hard to read crap.
2. The code must have been reviewed either by a person or a program to show that common failures are avoided (such as a failure to check bounds). In short, no use of gets() and it must pass lint. Java has a clear advantage here over both C and perl, by the way. I wouldn't let C touch a system that really needed to be secure. Useful as pointers are, blown pointers and buffers happen (in C).
3. BY DEFAULT the system must not allow administrative access via unencrypted or unauthenticated means. No
4. BY DEFAULT, the only Internet protocol MUST be IP (no IPX, Appletalk, DECNET, etc). and daemons MUST be disabled or inaccessible to the outside (including routed, dhcpd, sendmail, and X). NO file system protocols, thank you very much!
5. Any sort of applet technology requires authentication (i.e., signatures) and authorization.
Eh.. just some musings...
If you are doing the counting for your own purposes, and you want very accurate statistics, you should consider doing two things:
1. Use cookies to identify each browser. You want to do this anyway in order to track sessions, and for reliability purposes. Now say what you will about cookies, but their proper use would be a good thing for everyone (yes, and world peace is a great goal, I know). I would solve this by querying the browser and then pleading with the individual to allow cookies through by promising good behavior (and following through on that promise, unlike Amazon). It won't be perfect but it would be closer to enumeration than sampling.
2. Reconcile that data with unique IP addresses (i.e. if the browser won't allow you to set a cookie, consider counting at least that ip address).
Again the counting mechanisms won't be perfect, and it would be useful to do this to validate the statistical methods.
Could it possibly be that copying someone else's work without there permission is actually WRONG while at the same time recognizing that the RIAA are in fact scum? Nahh... has to be one or the other..
Your point (b) is irrelevant since most enterprises don't need a multigigabit router to get to the Internet. A Cisco can do very close to line rate up to about OC3 in either a 7500 or 7200. Also see Turbo ACLs, which cost O(c), and are available on GSRs, 7500s and 7200s.
Were I an enterprise administrator I would be a little concerned about GNUtella, since silly people can download binaries with all sorts of fun stuff. Even though they may find other ways to infect their disks, as an enterprise administrator I might be inclined to at least make it inconvenient for them to do so.
Napster is a horse of a different color.
Either you or they should run an intrusion detection system. In the case of DOS or DDOS, your provider must be able to trace back the source of the attack. That means that you need a good procedure with them, and they need good procedures with their upstreams.
Don't just trust them. Ask for references in this area, or copies of those procedures.
Hope this helps...
I have a friend who has dealt extensively with officials of a certain large oppressive country to the (far) east.
While we were in the throws of the Bernstein debate, etc., he asked a judge in the aformentioned country whether he could use encryption.
The judge responded that he may, so long as he could decrypt any message upon request. If he could not, he would be in trouble (read: executed).
The point is that sometimes technology cannot easily overcome oppression.
So if you had your choice of where to download a file, knowing that it was legitimate for you to do so, would you rather get that file from some random shmo or would you rather get it from the source?
What we have hear is a silly marketing idea to save the distribution company the cost of distribution, i.e., Bandwidth and lots of it!
Only it won't work. First, as a consumer I have quality requirements. If I'm going to download a 1.5 hour movie that is upwards of several hundred megabytes I'll want to know that there is sufficient bandwidth to do the job.
Next, I want to know who I'm downloading from, without having to either hack my own version of GNUtella or constantly do netstats to figure it out. In fact I'd like a digital signature, please. Let's see how often that can actually work with GNUtella, given the number of truncated files.
Now the one thing GNUtella DOES have going for it is that it is completely restartable. HTTP is not, and I know of no semantics in an FTP URL to allow for restart.
The article makes some very good points, but doesn't go into detail about the fundamentals of M&A, and how they would apply in this case. No doubt there will be consolidation in the Linux market.
Here are four key points for mergers:
1 Size Matters
The hardest mergers are those of companies of equal size. These mergers require both companies to grow by 100%, and usually outgrow lots of internal processes. In addition, there's a lot of duplication of functionality within the new company that needs to be resolved (and that's painful).
How does this apply to Linux companies?
Some of the companies out there are very much home grown, and use home grown processes meant to get them through startup phase without large expenditures (read: they hacked something together). If two such companies merge, they are in trouble, and they will be absorbed by a third company later.
2 Physical locality matters
The article points this out. If you have two units that have their engineering staffs in the same location that's a lot easier to get them to work together and communicate. On the other hand, two former competitors separated by a continent could end up continuing their competition internally, especially if management doesn't lead (this is commonplace).
3 Nitch Functionality/Coverage
Again, the article mentioned this, and it's most easily understood- the smaller the duplication the easier the merger. The Red Hat/Cygnus deal looks good from this perpsective. This means, however, that two linux companies that have divergent source code bases are going to have a hard time. Watch for this as the deals come together.
4 Cultural Fit
On the surface, people who work in the OS world have some basic philosophies in common. But that's not enough by itself. Other issues include coding and reviewing style, customer support paths, patch philosophy, functionality vs. reliability (when do you release?). How many *nixes are out there because of disagreements amongst smart people?
Anyway, just some thoughts...
robwicks is right on! Given the choice between taking these sites in and using them to PROMOTE Iron Chef, they instead have decided to alienate loyal fans. Remember alt.tv.twin-peaks? Who shot JR? Here was an opportunity to advance Iron Chef into Americana (if you will excuse the expression) and they blow it. What morons.
We're going to see a lot of QoS games on the Internet in the next few years. Most of these games are likely going to be tied with Voice offerings (there are a few companies out there doing this now). It's fairly straight forward to do QoS for voice, since largely speaking that's a UDP application, and you merely police the input at a certain rate and do some sort of admission control (ala RSVP).
It's quite something else to do this for TCP. What does it mean if you drop a high priority packet? In a UDP world something has probably gone wrong. But with TCP dropping is just part of the slow start game, and likely to happen under changing conditions, since TCP rates are variable.
This raises the question- how does one measure such a service? By drops? Or is it all done via 3rd parties, like keynote?
My point is that governments can have a positive impact, and further, that they can in fact create markets through their tremendous spending and regulatory powers. And it doesn't have to be the US government. One can argue about their efficiency, but that is different from the impact.
The human genome project is another example where the government took a seemingly impossible task and saw it through.
Part of this had to do with the barriers of entry to market. The same sort of analysis can be applied to Costa Rica. Even though it may seem like a usurping of private enterprise, if private enterprise sees barriers that are too high, a government interest to intervene in that market cannot dismissed without serious consideration.
The real question is whether the government of Costa Rica will recognize the appropriate time to divest itself of such a service.
We technologists seem to forget that government can play a positive role in our lives.
For example, the reason you have a phone that can call across the country is that the government gave AT&T a monopoly. And while it wasn't the best for customer service, AT&T did provide a phone to everyone who could afford it (eventually just about everyone). A monopoly can be viewed as a government extension. And since Costa Rica doesn't have to create the technology or standards, they can jumpstart their usage of the Internet this way.
Similarly, the Internet itself was a government and university effort 20 years. The web came out of the government.
This is not to say that shortages of PCs (or pencils, for that matter) can be solved with Internet connectivity. But if it's part of a balanced program, it could be done. And of course, nothing is actually free when a government provides it.
In answering this question one has to ask, what drives technology? The answer has universally been sex and money.
And since money is merely the vehicle to sex, what the next step in the Internet sexual revolution? And how much bandwidth will it take? Who was it that proposed National TeleDildonics?
And no encryption is allowed either. Not cypherpunk friendly.
So just how universal is the access? There are "free" sites that advertise you to tears, but for someone who has nothing, maybe it's better than nothing.
Oh incidentally, there are companies out there that are attempting to design protocols so that more targeted advertisement can be performed locally.
Be scared...
You misunderstand. I didn't say they weren't configured to route. All it takes is a device that source routes (and that includes most routing devices by default).
A far more worthwhile yet difficult study would be to see how free software has actually impacted the state of the art. After all, it's one thing to act based on faith (since such longitudinal studies don't exist), and something quite different to act with some factual basis for an expected result. I'll spare you a long list of examples, but consider Perl or gcc.
If you are talking about using private address space (or any assignment of addresses) and the routing system as a form of security, it's weak security at best. Your message (and others) implied that.
This is a common misconception, propagated by people usually selling something.
Disclosure- I work for Cisco, but I don't speak for them.
It is certainly true that Cisco doesn't put out code without demonstrated demand, and multicast is a perfect example. I know. I asked Len Bosak to do multicast in 1990. Cisco likes making money. Big shock.
However, anyone who has been at the IETF for the last few years knows that Cisco has contributed a lot to both the standards and the state of the art. The reason that multicast is disabled by default is that there are two standards for multicast routing- DVMRP and PIM. To make matters more screwy there are two different types of PIM - sparse and dense. None of these play well with each other by default. Hence, The Principle of Least Astonishment dictates that we not enable anything until the standards settle down a bit. (If you're turning on anything, btw, go with PIM sparse).
Add to that areas where service providers are rightfully nervous. This relates to interdomain multicast (IDR), and the use of MBGP and MSDP. This stuff is still pretty fresh code. Not to mention that many ISPs don't know how to measure and plan for multicast services. The only thing that will help them is gradual deployments so they can get operational experience.
Regarding IPv6, we're all going there, slowly but surely. We need some customers to use it. Want it? Ask for it. We've actually had images you can play with for years. But the routing software isn't the only issue. There is a vast support infrastructure that is tied to IPv4 right now, such as HPOV, your preferred commercial databases, most free (or any other) code. To paraphrase the great William Shatner: Said in another way, the installed base of IPv4 is over 100 million people and has been for some time. Moving to a new version will take time and great care, things break all over the place.
Finally, on proprietary standards, all I ask is that you simply count the number of Cisco employees who attend IETF, and then look at the quality of the output of the groups they're in.
And this is the difference between Cisco and Microsoft, IMHO. Our APIs, if you will, are protocols such as IP, RIP, OSPF, BGP, IS-IS, SNMP, HTTP (to some extent), COPS, and RSVP, all protocols that were done in the open, in full view of the public, with public participation.
Several people have tied the notion of Network Address Translation and the use of private IP address space to firewalls.
The use of private address space in itself offers little if any security!
All that is required to break in to a site using RFC-1918 space is a compromised account on a system that has local routing knowledge. That could be a router or a nearby server.
The issue with H.323 and VoIP is the underlying quality of transport between the two endpoints. Voice has a tolerance of about 200ms delay. Beyond that you start getting echo. The technology is pretty much there to ensure that you get good quality from anywhere on earth, but ISPs are still attempting to build services for it. Essentially it requires either diffserv or intserv, and intserv isn't happening on the Internet anytime soon. But it can happen on a corporate WAN. Also, many ISPs overprovision, such that if you own both end points to a provider you can turn on things like WRED or MDRR or FRF.12 and away you go. Remember that interleaving of large packets with voice requires special treatment, though. Later versions of Ciscos will do this.
IRIX 5.3 will run fine on MIPS R4K hardware; specifically on Indigo, Indy, and Challenge hardware, as well as R3K platforms. Some later CPUs may require specific patches to operate properly.