Résumé

  • Dès 1984, un projet bénévole a rendu partageables les noms de machines UUCP et leurs voisins, sans annuaire central complet et constamment à jour.
  • La carte pouvait alimenter pathalias, mais la vérification des fiches et leur conversion en routes utilisables dépendaient des sites participants.

Analyse

Une carte commune commençait par des informations déclarées

Le récit rétrospectif du Stargate Internet Museum situe l’origine du UUCP Project dans une séance informelle à la conférence USENIX de janvier 1984. Plus de trente volontaires se sont chargés de créer et d’entretenir une carte. USENIX a apporté un financement initial ; après la fin de cette aide, les bénévoles et coordinateurs régionaux ont poursuivi le travail. Cette source raconte la genèse du projet, mais ne prouve pas que toutes les régions ou machines y aient participé de manière égale.

La carte circulait dans comp.mail.maps; des hôtes bénévoles en proposaient aussi des copies. C’était une réponse à un problème pratique. UUCP transférait le courrier par échanges programmés entre machines. L’expéditeur devait connaître un voisin susceptible de rapprocher le message de sa destination. Aucun service toujours actualisé n’était interrogé par chaque machine avant chaque transfert. Les opérateurs fournissaient une grande part des connaissances nécessaires au calcul d’un itinéraire.

Les fiches associaient données réseau et responsabilité humaine : nom de la machine, organisation, contact, adresse électronique, voisins et dernier éditeur. Un itinéraire proposé dépendait de ces descriptions, et quelqu’un devait pouvoir corriger une fiche erronée. Les consignes invitaient chaque site à vérifier son hôte et ses voisins, puis à envoyer corrections et ajouts. Elles témoignent d’une demande de maintenance, pas d’un contrôle de conformité ; les archives ne donnent pas le délai de diffusion d’une correction.

La carte décrivait ; le calcul restait local

Le README archivé indique que les données publiées servaient d’entrée à pathalias. Des mentions telles que DAILY, WEEKLY, DIRECT et DEMAND correspondaient à des pondérations que le programme traitait comme des coûts de connexion fictifs. Ce n’étaient ni des factures ni des prix mesurés. Un opérateur pouvait ajouter ses données locales Path.* et calculer depuis sa machine un itinéraire de courrier de moindre coût.

Cette séparation rendait la carte réutilisable sans en faire un système de commande central. Le projet publiait une description commune ; chaque site choisissait les détails supplémentaires à conserver et la route à privilégier. Le « meilleur » trajet dépendait des données et hypothèses du site qui effectuait le calcul. Si l’horaire d’un voisin changeait sans mise à jour, la route pouvait être périmée. La carte ne se corrigeait pas et ne confirmait pas qu’un appel aboutirait.

Les données servaient aussi hors calcul. Le README indique qu’elles permettaient de trouver un contact en cas de problème et un site susceptible d’accepter une nouvelle connexion. Les noms, organisations et voisins formaient un annuaire informel pour les personnes chargées de l’exploitation. Le calcul d’itinéraire était un usage parmi d’autres.

Les limites de publication protégeaient les détails locaux

Le projet conseillait aux grands sites de publier quelques passerelles plutôt que chaque machine de leur réseau local. Pour la distribution interne du courrier, un site pouvait garder un supplément non publié et le combiner aux données communes lors de l’exécution de pathalias. La carte publique décrivait les hôtes joignables dans le réseau UUCP étendu, pas toutes les stations derrière une passerelle.

Cette limite réduisait la taille d’une carte appelée à circuler dans des systèmes contraints, évitait d’exposer chaque machine interne et laissait aux sites leurs détails propres. En contrepartie, la carte publique ne pouvait fournir tout ce qu’exigeait chaque route. Le projet acceptait cette incomplétude locale pour garder une couche partagée plus petite et plus facile à maintenir.

Un exemple australien distinct montre un besoin voisin, sans relever du UUCP Project. Dans une lettre d’information de l’Australian UNIX systems User Group en 1988, D. F. Davey écrivait que les informations sur les nœuds ACSnet étaient recueillies et diffusées dans aus.map depuis mars 1986. Il évoquait des logiciels et une administration imparfaits, ainsi que de petites machines incapables de contenir tout l’état du réseau. Cette comparaison illustre une autre carte comblant les lacunes des outils ; elle ne prouve pas que l’ACSnet et UUCP partageaient une carte ou un projet.

Trouver une fiche est devenu un problème distinct

En novembre 1990, un utilisateur d’Usenet demandait comment rechercher ou parcourir les cartes UUCP. Richard Foulk sollicitait des scripts Perl ; Paul Vixie publia une archive shell avec un outil de décompactage et des utilitaires, dont un indexeur et un navigateur qu’il disait avoir écrits. L’échange rend visible un problème d’usage : diffuser les données ne suffisait pas si l’on ne pouvait pas retrouver la fiche voulue. Il prouve une demande et une réponse, pas le taux d’adoption.

La carte dépendait d’une chaîne de tâches ordinaires : un site signalait ses voisins, quelqu’un vérifiait et corrigeait la fiche, les bénévoles organisaient les mises à jour, puis les opérateurs récupéraient, recherchaient et combinaient les données avec leurs ajouts locaux. Un maillon faible pouvait fournir au calculateur une image plausible mais ancienne. La carte était une référence entretenue par une communauté, pas un protocole automatique de découverte.

Sources