Cette archive, le GitHub Code Vault, a été créée par le programme d'archives GitHub, dont la mission est de préserver les logiciels open source pour les générations futures. Vous lisez peut-être dans un an ou mille, mais dans tous les cas, nous espérons que son contenu, et peut-être le concept même d’open source, vous seront utiles.
Il s'agit principalement d'une archive de logiciels. Le logiciel est une série de commandes utilisées pour contrôler les actions d'un ordinateur. Un ordinateur est un appareil qui peut exécuter automatiquement des fonctions mathématiques tellement plus rapidement qu'un esprit humain qu'il a des pouvoirs bien au-delà de nous. Nos ordinateurs sont utilisés pour aider à explorer les secrets de l'univers, pour connecter toute l'humanité dans un réseau d'information omniprésent, pour manipuler des signaux assez rapidement pour transmettre des sons et projeter des images en mouvement détaillées sur des écrans électriques, et pour contrôler des machines extrêmement puissantes qui dépasse à la fois la capacité et la précision du travail humain.
Un ordinateur sans logiciel ne peut faire aucune de ces choses. Un ordinateur est une chose extraordinaire et merveilleuse, mais sans logiciel, toute sa puissance est inutile. Le but de ces archives est de vous transmettre ce que nous savons sur les logiciels.
Les logiciels sont écrits sous la forme de séquences de commandes complexes mais lisibles par l'homme, dont les différentes saveurs sont appelées langages de programmation, car une unité complète de logiciels est souvent appelée programme. Ces programmes sont ensuite convertis dans le langage binaire des uns et des zéros utilisé par les ordinateurs. Ce processus est connu sous le nom de compilation.
Étant donné que le logiciel compilé est très difficile à déchiffrer dans sa forme de programme d'origine, également connue sous le nom de code source, il est possible pour les gens de garder cette forme originale secrète et d'en revendiquer la propriété. Les logiciels open source ne sont pas un type de logiciel différent, mais une philosophie différente. L'éthique open source rejette le secret et la propriété. Les logiciels open source sont mis à la disposition de tous ceux qui souhaitent les utiliser, sans frais, afin qu'ils puissent à leur tour améliorer ces programmes ou les utiliser pour créer quelque chose de nouveau et de meilleur.
Un projet open source est le travail collectif d'une communauté auto-organisée qui peut se compter par milliers. L'accumulation de tous les projets de logiciels open source archivés ici est l'œuvre d'une communauté de plusieurs millions de personnes. Bien que certaines personnes puissent avoir des droits spéciaux dans un projet donné, comme la possibilité d'approuver ou de rejeter les modifications suggérées à la dernière version officielle de son code source, personne ne la possède jamais. Chaque personne a le droit de prendre et d'utiliser une copie complète de tout projet open source à tout moment, sans frais ni pénalité. C'est ce qu'on appelle la création d'un projet.
Lorsque de nombreuses personnes travaillent sur le code source en même temps, il est difficile de suivre et d'intégrer toutes leurs modifications. Un projet open source appelé «Git» est consacré à la résolution de ce problème. Il intègre un historique complet de tous les ajouts et modifications d'un projet dans une entité connue sous le nom de référentiel Git. Cette archive est essentiellement une archive de ces référentiels.
Cette archive a été créée par une société nommée `` GitHub '', qui fournit un service qui permet aux utilisateurs du monde entier de stocker les logiciels qu'ils ont écrits, de suivre les modifications apportées à ces programmes et de collaborer avec d'autres pour les améliorer et les développer. GitHub met ses services gratuitement à la disposition des développeurs de logiciels publics open source. Il compte des dizaines de millions de ces utilisateurs.
Ce qui suit est une description de ce que nous pensons que vous devrez savoir et avoir pour utiliser au mieux ces archives logicielles. Si vous ne savez pas ou ne comprenez pas tout ou partie de cela, ne désespérez pas! Nous avons également inclus un guide expliquant comment répondre à ces exigences. Si, pour une raison quelconque, vous ne pouvez pas les accomplir vous-même, vos descendants le peuvent.
En principe, tout ce dont vous avez besoin pour accéder au contenu de cette archive est une source d'éclairage et une sorte de loupe. Cependant, la plupart (mais pas toutes) de ses données ont été emballées très étroitement sur des bobines de film sous une forme codée et compressée. La lecture, le décodage et la décompression de ces données exigeront en soi un calcul considérable. En théorie, cela pourrait se faire sans ordinateur, mais ce serait très fastidieux et difficile.
Nous nous attendons à ce que vous n'ayez pas besoin de nos définitions de logiciel, ordinateur et autres termes. Nous imaginons que vous avez vos propres ordinateurs, probablement beaucoup plus avancés que le nôtre, et peut-être d'une architecture fondamentalement différente. Une fois que vous aurez compris l'aperçu et le guide ci-dessous, vous pourrez facilement accéder à toutes les données.
Cependant, il est possible que vous ayez des ordinateurs inférieurs aux nôtres, voire aucun ordinateur. Dans le cas de cette éventualité, nous avons préparé une bobine de données non compressée, non codée et lisible par l'homme que nous appelons l'arbre technologique. L'arbre technologique contient des informations sur nos technologies fondamentales, nos ordinateurs et nos logiciels, dans l'espoir qu'au fil du temps, vous pourrez utiliser ces connaissances pour recréer des ordinateurs qui peuvent utiliser les logiciels open source de ces archives.
L'archive est si grande - environ 24 billions d'octets (expliqués ci-dessous) - car elle est extrêmement inclusive et démocratique. Des millions de personnes mettent le logiciel qu'elles écrivent à la disposition de tous. Cette archive comprend un instantané - c'est-à-dire une seule copie, à un seul instant - de tous les logiciels publics que les utilisateurs de GitHub développent activement. Cela signifie qu'il comprend des dizaines de millions de référentiels séparés. Nous espérons que cette approche large et démocratique intéressera les historiens de l'avenir.
Les référentiels inclus dans cette archive ont été déterminés uniquement par leur dernière heure de validation, c'est-à-dire la dernière fois qu'ils ont été mis à jour, et leur nombre d'étoiles. (Les utilisateurs de GitHub peuvent tous «mettre en vedette» les référentiels publics, pour indiquer qu'ils présentent un intérêt ou une signification pour eux.) L'instantané a été lancé le 02/02/2020, c'est-à-dire le deuxième jour du mois de février, en l'année 2020 du calendrier grégorien, comme on compte le temps. Les référentiels qui y sont inclus sont: tous les référentiels avec des validations au cours des 80 jours précédents; tous les référentiels avec au moins une étoile avec des validations au cours des 365 jours précédents; et tous les référentiels avec au moins 250 étoiles, quelle que soit la date de leur dernière mise à jour.
Bien sûr, tous ces référentiels ne sont pas tout aussi importants en termes d'influence et de dépendances. L'arbre technologique comprend un index et une brève description des référentiels les plus importants de l'archive, et des listes sur lesquelles chacun peut être trouvé, de sorte qu'ils puissent être consultés sans avoir à parcourir tous ces millions de référentiels pour déterminer lesquels sont les plus pratiques. utile.
L'archive se compose de 201 bobines de film: une "bobine guide" d'informations et de conseils lisibles par l'homme, et 200 bobines de logiciels archivés. Chaque bobine comprend 65 000 cadres individuels. Les cadres au début de chaque bobine et les cadres de la bobine de guidage comprennent du texte et des images lisibles par l'homme. Toutes les autres images de film sont constituées de données numériques stockées sous une forme visuelle connue sous le nom de codes QR.
Les données numériques signifient des données finalement stockées au format binaire, c'est-à-dire sous forme de 0 et de 1, car les ordinateurs eux-mêmes sont binaires - contrôlés par des signaux électriques qui sont soit "allumés" soit "éteints", correspondant à 1 ou 0 - et donc les données binaires sont les ordinateurs sont beaucoup plus faciles à comprendre que les autres.
Les métadonnées lisibles par l'homme stockées au début de chaque bobine incluent des informations sur le film lui-même, un guide pour l'encodage QR utilisé, un logiciel pour le décoder et un index. L'index répertorie le titre, le numéro de trame de début et la somme de contrôle pour chaque fichier stocké sur cette bobine.
Un fichier est une seule entité de données cohérente. Une somme de contrôle est une valeur unique d'un calcul, appelée fonction de hachage, exécutée sur tout le contenu d'un fichier, pour garantir que son contenu n'a pas été endommagé ou corrompu; la fonction de hachage utilisée dans l'archive est connue sous le nom de «SHA-1».
Chaque code QR se compose d'un champ de minuscules carrés blancs ou noirs qui occupent presque toute l'image du film. Nous utilisons des codes QR car ils sont beaucoup plus compacts et robustes que le texte lisible par l'homme. Un code QR se décode en données binaires, c'est-à-dire une série de uns et de zéros.
Ce décodage n'est que la première étape pour transformer ces données binaires en informations significatives. Ce sont des données compressées, ce qui signifie qu'elles ont été compactées pour économiser de l'espace, de la même manière que l'on pourrait écrire "128xA" plutôt que d'écrire la lettre A 128 fois. Après avoir été décodé, il doit être décompressé.
Le résultat après décompression est connu sous le nom de fichier archive: un fichier unique contenant tout le contenu du référentiel d'un seul projet logiciel. La plupart des référentiels contiennent de nombreux fichiers, donc ce fichier d'archive est comme un livre contenant de nombreux chapitres séparés, ou une boîte contenant de nombreuses autres boîtes. Il est généralement avantageux, mais pas absolument nécessaire, de décompresser le fichier archive dans ses fichiers composants avant d'y accéder.
Enfin, chaque fichier composant est son propre ensemble de données binaires, c'est-à-dire des uns et des zéros. On peut donner un sens aux données si vous connaissez leur format. Par exemple, dans le format connu sous le nom «UTF-8», le format le plus courant dans l'archive, les uns et les zéros sont divisés en groupes de huit, appelés octets, l'octet 01000001 représente la lettre A; les trois octets 01101001 01101110 01110100 représentent le mot int; et les deux octets 11000011 10000011 représentent la lettre à (A avec un accent tilde en haut.)
Ce processus d'archivage des données, des fichiers binaires emballés dans des fichiers d'archive qui ont d'abord été compressés puis encodés en QR, est évidemment complexe par rapport à la simple écriture de texte lisible par l'homme. Le processus de désarchivage que vous devrez suivre - QR en binaire compressé; compressé à non compressé; archiver le fichier dans plusieurs fichiers; fichiers texte en texte lisible par l'homme - est tout aussi complexe. C'est parce que cette complexité nous permet de stocker beaucoup plus de données que ce qui serait autrement possible, d'une manière relativement facilement lisible par ordinateur.
Si cette complexité est difficile et coûteuse pour vous, nous nous excusons, mais nous nous attendons à ce que, si tel est le cas, ce guide et l'arbre technologique lisible par l'homme atténueront cette complexité et pourraient peut-être vous être plus utiles que le le contenu de l'archive, au moins jusqu'à ce que vos ordinateurs soient suffisamment avancés pour que la complexité des données de l'archive soit facile à gérer.
Il peut être instructif de discuter de la manière dont l'archive est logiquement divisée. En particulier, une discussion sur les fichiers, les répertoires et les formats de données sera probablement utile.
Un fichier est une collection de données regroupées en une entité cohérente avec un seul nom: considérez les données comme du sable, et un fichier comme une sorte de sac qui peut contenir du sable, et seulement du sable. Un répertoire est une collection de fichiers: considérez-le comme une sorte de sac qui ne peut contenir que d'autres sacs. Suite à cette métaphore, chaque référentiel se compose d'un répertoire externe, appelé répertoire racine, qui contient un certain nombre de fichiers et / ou un certain nombre de répertoires. Chaque répertoire peut, à son tour, contenir à la fois des fichiers et des répertoires.
Cette structure est préférable car les fichiers organisés en groupes sont beaucoup plus faciles à utiliser qu'une seule collection de fichiers. L'identifiant d'un fichier particulier dans le répertoire externe se compose des noms de tous ses répertoires englobants, en commençant par la racine, suivi de son propre nom individuel, avec un caractère / entre chaque nom. Par exemple, un fichier nommé README.md dans le répertoire racine serait identifié comme /README.md et un fichier identifié comme /public/www/index.html serait le fichier index.html dans le répertoire 'www' à l'intérieur du ' public 'dans le répertoire racine.
Chaque référentiel a à son tour deux noms, séparés par un séparateur, qui dans l'archive est un caractère _ ou un trait de soulignement. (Historiquement, il s'agit d'une barre oblique /, mais qui est également utilisée pour indiquer un répertoire, nous utilisons donc _ pour plus de clarté.) Le premier nom est le compte GitHub qui possède ce référentiel; le second est le nom du référentiel individuel. La combinaison d'identifiants de référentiel et de fichier peut être utilisée pour identifier de manière unique un fichier individuel dans l'archive. Par exemple, le fichier 'package.json' dans le répertoire 'web' dans le référentiel 'ykarma' dans le compte GitHub 'rezendi' pourrait être identifié de manière unique comme /web/package.json dans rezendi_ykarma dans l'archive.
Différents types de fichiers ont des objectifs différents. L'archive GitHub se compose en grande partie de fichiers texte, c'est-à-dire de fichiers dont les données sont censées représenter le langage écrit. La plupart des logiciels sont écrits dans des fichiers texte contenant du texte hautement structuré appelé code source. Un programme spécial appelé compilateur convertit ce code source lisible par l'homme en instructions lisibles par ordinateur appelées code compilé ou code machine.
Les fichiers qui ne sont pas des fichiers texte, tels que les fichiers qui représentent des images visuelles ou contiennent du code compilé, sont souvent appelés fichiers binaires. C'est malheureusement un terme trompeur, car les fichiers texte sont également des 1 et des 0. Nous ferons référence aux fichiers qui ne sont pas des fichiers texte comme des fichiers non texte.
Il existe de nombreuses façons de représenter le langage humain écrit à l'aide de 1 et de 0. Pour des raisons historiques, la plupart du code source a été écrit à l'origine dans ce que l'on appelle l'écriture latine. L'écriture latine a 26 caractères de base qui sont utilisés pour représenter des mots parlables, chacun ayant deux formes, en majuscules et en minuscules. Il a également 10 chiffres pour représenter les nombres. L'écriture latine, ainsi que divers autres symboles associés utilisés pour indiquer la structure et d'autres concepts, est codée en 1 et en 0 dans un format appelé `` ASCII '', qui peut représenter 128 caractères différents et, pour des raisons historiques, a dominé la plupart des logiciels pendant de nombreuses années .
Cependant, l'écriture latine n'est qu'un petit sous-ensemble des nombreuses façons dont les humains s'expriment dans la langue écrite. Pour prendre en charge d'autres scripts, tout en permettant à tous les logiciels qui avaient été écrits pour utiliser ASCII de continuer à fonctionner sans changement (un concept connu sous le nom de compatibilité descendante), un autre format de données appelé «UTF-8» a été introduit.
ASCII reste le format de code source le plus courant. Chaque bobine de cette archive comprend un guide des caractères ASCII. ASCII est un sous-ensemble de UTF-8, c'est-à-dire que tous les encodages ASCII sont également des encodages UTF-8. La bobine de guidage contient en outre une spécification de tous les caractères UTF-8. Presque tous les fichiers texte de cette archive doivent être encodés en UTF-8.
Les fichiers non textuels incluent des fichiers destinés à représenter des images et des documents formatés. Une convention largement utilisée est que les noms de fichiers se terminent par un '.' caractère suivi d'un suffixe indiquant le type de fichier. Par exemple, un nom de fichier qui se termine par .jpg est probablement un fichier image JPEG; celui qui se termine par .PNG est probablement un fichier d'image graphique de réseau portable; et un qui se termine par .pdf un fichier au format de document portable.
Il n'y a pas de suffixe unique qui indique les fichiers texte. Au contraire, pour le code source, le suffixe est plus susceptible d'indiquer dans quel langage de programmation ou de balisage le code est écrit. Les langages de programmation et de balisage seront décrits plus en détail ci-dessous.
Ici, nous allons fournir un aperçu de la façon de décompresser un référentiel archivé particulier dans ses différents fichiers constituants. Encore une fois, ce processus consiste en:
-
Identifier la bobine et les cadres spécifiques sur lesquels les données du référentiel sont archivées.
-
Décodage à partir des codes QR, des champs de pixels noirs, blancs et gris sur ces cadres, en un fichier binaire, une séquence de (au moins des milliers et souvent des millions de) 1 et 0.
-
Décompressez le fichier binaire dans un fichier d'archive plus long et non compressé.
-
Décompression du fichier d'archive dans les sous-fichiers séparés qu'il contient. Notez cependant que les données d'archive sont généralement compréhensibles, bien que désordonnées, même si cette étape est omise.
-
Enfin, la conversion de chacun de ces sous-fichiers - eux-mêmes des séquences de 1 et de 0 pouvant aller de très court à très long - en caractères écrits, s'il s'agit de fichiers texte.
Identification de la bobine et des cadres spécifiques sur lesquels les données du référentiel sont archivées
Chaque bobine de film commence par un leader de film vide, puis le cadre de référence zéro, qui consiste en un rectangle noir uni dans un coin d'une image autrement vide. Le prochain cadre lisible par l'homme est le cadre de contrôle, avec des informations sur la bobine. Vous trouverez ci-après la table des matières, qui comprend à son tour une liste de fichiers de données utilisateur.
Chaque référentiel sur cette bobine est l'un de ces fichiers de données utilisateur. La liste comprend un ID unique, un ID de fichier et un nom pour chacun de ces fichiers. Par exemple, le référentiel CPython du compte Python peut avoir l'ID de fichier répertorié comme 12345 et le nom répertorié comme python_cpython.tar.
Après la liste des fichiers de données utilisateur se trouve une liste des emplacements de données numériques. Cette liste comprend l'ID de fichier, une image de début, un octet de début, une image de fin et un octet de fin. Ainsi, en utilisant l'exemple hypothétique de CPython, l'élément de cette liste avec l'ID 12345 peut avoir une image de début de 054321, un octet de début de 03210321, une image de fin de 054545 et un octet de fin de 12321232.
Cela signifie, pour obtenir les données CPython: Allez à l'image 54321 de cette bobine de film. Décodez toutes les trames de la trame de début, 54321, à la trame de fin, 54545, en valeurs binaires, par les moyens décrits ci-dessous. Cela vous donnera 225 pièces de données numérotées de 54321 à 54545, qui commenceront par un ensemble de pièces vierges sans données. Jetez les 3210320 premiers octets dans la première donnée non vierge. Ajoutez tous les éléments de données «intermédiaires», dans l'ordre. Enfin, ajoutez les 12321232 premiers octets du dernier élément de données, 54545. Vous avez maintenant assemblé le référentiel CPython complet, en un seul fichier d'archive compressé.
Les détails sur la façon de décoder les images du film en données binaires se trouvent dans les informations de représentation lisibles par l'homme qui se trouvent à la suite de la table des matières au début de chaque bobine de film dans les archives. Ces informations se trouvent sur chaque bobine de sorte que, même si une bobine individuelle est séparée de l'archive, il sera toujours possible de déchiffrer son contenu. Ces informations de représentation comprennent, dans l'ordre:
-
Un guide du programme d'archivage GitHub (ce document)
-
Index descriptif GitHub, une liste et une brève description de tous les référentiels sur cette bobine
-
Description des informations de représentation
-
Conservation numérique et comment récupérer des données, un aperçu des détails de la récupération des données
-
Description du support de stockage
-
Technologie de récupération des données
-
Structure générique de bobine de conservation (format de bobine)
-
Description du format générique du cadre 4K
-
Description de la bibliothèque de déballage (pour les codes QR)
-
Débloquer le code source de la bibliothèque
-
Spécification du format de données ASCII
-
Spécification du langage de programmation C
-
Code source du fichier d'archive TAR
-
Code source PDF
-
Spécification du format de fichier XZ (pour la compression / décompression, décrite ci-dessous) Le sixième de ces éléments, le document sur la technologie de récupération des données, décrit les exigences et les processus pour utiliser un scanner pour capturer les données sur une seule image de film codée numériquement et les transformer en une forme pouvant être analysée par ordinateur. Le huitième d'entre eux, la description du format Generic 4K Frame, fournit les informations techniques, y compris le code source, nécessaires pour qu'un ordinateur prenne une telle image numérisée et la convertisse en données binaires.
Il est théoriquement possible, en principe, de convertir un référentiel de données encodées en QR en données binaires sans utiliser d'ordinateur. Cependant, ce serait extrêmement difficile et exigerait probablement un effort considérable de la part d'une communauté bien organisée pendant plusieurs semaines, voire des mois ou des années. Étant donné que le contenu des référentiels est un logiciel destiné à fonctionner sur un ordinateur, leur utilisation en l'absence d'un ordinateur serait au mieux minimale.
Dans le cas où les héritiers de cette archive n'ont pas d'ordinateurs, ils doivent conserver l'archive entière et en sécurité jusqu'à ce qu'ils le fassent. L'un des objectifs de l'arbre technologique lisible par l'homme est d'aider à accélérer le développement des technologies et des ordinateurs en cas de cette éventualité. (Son autre objectif est de codifier notre technologie et son développement pour les futurs historiens.)
Le fichier binaire de chaque référentiel est dans un format appelé TAR, pour Tape Archive. Un fichier TAR est essentiellement composé en regroupant un certain nombre de fichiers en connectant la fin de l'un au début du suivant, comme en collant des morceaux de papier individuels dans un seul rouleau. Un fichier TAR peut inclure n'importe quel nombre de fichiers, de n'importe quelle taille, divisés en n'importe quel nombre de répertoires et de sous-répertoires.
Chaque sous-fichier d'un fichier TAR est précédé d'un enregistrement d'en-tête de 512 octets, qui agit comme la bande dans la métaphore de défilement. Cet enregistrement d'en-tête contient des informations sur le fichier, telles que son nom et sa taille. La fin de l'archive est indiquée par au moins deux blocs consécutifs de 512 octets.
Étant donné que les fichiers TAR sont essentiellement des collections de fichiers avec des enregistrements de texte entre eux, si un fichier TAR contient tous les fichiers texte, il peut être traité comme un fichier texte lui-même. S'il contient un mélange, il peut être traité comme un fichier texte qui contient un mélange de texte structuré et significatif (les fichiers texte constitutifs) et de charabia incompréhensible (les fichiers non textuels constitutifs.)
Il est possible d'imbriquer des fichiers TAR dans des fichiers TAR, un conteneur dans un autre, et c'est ainsi que la plupart de nos données archivées sont stockées. Pour tout référentiel donné, le fichier TAR externe contiendra au moins:
- un seul fichier de métadonnées non compressé appelé META, qui comprend le nom du référentiel, le nom du compte, la description, la langue, le nombre d'étoiles et le nombre de fork
- un fichier compressé (voir ci-dessous) nommé COMMITS, qui comprend le journal des modifications apportées au référentiel au fil du temps
- un fichier nommé repo.tar.xz, un fichier TAR compressé qui contient le contenu réel du référentiel
D'autres métadonnées, telles que les wikis, les pages gh, les problèmes et les demandes d'extraction, peuvent également être incluses en tant que fichiers compressés séparés.
Les détails spécifiques des fichiers TAR, et le logiciel pour les encoder et les décoder, peuvent être trouvés dans les informations de représentation dans chaque bobine de l'archive.
Afin d'inclure autant de référentiels et autant de données que possible, la plupart des données ont été compressées. La compression signifie utiliser une petite quantité de données pour représenter une plus grande quantité, en utilisant des modèles et des répétitions dans cette plus grande quantité. Par exemple, au lieu d'écrire le caractère neuf fois de suite, on pourrait simplement écrire le texte compressé 9a, si l'on était sûr que le lecteur comprendrait que 9a signifiait le texte non compressé aaaaaaaaa.
Les algorithmes de compression efficaces sont beaucoup plus complexes que cela, mais le même principe s'applique. Cette archive utilise un programme de compression appelé «XZ», qui à son tour utilise un algorithme appelé «LZMA». Le deuxième fichier de données de chaque bobine contient le code source et la documentation de XZ dans un seul fichier d'archive TAR non compressé, décrit ci-dessous. (Le premier fichier de données contient la Déclaration universelle des droits de l'homme dans chaque langue humaine écrite disponible.)
LZMA combine ce que l'on appelle un algorithme «LZ77» et un «encodage de plage». LZ77 remplace les données répétées par des références aux apparitions précédentes de ces données. Par exemple, pour simplifier à l'extrême, si une phrase de 80 octets apparaît deux fois, 400 octets d'intervalle, la deuxième fois, l'algorithme compacte essentiellement les données en disant «répéter 80 octets à partir d'il y a 400 octets». Le codage par plage convertit essentiellement un message entier en un seul nombre très long, qui à son tour peut être codé.
Les étapes spécifiques de l'algorithme à utiliser pour décompresser les données sont décrites par le code source XZ contenu dans le deuxième fichier de données dans chaque bobine. Bien qu'il soit théoriquement possible de décompresser à la main, encore une fois, ce serait un processus extrêmement long et laborieux. Dans la pratique, un ordinateur fonctionnel serait nécessaire.
L'humanité a utilisé de nombreux caractères écrits au cours des millénaires. L'encodage utilisé pour représenter ces caractères sous forme de 1 et de 0 dans cette archive est appelé «UTF-8». Un seul caractère UTF-8, c'est-à-dire un seul symbole écrit, peut occuper de 1 à 4 octets de données binaires.
Pour des raisons historiques, parce qu'ils étaient les plus largement utilisés à l'époque et dans la région où et quand le développement logiciel a commencé, un groupe de caractères (et de concepts) appelés «ASCII» sont encodés le plus efficacement, à 1 octet par caractère. Tout ce qui n'est pas ASCII est codé sur 2 octets ou plus par caractère. La plupart des fichiers texte de cette archive sont ASCII, mais un grand nombre ne le sont pas. Beaucoup d'autres seront principalement ASCII avec parfois des caractères non ASCII.
Les spécifications détaillées d'ASCII peuvent être trouvées dans les informations de représentation dans chaque bobine de l'archive. Les spécifications détaillées de l'UTF-8 se trouvent dans la bobine de guidage. Le premier fichier de données sur chaque bobine des archives contiendra le texte de la Déclaration universelle des droits de l'homme dans chaque langue humaine écrite disponible. Cela servira à la fois d'outil de traduction et d'exemple d'ASCII et d'UTF-8.
Il existe de nombreux types de fichiers texte, créés pour différentes raisons. Le type principal ici, la raison pour laquelle cette archive existe, est le code source. Le code source est un texte très dense et extrêmement structuré, dans lequel des symboles comme "{" et ";" ont une grande importance.
L'essentiel du code source est qu'il est écrit pour être lu par les compilateurs. Puisque les compilateurs sont des logiciels, une autre façon de formuler cela est que le code source est écrit pour être lu par des ordinateurs. Un bon code est également écrit afin que d'autres humains, s'ils sont qualifiés et éduqués dans le domaine des logiciels, puissent le comprendre; mais il n'est correct que si un compilateur peut le comprendre.
Ce compilateur, à son tour, à travers des séquences compliquées décrites dans l'arbre technologique, convertira le code source en séquences de uns et de zéros qui amèneront l'ordinateur à exécuter les fonctions et activités décrites par le code. Pour prendre un exemple très simple, la ligne de code
_for (int i = 0; i <5; i ++) {} _
sera converti par le compilateur en une série d'instructions binaires transmises à l'ordinateur, ce qui amènera une infime partie de l'ordinateur, appelée registre, à définir sa valeur à 0, puis à incrémenter cette valeur à 1, 2, 3, et puis 4. (Ce n'est pas un exemple de code utile; c'est juste une illustration du processus à plusieurs couches de transformation du code source en logiciel en cours d'exécution.)
D'autres types de fichiers texte, tels que JSON, XML et HTML, sont utilisés pour stocker des données (par opposition aux commandes) pour les ordinateurs. Ils sont généralement également lisibles par les humains, bien que leurs formats structurés les rendent plus difficiles à lire que le texte de narration moins structuré comme ce fichier.
La plupart des autres types de fichiers texte sont destinés à être éventuellement lus par les humains. Certains sont des textes simples, pour la plupart non structurés, comme ce fichier que vous lisez actuellement. Un type que vous rencontrerez largement dans l'archive est Markdown, signifié par l'extension .md d'un fichier, qui est une sorte de forme intermédiaire censée être lisible par les humains sous leur forme brute et aussi, en même temps, structurée de manière à ce que les ordinateurs peuvent les formater en des mises en page plus attrayantes et plus utiles. La plupart des référentiels de cette archive ont un fichier README.md Markdown, qui est généralement conçu comme une introduction initiale au référentiel, décrivant ce qu'il est, pourquoi il existe et comment l'utiliser.
Un bref aperçu des formes les plus courantes de fichiers non textuels peut également être utile. Le code compilé n'est pas du texte. Les fichiers JPG et PNG encodent les images au format numérique et les MP3 et WAV encodent l'audio. Les fichiers PDF encodent les documents avec un formatage précis et parfait. Et les fichiers ZIP et TAR, comme mentionné précédemment, sont des fichiers conteneurs qui peuvent à leur tour inclure un ou plusieurs autres fichiers.
Il existe des milliers de langues écrites utilisées par l'humanité aujourd'hui, et encore plus de langues parlées. La plupart de ces langues ne sont utilisées que par des populations relativement petites, mais au moins vingt langues sont utilisées comme première ou deuxième langue par au moins 60 millions de personnes.
Les langues les plus utilisées dans le monde sont l'anglais et le chinois. Pour des raisons historiques, pendant de nombreuses années, la plupart des développements de logiciels ont eu lieu dans les pays anglophones, de sorte que pendant un certain temps, l'anglais est devenu la langue par défaut des logiciels. La plupart des langages de programmation utilisent des mots anglais dans leur syntaxe. C'est la langue dans laquelle ce guide des archives a été rédigé pour la première fois.
Il n'est pas garanti que les héritiers de cette archive connaissent l'anglais, même si cela semble une langue particulièrement susceptible de durer indéfiniment. Au cas où des conseils sur d'autres langues seraient utiles, nous incluons les plus de 500 traductions disponibles de la Déclaration universelle des droits de l'homme sous forme de fichier UTF-8 non compressé au début de chaque bobine, ainsi que dans l'arbre technologique. Cette déclaration est une liste des droits et libertés de chaque être humain à notre époque, qui ne doivent jamais être enlevés.
Les langages de programmation sont ceux utilisés par les humains pour communiquer des instructions aux ordinateurs. Ce sont les langages dans lesquels les logiciels s'expriment. D'autres humains (formés) devraient également être capables de lire le logiciel écrit dans des langages de programmation, mais c'est un objectif secondaire.
Un langage de programmation est un ensemble d'éléments prédéfinis, dont la plupart sont des mots, qui peuvent être organisés de manière structurée pour demander à un ordinateur d'exécuter l'action spécifiée de la manière spécifiée. Une collection de ces instructions est connue sous le nom de programme ou de code source. Le code source est essentiellement un logiciel sous une forme écrite figée.
Les programmes sont généralement divisés en étapes distinctes, appelées instructions, qui à leur tour sont regroupées en collections appelées fonctions. Un programme entier peut être contenu dans un seul fichier, ou peut être réparti sur des milliers.
Il existe des centaines de langages de programmation différents, répartis sur de nombreuses formes, approches et philosophies différentes. Certains sont compilés dans des fichiers binaires séparés, qui sont ensuite exécutés; certains, appelés langages «interprétés», sont effectivement compilés et exécutés en une seule fois, sans étape intermédiaire. La plupart des langages de programmation modernes incluent des bibliothèques de fonctions pré-écrites, et ces bibliothèques peuvent être très volumineuses et élaborées. Certains des langages de programmation les plus populaires d'aujourd'hui incluent:
-
C, l'un des langages les plus anciens et les plus rapides, les plus universels et les plus puissants, simple à certains égards mais assez limité à d'autres, et pas toujours intuitif, facile à lire ou facile à apprendre.
-
C ++, une évolution plus complexe, abstraite et puissante de C.
-
C #, une évolution supplémentaire compilée non pas en code machine binaire mais en un "runtime" interprété.
-
Java, qui est similaire (mais antérieur) à C #, est peut-être le langage le plus utilisé aujourd'hui.
-
JavaScript, assez différent de Java malgré la similitude de nom, et également connu sous le nom de «ECMAScript», est un langage initialement utilisé entièrement dans un navigateur Web, c'est-à-dire un programme qui récupérait, interprétait et affichait des données à partir d'un ordinateur distant connu sous le nom d'Internet. serveur; aujourd'hui, cependant, il est également largement utilisé sur ces serveurs.
-
TypeScript, une forme de JavaScript avec des règles plus strictes afin que les erreurs, également appelées bogues, soient moins susceptibles de se retrouver dans les programmes.
-
Python, un langage élégant populaire parmi les scientifiques, à la fois puissant et bon premier langage.
-
Ruby, un langage intuitif dont les déclarations se lisent souvent presque comme l'anglais écrit.
-
Go, un langage simple et puissant qui excelle particulièrement dans les programmes parallélisés, c'est-à-dire les programmes écrits de telle sorte que plusieurs fonctions s'exécutent indépendamment en même temps.
-
Swift, un nouveau langage utilisé pour écrire pour les téléphones et autres appareils utilisés par un milliard de personnes.
-
Rust, destiné à remplacer C, qui rend les bogues dangereux beaucoup moins probables.
-
PHP, un langage simple utilisé pour les serveurs Internet.
-
Lisp, un langage très ancien avec une approche fondamentalement différente de la programmation axée sur la fonction.
-
SQL, un langage très différent utilisé pour récupérer des données à partir de magasins de données structurés et très efficaces appelés bases de données.
-
Assembleur (ou assemblage), une famille de langages très cryptique, limitée, mais rapide et puissante dans laquelle il existe une relation directe entre les constructions de langage et le code machine de l'ordinateur en question; il peut être considéré comme du code à moitié compilé.
Le processus consistant à prendre un fichier de code source unique et simple et à le convertir en impulsions électriques dans un ordinateur est extrêmement complexe. Nous traitons cette complexité en utilisant des couches d'abstraction. Une abstraction connue sous le nom de jeu d'instructions permet d'utiliser la sortie du code machine d'un seul compilateur sur de nombreux types d'ordinateurs. Un auteur de code source n'a généralement pas besoin de savoir ou de se soucier du type d'ordinateur, ou même du jeu d'instructions, qui sera utilisé pour exécuter ce code; ceci est résumé par le compilateur.
Les logiciels modernes sont, quant à eux, beaucoup plus complexes qu'un seul auteur travaillant sur un seul programme pour un seul ordinateur. Il se compose de nombreux auteurs travaillant sur de nombreux fichiers dans un même projet, simultanément, souvent en utilisant plusieurs langages de programmation. De plus, chaque projet dépend d'autres projets autonomes et séparés en tant qu'outils et / ou composants, alors que ces projets sont eux-mêmes activement travaillés et dépendent à leur tour d'autres projets. Faire fonctionner toutes ces pièces mobiles ensemble de manière élégante et efficace est le défi du développement logiciel moderne.
Lorsque plusieurs auteurs de code source, également appelés développeurs de logiciels, travaillent sur un seul projet, chacun a son propre ordinateur et une copie de l'ensemble du projet sur son ordinateur. S'ils apportent chacun des modifications, chacun a une version différente du même projet. Le processus de réconciliation de plusieurs versions d'un projet est appelé contrôle de version. Il est géré par un logiciel de contrôle de version; dans cette archive, par un logiciel appelé Git, après quoi GitHub lui-même est nommé. Chaque référentiel de cette archive est un référentiel Git.
Git peut fusionner automatiquement différentes versions de logiciels en une seule forme cohérente avec une intervention humaine minimale requise. Git conserve également un historique complet qui vous permet de revenir à une version précédente en cas de besoin. Cependant, afin d'économiser de l'espace, les référentiels de cette archive n'incluent généralement pas d'histoires Git.
Lorsque plusieurs développeurs prennent un projet sur plusieurs chemins différents simultanément, on parle de branchement d'un projet, et ces chemins sont appelés branches. La branche principale convenue d'un projet est connue sous le nom de tronc, ou branche principale. Git fournit une fonctionnalité que les développeurs peuvent utiliser pour résumer les différences entre deux branches et proposer de joindre la leur à l'autre. C'est ce qu'on appelle une demande de tirage. Le développement de logiciels modernes consiste en grande partie à créer un projet, à écrire ou à éditer le logiciel sur votre branche et, une fois terminé, à soumettre une demande d'extraction pour que votre travail soit réintégré dans la branche principale.
Essentiellement, chaque langage de programmation prend en charge la construction sur le travail des autres. Sans réutiliser le travail des autres, chaque projet serait énormément plus difficile et beaucoup plus lent, et très peu de projets verraient un jour une utilisation réelle dans le monde réel.
Si le projet A doit inclure le projet B pour que A puisse faire son travail, alors A est connu comme dépendant du projet B, et B est connu comme une dépendance du projet A. A peut avoir de nombreuses dépendances, chacune pouvant avoir plusieurs dépendances qui leur sont propres, et ainsi de suite. De plus, chaque dépendance est pour une version particulière, ou une plage de versions, d'un projet donné. L'énumération complète de toutes les multiples couches de dépendances d'un projet est connue sous le nom d'arborescence de dépendances.
Généralement, les dépendances sont répertoriées dans les fichiers de code source, généralement tout en haut, et chaque fois que le compilateur ou l'interpréteur trouve une dépendance, il la recherche dans un ensemble de répertoires prédéfinis. Étant donné que l'arborescence des dépendances d'un projet peut être très complexe, elle est parfois détaillée dans son intégralité dans un seul fichier au sein d'un projet appelé liste de packages. Par exemple, les projets Ruby peuvent avoir un Gemfile à cet effet, et les projets JavaScript peuvent avoir un fichier package.json. Cela permet à une sorte d'outil connu sous le nom de logiciel de gestion de packages de récupérer toutes les dépendances d'un projet à la fois, à partir d'un ou plusieurs serveurs Internet.
Dans le cas de cette archive, il est probable que les dépendances pour un projet donné existent ailleurs dans l'archive. Afin de trouver une dépendance dans l'archive, il faut d'abord découvrir le nom de la dépendance dans le code source ou la liste des packages, dont les détails exacts varient selon la langue et le framework, puis utiliser l'index maître dans la bobine de guide, ou, en son absence, les index à l'avant de chaque bobine, pour déterminer sur quelle bobine et sur quel (s) châssis le référentiel en question peut être trouvé.
Étant donné que l'exécution d'un programme sur un ordinateur ne nécessite que le code machine compilé, il est possible de le distribuer tout en gardant le code source secret. C'est ce qu'on appelle le modèle source fermée. Au tout début de l'informatique, le code source était généralement distribué avec son code machine, mais par la suite, à mesure que le logiciel devenait une industrie rentable, le modèle de source fermée est devenu plus courant.
On a depuis appris que rendre le code source public, pour quiconque le copie, le branche et l'améliore, est une approche beaucoup plus efficace du développement logiciel. Plus de personnes capables de lire le code source d'un projet signifie plus de personnes pour identifier les besoins possibles et les nouvelles fonctionnalités utiles, plus de personnes qui comprennent suffisamment le projet pour y contribuer, plus de personnes susceptibles de détecter des bogues et de soumettre des correctifs, et plus de personnes à tester et vérifier ce nouveau code fonctionne.
En général, la source fermée conduit à des communautés plus petites, insulaires et fragmentées qui peinent à trouver et à adopter des idées nouvelles et meilleures. L'open source conduit à de grandes communautés interconnectées, chacune aidant les projets de l'autre à grandir, à s'épanouir et à réussir, utilisant le travail de chacun comme dépendances et / ou réutilisant leur code et apprenant les uns des autres. Le logiciel open source est une boîte à outils pour l'utilisation collective de toute l'humanité, et plus nous avons d'outils et de meilleurs outils, plus vite et mieux nous pouvons progresser en tant qu'espèce.