2024-07-21
Internet est un lieu d’échange, mais sa mémoire est volatile. Nous avons tous connu des sites qui disparaissent, des ressources qui deviennent inaccessibles. Personnellement, j’ai perdu tous mes sites web avant ce blog. J’ai perdu tout ce que j’ai posté sur les réseaux sociaux, particulièrement Google+ où j’étais très actif.
Cela m’a servi de leçon. La simplification à outrance de ce blog est une manière pour moi de le pérenniser.
La fin d’un blog et la dernière version de ploum.net (ploum.net)
Tout le monde ne pense pas comme moi ou ne réalise pas l’importance de l’archivage.
Toutes les archives du site de MTV, la chaine télé musicale qui a marqué ma génération, viennent d’être irrémédiablement effacées.
Cela va continuer. Avec le Web en 91 puis les smartphones en 2007, Internet s’est complètement insinué dans la société et la vie de tous les humains. Mais c’est très récent. Tellement récent que nous n’avons aucun recul sur ce que cela signifie sur le long terme.
Rappelons que les protocoles à la base d’Internet ont été conçus en imaginant que le stockage serait cher, mais que la bande passante serait bon marché. Internet est donc un réseau de routage de paquets sans aucune capacité de mémoire. Mémoriser ne fait pas partie de sa structure intrinsèque. Le réseau est conçu pour échanger et oublier.
Ironiquement, l’inverse s’est passé : le stockage est devenu meilleur marché que la bande passante. Mais la technologie ne s’est pas adaptée. Les humains non plus. Nous échangeons à toute vitesse des informations que nous oublions tout aussi vite.
Il n’y a, à ce jour, qu’une seule technologie qui a fait ses preuves pour nous souvenir et améliorer notre mémoire collective dans la durée : l’écriture. Les livres. Les livres qui, à l’exception d’incendies dramatiques, résistent aux millénaires, aux multiples lectures, aux annotations, à l’écorchage de leurs pages.
Internet et les livres resteront toujours complémentaires. Le premier pour nous mettre en contact et nous permettre d’échanger en temps réel. Les seconds pour nous permettre de nous souvenir et d’échanger à travers les années et les siècles.
Sur Internet, on passe son temps à réinventer la roue alors que la solution existe probablement. D’où cette question provocante, mais incroyablement pertinente : pourquoi ne pas utiliser SSH pour tout ?
Why aren’t we using SSH for everything? (shazow.net)
Exemple avec un chat qui enfonce les Slack et autres Teams tout en ne nécessitant rien d’autre qu’un client ssh.
quackduck/devzat: The devs are over here at devzat, chat over SSH! (github.com)
SSH all the things!
On me rétorquera que c’est plus compliqué. Je réponds que pas du tout. Il faut juste apprendre tout comme nous avons appris à cliquer sur des liens. Il faut arrêter de prendre les utilisateurs pour des nuls et expliquer des choses qui pourront leur servir toute leur vie.
Une fois le principe de base d���une ligne de commande compris, un ordinateur devient une machine incroyable qui obéit aux ordres qu’on lui donne et non plus une boîte noire magique dont il faut deviner ce qu’elle veut qu’on fasse. La ligne de commande contrôle l’ordinateur là où le GUI contrôle l’utilisateur.
Retenir une ligne de commande est très simple : il suffit de l’écrire quelque part. Par exemple dans un livre. Retenir une action à accomplir dans une interface graphique est très difficile. De toute façon, elle change tout le temps.
Autre point sous-estimé : une ligne de commande se partage très simplement. La ligne de commande est, par essence, sociale. Le GUI est solitaire. Comme cette fois où j’ai tenté, par téléphone, d’aider ma mère à installer un logiciel sous Ubuntu. Comme je n’arrivais pas à lui dire où cliquer, j’ai fini par lui faire lancer un terminal et lui dicter la commande. Ça a fonctionné du premier coup (j’ai juste dû lui prévenir que c’était normal que son mot de passe ne s’affiche pas, qu’il fallait le taper à l’aveugle).
GUIs are Antisocial (mtlynch.io)
Dans un billet précédent, j’explique que contribuer à l’open source doit être vu comme une contribution aux communs et, de ce fait, il faut favoriser les licences Copyleft qui imposent de reverser aux communs toute modification/contribution ultérieure.
On Open Source and the Sustainability of the Commons (ploum.net)
Ces 20 dernières années sont une leçon que si l’Open Source a gagné, c’est essentiellement parce que les grosses entreprises utilisent l’Open Source comme un gigantesque réservoir de main-d’œuvre gratuit. Elles vont même jusqu’à se plaindre quand un logiciel casse leur produit alors même qu’elles n’ont jamais acheté ce logiciel ni contribué.
Thomas Depierre pointe l’erreur de logique: les entreprises parlent de « Supply Chain » (chaine des fournisseurs), mais lorsqu’on écrit du code Open Source, on n’est pas un fournisseur. Et on n’a pas spécialement envie de le devenir. Un truc que les entreprises ont du mal à comprendre « Si on a ce code dans notre produit, il provient soit de chez nous, soit d’un fournisseur, non ? ». Et bien non.
I am not a supplier (www.softwaremaxims.com)
The software supply chain is something they've done to themselves (njms.ca)
La meilleure solution est pour moi d’utiliser des licences copyleft et, plus spécifiquement la licence AGPL qui impose le copyleft y compris pour les utilisateurs réseau. En clair, s’il est prouvé que Google utilise du code copyleft dans son moteur de recherche, n’importe quel utilisateur a le droit dé réclamer le code de tout le moteur Google.
Inutile de dire que les entreprises sont terrifiées à cette idée et qu’elles fuient le code GPL/AGPL comme la peste. C’est la raison pour laquelle le noyau Linux, sous GPL, est complètement isolé du reste du système dans Android. À part Linux, Apple, Google et Microsoft considèrent le GPL comme un véritable cancer. Les serveurs Netflix ou la PlayStation Sony sont sous FreeBSD par crainte de la GPL. macOS se base également sur BSD en évitant le monde Linux par peur d’être contaminé à la GPL.
Ils ont tellement peur qu’ils accusent les licences copyleft d’être « restrictives ». Non. La seule restriction que vous impose le copyleft, c’est de vous interdire d’ajouter des restrictions à vos utilisateurs. Il est interdit d’interdire.
Copyleft licenses are not “restrictive” (drewdevault.com)
Alors, oui, au plus il y aura du code sous licence AGPL, au moins les entreprises considéreront les développeurs open source comme des fournisseurs. Plus il y aura de code sous licence copyleft, plus large sera notre mémoire commune numérique.
TL;DR: release your code under the AGPL
Bon, après, je dis AGPL, mais je suis seulement en train de découvrir qu’en droit européen, il est bien possible que l’EUPL soit préférable. Mais, dans l’esprit, les deux sont équivalentes.
How does FSF considers EUPL? (joinup.ec.europa.eu)
----
Email:
permalinks: