Si vous vous êtes récemment connecté à GitHub et que vous êtes un utilisateur actif, vous avez peut-être remarqué un nouveau badge sur votre profil: "Arctic Code Vault Contributor". Cela semble assez génial, non? Mais à qui le code a-t-il été archivé dans ce coffre-fort, comment est-il stocké et à quoi ça sert?

Ils ont gelé mon ordinateur!

Le 2 février, GitHub a pris un instantané de chaque référentiel public répondant à l'un des critères suivants:

  • Actif depuis nov.2019
  • 250 étoiles ou plus
  • Au moins une étoile et de nouveaux commits depuis février 2019

Ensuite, ils se sont rendus à Svalbard, ont trouvé une mine de charbon désaffectée et ont archivé le code dans un stockage profond sous terre – mais pas avant d'en faire une vidéo très cinématographique.

Comment ça fonctionne

Source: GitHub

Pour la combinaison de la longévité, du prix et de la densité, GitHub a choisi le stockage de films, fourni par piql.

Le support de stockage n’a rien de très remarquable: l’archive tar de chaque référentiel est codée sur un film aux halogénures d’argent standard sous la forme d’un code-barres 2D, réparti sur des images de 8,8 millions de pixels chacune (environ 4K). Bien que officiellement évalué à 500, le film devrait durer au moins 1000 ans.

Vous pouvez imaginer que tous les référentiels publics de GitHub prendraient beaucoup d'espace lorsqu'ils sont stockés sur film, mais les données ne sont que de 21 To lorsqu'elles sont compressées – cela signifie que toute l'archive tient confortablement dans un conteneur d'expédition.

Chaque bobine commence par des diapositives contenant un guide de texte lisible par l'homme non codé dans plusieurs langues, expliquant à l'humanité future comment fonctionne l'archive. Si vous avez cinq minutes, lire le guide et comment GitHub explique l'archive à quiconque le découvre est très amusant. Il est intéressant de voir l’éventail des connaissances futures auxquelles le guide s’adresse – il commence par expliquer en termes très basiques ce que sont les ordinateurs et les logiciels, malgré le fait qu’un logiciel de décompression serait nécessaire pour utiliser l’une des archives. Pour combler cette lacune, ils fournissent également un «arbre technologique», un guide complet sur les logiciels modernes, la compilation, l'encodage, la compression, etc. Fait intéressant, alors que le guide d'introduction est open source, l'arbre technologique ne semble pas l'être.

Mais la question plus grande que comment GitHub l'a fait est pourquoi l'ont-ils fait?

Pourquoi?

La mission du programme d'archivage GitHub est de préserver les logiciels open source pour les générations futures.

GitHub parle de deux raisons de préserver un logiciel comme celui-ci: la curiosité historique et le désastre. Parlons d'abord de la curiosité historique.

Il y a un argument selon lequel la préservation des logiciels est essentielle à la préservation de notre patrimoine culturel. C'est un argument facile à acheter, car même si vous êtes dans le camp qui pense qu'il n'y a rien d'artistique dans un tas de zéros et de zéros, on ne peut nier que le logiciel est une plate-forme et un support pour une quantité incroyablement diversifiée de culture moderne. .

GitHub cite également des exemples passés d'informations techniques importantes perdues pour l'histoire, telles que la recherche des plans de Saturne V ou la découverte du mortier romain qui a construit le Panthéon. Mais le stockage, la sauvegarde et les réseaux de données ont considérablement évolué depuis la production des plans de Saturn V. Aujourd'hui, les gens répètent souvent: «Une fois que c'est sur Internet, c'est là pour toujours». Qu'est-ce que tu en penses? Pensez-vous que l'argument selon lequel les logiciels (ou plutôt, le sous-ensemble de logiciels qui vivent dans les dépôts publics GitHub) pourraient être facilement perdus en 2020+ est valide?

Quelle que soit votre opinion, la simple préservation des logiciels open source sur de longues périodes est déjà effectuée par de nombreuses autres organisations. Et il ne nécessite pas de bunker arctique. Pour cela, nous devons considérer le deuxième motif de GitHub: un désastre à grande échelle.

Si quelque chose va exploser

Nous ne pouvons pas prédire les catastrophes apocalyptiques que l’avenir pourrait apporter – c’est en quelque sorte le problème. Mais si l'humanité essayait de résoudre le problème, un coffre-fort de code serait-il utile?

Premièrement, clarifions les choses: pour que nous ayons besoin d’utiliser une archive de code enfouie profondément dans le Svalbard, il faut que quelque chose se soit vraiment, vraiment mal passé. C'est assez faux pour que des éléments tels que softwareheritage.org, Wayback Machine et d'innombrables autres sauvegardes «conventionnelles» ne fonctionnent pas. Ce serait donc un désastre qui aurait anéanti la majorité de notre infrastructure numérique, y compris les sauvegardes et les réseaux de redondance mondiale, nous obligeant à reconstruire les choses à partir de zéro.

Cela soulève la question: si nous devions reconstruire notre monde numérique, ferions-nous une copie conforme de ce qui existe déjà, ou reconstruirions-nous à partir de zéro? Il y a deux faces à cette médaille: pourrait nous reconstruisons nos systèmes existants et serions-nous vouloir pour reconstruire nos systèmes existants.

S'attaquer d'abord au premier: les logiciels modernes reposent sur de très nombreuses couches d'abstraction. Dans un monde post-apocalyptique, pourrions-nous même utiliser une grande partie du logiciel avec notre infrastructure / services de niveau inférieur anéantis? Pour prendre un exemple aléatoire, peut-être ténu, disons que nous avons dû reconstruire nos réseaux, DNS, FAI, etc. à partir de zéro. Inévitablement, le comportement serait différent, les nœuds et les informations manquants, et donc les logiciels construits sur des couches supérieures pourraient être instables ou non sécurisés. Pour prendre des exemples plus concrets, ce problème est le plus important lorsque les logiciels open source reposent sur une infrastructure à source fermée – AWS, des API tierces et même des conceptions de puces de bas niveau qui n'auraient peut-être pas survécu au désastre. Pourrions-nous réimplémenter les logiciels existants de manière stable en plus des solutions re-hachées?

Ce dernier point – voudrions-nous reconstruire notre logiciel tel qu'il est actuellement – est plus subjectif. Je ne doute pas que tous les lecteurs de Hackaday ont une ou deux choses sur lesquelles ils pourraient changer, enfin presque tout, mais pas en raison de l’infrastructure existante et des systèmes hérités. L'opportunité de reconstruire des systèmes modernes serait-elle en mesure de l'emporter sur le coût en temps que cela représente?

Enfin, vous avez peut-être remarqué que les logiciels évoluent assez rapidement. Être un développeur Web aujourd'hui familier avec toutes les principales technologies utilisées semble assez différent du même rôle il y a 5 ans. L'archivage d'un instantané statique de code a-t-il donc un sens étant donné la rapidité avec laquelle il serait obsolète? Certains diront que lancer des chiffres comme 500 à 1000 ans n'a pas de sens pour la réutilisation si le paysage logiciel a complètement changé en 50. Si une apocalypse devait se produire aujourd'hui, voudrions-nous reconstruire notre monde en utilisant le code des années 80?

Même si nous ne devions pas réutiliser directement le code archivé pour reconstruire notre monde, il y a encore de nombreuses raisons pour lesquelles cela pourrait être utile, comme faire référence à la logique implémentée en son sein, ou à l'architecture, aux structures de données, etc. . Mais ce ne sont que mes pensées et je veux entendre les vôtres.

Était-ce une chose utile à faire?

L'idée qu'il existe un coffre-fort dans l'Arctique contenant directement le code que vous avez écrit est indéniablement amusante à penser. De plus, votre code vous survivra presque certainement! Mais pensez-vous, cher lecteur de Hackaday, que ce projet est un exercice amusant de science-fiction ou a-t-il une valeur réelle pour l'humanité?

LAISSER UN COMMENTAIRE

Rédigez votre commentaire !
Entrez votre nom ici