They say that to land the shuttle, you need an auto-pilot, a human pilot and a dog. The dog is there to guard, that the human pilot does not touch the control yoke.
The system on Donkey/Mule network works in practice.
If a RIAA person marks all good files as bad, someone will notice this at some time and add a new, additional comment refuting the other one. At that point people will just have to accept the contradiction and see for themselves. The real good files propagate enough so that their availability will be the best recommendation.
Marking bad as good helps RIAA little, because many people will mark it bad anyway, or delete it from their disks before it becomes widely spread.
Another nice info on eMule is a list of differing names of all occurrences of the file (by its MD5 has) it has found. Those often reveal more info, because people rarely use the comment feature, but they might still change file names in an informative way. This is also useful in finding what language the video is, or codecs info, or release info.
Half of their top games can be emulated on the Nintendo Revolution, and most for free and legally. And they will be available through easy to use official channels, not only from underground P2P networks.
Any new infrastructure is feasible, if it routes IP as a legacy service, and interacts nicely with a necessary subset of old protocols, like BGP, and provides rudimentary client side tools and proxies to acess the IP world outside.
I see the problem with IP is that it is both too high level and too low level. It is too high because it requires global addressing state inside the network and does not expose nodes inside to the end nodes. It is too low, because it operates on packet level, not on a level of an abstract byte stream (or a "connection", if you want), which could be negotiated for security and speed control.
Plan 9 9P/2000P provides a better altervative. As a inheritant of file level UUCP ideas with local addressing and source routing, it provides exact control of all nodes in communication with no centralized addressing. Each hop is always authenticated with application developer friendly protocols. It is perfectly capable of carrying itself over IP links, or carrying IP over 9P.
Would it be possible to develop a standard conversion tool that translates or at least helps to translate Windows driver source code to Linux driver source code, which would then be releases as binary only? So that HW manufacture could produce a binary Linux driver easily without too much expensive Linux experience work and without revealing their (perhaps legally hazardous) specs to outside community?
Note that IF a company wants to release HW specs it is mainly because they want to have Linux drivers available and a Linux market. It is not that releasing specs would be ever ba an end itself, but rather an unpleasant means.
Generally, wouldn't it be a time for Mr. Torvalds to start thinking about making life easier for proprietary driver development (like freezing the driver binary interface between minor kernel releases).
On the other hand, why is open source hardware development not catching on? Is it again this patent isssue? If the OSS community would provide nice open blueprints for hardware, I don't see why the chinese wouldn't be more than happy to print millions of chips for the consumer market, with manufacturing costs only, no development costs at all.
Mobile IP works great. But only if you have a public IP address, and some people might argue you should also have Mobile IP support at servers. Which both mean in practice, that you and the servers need IPv6 and Teredo tunnelling in the real life non-IPv6 Internet of today.
All this you can have today on Windows XP SP2. The only thing missing are clients supporting IPv6, but there are some...
I believe that currently this looks like the only real reason to have IPv6, but reason enough.
That's what IUCN Red List has. And although an extinction is "official" only after 50 years of not finding any specimens around, there are only a handful of cases "waiting in the line", species that we would only recently have stopped finding in wild.
The only problem are the myriads of unknown small, rare and local species that we don't perhaps know anything about, until they are already gone. BUT WHAT PROBLEM IS THIS REALLY? First, the numbers are highly speculative. Second these obscure species are typically small variants of each other, and a loss of one is not of very big imporatnce to even the local ecosystem. This whole extinction scare is irrational and emotional.
Note that there is an answer to saving those species that are endangered by hunting or scavenging: if they are sought after, they have a price. Capitalism and property rights are the key. Let the local people own them, cultivate or heard them, and use or sell them! They will soon be no more extinct than rice or cows.
The human nature of primates is a little different question. Rather than letting the local homo sapiens to own and eat the chimpanzee and gorillas I'd rather grant "half-human rights" to their bodies and some kind of "ownership" to their habitat, to be administered by some human custodian.
The favorite idol of us all, Mr. Gates, wrote in his N.Y.T. column, that according to what he has seen, the most common reason why smart people fail professionally and/or financially is their lack of focus.
I don't think this is so easy. We need both general people and focused people, but both attitudes have their risks. Focusing on details is laborous and boring and as a such a sought after capability. But a narrow expert easily becomes weak and expandable in a community.
I have designed a course on version six and I also teach 3G/UMTS and GPRS networks.
Why six will succeed (and I used to be a long time skeptic) is that Mobile IP will be big, and it will not work well with the version four world. Every PDA and phone will have VoIP and many other P2P applications and they will need to be reachable, not hidden as private addresses behind NAT routers.
I guess we could figure out some weird protocol to register on a SIP server your current NAT/port instead of your current version four IP, which often is private. Or we can have generalized "presence" servers and connections routed through non firewalled third parties. Actually IPv6 Teredo is a clever example of using similar tricks to create IPv6 public addresses behind v4 NATs and tunneling ANY IPv6 traffic to them.
Another huge problem with with Mobile IP, which still remains is incompatibikity with ingress filtering. That is a problem even with IPv6, but can be solved with the IPv6 mobility header home address option. And that needs general upgrading in the servers of the Internet, and it would never happen with Mobile IP v4, even if a similar solution (tunneling to servers) would be devised.
There are also political, commercial and psychological reasons for IPv6 to succeed, but not very much other technical ones: you need to be publicly addressable, independent of your location!
The point is, that you want your phone to be callable. AFAIK, there is no version four based protocol to initiate a connection to a node behind a NAT.
Besides public addresses of version six solving the problem, the 128 bits of the long address help to do other magic like Teredo: standard with my Windows XP SP2, anybody can actually open ANY IPv6 based protocol connection to me right now with my Teredo address, though I am behind a corporate ("restricted") NAT/firewall, which does not know about six at all, and can't even filter it! And I can reach any six user in the world.
Try Teredo today, because when the firewall people here about it, it will be history.
O'Reilly book? IBM LPI exam prep tutorials!
on
LPIC 1 Exam Cram 2
·
· Score: 1
I started reading Jeffrey Dean's "LPI Linux Certification in a Nutshell" by O`Reilly and it was quite nice, maybe bit boring. But it was not at hand later when I needed it, and I prepared for the exam with IBM DeveloperWorks tutorials (Google for "lpi exam prep"). They are written by the Gentoo founder Daniel Robbins! I additionally skimped through some of the links he mentions, like PPP HOWTO, stuff which he does not cover and which I have never touched.
I passed with best scores in my company (630/640 out of 800/800).
I have toyed with an idea of a story, which starts from a keypress, goes on to keyboard driver, Unix tty subsystem and character coding. One story line branches to the handling of characters in the console subsystem and its fonts (in ROM or somewhere else?). The frame buffer and a graphical console are another avenue that needs to be handled. Finally the glorious or ("goreous") story line branches to X client, X primitives, X server, X character coding, X font files, X rendering, X color maps and resolutions and finally to screen pixel technology.
Especially the FILES section of the story would be interesting. I would like to see a complete list of all possible configuration files and font files which can have an effect on a character/font you see on your screen when you press a key. We can limit ourselves to a case of a dozen well-known applications.
There is a statistical "bias" for the more knowledgeable people editing more, because subject interest, knowledge and activity are correlated. The few vandals or ignoramuses hardly can destroy actively edited articles, because a number of good authors can easily cancel bad edits.
Articles with less activity can be bad or even destroyed without no one noticing for a long time. But it is usually easy for the reader to spot bad articles and ignore them. Actually, it is _good_ thing that no professional editing post-process masquerades bad content with correct language and layout. Note that even bad articles can have some good data, or pointers for further research, or just the right keywords for Google.
The bias of personal values of the active editors shows even in the best articles, sure. But that is true even for Encyclopedia Britannica, or any book.
But the point is, that if it spoofed and not originating from Google as it claims, then it falls to your non-auhenticated suspects bin. Mail can not be both spooded _and_ authenticated.
Thanks for your excellent comments! Being able to find this kind of commentary from knowledgeable people at Slashdot easily (browsing at level file) is what keeps me reading. It seems to works even in this case, when the subject matter is a little off from the regular competencies at Slashdot!
Why only drivers? Why not all software on demand? Perhaps package by package (apt-get & such almost do this already).
Even better: file by file on demand. Why should I install all the 100 files of a package X today if my usage habit only really accesses 10 of them today, and 10 more tomorrow, and others never.
Hmm... While we are at it, why stop at file level. Why not memory map the remote files to local VM and fetch them page by page on demand from the network? Persistent local page cache (a new sort of swap file) would make it fast after first fetch.
Note that Rob Pike of Plan 9 fame works for Google these days. The Plan 9 folks have Venti file server (use Google...), which only stores each unique data block once, and then checks all later writes for identical blocks. Identical blocks are only stored as pointers to existing blocks. This way an April fools email circulated for a million times perhaps in a dozen variations would propbably consume "12 * message_size bytes + some per user minimal overhead" on the whole Gmail system, even if all users would receive it and keep it forever.
This is only one very general idea for compressing. I can think of many reasons, why a specialized application like email could benefit from related statistical pecularities in implementing its own super-compression.
The truth is that the percieved need for radically new IP version turned out to be false. The only problem that IPv6 really solves is the address shortage, and whether you think IPv4 address translation is great or not, it has already solved it, and we can live with it with no real problems. And many people will want NATs for security and for privately managed address spaces even with IPv6.
Smaller routing tables? It is very wel likely that IPv6 will not achive that and it doesn't matter anyhow, Moore's law and router optimizations (cache memory) already solved that.
Security? IPSec works exactly the same in IPv4 and IPv6.
Stateless autoconfiguration? Does not work satisfactorily. Where do you get DNS address? Own DNS name? Domain DNS search path? Besides, the network administrator wants to recognize your MAC address, get your DNS name and dynamically update internal DNS for management. DHCP is familiar and easy and does all that, so DHCPv6 will still dominate in the IPv6 world. Besides, most computers do IPv4 autoconfiguration with 254.192.*.* addresses by default already, but who usues it? Nobody!
QoS? There is the traffic class / type of service byte which is the same in both versions, but 99,9 % of Internet traffic does not use it. The new "flow label" does not even have a deployment plan, and can be considered failure.
The problem is, that the hyped IPv6 bandwagon probably can't be stopped, and we are stuck with the hopeless confusion, security hazards and wasted man-millenia of the long and horrible transition phase. Remember, that most applications have to be upgraded or at least recompiled. Inefficient tunnelling has to be used always if there is a single IPv6 challenged router between you and the other party. That is, if your software even can do it with Teredo (which is even a challenge to undertstand) or similar, and if your firewall permits it.
And note that there is very limited support for IPv6 in firewalls. And as long as that is missing and is unmature, no organization will allow IPv6.
Traffic volume still a problem, solve by signing
on
Another Whack at Spam
·
· Score: 1
Bayesian filtering works great, yes (I use SpamBayes). But the the traffic volume remains a problem, both personally and globally. For example on my VPN link to my company it takes half an hour to download and filter all the 500 spam & virus messages I get daily now. And I refuse to give in and disable or completely hide my old and well-known mail address.
I don't have the links handy, but there was a suggestion, and now f.ex. PGP Corp. has the product, which makes the company mail relay sign all outgoing mail by the company private key (S/MIME or PGP). I think it is realistic to make this the norm: all organizational mail relays will sign all outgoing mail automatically. SMTP relays will only accept messages with valid and trusted signatures for further processing.
The beauty is, that the users don't have to do anything.
Of course you can still spam, but not very anonymously. Getting your keys trusted will require some well-known signers, and they will require a contract preventing spamming. Removing trust from the few that manage to cheat the system will be easy.
It is safer to then run "ssh-agent bash", then "ssh-add" and keep you private key passpahrase protected. This way you can use an ssh key pair all day on all machines without password queries, and still have your private key protected.
This is computer simulation play just like the Club of Rome simulations in the late sixties that basically started the "limits of growth" hysteria. According to those, the mankind would be all but suffering in poverty by now, after depleting all the resources and destroying the nature.
Predicting the weather is difficult. It is difficult locally for this week, and even more so for global long time predictions.
http://www.apnic.net/stats/bgp/TOTAL/totaladd.ht ml
Currently about 33% has been used, growing about two percentage points a year. We will run out in perhaps 30 years. Except that not many people will need IP anymore then. Plan 9 protocol 9P is a good example of a future protocol. It can of course use IP as a "data link layer", but it could also replace IP as the internetworking protocol (see http://www.cs.bell-labs.com/sys/man/5/INDEX.html).
If 9P will not make it, I bet something will. Let's hope it is something better than IPv6, which gains us nothing more than more addresses (and a lot of work in the upgrade process: devices, application software, and the looooong transition phase with double work for maintenance of networks and systems!).
OK, I admit. The 9P protocol uses relative, local source routed addresses a la UUCP. So what? A modern version of "pathaliases" can easily be made to solve the problem the right way: having the routing intelligence in the end-points and applications, not in the networks!
Slashdot Mirror
They say that to land the shuttle, you need an auto-pilot, a human pilot and a dog. The dog is there to guard, that the human pilot does not touch the control yoke.
The system on Donkey/Mule network works in practice.
If a RIAA person marks all good files as bad, someone will notice this at some time and add a new, additional comment refuting the other one. At that point people will just have to accept the contradiction and see for themselves. The real good files propagate enough so that their availability will be the best recommendation.
Marking bad as good helps RIAA little, because many people will mark it bad anyway, or delete it from their disks before it becomes widely spread.
Another nice info on eMule is a list of differing names of all occurrences of the file (by its MD5 has) it has found. Those often reveal more info, because people rarely use the comment feature, but they might still change file names in an informative way. This is also useful in finding what language the video is, or codecs info, or release info.
Half of their top games can be emulated on the Nintendo Revolution, and most for free and legally. And they will be available through easy to use official channels, not only from underground P2P networks.
Any new infrastructure is feasible, if it routes IP as a legacy service, and interacts nicely with a necessary subset of old protocols, like BGP, and provides rudimentary client side tools and proxies to acess the IP world outside.
I see the problem with IP is that it is both too high level and too low level. It is too high because it requires global addressing state inside the network and does not expose nodes inside to the end nodes. It is too low, because it operates on packet level, not on a level of an abstract byte stream (or a "connection", if you want), which could be negotiated for security and speed control.
Plan 9 9P/2000P provides a better altervative. As a inheritant of file level UUCP ideas with local addressing and source routing, it provides exact control of all nodes in communication with no centralized addressing. Each hop is always authenticated with application developer friendly protocols. It is perfectly capable of carrying itself over IP links, or carrying IP over 9P.
Would it be possible to develop a standard conversion tool that translates or at least helps to translate Windows driver source code to Linux driver source code, which would then be releases as binary only? So that HW manufacture could produce a binary Linux driver easily without too much expensive Linux experience work and without revealing their (perhaps legally hazardous) specs to outside community?
Note that IF a company wants to release HW specs it is mainly because they want to have Linux drivers available and a Linux market. It is not that releasing specs would be ever ba an end itself, but rather an unpleasant means.
Generally, wouldn't it be a time for Mr. Torvalds to start thinking about making life easier for proprietary driver development (like freezing the driver binary interface between minor kernel releases).
On the other hand, why is open source hardware development not catching on? Is it again this patent isssue? If the OSS community would provide nice open blueprints for hardware, I don't see why the chinese wouldn't be more than happy to print millions of chips for the consumer market, with manufacturing costs only, no development costs at all.
Mobile IP works great. But only if you have a public IP address, and some people might argue you should also have Mobile IP support at servers. Which both mean in practice, that you and the servers need IPv6 and Teredo tunnelling in the real life non-IPv6 Internet of today.
All this you can have today on Windows XP SP2. The only thing missing are clients supporting IPv6, but there are some...
I believe that currently this looks like the only real reason to have IPv6, but reason enough.
That's what IUCN Red List has. And although an extinction is "official" only after 50 years of not finding any specimens around, there are only a handful of cases "waiting in the line", species that we would only recently have stopped finding in wild.
The only problem are the myriads of unknown small, rare and local species that we don't perhaps know anything about, until they are already gone. BUT WHAT PROBLEM IS THIS REALLY? First, the numbers are highly speculative. Second these obscure species are typically small variants of each other, and a loss of one is not of very big imporatnce to even the local ecosystem. This whole extinction scare is irrational and emotional.
Note that there is an answer to saving those species that are endangered by hunting or scavenging: if they are sought after, they have a price. Capitalism and property rights are the key. Let the local people own them, cultivate or heard them, and use or sell them! They will soon be no more extinct than rice or cows.
The human nature of primates is a little different question. Rather than letting the local homo sapiens to own and eat the chimpanzee and gorillas I'd rather grant "half-human rights" to their bodies and some kind of "ownership" to their habitat, to be administered by some human custodian.
The favorite idol of us all, Mr. Gates, wrote in his N.Y.T. column, that according to what he has seen, the most common reason why smart people fail professionally and/or financially is their lack of focus.
I don't think this is so easy. We need both general people and focused people, but both attitudes have their risks. Focusing on details is laborous and boring and as a such a sought after capability. But a narrow expert easily becomes weak and expandable in a community.
I have designed a course on version six and I also teach 3G/UMTS and GPRS networks.
Why six will succeed (and I used to be a long time skeptic) is that Mobile IP will be big, and it will not work well with the version four world. Every PDA and phone will have VoIP and many other P2P applications and they will need to be reachable, not hidden as private addresses behind NAT routers.
I guess we could figure out some weird protocol to register on a SIP server your current NAT/port instead of your current version four IP, which often is private. Or we can have generalized "presence" servers and connections routed through non firewalled third parties. Actually IPv6 Teredo is a clever example of using similar tricks to create IPv6 public addresses behind v4 NATs and tunneling ANY IPv6 traffic to them.
Another huge problem with with Mobile IP, which still remains is incompatibikity with ingress filtering. That is a problem even with IPv6, but can be solved with the IPv6 mobility header home address option. And that needs general upgrading in the servers of the Internet, and it would never happen with Mobile IP v4, even if a similar solution (tunneling to servers) would be devised.
There are also political, commercial and psychological reasons for IPv6 to succeed, but not very much other technical ones: you need to be publicly addressable, independent of your location!
The point is, that you want your phone to be callable. AFAIK, there is no version four based protocol to initiate a connection to a node behind a NAT.
Besides public addresses of version six solving the problem, the 128 bits of the long address help to do other magic like Teredo: standard with my Windows XP SP2, anybody can actually open ANY IPv6 based protocol connection to me right now with my Teredo address, though I am behind a corporate ("restricted") NAT/firewall, which does not know about six at all, and can't even filter it! And I can reach any six user in the world.
Try Teredo today, because when the firewall people here about it, it will be history.
I started reading Jeffrey Dean's "LPI Linux Certification in a Nutshell" by O`Reilly and it was quite nice, maybe bit boring. But it was not at hand later when I needed it, and I prepared for the exam with IBM DeveloperWorks tutorials (Google for "lpi exam prep"). They are written by the Gentoo founder Daniel Robbins! I additionally skimped through some of the links he mentions, like PPP HOWTO, stuff which he does not cover and which I have never touched.
I passed with best scores in my company (630/640 out of 800/800).
But which book is really best?
I have toyed with an idea of a story, which starts from a keypress, goes on to keyboard driver, Unix tty subsystem and character coding. One story line branches to the handling of characters in the console subsystem and its fonts (in ROM or somewhere else?). The frame buffer and a graphical console are another avenue that needs to be handled. Finally the glorious or ("goreous") story line branches to X client, X primitives, X server, X character coding, X font files, X rendering, X color maps and resolutions and finally to screen pixel technology.
Especially the FILES section of the story would be interesting. I would like to see a complete list of all possible configuration files and font files which can have an effect on a character/font you see on your screen when you press a key. We can limit ourselves to a case of a dozen well-known applications.
There is a statistical "bias" for the more knowledgeable people editing more, because subject interest, knowledge and activity are correlated. The few vandals or ignoramuses hardly can destroy actively edited articles, because a number of good authors can easily cancel bad edits.
Articles with less activity can be bad or even destroyed without no one noticing for a long time. But it is usually easy for the reader to spot bad articles and ignore them. Actually, it is _good_ thing that no professional editing post-process masquerades bad content with correct language and layout. Note that even bad articles can have some good data, or pointers for further research, or just the right keywords for Google.
The bias of personal values of the active editors shows even in the best articles, sure. But that is true even for Encyclopedia Britannica, or any book.
But the point is, that if it spoofed and not originating from Google as it claims, then it falls to your non-auhenticated suspects bin. Mail can not be both spooded _and_ authenticated.
Thanks for your excellent comments! Being able to find this kind of commentary from knowledgeable people at Slashdot easily (browsing at level file) is what keeps me reading. It seems to works even in this case, when the subject matter is a little off from the regular competencies at Slashdot!
Why only drivers? Why not all software on demand? Perhaps package by package (apt-get & such almost do this already).
Even better: file by file on demand. Why should I install all the 100 files of a package X today if my usage habit only really accesses 10 of them today, and 10 more tomorrow, and others never.
Hmm... While we are at it, why stop at file level. Why not memory map the remote files to local VM and fetch them page by page on demand from the network? Persistent local page cache (a new sort of swap file) would make it fast after first fetch.
Note that Rob Pike of Plan 9 fame works for Google these days. The Plan 9 folks have Venti file server (use Google...), which only stores each unique data block once, and then checks all later writes for identical blocks. Identical blocks are only stored as pointers to existing blocks. This way an April fools email circulated for a million times perhaps in a dozen variations would propbably consume "12 * message_size bytes + some per user minimal overhead" on the whole Gmail system, even if all users would receive it and keep it forever.
This is only one very general idea for compressing. I can think of many reasons, why a specialized application like email could benefit from related statistical pecularities in implementing its own super-compression.
The truth is that the percieved need for radically new IP version turned out to be false. The only problem that IPv6 really solves is the address shortage, and whether you think IPv4 address translation is great or not, it has already solved it, and we can live with it with no real problems. And many people will want NATs for security and for privately managed address spaces even with IPv6.
Smaller routing tables? It is very wel likely that IPv6 will not achive that and it doesn't matter anyhow, Moore's law and router optimizations (cache memory) already solved that.
Security? IPSec works exactly the same in IPv4 and IPv6.
Stateless autoconfiguration? Does not work satisfactorily. Where do you get DNS address? Own DNS name? Domain DNS search path? Besides, the network administrator wants to recognize your MAC address, get your DNS name and dynamically update internal DNS for management. DHCP is familiar and easy and does all that, so DHCPv6 will still dominate in the IPv6 world. Besides, most computers do IPv4 autoconfiguration with 254.192.*.* addresses by default already, but who usues it? Nobody!
QoS? There is the traffic class / type of service byte which is the same in both versions, but 99,9 % of Internet traffic does not use it. The new "flow label" does not even have a deployment plan, and can be considered failure.
The problem is, that the hyped IPv6 bandwagon probably can't be stopped, and we are stuck with the hopeless confusion, security hazards and wasted man-millenia of the long and horrible transition phase. Remember, that most applications have to be upgraded or at least recompiled. Inefficient tunnelling has to be used always if there is a single IPv6 challenged router between you and the other party. That is, if your software even can do it with Teredo (which is even a challenge to undertstand) or similar, and if your firewall permits it.
And note that there is very limited support for IPv6 in firewalls. And as long as that is missing and is unmature, no organization will allow IPv6.
Bayesian filtering works great, yes (I use SpamBayes). But the the traffic volume remains a problem, both personally and globally. For example on my VPN link to my company it takes half an hour to download and filter all the 500 spam & virus messages I get daily now. And I refuse to give in and disable or completely hide my old and well-known mail address.
I don't have the links handy, but there was a suggestion, and now f.ex. PGP Corp. has the product, which makes the company mail relay sign all outgoing mail by the company private key (S/MIME or PGP). I think it is realistic to make this the norm: all organizational mail relays will sign all outgoing mail automatically. SMTP relays will only accept messages with valid and trusted signatures for further processing.
The beauty is, that the users don't have to do anything.
Of course you can still spam, but not very anonymously. Getting your keys trusted will require some well-known signers, and they will require a contract preventing spamming. Removing trust from the few that manage to cheat the system will be easy.
"...One of the good things about EMACS, though, is its programmability and the modelessness. Those are two ideas which never occurred to me..."
LOL! The vi today is touted for the BENEFIT of its modes, and for its own wicked latecomer programmability!!!
But I prefer wily/acme mouse editing anyway, from the Plan 9 camp.
It is safer to then run "ssh-agent bash", then "ssh-add" and keep you private key passpahrase protected. This way you can use an ssh key pair all day on all machines without password queries, and still have your private key protected.
This is computer simulation play just like the Club of Rome simulations in the late sixties that basically started the "limits of growth" hysteria. According to those, the mankind would be all but suffering in poverty by now, after depleting all the resources and destroying the nature.
Predicting the weather is difficult. It is difficult locally for this week, and even more so for global long time predictions.
Most Web links seem rather heavy on the physics side, but this was good for me:
DSI Media & Materials research group article on perpendicular recording.As visible from the announced BGP routes:
t ml
.
http://www.apnic.net/stats/bgp/TOTAL/totaladd.h
Currently about 33% has been used, growing about two percentage points a year. We will run out in perhaps 30 years. Except that not many people will need IP anymore then. Plan 9 protocol 9P is a good example of a future protocol. It can of course use IP as a "data link layer", but it could also replace IP as the internetworking protocol (see http://www.cs.bell-labs.com/sys/man/5/INDEX.html)
If 9P will not make it, I bet something will. Let's hope it is something better than IPv6, which gains us nothing more than more addresses (and a lot of work in the upgrade process: devices, application software, and the looooong transition phase with double work for maintenance of networks and systems!).
OK, I admit. The 9P protocol uses relative, local source routed addresses a la UUCP. So what? A modern version of "pathaliases" can easily be made to solve the problem the right way: having the routing intelligence in the end-points and applications, not in the networks!
Acme is a great text+mouse+windows user interface framework for programmers on Plan 9 (where Linus gets his better ideas):
e / index.html
http://plan9.bell-labs.com/sys/doc/acme/acme.ps
http://www.cs.bell-labs.com/wiki/plan9/Using_acm
Also available for other unices as Wily:
http://www.cs.yorku.ca/~oz/wily/