Termes expliqués n°2 : Les acronymes « logiciels »

closeCet article a été publié il y a 8 ans 8 mois 27 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Cet article vous parlera encore plus que celui sur le matériel, notamment avec l’omniprésence d’Internet et plus largement des réseaux informatiques (rappel – votre machinbox et ce qui est raccordé dessus constitue un réseau), qui fonctionne de la même manière quelque soit l’appareil raccordé à ceux-ci. On parlera beaucoup de protocoles, mais pas seulement.

HTML

Souvent rencontré sous la forme récente HTML5, c’est un langage de « programmation » permettant l’écriture de pages Web. C’est un langage dit descriptif, ayant recours à des balises, en ce sens qu’il définit le « sens » des différents éléments de texte. Pas exemple, pour afficher coucou, la page utilise la « formule » suivante : <strong>coucou</strong>, avec une balise d’ouverture et de fermeture (identique, sauf le / de fin), qui indique au navigateur d’afficher le texte en gras. Certaines balises sont juste là pour dire que le texte tient dans un même paragraphe, d’autres sont ajoutées pour, plus tard, appliquer plusieurs règles de styles, grâce à un mécanisme qu’on va voir juste après.

Pour info, ce bon vieux HTML a été créé il y a 25 ans, par Tim Berners Lee, qui a ensuite monté le W3C, pour être sûr que tous les acteurs du Web suivent une même vision (c’est pas toujours le cas, malheureusement). L’un des plus fervents défenseurs d’un Web propre, ouvert, est, comme par hasard, Mozilla. Vous comprenez maintenant pourquoi je les aime ?

CSS

Cascading StyleSheet. Avant de parler de cette propriété de cascade (quel rapport avec l’eau me direz-vous ?), on va parler de feuille de style. Aux origines du langage HTML, tout ce qui permettait de définir la forme du texte, sa position, sa taille, sa police, se faisait directement au sein du code de la page, ce qui la rendait peu lisible, et de plus en plus difficile à maintenir à mesure que les pages se sont alourdies (pas que pour le texte, pour tout le contenu en fait). On a donc décidé de définir un système de classes, dont les règles sont définies dans un ou plusieurs fichiers à part, les feuilles de style.

Du coup, dans le code de la page ne restent plus que le contenu et des références au style à appliquer. Plutôt que de dire directement dans la page que le paragraphe devra être écrit en police Comic Sans, taille 24, italique, bleu turquoise, justifié, on indique juste que le paragraphe devra appliquer la classe « mauvaisGout », qu’on retrouvera dans le fichier annexe avec l’ensemble de ces règles. Avantage, ça permet de n’avoir qu’une seule règle qu’on peut appliquer à plusieurs endroits différents du texte, notamment s’ils ne sont pas l’un à côté de l’autre.

image code html/html+css

Le principe de cascade, c’est qu’on peut avoir, pour différentes raisons, besoin de définir successivement plusieurs classes, ou de n’avoir besoin de modifier qu’une seule partie des propriétés d’une classe. Dans ce cas, on définit une autre classe dans laquelle on n’inscrit que les modifications, ensuite on appelle les deux classes en même temps, dans l’ordre, pour que la deuxième écrase les paramètres modifiés de la première.

JavaScript

C’est bien beau, mais toute cette débauche de technologie amène au même constat : le code est majoritairement fixe, et son contenu aussi. Pour le manipuler sans avoir à recharger toute la page à chaque fois, on a créé un langage de script. Sa gestation a été douloureuse, notamment parce qu’à ses débuts, chaque éditeur de navigateur n’en faisait qu’à sa tête, ajoutant des fonctions qui n’existaient pas chez les autres, ou adoptant un comportement différent pour une même fonction. On comprend d’autant mieux avec le JavaScript l’intérêt du W3C dans la standardisation du système.

JavaScript est capable de manipuler en direct à peu près tous les éléments d’une page Web en temps réel. C’est grâce à lui par exemple que Google Maps va chercher les morceaux de cartes quand vous vous déplacez dessus ou zoomez, que Facebook et Twitter vont chercher les articles plus anciens à mesure que vous faites défiler la page…

API

J’y ai fait moi-même référence dans mon prototype pour collect, mais essayons d’être plus abordable. Application Programming Interface, soit interface de programmation pour applications. Dans le cadre du Web, on utilise une API pour qu’un programme externe accède à des données ou certaines commandes d’un service, sans avoir à lui donner toutes les clés. Ainsi, si plusieurs programmes savent afficher vos flux Twitter, aucun n’a accès aux rouages internes du réseau social, qui reste sous son entier contrôle. J’utilise l’API Yahoo Météo pour afficher les prévisions dans Domohouse, mais je n’ai pas accès direct aux données ni aux méthodes de récoltes ou de prévision de Yahoo.

L’avantage, c’est que la communication est réduite à son strict minimum, réduisant les besoins de bande passante, et surtout, il est possible à une application ou une page Web (au travers du JavaScript), de se mettre à jour en temps réel sans avoir à afficher une horrible page blanche à chaque clic. Récemment, l’actualité la plus visible autour des APIs est celle de YouTube, qui a lancé une nouvelle version, incompatible avec l’ancienne, qui était utilisée par nombre d’appareils comme des téléviseurs, mais aussi certains lecteurs multimédias (ça a été le cas de la Freebox Revolution), qui doivent alors mettre à jour leur application pour continuer à pouvoir proposer les vidéos directement sur la TV.

Bref, c’est à la mode, parce que ça évite d’avoir à montrer comment on lave le linge sale, et de présenter un truc tout beau, souvent « gratuit », faussement ouvert, pour avoir l’air cool (t’imagine, les mecs, on a accès à ce qui les fait vivre). Sans discuter de l’éthique, il est vrai par contre que ça permet l’émergence d’une quantité de services tiers, qui peuvent être diablement pratiques quand on croise plusieurs sources de données.

HTTP(S)

Là on rentre dans l’un peu poilu, mais après tout, vous le croisez tous les jours dans les adresses web (http://blabla ou https://secureblabla). C’est le protocole utilisé par les serveurs Web et les navigateurs pour que les premiers servent les contenus aux seconds. Sans rentrer dans le détail, le navigateur demande une page, le serveur cherche s’il l’a, si c’est le cas, soit il l’envoie (dans le cadre d’une page toute faite), soit il demande à la faire construire (dans le cadre d’une page dite dynamique), puis envoie le résultat. Pareil pour les images, et tout ce qui peut être demandé avec une adresse. La communication se fait aussi dans l’autre sens, quand on remplit un formulaire par exemple : le navigateur envoie le formulaire et ses données au serveur, qui les donne aux scripts de traitement (stockage dans la base de données, ou vérification d’identité dans le cadre d’un « login »).

La version HTTPS n’est qu’une évolution destinée à chiffrer la communication entre le navigateur et le serveur. En effet, par défaut tout transite en clair avec HTTP, et un individu malintentionné peut afficher directement tout ce qui passe entre les deux (dernièrement, c’est notre gouvernement qui cherche à s’arroger ce « droit »). On a donc créé l’HTTPS pour ajouter une bonne dose de sécurité, parce qu’on imagine pas entrer notre numéro de carte bleue devant le monde entier lorsqu’on achète le dernier sex-toy à la mode sur lequel on craque.

URL

Pierre angulaire du protocole HTTP, l’Uniform Resource Locator. C’est l’adresse d’une page, d’un contenu, celle qui commence par http://… La particularité d’une URL, c’est qu’elle est censée être unique : elle ne point que vers un contenu, et un seul. Dans la pratique c’est un poil différent maintenant, mais à ses débuts c’était vraiment le cas. Et en même temps, HTTP et HTML ont été d’abord conçus pour faciliter le partage de documents sur le réseau, il fallait donc bien que ça pointe sur les bons « dossiers » sans ambiguïté.

Dans la pratique, une URL peut désigner d’autres protocoles qu’HTTP. Dans ce cas, elles commenceront par d’autres lettres, comme ftp://, magnet:, mailto:…

DLL

Quittons un peu le monde du Web. Exclusif au monde Windows, les Dynamically Linked Libraries sont des collections de fonctions partagées/partageables entre plusieurs applications, pour ne pas avoir à réinventer la roue à chaque programme. C’est souvent quand il en manque une à un programme que vous rencontrerez ce terme. Les distributions Linux ont tendance à fortement user du concept, ce qui permet bien souvent d’avoir un système plus « léger » sur le disque. L’avantage le plus évident, en dehors de la taille, c’est la sécurité : mettez un composant à jour, et tous les programmes se reposant dessus seront d’un seul coup protégés d’une faille bouchée, ou d’un bug corrigé.

Un exemple ? Sur ma machine, j’utilise les logiciels VLC et 3ncode (découvert grâce à La Vache Libre), qui reposent tout deux sur les composants du projet ffmpeg, qui n’est donc installé qu’une seule fois. Quand celui-ci est mis à jour (au hasard, pour supporter x265, la version open-source du HEVC, codec utilisé pour la 4k), les deux logiciels en profitent tout de suite. D’ailleurs c’est aussi ffmpeg que j’ai mis à contribution dans mon script de conversion FLAC vers MP3 pour sa version Linux.

Fichier d’échange (ou swap)

Ce fichier, en théorie, doit servir à délester la mémoire vive de votre ordinateur des vieilles données sans les supprimer pour autant quand cette mémoire vive est saturée par trop de programmes gourmands. Dans la pratique, Windows réussit le tour de force d’exploiter le fichier d’échange dès le démarrage, et ce même si vous disposez d’une quantité plus que confortable (supérieure à 4Go). Même sans programme additionnel qui se lancerait automatiquement. Sous Linux, vous pouvez réglez la sensibilité du basculement des vieilles données avec quelques manipulations simples.

BIOS/UEFI

Comme c’est avant tout du logiciel, je le met ici, mais ça aurait pu être traité dans les acronymes matériels. Le Basic Input Output System est un micrologiciel qui s’exécute à l’allumage de votre ordinateur. Il est chargé de détecter les principaux composants, et de les déclarer pour le système d’exploitation, afin qu’il sache en tirer parti (allocation de ressources, zones mémoire d’accès, périphériques de stockage…). C’est aussi par lui qu’on peut prérégler l’horloge de la machine, choisir sur quel périphérique démarrer, et d’autres choses. Il permet aussi dans une certaine mesure de diagnostiquer des défauts matériels, quand ce n’est pas la carte mère sur laquelle il est installé qui est en défaut. N’avez-vous jamais eu une machine qui « bippait » en boucle sans démarrer proprement ? C’est de sa faute.

l’Unified Extensible Firmware Interface a été conçu pour remplacer le BIOS, historiquement limité dans ses capacités et son interaction avec l’utilisateur. Comme tout a évolué, il nécessite un système d’exploitation récent qui sait s’en accommoder. Si Windows s’en charge depuis Vista SP1,  pour Linux, c’est un poil plus compliqué, mais grosso modo depuis 2006 (en pratique, certaines distributions ont encore un peu de retard, parce qu’elles utilisent un chargeur de démarrage trop ancien, ou un noyau trop vieux, avant le 3.3, ce qui est le cas de Debian Wheezy, encore en service sur pas mal de serveurs). Mais le rôle général reste le même : préparer et tester le matériel avant le lancement de l’OS. Mais il apporte quelques améliorations nécessaires pour les machines récentes : support des disques durs de plus de 2To, le tendancieux Secure Boot…

À noter que l’UEFI est majoritairement utilisé sur les plate-formes PCs « standards » (les Mac en sont depuis leur passage à des CPU Intel). Les plate-formes ARM (nos smartphones, tablettes, Raspberry Pi), ne disposent pas de BIOS ou d’UEFI, et chargent directement le système d’exploitation, qui doit impérativement contenir de quoi exploiter le matériel.

Secure Boot

Parlons-en du démarrage sécurisé. Certes, la plupart des utilisateurs de Windows n’ont généralement pas besoin de s’en soucier, et pour cause : il ne fonctionne bien qu’avec Microsoft, à cause des fabricants de matériel. Cette fonction permet de « valider » le démarrage du système d’exploitation, qui doit être signé avec une clé stockée dans la mémoire de l’UEFI. Problème, les fabricants de matériel n’acceptent de clés de signatures que de la part de Microsoft, excluant de facto tout système alternatif, distributions Linux en tête. Une violation manifeste de neutralité matérielle (ce n’est pas à lui de se soucier de ce qu’il exécute).

Fort heureusement normalement la fonction DOIT être désactivable dans la configuration de l’UEFI, mais ce n’est pas toujours le cas. Pour pallier ce problème, Red Hat a signé un pacte avec le diable : disposer d’un chargeur de démarrage signé par Microsoft (entre grosses entreprises, on se comprend). Et certains ont eu le droit de reprendre cette signature maudite à leur tour dans leurs distributions. Avec l’épée de Damoclès de Microsoft au dessus de la tête, qui pourrait décider du jour au lendemain que la signature n’est plus valide, et les toutous fabricants suivront.

Ça part pourtant d’une bonne idée : pouvoir éviter que des programmes malveillants de haute tenue ne s’exécutent avant le système d’exploitation ou pendant son démarrage, lorsqu’ils peuvent disposer de tous les droits possibles et imaginables (et l’histoire informatique est truffée de saloperies de ce genre). Dans la pratique, les fabricants de matériel n’ont pas joué le jeu de l’ouverture (de toute façon, aucun code source d’UEFI ou de BIOS n’a jamais été publié, et la plupart ont toujours été pétés de bugs). Donc dès qu’on peut le désactiver, on le fait. Et tant pis pour la sécurité de base, fallait pas merder dans l’implémentation.


J’ai volontairement esquivé tout ce qui avait trait à l’audio ou la vidéo, puisque ça fera l’objet d’un article « multimédia » dédié. Mais avant ça, on fera un détour par un autre aspect du logiciel, suffisamment gros pour être traité à part : les licences. Oui, ça fait donc encore au moins deux épisodes 🙂