home.social

#arpanet — Public Fediverse posts

Live and recent posts from across the Fediverse tagged #arpanet, aggregated by home.social.

  1. En 1981, la société BBN a écrit pour la DARPA (ex-ARPA) un rapport de 184 pages « A history of the Arpanet - The first decade » qui faisait le bilan des dix (en fait plutôt onze et demi) premières années du réseau #Arpanet. Cela reste un des meilleurs documents pour celles et ceux qui veulent comprendre comment marchait l'Arpanet, qui n'était pas du tout un Internet en plus petit, mais un réseau assez différent.

    bortzmeyer.org/arpanet-first-d

  2. @tedu

    Fuckers.

    I will always be BT74, going back all the way to NIC.DDN.MIL aka, yet another nom de plume of SRI, or, as was affectionately referred to as, "The NIC".

    Back in the mid-80's after we introduced DNS in 1985 (and even before), you could actually call up Jake Feinler directly over the phone for time sensitive issues of a priority nature. She was always able to get things resolved in a matter of hours - sometimes I'd get a call back in a few minutes from an engineer at SRI to confirm that all was well.

    according to the man pages, you should still be able to a #WHOIS searches #NIC handles for "NET-...", POCs like my handle above (um... sort of, I'll get to that), etc.

    So I should note, that the NIC Handle I've listed above hasn't actually been searchable for quite some time now (at least ten years). but you should still be able to grep for it (coz I've made certain to still listed that way in my registry records). A simple, elegant system that lends well it's usage to humans, is now being cast aside for something less readable and in many ways, relevant, when you're quickly trying to pull a piece of primary data to reach someone responsible for a contact point (PoC), with respect to themselves, their property, or a "Role Account" that is responsible for a resource and shared by perhaps, several individuals.

    So, the various contacts in the WHOIS records are variously, Registrant, Admin, Tech, and Billing contacts. In reality (and I've not seen a change in the RFCs on this point, but I don't follow that closely nowadays), the TECH CONTACT is defined as the person or role account responsible for the direct administration of DNS - not neccessarily the same as any other contact role account. ADMIN is important too, but not really as important as the TECH contact. In theory and still many times in practice, a remote sysadmin somewhere needs to get ahold of the DNS administrator to report abuse or some other issue, so a WHOIS is performed and voila! - you have a contact point to help fix a technical situation.

    REGISTRANT is the owner of the domain registration, and as such, might legitimately have a reason to pay a privacy bureau to act as a proxy for contacting (to block stalkers, spammers, whatev), and the BILLING contact really has little technical relevance, but unlike the REGISTRANT, is the actual person or role account to interact with when it comes to domain renewals, etc.

    So the ADMIN and at the very least, TECH contacts must (or should) be live phone and/or Fax numbers and email addresses that are searchable and reachable by anyone. In reality, however, after #NSI started to become less of a NIC, and shed themselves of the internic.net moniker as they commercialized under pressure from the nascent ICANN in order to have their contract renewed, anyone who registered a domain ended up having the fields to all of the contacts being filled out with the same data as that of the* registration owner/admin*, instead of what it should have been for at least the TECH and ADMIN contacts - you can override these defaults, but most will never bother, and have no idea why there are all these various roles in the records. (/me sighs....).

    Okay, so after Jon Postel's untimely passing, the miscreants pretending to be legitimate enough to bootstrap ICANN quickly came to the realization that there's really no such thing as IANA - it was just a pseudonym for Jon, who literally ran pretty much everything we hold sacred today - like, being the RFC editor, and being IANA, managing the AUTH delegations of the #ccTLDs and even the DNS root servers (litterally moved one unilaterally once). So IANA was created by these miscreant folks, like Esther Dyson and Mike Roberts - pretenders provocateur. But I digress.

    So now we've got these RIRs (which is a good thing, some better than others, but still). RIPE still uses NIC-HANDLEs, and so does #ARIN.

    And as I promised, my NIC-HANDLE, once and always BT74, evolved into BT74-ARIN once that RIR was created. More explanations are in the alt-text accessibility tags for the two attached images.

    So I won't go on further with this historical perspective that just sort of quietly was usurped by commercial pressures in the special interest lobby sector, #ICANN, and #WIPO, but anyone who's really interested can check out and read my friend Ellen Rony's book about the #Domain_Wars.

    But just for shits and giggles, I've included a couple of screenies attached to this post:

    - my current, automatically evolved NIC-HANDLE following the formalization of ARIN, from the ARIN website, and...
    - An explanation of the usage of NIC-Handle's from the current man pages of WHOIS.

    I hope that helps!

    All the best!

    #tallship #UNIX #DNS #FOSS #systems_administration #Stanford_Research_Institute #ARPANET #MILNET #NSFNET

    .

    RE: https://honk.tedunangst.com/u/tedu/h/4g4vG2g8TH52x5g3PY

    @tedu

  3. CW: TENEX

    #TENEX fue un sistema operativo de tiempo de cómputo compartido desarrollado por #BBN para la DEC #PDP-10.

    En la década de 1960 BBN desarrollaba proyectos de ingeniería basados en programas de Inteligencia Artificial para la Agencia de Proyectos Avanzados para la Defensa de los Estados Unidos (DARPA). Dichos proyectos requerían uso cómputo de potencia, particularmente equipos que contaran con paginado de memoria.

    A tal efecto la compañía se abocó en 1968 a mejorar el diseño básico de la PDP-10 incorporandole una unidad de paginado de memoria de desarrollo propio que permitiera afrontar los despliegues más potentes del lenguaje LISP. Asimismo, BBN decidió recurrir a la creación de un sistema operativo superador del programa de control provisto típicamente dicha máquina, el simplón MONITOR.

    Este nuevo sistema operativo para “la Diez extendida” recibió el nombre de TENEX, otorgándole así capacidad multiusuari@ multitarea.

    Estas características se hicieron rápidamente deseables para los investigadores de Stanford y el MIT, y constituirían el cimiento de la cultura

    La influencia de BBN en el ámbito de la defensa otorgó a TENEX un rol definitorio en la implementación de los primeros nodos de la #Arpanet. A tal punto se dio su preferencia que casi todos los sistemas conectados a la ARPANET corrían TENEX.

    La temprana popularidad de TENEX en ARPANET fue sin duda una clave para su posterior aceptación, transformación y soporte como TOPS-20 bajo la órbita de DEC.

    TENEX permitía utilizar memoria virtual en los primeros modelos de la PDP-10 gracias al BBN Pager, un hardware de paginado de memoria desarrollado específicamente. Este gabinete de 2 metros de altura por 30 centímetros de ancho permitía hacer las funciones de memoria de intercambio y caché. TENEX convertía así a la PDP-10 en una máquina de mayor potencia y flexibilidad, capaz de operar con muchos usuari@s de forma concurrente.

    Una de las características más recordadas de TENEX es el empleo de un intérprete que utilizaba comandos completos y descriptivos, a la vez que ofrecía autocompletado de tipeo con el comando ?. Especialmente influyente fue su sistema de archivado provisto de control de versiones (denominadas “generaciones de archivo”).

    TENEX terminó convirtiéndose en un sistema mucho más popular y capaz que TOPS-10, y realmente influyente en desarrollos de sistemas posteriores, principalmente su descendiente indirecto TOPS-20 “TWENEX” y VMS.

  4. CW: ARPANET
    Antes de su presentación "en sociedad", los primeros días de la red de datos #Arpanet estuvieron signados por grandes promesas, funcionalidad modesta, y sorpresas.

    La visión del cómputo distribuido en la medida que los usuarios y programas hicieran despliegue de recursos múltiples, distribuidos y concurrentes (ya fuesen otros programas o simplemente ciclos de computadora) continuó siendo simplemente una quimera. La funcionalidad de la red de datos resultó limitada fundamentalmente por la carencia de protocolos huésped a huesped (cimientos sobre los cuales se construyen la #telemática de alto nivel). De hecho, la única aplicación real continuó siendo una versión primitiva de #RLOGIN (acceso electrónico a otra computadora distante). Si bien resultaba instructivo, este acceso remoto no podía considerarse un logro mayor. Sin embargo, las primeras sorpresas en el uso demostraron probar la valía de la red de datos.

    Tráfico intra-IMP

    La primer sorpresa fue que un usuario podía reconectar su terminal entre las computadoras locales conectadas al IMP (los disposivos paquetizadores que cumplían el rol de enrutador, de tamaño de una heladera). Esto se podía lograr simplemente lanzando un comando al IMP, en lugar de tener que reconectar la terminal en un confuso panel de conectores, como había sido la práctica. Se descubrió que la mayoría del tráfico de terminal rara vez terminaba saliendo a la red, sino que permanecía dentro de los #IMPs huéspedes (tráfico intra-IMP).

    Cambiar rápidamente la conexión de terminal entre las computadoras LOCALES resultó de gran beneficio para aquellos que necesitaban acceder a múltiples computadoras situadas en el centro de cómputo, y terminó reflejando una necesidad que una década más tarde daría impuso a la interconexión #LAN.

    La segunda sorpresa fue que los usuarios de la red no se frustraron de manera alguna por la falta de funcionalidades de la ARPANET, ya que esto era lo que siempre habían querido.

    Este uso de terminal somero en la ARPANET fue lo que motivó la creación un segundo tipo de IMP simplificado: el Procesador de Interfaz de Terminal, o #TIP. La ventaja de los TIPs residía en que las terminales podían conectarse directamente a la red a través de los TIPs sin tener que conectar los puertos de terminal a un mainframe para efectuar esta conexión a la red en sí.

    La mayor sorpresa fue, sin embargo, el correo electrónico o #email. Si bien Roberts había creído que el correo electrónico resultaría una aplicación de red importante, nunca lo hizo aparecer en ninguna de las especificaciones originales, y la mayoría admite que resultaron completamente sorprendidos por la aceptación inmediata.
    En un comienzo, el correo electrónico consistíó simplemente en un mensaje de una persona a persona. Pero en la medida que creció su utilización, se incrementó la presión para incorporarle innovaciones y funcionalidades adicionales. Roberts programó una de las primeras mejores: un "hack de #TECO" que permitía al usuario seleccionar qué mensaje leer en lugar de resultar obligado a leer los mensajes únicamente en el orden en que los había recibido. (TECO, el Editor y Corrector de Texto, era un lenguaje de edición computarizado primigenio, y hack se refiere a un truco de programación innovador, a pesar que se trate de un programa improvisado y sin soporte, y se lo utiliza en un sentido de respeto por cumplimiento técnico).

    Ray Tomlinson y Dan Murphy, ambos de BBN y autores del sistema operativo TENEX, escribieron el programa de correo electrónico original. Tenían una PDP-10 para ellos mismos, la que utilizabas en el desarrollo de TENEX. Tan pronto como tuvieron un sistema de ficheros concurrente, comenzaron a dejarse notas el uno en el disco para mantener un registro de trabajo colaborativo. Al punto de conectar la #DEC PDP-10 con #TENEX a la ARPANET, se propusieron transmitir estos mensajes de una máquina a otra: ellos mismos escribían el código de la red ARPANET también.

    El correo electrónico representó una forma nueva de interacción y de comunicación: era conveniente, capaz de ser dejado por el remitente y recogido por el receptor según sus tiempos, ya que no requería que se respondiese inmediatamente a un comentario, sino que podía pensarse la redacción más seriamente. Desde el comienzo, el correo electrónico fue un modo informal de comunicación. Nadie se preocupó sobre el tipo de estructura. Las comunicaciones eran cortas e importaba más ser directo.

    Incluso aunque la Arpanet no representaba inicialmente un nuevo paradigma de cómputo distribuido según lo había envisionado Roberts, hizo posible una comunidad digital de científicos del cómputo, y con el tiempo permitió a otros usuarios, y más notablemente, demostró de manera práctica que la conmutación de paquetes funcionaba.

    #retrocómputo #retrocomputing #router #modem #internet #arpanet #terminal #textoplano #hacking #hackers