Ce blog a pour objectif de présenter, de manière simple et concise, différents concepts liés au monde associatif, ainsi que des techniques et notions informatiques.
Les articles sont volontairement courts afin de proposer une lecture rapide et accessible, tout en allant à l’essentiel.
Si vous souhaitez voir un concept particulier abordé sur le blog, n’hésitez pas à me contacter à l’adresse suivante : contact@ethiciel.org.
Linux repose largement sur un modèle permissif : un processus autorisé peut
lancer d’autres binaires via execve, root conserve un accès étendu
aux secrets en mémoire, et les sockets Unix restent surtout privés aux processus.
SELinux, AppArmor, namespaces et conteneurs réduisent ces risques, mais au prix d’une configuration complexe. D’où l’idée d’un Linux « restrictif par défaut » : exécution sur des ressources en liste blanche, secrets extractibles uniquement par le processus qui les utilise (et non par les utilisateurs), communication entre processus isolés et privés.
L’atomicité des opérations de transfert de fichiers, notamment via mv/rename
ou un cp dans un répertoire temporaire suivi d’un renommage
atomique,
facilite le retour en arrière : une modification est appliquée entièrement
ou pas du tout. Ce retour en arrière après un ctrl-break par exemple ne peut pas s’appliquer
de façon atomique si l’opération traverse plusieurs filesystems.
Il ne doit donc pas y avoir de point de montage
sur /usr ou /etc, et /tmp doit appartenir à la partition
root. Une partition /home peut toutefois contenir /home/tmp.
Et si votre shell ne se contentait plus d’exécuter des commandes, mais aidait à les comprendre avant validation ?
L’idée : décrire chaque commande par une grammaire et proposer une auto-completion sur les arguments avec aide contextuelle sur leur utilisatinn ou accès au man grâce à la touche <TAB>, proposer une complétion contextuelle navigable, filtrer fichiers wildcardés (en sélecitonnant ceux que l'on veut vraiment dans la ligne de commande), sélectionner le <PID>, <UID> ou <GID> ou <DEV> après une option qui nécessite un PID, UID ou GID, ou devices selon les droits, explorer le filesystem quand l'option attend <FILE> | <DIR>, rechercher l’historique par regexp et construire un AST sémantique pour évaluer par sa résolution l'acceptabilité de l'opération selon le mode activé (défensif ou non défensif).
Un mode défensif pourrait alors simuler cp, mv ou rm, estimer espace et atomicité, détecter les risques et proposer retour en arrière, corbeille ou transaction avant exécution.
Et si l’email redevenait local ?
Ce projet imagine une messagerie où les fournisseurs d'emails ne servent plus qu’au transport. Les messages sont récupérés, chiffrés, stockés, signés et répliqués sur les appareils de l’utilisateur grâce par exemple à des serveurs sftp.
L’antispam repose sur une confiance mutuelle via invitations mutuelle signées. Le POC « termail » testerait SMTP/POP3, stockage .eml, chiffrement et synchronisation, avant la création d'un webmail et un sysmail (avec toolkit graphique).
VTTK (View & Terminal ToolKit) propose un raisonnement méta ou des algorithmes aux propriétés connexes pour tous les types et tailles d'écran capables d’adapter automatiquement une application GTK, Qt ou Slint au terminal, au type et à la taille d’écran disponible, sans modifier son API et ainsi, si possible, maintenir la compatibilité ABI avec les versions Gtk, QT et Slint actuelles.
Un moteur de règles choisit la représentation adaptée : native, Web, texte ou embarquée. L’objectif : déplacer le design adaptatif au niveau système tout en conservant les API historiques.
Au lieu de concevoir de bas en haut, on part du haut (écran aillant la plus grande taille) jusqu'en bas. En d'autres termes, ce n'est pas une question de taille d'écran mais une question de présentation de la saisie des informations pour la plupart des composants graphiques de saisie ou d'affichage. Ce que l'on peut saisir sur un grand écran pour les composants graphiques standards peut l'être également sur un petit écran en une ou plusieurs étapes car, généralement, il a des dimensions aujourd'hui assez acceptables pour les ordiphone qui ont quelques années. Sinon on parle de système mebarqué.
Deux fonctions pourraient enrichir les applications Linux, qu’elles soient en terminal, graphiques ou Web. Une barre de statut diffuserait des annonces fédérées de 255 caractères : messages système, mises à jour, informations d’applications ou annonces choisies par l’utilisateur, avec lien court et possibilité de financement du système, des applications par les utilisateurs ou de la part des annonceurs.
Un shell en langage naturel, propre à chaque application et optionnel, permettrait aussi de lancer simplement des commandes applicative adaptées à son contexte. Un nouveau lex & yacc serait développé pour simplifier la lecture du langage naturel avec possiblement une lecture de grammaire basée sur BNF qui génèrerait un arbre AST adaptée aux besoins de l'application.
À l’image d’OLE sous Windows, Linux pourrait iémplémenter et adopter LinkLive : un mécanisme reliant chaque type MIME à un composant fourni par l’application spécialisée. Un document pourrait ainsi intégrer une image, une vidéo, un audio, un texte, un doucment ou un tableur, éditable sur place ou via un bouton ouvrant l’outil associé. Les dépendances seraient déclarées au système. Résultat : code réutilisé, logiciels spécialisés et efforts concentrés sur moins de projets, à condition d’une gouvernance commune et adaptée.
Linux permet de créer des fichiers contenant des systèmes de fichiers, avec une taille physique parfois inférieure à leur taille virtuelle. L'image fichier contenant un système de fichiers serait un classique : /etc, /usr, /var, /var/data, /tmp possiblement sur le même système. Une application et ses données dans un seul espace utilisateur deviendraient alors un objet portable unique, déplaçable d’un disque local ou réseau à un autre par un simple mv ou cp d'un seul fichier.
Il pourrait même devenir multiplateformes grâce à l'utilisation de Podman qui permettrait de conteneuriser l'application sous Linux ou de la démarrer dans une VM sous MacOS et Windows.
Grâce à l'utilisation d'un ISO Live Linux sur une clé USB, on pourrait obtenir une application portable en quelques minutes sous contraintes de pouvoir démarrer un système OS externe (sur clé USB) sur l'ordinateur cible. Cela demande aujourd'hui l'accès à l'interface de paramétrage de la machine. Il faut généralement quelques connaissances techniques pour y arriver.
Un shell en dessous de la barre de manu en langage naturel pourrait devenir une interface universelle pour piloter les applications. Chaque logiciel exposerait son état et ses fonctions sous forme d’actions, getters, setters et structures de contrôle, décrites par une grammaire extensible qui, une fois parsée, génèrerait un arbre AST sémantique.
Des plugins validés par la gouvernance du projet ajouteraient actions, transformations, menus, suite de tests, suite de performance et traitements batch. Les commandes seraient traduites en AST puis en Python avec import API lib C applicative et interprété ou C et compilé, afin d’automatiser des workflows, partager des macros et créer des standards ouverts entre applications.
Enfin, le système shell pourrait être la somme de toutes les extensions applicatives et pourrait permettre d'exécuter des choses du genre :
kdenlive( fais-moi un short à partir du projet toto pour Pixelfed et téléverse-le sur mon compte laurent )
Pour sécuriser Linux, la conteneurisation seule ne suffit pas : il faudrait cumuler plusieurs couches d’isolation. Chaque application ou démon exposé à Internet pourrait fonctionner sous un compte utilisateur distinct, éventuellement dans un conteneur OCI ou autre, sans accès à sudo. Wayland pourrait rendre cette séparation transparente grâce à un agent gérant presse-papiers et transferts de fichiers. Reste à évaluer le coût en ressources physiques et la complexité d’une telle architecture pour l'utilisateur et pour la maintenance.
Reprenons l'architecture bien connu des années 2000 avec Front <-> Middle <-> Back Office. Ce modèle peut définir les trois couches communiquantes comme locales, distantes ou hybrides (2 couches locales et une couche distante).
Imaginez la création d'une application qui commence par le choix de légos techniques que l'on assemble au sein d'un socle technique fournissant un ensemble de possibilités appelé Corpus à une équipe métier.
L'équipe métier développe des règles de gestion spécifiques à son institution en utilisant un langage proche du langage naturel local ignorant tous les aspects techniques gérées par les spécifications techniques.
Enfin une équipe UI rédige les règles SUSI (Semantic Unified Screen Interface) qui sont génériques à tous les écrans existants 2D (voir 3D) ou SUIX (Semantic Unified Interface Exchange) pour une interface par étape comme par audio/téléphone, braille/clavier braille, caméra/langage des signes ou pilotage corporelle, vidéo/clavier+souris. Un moteur de rendu adptatif sera développé pour SUSI implémentant chaque type de terminal et de même pour SUIX pour chaque type d'interactions.
Derrière ces spécifications, un modèle MVC (Modèle Vue Contrôleur). Le Modèle est une arbre AST, La vue sémantique est un arbre AST qui vérifie les règles de surface et certaines règles inter-champs, le contrôleur se charge des vérificaitons de surface, de l'application des règles de gestion, des transitions d'états métier et de la restitution de l'arbre AST du modèle dans le nouvel état méter.
Enfin et c'est là que c'est le plus beau, toutes ces spécifications génère une application complète en langage machine à partir d'un code généré par le compilateur oapp (Open Application) dans un langage de bas niveau compatible (C, Rust etc.).
Est-ce difficile de nos jours d'avoir un installateur avec zoom intégré (pour les malvoyants) ou d'avoir un lecteur d'écran (TTS) ou d'avoir un clavier virtuel à utiliser à la souris ou sur écran tactile, voir dans le meilleur des cas, de disposer de la reconnaissance vocale lors de l'installation de Linux ?
Non ? Linux est réservé aux geeks en bonne santé malheureusement encore aujourd'hui ?
Et si on changeait ça ? Sérieusement ! J'ai des exemples dans mon entourage de personne ayant besoin de logiciels accéssibles, homogènes (pourquoi réapprendre tous les raccourcis clavier à chaque fois qu'on change de logiciel ou d'environnement etc. Et simple à utiliser, ce n'est peut-être pas votre cas ?
Les idées n'ont d'impacts que si il y a des personnes pour se lancer dans leur réalisation. N'hésitez pas à me contacter si cette prose vous interpèle.
La norme AT-SPI2 (Assistive Technology Service Provider Interface) cherche à fournir une interface commune entre les applications et les technologies d’assistance.
Un système d’exploitation doit s’adapter à chacun, et non l’inverse. Il doit rester utilisable par les personnes malvoyantes, aveugles, âgées ou en situation de handicap, grâce au zoom, à la voix, au braille et à des commandes simples. L’accessibilité doit être disponible partout, à tout moment, et devenir un principe de base pour rendre l’informatique réellement universelle.
Aujourd’hui, cet objectif est encore loin d’être atteint. Les paramètres d’accessibilité eux-mêmes sont parfois écrits trop petits et sont difficiles à agrandir et, sans paramétrage préalable, on ne pas être autonome. Il n'y pas à ma connaissance un raccourci clavier pour le menu accéssibilité notamment sur clavier AZERTY. Beaucoup d’informations affichées ne peuvent pas être copiées. Par exemple, la taille d’un dossier sous Gnome/Gtk peut rester inutilisable : trop petite à lire et impossible à zoomer facilement avec CTR++ ou CTRL+- ou CTRL molette et à copier/coller dans un mail, un document etc.
Les technologies autour du TTS et la reconnaissance vocale n'ont peut-être pas beaucoup évolué dans les logiciels libres alors que les géants américains ont tous des voix de plus en plus proche de voix naturelles. Serait-ce vraiment compliqué de proposer aujourd'hui des voix TTS dérivé de notre propre voix ? Ou une reconnaissance vocale adaptée uniquement à notre voix ? Avec les outils d'aujourd'hui j'ai l'intuition que cette approche est sûrement possible.
Les images OCI peuvent embarquer des dépendances, fichiers et droits inutiles, augmentant la surface d’attaque. L’objectif est de réduire ces ressources au strict nécessaire et de sécuriser l’exécution avec Podman rootless et systemd.
Développer en C sous Linux :
But final : construire une chaîne permettant de connaître, déclarer, vérifier et limiter les ressources réellement nécessaires à une application Linux et idnentifier les limites de ces approches.