Slashdot Mirror

1973 Peter Kirstein at University College London (UCL) established the first transatlantic packet network link - Rutherford Laboratory IBM 360/195 in the UK linked through UCL and satellite link from Norway to ARPAnet. In November the RL machine is the most powerful on the ARPAnet

the total legal justification (from the US viewpoint) for running the network services between Arpanet and the UK networks between 1973 and 1988 was the need to test these developments with real traffic

http://adsabs.harvard.edu/abs/1976ucle.rept.....K

That's how the keyboard is laid out in Germany (Perhaps other countries as well?) but I don't know why it is different or if it makes a difference in typing speed. On the French keyboard layout the first row starts with AZERTY. See here.

Small, green aliens probably don't use QWERTY keyboards, either.

• Although this revision was partially driven by IBM (they needed some changes to do XML in EBCDIC, there are other problems that people wanted to address. ERH seems to think this is all a case of IBM throwing its weight around -- which is just not true.

• ERH blames this hassle over an "obsolete" coding on IBM's corporate arrogance. In this, he follows the common wisdom that IBM just ignored the whole EBCDIC/ASCII issue until the PC revolution made a switch to standard character sets unavoidable. I actually believed this stuff myself, until I stumbled onto the real story. Which is that ASCII (which was invented at IBM!) was supposed to be the standard for IBM mainframes, but a series of bureaucratic screwups and bad decisions prevented this from happening.

  Yeah, IBM, should have made the change anyway. But we all how hard it is to change a technical direction once a lot of effort has been put into it. Look at the groddy UI at Slashdot. Look at all the web presence providers (including mine!) who won't upgrade to a taint-safe version of Perl because it would break too much of their code. The examples are endless. You may not sympathize, but you damn well should understand.

• If you read the 1.1 spec carefully (I recommend the version with highlighted revisions) you'll realize that 1.1 is in no way a replacement for 1.0. People with a lot of 1.0-compliant XML and who don't need to read any 1.1-compliant XML can simply ignore the new spec, if they choose. The 1.1 spec very clearly states that nothing has changed in terms of what parsers should and should not do with XML 1.0. Provided, of course, people remembered to head all their XML files with the mandatory processing instruction:

  <?xml version="1.0"?>

  And if you've read ERH's books, you know to do that!

Protocols to mention besides OpenLDAP and OAI are Whois++ and Z39.50. OAI actually is transported over HTTP. You could do the same with EAD or others.

Projects which implemented Z39.50 for the purposes of interoperability are ONE and ONE-2, EUROPAGATE, Desire and Desire II, DECOMATE and DECOMATE II, and Renardus just to touch the surface. Don't forget OHIOLINK...

Another other older, but interesting, metadata activity have been SGML MARC, and the corresponding XML MARC.

The BYTE article was exciting to see again and could have benefited further from pointing out the relative ease of use of Dublic Core. OAI uses unqualified Dublic Core, SAFARI uses qualified Dublin Core to create an up to date index over academic research in Sweden. Shoot, since it already uses some META tags, you could even tweak htdig to use Dublic Core on your own site for those high precision searches.

With the interest in structured data (XML?) maybe well see some sites serving up not just HTML with Dublic Core, but maybe even Docbook or even TEI / TEI Lite. There are great tools for converting from Docbook to HTML, PDF, RTF, etc. and AbiWord and Kword already have partial support for docbook. If there were more, then we could see some real changes on searching the web. Coding for SGML is more difficult, so the obvious choice would be to start from Docbook XML.

This will be true only in ISO-8859-1 (or ISO-8859-15 with Euro) world or at least 8bit simple encodings world.

For other billions of people (Chinese, Indian, Arab, and so on), Linux desktop (with XFree86, GNOME, and KDE) is far from usable for average people.

In other words, there are still remaining large market for such billions of people.

Publishing the interface specification has nothing to do with creating an "open source" computer. The Purple Book provided enough information for third-party developers to build adapter cards compatible with the PC, but not enough information to clone the PC itself.

IBM was simply imitating the highly sucessful Apple II, which Wozniak designed as a platform that his fellow hardware hackers could easily extend. IBM also imitated Apple in keeping the ROM BIOS source code closed, and making it legally difficult for anybody to reverse-engineer it. Neither company was interested in having competition build the basic platform.

Unfortunately for IBM (and fortunate for consumers of commodity hardware), Phoenix, Compaq, and others were able to use "clean-room" techniques to reverse-engineer IBM's software without breaking existing law. Alas, the law has since been tightened.

Sounds way over the roof.
500 locations and 8000 servers, that's about 16 servers in each. That doesn't look right. What I have been hearing is that Akamai has 3 servers in cluster.
Here is how live Akamai cluster looks like.
Also on Content Delivery Networks conference July 6-7, 2000 Barcelona, Spain in the study "The Measured Performance of Content Distribution Networks" it was shown that to achieve optimal performace you don't need even a 1000 servers, much less number will do the same job.
So what those "8000" servers are for?

Unfortunately, there is still no coherent architecture for mirroring and for mirror sites to register their collections with the sites which they mirror. In fact, we lack even a common (de facto) standard for recording this replication information in a machine readable for-mat. Some progress was made on this a few years ago by the Internet Engineering Task Force s [1] working group on Internet Anonymous FTP Archives, with the creation of the so-called IAFA Templates [2]. These provided a simple machine readable format for recording per-resource or collection metadata, which could easily be created by hand or programatically. Although support for IAFA templates was integrated into some software packages, e.g. the ALIWEB search engine [3] and the ROADS resource discovery sys-tem [4] , this approach never became successful on a large scale. The World Wide Web Consortium s Resource Description Format (RDF) [5] and the Dublin Core metadata effort [6] may eventually provide a viable machine readable interchange format.

Currently, the database underlying the freshmeat.net weblog [7] is perhaps the closest thing we have to a genuine mirror registry - though it focuses almost exclusively on soft-ware packages and operating system distributions, and only offers limited mirror informa-tion. RDF is also being used in this capacity as part of rpmfind.net [8], although mirror information is very limited in this case too. The Internet Engineering Task Force s Uni-form Resource Names effort [9] is also relevant here, since it would be very useful if there were persistent and location independent names for these collections of replicated resources.

[1] http://www.ietf.org/ Internet Engineering Task Force website
[2] http://info.webcrawler.com/mak/projects/iafa/ IAFA Working Group & IAFA Templates homepage
[3] http://aliweb.emnet.co.uk/ ALIWEB website
[4] http://roads.opensource.ac.uk/ ROADS website
[5] http://www.w3.org/RDF/ World Wide Web Consortium Resource Description Format (RDF) homepage
[6] http://purl.org/dc/ Dublin Core website
[7] http://freshmeat.net/ freshmeat.net website P. Lenz & Andover Advanced Technologies, Inc.
[8] http://rpmfind.net/ rpmfind.net website
[9] RFC 1737, Functional Requirements for Uniform Resource Names K. Sollins & L. Masinter December 1994

And at the end somewhat less relevant to the topic.

This kind of metadata should be extremely valuable for implementation of the URIs and particularly for the I2C(s) (URI tp URC). Quote from the RFC 2483:

"Uniform Resource Characteristics are descriptions of resources. This request allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resource's URLs. The description might be a bibliographic citation, a digital signature, or a revision history. This memo does not specify the content of any response to a URC request. That content is expected to vary from one server to another."

Unfortunately, there is still no coherent architecture for mirroring and for mirror sites to register their collections with the sites which they mirror. In fact, we lack even a common (de facto) standard for recording this replication information in a machine readable for-mat. Some progress was made on this a few years ago by the Internet Engineering Task Force s [1] working group on Internet Anonymous FTP Archives, with the creation of the so-called IAFA Templates [2]. These provided a simple machine readable format for recording per-resource or collection metadata, which could easily be created by hand or programatically. Although support for IAFA templates was integrated into some software packages, e.g. the ALIWEB search engine [3] and the ROADS resource discovery sys-tem [4] , this approach never became successful on a large scale. The World Wide Web Consortium s Resource Description Format (RDF) [5] and the Dublin Core metadata effort [6] may eventually provide a viable machine readable interchange format.

Currently, the database underlying the freshmeat.net weblog [7] is perhaps the closest thing we have to a genuine mirror registry - though it focuses almost exclusively on soft-ware packages and operating system distributions, and only offers limited mirror informa-tion. RDF is also being used in this capacity as part of rpmfind.net [8], although mirror information is very limited in this case too. The Internet Engineering Task Force s Uni-form Resource Names effort [9] is also relevant here, since it would be very useful if there were persistent and location independent names for these collections of replicated resources.

[1] http://www.ietf.org/ Internet Engineering Task Force website
[2] http://info.webcrawler.com/mak/projects/iafa/ IAFA Working Group & IAFA Templates homepage
[3] http://aliweb.emnet.co.uk/ ALIWEB website
[4] http://roads.opensource.ac.uk/ ROADS website
[5] http://www.w3.org/RDF/ World Wide Web Consortium Resource Description Format (RDF) homepage
[6] http://purl.org/dc/ Dublin Core website
[7] http://freshmeat.net/ freshmeat.net website P. Lenz & Andover Advanced Technologies, Inc.
[8] http://rpmfind.net/ rpmfind.net website
[9] RFC 1737, Functional Requirements for Uniform Resource Names K. Sollins & L. Masinter December 1994

And at the end somewhat less relevant to the topic.

This kind of metadata should be extremely valuable for implementation of the URIs and particularly for the I2C(s) (URI tp URC). Quote from the RFC 2483:

"Uniform Resource Characteristics are descriptions of resources. This request allows the client to obtain a description of the resource identified by a URI, as opposed to the resource itself or simply the resource's URLs. The description might be a bibliographic citation, a digital signature, or a revision history. This memo does not specify the content of any response to a URC request. That content is expected to vary from one server to another."

> Akamai is awesome ...

Yeah, well maybe ... but it ain't "optimal"! ;-)

http://www.terena.nl/conf/wcw /Proceedings/S4/S4-1.pdf