-
S'abonnerAbonnez-vous à nos différents supports -
Magazines à l’unitéCommandez les nouvelles parutions ou complétez votre collection -
Livraison offerte à partir de 50€ d’achat ** Offre valable pour les numéros hors abonnements, livraison en France métropolitaine, appliquée une fois connecté !
- Kiosk OnlineLes magazines 100% online
- Diamond ConnectBase documentaire 100% digitale
GNU/Linux Magazine 265
Compilation, versioning, crossbuild, release et conteneurisation en un seul outil ?
Automatisez la construction et la diffusion du code avec GoReleaser
En savoir plus9,90 € TTC
Anciens Numéros
Bas Niveau
p. 06 SmolBSD : un système UNIX de 7 mégaoctets qui démarre en moins d’une seconde
Autour du Code
p. 18 Le microbenchmark est mort, vive le benchmarking différentiel !
p. 28 En finir avec les Makefiles en Go avec GoReleaser
Sécu & Hack
p. 42 Génération et gestion de certificats avec Erlang/OTP
p. 56 Sysdig et sécurité locale
Scripting Zone
p. 63 Les codes fantastiques : bouturage
IA & Algo
p. 64 PEAC : l’arrière-petit-neveu de Galois et Fibonacci
« Move fast and break things »
Vous avez peut-être déjà entendu cette phrase, ou plutôt cette devise initialement issue de la philosophie des équipes de développement Facebook pré-2014 et flottant de-ci de-là depuis, comme la clé même de la notion d’innovation. Popularisée ces dernières années par quelques réussites grandi-
loquentes comme celles de SpaceX, préférant tester dès que possible et apprendre de ses erreurs (comme avec le lancement de Starship et son « désassemblage non planifié ») que plancher, comme la NASA l’a fait pour Apollo et STS, sur un concept pour ne passer à la pratique qu’une fois tous les problèmes réglés avec une quasi-certitude.
Cette approche est certes intéressante, mais n’est finalement ni récente ni applicable universellement. Nous avons eu dernièrement un aussi triste que parfait exemple des limites, lorsqu’il s’agit de la sécurité des personnes. Je parle, bien entendu, de l’accident du submersible Titan d’OceanGate utilisant cette « philosophie » pour soi-disant innover dans l’utilisation de matériaux composites, pourtant connus pour leur faiblesse en compression, dans les applications sous-marines de grande profondeur (voir à ce propos l’excellente vidéo YT de Real Engineering [1]).
La devise n’est pourtant pas nouvelle, puisqu’il ne s’agit finalement que de la transposition du fameux « Release Early, Release Often » (ou RERO) dont parle Eric S. Raymond dans son essai « The Cathedral and the Bazaar » en 1997 ! Mais RERO ne s’arrête pas à RERO, car l’acronyme, dans le texte original, se poursuit par un très clair « And listen to your customers ».
De manière générale, ce genre de devise, qu’il s’agisse de développement logiciel, de déploiement d’infrastructure, d’innovation technologique, ou encore d’exploration spatiale ou sous-marine ne peut exister, et surtout être appliquée sans se voir dûment complétée par une autre : ne risquez jamais quelque chose que vous n’êtes pas à 100 % prêt à perdre. Et il existe un grand nombre de choses qui devraient normalement automatiquement entrer dans cette catégorie, les vies humaines, la liberté, le droit à la vie privée, l’esprit critique...
Sans cela, la philosophie n’est pas RERO ou MFBT, mais juste YOLO et ça, on sait généralement comment ça finit.
Denis Bodor
Le magazine de référence technique pour les développeurs sur systèmes open source et les ingénieurs R&D !
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...
Quand on travaille avec des langages compilés, construire ou téléverser des artefacts sont des tâches qui peuvent devenir répétitives. On peut automatiser ces tâches avec des outils qui ont fait leurs preuves comme make. Mais il existe un outil qui permet d’automatiser un grand nombre de ces tâches en très peu de temps quand on fait du Golang : GoReleaser. Dans cet article, nous allons expérimenter de manière incrémentale ses fonctionnalités.
Que de racolage en si peu de mots. Et pourtant si, c’est bien la promesse de cet article, comment parvenir à construire un système d’exploitation fonctionnel en moins de… 10 mégabits. Quelle est cette sorcellerie ? En utilisant une fonctionnalité prévue, mais pas utilisée à cet escient par le noyau NetBSD, nous allons lui faire subir un régime drastique !
« L’important ce n’est pas d’avoir raison, mais d’être compris » a dit Dominique de Villepin, un soir à la télé. Je ne suis pas diplomate, mais cet adage s’applique aussi parfaitement dans le domaine des sciences, et surtout des mathématiques et de ses applications, où la vérité absolue nous échappera toujours un peu (merci, Monsieur Gödel) et nos heuristiques comblent les lacunes. Avoir tort est inévitable quand on défriche un sujet totalement nouveau, la compréhension est alors indispensable pour compenser les petites erreurs ou zones d’ombre. Donc, ces derniers mois, je vous ai parlé en détail de checksums [1], de Galois et des corps finis [2] ou de générateurs de nombres pseudo-aléatoires [3] [4], ravivant avec succès une bien vieille série. Tout cela pour établir les bases du présent article, qui synthétise enfin PEAC : un générateur de séquences pseudo-aléatoires (PRNG), dérivé accidentel de la séquence de Fibonacci, aux propriétés fascinantes et aux applications très intéressantes.
