Aujourd’hui, les grandes entreprises et administrations publiques hésitent entre continuer à utiliser des logiciels propriétaires ou basculer vers les Logiciels Libres. Pourtant, la plupart des logiciels libres sont capables de bien traiter les données issues des logiciels propriétaire, et parfois avec une meilleur compatibilité.
C’est alors la barrière de la prise en main qui fait peur, et pourtant...
Les logiciels libres
L’aspect « Logiciel Libre » permet une évolution rapide et une plus grande participation des utilisateurs. Les aides et tutoriels foisonnent sur Internet ou sont directement inclus dans le logiciel lui-même.
Enfin, les concepteurs sont plus proches des utilisateurs, ce qui rend les logiciels libres plus agréable à utiliser et conviviaux.
Grâce à la disponibilité des logiciels libres, vous trouverez facilement des services de support techniques et la licence n’est plus un frein à l’utilisation de ces logiciels par votre personnel.
Notre support technique concerne essentiellement les logiciels libres, que ce soit sous forme de services ponctuels ou de tutoriels.
Un peu d'histoire, avec ce RFC 810, qui
mettait à jour le format du fichier géant qui, à l'époque, contenait
la liste de toutes les machines de
l'Internet. Il remplaçait le RFC 608.
Par rapport à son prédécesseur, ce RFC marquait le début de la fin de ce fichier
géant : ses limites étaient désormais bien comprises, et le
DNS était en cours
d'élaboration, quoique encore dans le futur. En attendant ce système
décentralisé et réparti, notre RFC mettait à jour la syntaxe du
fichier HOSTS.TXT, aussi appelé
« hosts » ou « host
table ». Il s'appliquait à
l'Internet mais aussi à son prédécesseur
Arpanet qui, à l'époque, vivait encore, une
vie séparée. Le fichier était ensuite distribué par un serveur
centralisé, décrit dans le RFC 811. Si vous
vouliez le fichier entier, notre RFC rappelait les instructions, à
l'époque où les URL n'existaient pas encore : « Connectez-vous
à 10.0.0.73 en FTP, en utilisant le compte
ANONYMOUS et le mot de passe
GUEST, puis utilisez la commande
get pour le fichier
HOSTS.TXT ». (On notera qu'à
l'époque, le FTP anonyme était réellement
anonyme, la convention d'utiliser son adresse comme mot de passe n'existait pas
encore.)
Bon, quelle était la syntaxe de ce fichier ? Les noms étaient
composés de lettres ASCII, de chiffres, de
traits d'union et de
points, en 24 caractères maximum. Ils étaient
insensibles à la casse. Il existait des
conventions de nommage : un routeur devait
avoir un nom se terminant en -GATEWAY ou
-GW. Un TAC devait se nommer
quelquechose-TAC. (Le RFC ne prend pas la peine
d'expliquer ce qu'est un TAC. Un TAC,
Terminal Access Controller était un ordinateur
spécialisé dans le service de terminaux, qui n'avait pas de compte
local et ne servait qu'à se connecter à des ordinateurs
distants.)
Le RFC décrit ensuite le format des adresses. Loin des débuts de
l'Arpanet, elles étaient déjà sur 32 bits à
l'époque (cela avait été normalisé par le RFC 796 en 1981). La longueur du
préfixe dépendait de la valeur des premiers bits de l'adresse (le
système des classes, qui a été abandonné en 1993).
Le fichier contenait aussi les noms des réseaux. Pour les
machines, le fichier ne contenait pas que noms et adresses. À cette
époque sans Web et sans
moteur de recherche, il servait aussi à
publier les services disponibles sur chaque machine. Et il indiquait
aussi le système d'exploitation des machines,
information utile quand on voulait se connecter avec
telnet. (D'autres protocoles nécessitaient de
connaitre ce système d'exploitation. L'utilisation de FTP en dépendait, sans
compter les problèmes d'encodage des
caractères, dans un monde sans
Unicode.) Voici quelques exemples de
machines, datant de 1983 :
HOST : 10.0.0.4, 192.5.12.21 : UTAH-CS : VAX-11/750 : UNIX : TCP/TELNET,TCP/FTP,TCP/SMTP :
HOST : 10.0.0.6 : MIT-MULTICS,MULTICS : HONEYWELL-DPS-8/70M : MULTICS : TCP/TELNET,TCP/SMTP,TCP/FTP,TCP/FINGER,TCP/ECHO,TCP/DISCARD,ICMP :
HOST : 10.0.0.9 : HARV-10,ACL : DEC-10 : TOPS10 ::
HOST : 32.2.0.42 : UCL-TAC,LONDON-TAC : H-316 : TAC : TCP :
HOST : 26.4.0.73 : SRI-F4 : FOONLY-F4 : TENEX ::
HOST : 10.0.0.51, 26.0.0.73 : SRI-NIC,NIC : DEC-2060 : TOPS20 : TCP/TELNET,TCP/SMTP,TCP/TIME,TCP/FTP,TCP/ECHO,ICMP :
Vous noterez que l'université d'Utah
utilise toujours, en 2021, le même préfixe
192.5.12.0/24… Par contre, le
MIT n'a plus de service ECHO… (Ce service
était normalisé dans le RFC 862.) La machine de
l'UCL était une des rares étrangères aux
USA. Le Foonly qu'on voit au
SRI était une machine connue pour avoir fait
les CGI des films Tron
et, come le note John Shaft, Looker :
« première fois qu'il était possible de voir de la
3D avec ombrage dans un film, de mémoire. Un
corps humain de surcroît. ». Quant à la machine
SRI-NIC, c'est elle qui distribuait ce fichier
(son adresse avait changé depuis la publication du RFC).
L'internet était encore assez centralisé à l'époque, et il était
possible de décider d'un « jour J », où on fait changer tout le
monde en même temps : ce RFC fixait la date au 1er mai 1982, où tout
le monde devait utiliser le nouveau format, l'ancien, celui du RFC 608, étant abandonné.
Une copie du fichier de 1983 est en
ligne (merci à Patrick Mevzek pour l'avoir trouvée) et j'en
ai fait une copie locale.
