HubTou a écrit 29 commentaires

Bonjour,

Alternatives à netlib.re
J’ai vu de nombreux sites proposant des services autour du DNS. Pour citer quelques exemples :
[…]
eu.org n’est pas pour des novices, et visiblement tout est géré à la main sans interface pour s’inscrire… difficile de faire plus éloigné des objectifs de netlib.re ;
[…]
Ces services sont sans doute très bien. J’envie même certaines de leurs fonctionnalités, que j’implémenterai peut-être plus tard pour netlibre. Mais il manque systématiquement le code source, ou l’interface n’est pas faite pour un novice, ou le service ne propose pas tout à fait les mêmes fonctionnalités.

Pour eu.org, l'ancêtre de gandi.net :
- L'interface me semble assez simple, mais pour celui qui ne connaît pas le fonctionnement du DNS ou qui ne dispose pas de l'infrastructure nécessaire c'est peut-être un peu compliqué en effet
- tout est automatisé mais la validation ultime repose sur 1 personne, et le site croule sous les demandes de spammeurs (plus de 100 000 la dernière fois qu'on en a discuté)
- L'interface pour s'inscrire est là : https://nic.eu.org/arf/fr/login/?next=/arf/fr/
- Le code source est là : https://github.com/pbeyssac/autoreg
- Et, last but not least, contrairement à netlib.re, eu.org n'est pas bloqué par le Zscaler de ma boîte :-)

Personnellement, j'en suis fan !

Bien cordialement,

Je ne vois pas trop en quoi développer une distribution Linux de plus contribuerait véritablement à la souveraineté numérique européenne. Et, quand bien même ce serait le cas, je ne pense pas non plus que ce serait l'action la plus pertinente à engager pour atteindre ce but !

Mais d'abord qu'est-ce que la souveraineté numérique et où est-ce qu'elle est mise en danger ?

Je pense que cela se joue principalement sur notre continuité d'activité, sur la sécurisation de nos informations et sur la maîtrise de nos coûts de fonctionnement.

Parmi quelques exemples récents d'atteintes à la souveraineté numérique, on peut citer :
- l'embargo sur la fourniture de certains composants électroniques, de logiciels ou de services informatiques à la Russie (par exemple dans le cadre du 14ème paquet de sanctions)
- l'embargo sur la fourniture de certains processeurs à la Chine ou sur l'utilisation d'Android par Huawei, qui a du coup développé son alternative HarmonyOS,
- l'impôt de 15 milliards levé par Broadcom sur les entreprises européennes utilisatrices de VMware.

Sur la non continuité d'activité, l'Europe représente un tel marché pour les logiciels américains que jamais ils ne nous bloqueront l'accès à leurs logiciels.
Même sur un coup de folie dont leur prochain président est coutumier…
Par contre, ils pourraient en augmenter le prix, comme ça a été le cas avec Broadcom, ou plus vraisemblablement l'Europe pourrait taxer plus fortement ces importations en rétorsion d'augmentations des droits de douane sur nos exportations.
Dans les deux cas, cela pousserait au développement d'offres locales et ils auraient plus à y perdre que nous.

Le sujet est plutôt sécuritaire, avec la possibilité d'envoi de mises à jour pouvant exfiltrer certaines données sensibles de nos systèmes ou y inclure des portes dérobées au profit de compétiteurs américains.
Pour contrer cela, il ne suffirait pas de produire une distribution européenne de Linux, mais il faudrait vérifier toutes les modifications upstream sur le noyau, les logiciels agrégés à la distribution retenue et un très grand nombre de solutions tierces.
Vaste programme, comme aurait pu le dire le Général de Gaulle !
Je crois toutefois qu'un effort Européen sur la vérification des algorithmes de chiffrement serait utile.

Reste l'enjeu économique, où là, sans hésitation, l'Etat français et ses homologues européens ont tout intérêt à se détourner autant que possible des logiciels propriétaires, ce qui n'implique pas pour autant de développer une nouvelle distribution Linux.
Car la question porte essentiellement sur les applications.

Et puis, au fond, est-ce que le système d'exploitation du poste de travail est encore le sujet ?
On est quand même entrés depuis plusieurs années dans une ère où on ne fait plus tourner grand chose sur ces postes.
La plupart des applications sont désormais hébergées dans des datacenters privés ou publics, et ce n'est pas l'offre qui manque en Europe, même si, fonctionnellement, nos offreurs sont un peu en retard technologique sur les 3 grands hyperscalers américains.

Les distributions Linux européennes ont l'air d'avoir toutes mis la clé sous la porte. Le français Mandrake/Mandriva, comme l'allemand SUSE. Faut-il en faire une nouvelle ?

Le moteur de recherche européen, Qwant, fonctionne aujourd'hui sur des technologies US.

Les initiatives sur le cloud, Cloudwatt, Numergy, CompatibleOne, ont toutes capotées. Et bientôt Gaia-X, noyauté par des offreurs américains ?

Les virtualiseurs européens, Xen et VirtualBox, sont tous passés sous pavillon US.

Je n'ai pas trop le temps de développer tout ça ce soir, mais il est clair que le sujet de la souveraineté numérique est bien plus complexe que de simplement relancer une nouvelle distribution Linux européenne.

A la place, je regarderais plutôt du côté de la protection de nos jeunes pousses innovantes (et donc du développement d'un capital risque européen digne de ce nom), du côté de la rétention de notre matière grise (nos ingénieurs qui vont chercher fortune outre-Atlantique), etc.

Ah Minetest! […] Même s'il est moins riche que son inspiration commerciale, il est quand même beau, bien fichu et adictif.

Avec le jeu VoxeLibre, je trouve qu'on est sur un clone quasi parfait de Minecraft. Je viens d'y jouer et je trouve les progrès immenses depuis mon précédent essai de Minetest (et manifestement aussi depuis la précédente dépêche sur LinuxFr). En fait, je n'ai pas vraiment vu de différences entre les deux !

Et question modding, je trouve cela bien mieux documenté que sur l'original. L'API est claire et il y a d'excellents tutoriels. La mise en place d'un environnement de dev en Lua est aussi considérablement plus simple que ce qu'il fallait faire pour modder Minecraft en Java.

Moi ça m'a donné envie de m'y remettre !

Cette dépêche et sa suivante sont malheureusement américano-centrées. Et ce pour la bonne et simple raison que, s’il est facile de trouver de l’information sur les cosmonautes russes, en trouver sur les informaticiennes est beaucoup plus ardu.

Pour la France, Claudie Haigneré, notre première spationaute (en 1996), a été ministre déléguée à la Recherche et aux Nouvelles technologies en 2002, mais n'était pas informaticienne.

Pour les informaticiennes françaises du secteur spatial, je pense que l'on peut chercher du côté de l'équipe de conception du langage Ada qui a souvent été utilisé pour les technologies spatiales (*).

Sans avoir de certitudes sur son implication dans le secteur spatial, je pense en particulier à Véronique Viguié Donzeau-Gouge, qui faisait partie de l'équipe de Jean Ichbiah. Il faudrait le lui demander !

La conquête de l’espace en quelques dates
Juillet 1969 : tandis que les Russes, dans le cadre du programme Bourane, lancent leur première navette spatiale, BOR-2, la mission Apollo 11 envoie Neil Armstrong et Buzz Aldrin sur la Lune.

Il ne faut pas confondre les avions orbitaux BOR avec la navette spatiale Bourane, qui ne volera pour la première fois que le 15 novembre 1988.

Merci pour cette dépêche de qualité (comme toujours !).

(*: par exemple dans la fusée Ariane, même si je précise qu'aucune femme n'a été mise en cause dans l'explosion du vol 501 d'Ariane 5 :-) )

Je n'ai pas (encore) lu ce rapport de la Cour des Comptes, mais je me demande s'il n'y a pas méprise sur leurs intentions ?

Dans son récent rapport sur « le pilotage de la transformation numérique de l’État par la direction interministérielle du numérique », la Cour des comptes relevait la nécessité d'une « vision générale des dépenses » en matière d'investissement numérique.

Quand on parle d'investissement, on fait habituellement uniquement référence aux projets (à leur bien-fondé et leur bonne exécution). Les dépenses logicielles, sauf quand on a développé ses propres solutions, rentrent généralement dans les coûts de fonctionnement…

Plus précisément, elle énonce qu' « une véritable stratégie numérique avec des objectifs et jalons ne peut faire l’économie d’une consolidation, actuellement inexistante, des dépenses numériques de l’État et de leur projection

Toujours dans cette lignée, on peut comprendre qu'il s'agit de s'assurer de la cohérence globale des investissements et de leur impact sur les futurs coûts de fonctionnement. Quand on fait l'analyse de rentabilité d'un projet ("business case"), on montre généralement le coût d'investissement, plus une projection de l'impact de la future application sur les coûts de fonctionnement sur 5 ou 6 ans.

Elle doit aussi être l’occasion de chiffrer les ambitions en matière de mutualisation et de contribution du numérique à la réalisation d’économies budgétaires. »

Là j'ai l'impression qu'on est en train de se dire que les business cases sont probablement un peu légers, voire qu'ils sont absents, ainsi probablement que les bilans de projets (la mesure effective de la valeur créée au fil de la vie de l'application résultant du projet). Pour être juste, même dans les grandes entreprises, les bilans de projets sont loin d'être systématiques…

Il est toutefois clair que pour des projets visant à réaliser des économies budgétaires, il vaut mieux avoir une compréhension fine des coûts de fonctionnement.

Elle fait également remarquer qu'elle avait proposé, en 2017, que la Direction interministérielle du numérique dispose des accès nécessaires « pour lui permettre d’analyser, avec la direction des achats de l’État et la direction du budget, les dépenses consacrées au système d’information de l’État. »

Bon là, OK, on parle bien des coûts de toute nature.

Un point de voûte de cette question est l'évaluation des dépenses logicielles de l'État, non seulement en termes de montant, mais également en termes d'organisation des dépenses, en ventilant, entre autres, entre licences libres et licence non libres.

C'est important en effet, mais ce qui compte surtout c'est de comprendre la dépense numérique de la sphère publique dans son ensemble (gouvernement, administrations, collectivités…) et dans toutes ses dimensions (charges de personnel, sous-traitance, logiciels, matériels, centres informatiques, etc. => cf. modèle de benchmarking des coûts IT du Cigref).

Certaines d'entre elles, en effet, peuvent être liées. Par exemple, le logiciel libre, quand on n'a pas le personnel capable d'en comprendre le fonctionnement et les environnements d'exécution, n'est pas forcément toujours la bonne réponse…

A titre personnel, je m'intéresse tout autant à la consolidation des centres de données de l'Etat (sujet démarré par Jacques Marzin il y a une décennie) et celle de son personnel informatique. Les duplications d'effort sont manifestes et, pris individuellement, les différentes composantes de l'Etat n'ont pas toujours la taille critique pour remplir leurs missions (je pense notamment à la sécurité des SI).

Cette évaluation […] permettra aussi la conduite d'une stratégie plus cohérente et efficace en faveur de promotion du logiciel libre – jugée encore insatisfaisant par la Cour dans le rapport précité. L'État ne peut plus se contenter d'être un observateur et un consommateur passif de solutions logicielles, y compris libres. Il doit mettre en œuvre une politique publique ambitieuse de priorité au logiciel libre et soutenir, par l'investissement, les communautés et les entreprises qui les font vivre.

A moins que l'Etat ne soit devenu membre de l'April, je doute que la priorité et/ou la promotion du logiciel libre ne soient pour lui une finalité. Au mieux un moyen, mais au service de sa maîtrise budgétaire, de sa souveraineté ou d'autres objectifs de plus haut niveau…

Quant à la Cour des Comptes, elle veille à la régularité, à l’efficience et à l’efficacité de la gestion de l’État et de ses opérateurs. Comme tout auditeur, elle n'a pas elle-même à aller trop loin dans la préconisation de solutions lors de ses contrôles. Il serait déjà merveilleux de disposer de données chiffrées sur ce que fait l'Etat en matière de numérique, mais il ne faut probablement pas trop en attendre par rapport au logiciel libre.

Double étoile, 1956
Le propos : un politicien, John Joseph Bonforte, est enlevé en pleine période électorale. Son équipe de campagne s’adresse à un acteur, Lawrence Smythe qui est son sosie pour le remplacer le temps de le retrouver.

Ça m'a refait penser à un autre roman de SF sur une élection présidentielle US, où l'un des candidats, après avoir subi un AVC, se voit doté d'un implant neuronal qui permet de l'alimenter en temps réel sur les réponses les plus susceptibles de plaire à la majorité des électeurs et de le contrôler (bon j'ai lu ça il y a 30 ans, mon souvenir est sans doute imprécis !).

Ce roman s'appelle Interface et a rassemblé sous le pseudonyme de Stephen Bury les auteurs Neal Stephenson (sans doute bien connu des lecteurs de LinuxFr) et George Jewsbury.

A quelques centimètres près, ça aurait pu devenir un roman d'anticipation, avec Trump dans le rôle du politicien, Musk dans celui du fournisseur d'implant Neuralink et un colistier très différent…

Le téléphone, forcément filaire
La première expérience de téléphonie sans fil daterait de 1900, soit vingt-quatre ans après l’invention du téléphone lui-même par Graham Bell. […] C’était encore un domaine très balbutiant en 1956, plutôt réservé aux voitures et autres véhicules automobiles. C’était cher et le matériel était lourd et encombrant. Le premier téléphone mobile réellement portable et utilisable par les piétons date du début des années 1970. Le prototype avec lequel Martin Cooper, chercheur chez Motorola, a passé le premier appel en 1973 pesait plus d’un kilo et ne tenait, évidemment, pas dans une poche et pas terriblement bien dans la main, à vrai dire.

La notion de « portabilité » a bien évolué au fil des ans. Dans la première moitié des années 80, cela voulait plutôt dire transportable 😊

La première (?) offre commerciale française dont j’aie connaissance, Radiocom 2000, associait un combiné classique à une base émetteur-récepteur encore assez volumineuse :

L’Apple //c, un tout petit peu avant, était équipé en série d’une poignée de transport et était généralement associé à un mini écran (la poignée est légèrement visible sur l'arrière de l'unité centrale) :

Et c'était déjà moins encombrant que le Compaq portable et ses 13 kilos :

Aujourd’hui, Smythe recevrait l’appel sur son téléphone mobile, mais sans aucune garantie de confidentialité et, évidemment, avec des écouteurs BlueTooth. Le futur (pas si lointain ?) serait qu’au lieu de parler à haute voix, on puisse se contenter de subvocaliser et que l’on ait des implants pour utiliser son ordiphone.

L’utilisation directe d’implants cochléaires est déjà disponible depuis 2017 chez Apple, qui aurait même déposé un brevet sur le sujet.

Si l’enjeu du commerce est d’être au plus près du prospect/client, alors pendant que l’on s’inquiète des dérives possibles à base d’enceintes connectées espionnant ce qui se passe à domicile, on ne fera jamais plus près qu’être dans l’individu ! Sans doute une arrière-pensée d’Elon Musk également…

Les archives Farley, des données incompatibles avec le RGPD
Aujourd’hui : les informations seraient enregistrées au fil de l’eau, numérisées et entrées automatiquement dans la base de données, voire, retranscrites en texte. Elles seraient accessibles de l’ordiphone via une application, et dans un futur presque immédiat accessible via des implants ou des lunettes de réalité augmentée à l’allure de paires de lunettes normales

Puis en projection rétinienne directe, comme dans Le problème à 3 corps :-)

C'était déjà la crainte à l'époque du lancement des Google Glass, mais depuis il y a eu la version Ray-Ban beaucoup plus discrète et avec un partenaire bien connu pour son respect de la vie privée, les Ray-Ban Meta smart glasses :-)

Merci Ysabeau pour ce billet.

Quelques commentaires de vieux schnock :

Des langages de balisages
[…] Pour rappel, un langage de balisage est un langage servant à définir et à structurer les informations dans un document.
Il en existe de nombreux, mais on n’évoquera que ceux qui semblent les plus connus ou les plus utilisés.
TeX le grand ancien

TeX, LaTeX et leurs prédécesseurs Roff, Nroff et Troff, auraient mérité une catégorie distincte de celle des langages de balisage : les langages de macros.

La différence entre les deux, c'est qu'il ne s'agit justement pas toujours de "définir et structurer les informations dans un document", bien souvent encadrées dans les dialectes de Markup Languages par une balise d'ouverture et de fermeture, mais de mêler le contenu du document avec des macros appelant des commandes plus ou moins complexes (parfois des programmes à part entière).

Le principe du langage TeX est la séparation du contenu de et la forme, ce qui était innovant.
[…] l’idée étant que l’auteur ou l’autrice :
puisse mettre son énergie à rédiger le contenu sans être distrait par l’apparence de son document.
En écrivant en langage LaTeX, l’utilisateur doit donc définir sémantiquement le contenu de son document plutôt que visuellement.

On avait donc un mélange du contenu et de programmes (macros), mais effectivement l'idée de LaTeX était de ne pas se préoccuper du rendu et de laisser faire le système pour obtenir un résultat professionnel et homogène.

On a eu la même transition de la présentation à la sémantique pour les langages de formattage de pages de manuel Unix de mandoc à mdoc.

On est en tout cas encore loin d'une séparation complète du contenu et de la forme !

Ce n’est pas un traitement de texte

Alors tout au contraire, c'était LE traitement de texte au sens étymologique du terme ("word processor" en VO), puisque le contenu mêlé de macros devait être interprété ou compilé pour produire un résultat adapté au support de sortie et plus riche en possibilités que le terminal texte de départ.

Comme souvent, cette expression a ensuite été complètement dévoyée pour désigner des logiciels où le seul processeur de traitement était l'utilisateur lui-même, qui devait faire tout le boulot de mise en page !!!

On a vu cela en de multiples occasions :

• du passage de systèmes d'exploitation au fonctionnement scripté au cliquodrome des systèmes fenêtrés… (qui en reviennent d'ailleurs aujourd'hui avec la montée en puissance de l'automatisation)
• de l'intention initiale d'un World Wide Web homogénéisant la structure de documents hypertextes à des concepteurs de pages voulant tout régler au poil de pixel près…

Quand Microsoft lance sa suite bureautique dans les années 1990, il adopte pour le traitement de texte, Word, l’extension .doc qui avait été aussi celle de WordPerfect. Word avait pour lui de montrer le rendu du texte immédiatement : le fameux WYSIWYG pour « What you see is what you get » (ce que vous voyez est ce que vous obtenez).

Ca n'a rien d'officiel, mais j'aimais bien l'acronyme un temps proposé pour traduire WYSIWYG en bon français : PETALE (Présenté à l'Ecran Tel qu'A L'Ecrit) :-)

Voilà.

Si quelqu'un veut des compléments d'information sur l'histoire des utilitaires de préparation documentaire sous Unix et ce que l'on appelle en France la "documentation automatique", j'ai pas mal abordé ces sujets dans un article sur Les dictionnaires sous Unix.

je ne suis pas administrateur du serveur de backup. Je ne veux pas être le SPOF. Varier les administrateurs c'est à mon avis aussi important que changer de DC parce que l'erreur matérielle n'est qu'une des façons de perdre des données.

C'est sûr mais il y a plein de façon de gérer ça : l'automatisation, les procédures, l'accès à d'autres compétences informatiques via le mariage, la procréation et/ou les amis :-) et donc à nouveau les procédures.

Pour rajouter quelques trucs auxquels on pense parfois moins :

• le mono fournisseur de serveurs (notamment par rapport aux politiques de suspension de comptes…)
• les moyens de paiement qui expirent (Paypal est bien pour éviter ça)
• les disques qui peuvent être vieux même sur un serveur neuf (dernière machine louée chez un fournisseur du Nord : 2 disques utilisés depuis 5 ans et un autre depuis 7 !)
• la maintenance des composants logiciels dont dépend la solution de backup (Borg, par exemple, est sensible aux versions de packages dont il dépend (msgpack…), ce qui peut se comprendre pour des raisons sécuritaires)
• …

Borg fait de la déduplication au niveau bloc

Ah, en effet, au temps pour moi, je l'avais zappé ou oublié. Merci pour la rectification !

D'après le comparatif posté dans le fil de discussion, il a même l'air d'être plus avancé que la concurrence sur ce point, ce qui en fait donc une solution quasi parfaite de mon point de vue (les critères de rapidité, consommation de mémoire et double chiffrement n'étant pas importants pour mes cas d'usage).

Bonjour,

demande à un utilisateur de PC, smartphone… si la destruction inopinée de son appareil entraînerait des pertes de fichiers irrémédiables qui pourraient l’affecter

Pour la partie smartphone (que votre article ne couvrait pas), j'utilise un serveur dédié NextCloud avec son app iOS ou Android pour synchroniser les données de mon smartphone (photos, vidéos). Sur iPhone, c'est un excellent remplacement d'iCloud ! J'utilise également le client desktop pour synchroniser les répertoires sensibles de mes machines Windows…

Pour mes serveurs Unix, après avoir longtemps utilisé BackupPC, je suis passé aujourd'hui à BorgBackup, qui répond à presque tous mes besoins (hormis l'absence de déduplication au niveau bloc plutôt que fichiers).

En bon paranoïaque, j'évite de faire tourner des serveurs chez moi (pour ne pas risquer un départ de feu quand je ne suis pas à côté !) et je backupe mon serveur de backup sur un autre serveur dédié dans un autre datacenter :-) (les disques durs sont si fragiles)

Je n’ai jamais eu de projet ou de besoin qui me pousse à maîtriser Perl ou Python. Je pense qu’ils sont encore plus puissants que bash.

Ils ne jouent pas dans la même ligue :-)

Le shell (Bash ou autres) reste bien pratique, mais pour tout développement significatif il vaut mieux passer à autre chose. Personnellement, je n'ai jamais vraiment accroché sur Perl (Write Once Read Never !) mais j'adore Python, ses bibliothèques et tous les paquets associés.

Tu as un bouquin en ligne sympa pour découvrir ce langage au travers de cas d'usages courants sur le site Automate the boring stuff with Python.

Et j'ai mis plein d'exemples de commandes Unix écrites en Python sur mon projet PNU, dont une en rapport avec le sujet de la restauration de sauvegardes, dcmp - directory compare, pour analyser les différences entre différentes versions de backups…

Ca te donnera peut-être l'envie de manger du serpent ?

Il n'y a pas d'intégration pour d'autres forges sur Advent of Code, donc oui, forcément c'est 100% :-)

Bien vu ! On ne peut en effet s'authentifier qu'avec GitHub, Google, Twitter ou Reddit. Autant pour moi.

Enfin, ça montre quand même que l'auteur n'a pas jugé utile de se lier à GitLab. Sans doute pensait-il (comme moi avant la lecture de cet article) que cette forge ne rassemblait que quelques dizaines/centaines de milliers de personnes et que ça n'en valait pas la peine !

En plus d'un statut associatif à but non lucratif, ce qui limite les risques de disparition du jour au lendemain

Je crois qu'au contraire, les coûts pourraient rapidement devenir difficiles à supporter par une association en cas de succès de la plate-forme !

la communauté compte fin avril 2024 plus de 102 000 utilisateurs

C'est le principe même d'Internet qu'un acteur / une plate-forme finisse par être dominant sur son domaine d'activité.
A 102K utilisateurs par rapport à 30M sur GitLab (que je trouve déjà marginal !) et 100M pour GitHub, on peut autant dire que Codeberg "semble avoir percé" que d'une quenotte dans la bouche d'un nouveau né :-)

Par exemple, lors de l'Advent of Code de cette année, 100% de ceux qui ont publié leur code l'ont fait sur GitHub. Déjà rien sur GitLab malgré ses 30M d'utilisateurs…

GitHub, lancé en 2008, est devenu la plus grosse plateforme d'hébergement de codes sources, utilisée par un grand nombre de projets majeurs du monde du libre
Ce qui […] conduit souvent à faire de Github un choix par défaut, facilitant les interactions avec les autres projets et permettant d'accéder à une large base de contributeurs potentiels.

Ce n'est pas forcément qu'un choix par défaut, mais un choix délibéré pour tous ceux qui veulent surtout exposer leurs logiciels à la communauté de développeurs la plus importante ou aux productions d'entreprises.

Il ne s'agit pas que d'accéder à une base de contributeurs potentiels, contributions qui sont de toutes façons plus qu'occasionnelles (même sur GitHub) pour la plupart des dépôts de code, mais surtout à une base d'utilisateurs potentiels.

Avec l'arrivée du projet Copilot, il est cependant certain que nos codes servent à alimenter un outil d'IA, permettant à Microsoft de monétiser des suggestions de code en faisant fi des questions de licence.

Je n'en suis pas si certain. Vu le nombre de projets non terminés, dysfonctionnels ou codés de façon non professionnelle, à leur place je serais assez sélectif sur les codes que je donnerais à manger à mes IA !
Et pour ce qui est d'entraîner celles-ci sur du code sûr, c'est encore plus limité vu l'inculture généralisée en matière de codage sécurisé.

Migrer le code source et l'éventuel Wiki associé ne devrait pas poser de problème particulier. Il suffit de configurer git pour pusher vers la nouvelle forge.

Le fait que toutes ces forges utilisent Git est à la fois :
* un moyen simple de supprimer le risque de perte de son code et de son historique par une sauvegarde locale
* une façon d'utiliser l'ensemble de ces plates-formes comme lieu d'exposition de ses productions logicielles : GitHub + GitLab + Codeberg :-)

Le tout étant de gérer ses versions de code source chez soi ou sur l'un de ses serveurs, GitHub ou un autre n'étant dans ce cas qu'une sorte de "faux primaire" (pour reprendre une expression liée à la gestion de DNS)…

Parmi les gens qui ont proposé des choses intéressantes en matière d'interface homme-machine, il y a Pranav Mistry, notamment avec son prototype SixthSense.

La société Humane Inc. apporte cela au grand public avec son produit Humane AI Pin qui fait l'unanimité… contre lui

Ah oui, j'ai vu ce truc-là et les critiques associées, mais je n'avais pas compris que cela reprenait les fonctionnalités de SixthSense.

J'ai regardé vite fait leur site. J'ai vu que la projection était là (l'affichage dans la main était l'une des fonctionnalités / démo de SixthSense. Sur la main ou n'importe quelle surface claire), mais je n'ai pas compris si cela reconnaissait les gestes de l'utilisateur ?

Pour SixthSense, comme le produit n'est jamais sorti, difficile de dire si c'était du pipeau ou réellement implémenté, mais en tout cas cette reconnaissance des gestes était vraiment quelque chose d'original et qui colle parfaitement à l'article ci-dessus.

Jouer à Pong dans le métro avec les pieds et une balle virtuelle, ou utiliser une feuille de papier A4 en guise de tablette m'aurait bien amusé :-) (c'est dans les démos encore trouvables sur YouTube, et il y a un TED talk sur le sujet).

Sympa cet article.

Quelques anecdotes et compléments :

Sur la photo de Ken et Dennis, on voit Ken travailler sur un TéléTYpe (clavier combiné à une imprimante). C'est l'appareil qui a donné son nom aux tty, avant d'être remplacé par les terminaux (écrans seuls connectés en série, du temps où nos systèmes étaient vraiment multi-utilisateurs), puis les terminaux virtuels encore présents dans nos Unix libres d'aujourd'hui…

Dans nos datacenters, la majorité des serveurs n'ont pas d'écrans, mais on positionne un KVM physique (clavier + écran + souris partagés) toutes les quelques baies de serveurs pour travailler sur place. Quand on loue un serveur dédié, on a parfois accès à un KVM virtuel (IDRAC, ILO, etc.) pour installer ou réparer un OS avant que celui-ci ne soit accessible en réseau.

La plupart des serveurs fonctionnent en mode headless, sans écran/clavier/souris, et l'on n'interagit avec eux que par les services qu'ils proposent (serveurs Internet : Web, messagerie, gestion de domaines, etc.). On trouve même ces modes headless dans les virtualiseurs pour utilisateurs locaux tels que VirtualBox. A vrai dire, ce mode headless ne pose problème que quand le système d'exploitation utilisé est pensé pour être contrôlé à la souris…

Parmi les gens qui ont proposé des choses intéressantes en matière d'interface homme-machine, il y a Pranav Mistry, notamment avec son prototype SixthSense. Son idée force c'était que ce qui est pénible dans l'informatique, ce sont les ordinateurs eux-mêmes. Du coup, il avait imaginé une sorte de cravate, avec d'un côté une caméra, de l'autre un pico-projecteur et au milieu un miroir réflecteur. Ca permettait d'afficher sur presque n'importe quoi et de contrôler le système avec des mouvements des mains…

Dernier point, avec les progrès récents en matière d'IA, les systèmes de Speech-To-Text (STT) et Text-To-Speech (TTS) ont fait d'énormes progrès, certains étant suffisamment performants pour fonctionner en local avec des ressources limitées. Du coup, de là à imaginer des machines parlantes, à commande et retour vocal, il n'y a qu'un pas, que certaines enceintes connectées, voitures, et autres ont commencé à franchir. J'imagine que cela devrait bien plus se généraliser dans les années à venir.

Perso, j'adorerais une solution recourant à la téléportation même si je ne vois pas trop en quoi ça peut servir à la modération de LinuxFr.

Téléporter les spammeurs au fond de l'océan ?

Ou créer une nouveau modèle dans lequel on paye pour commenter/rédiger.

C'est déjà le modèle d'une bonne partie de la presse écrite, et il me semble que ça existe déjà dans notre domaine. Je pense par exemple à l'excellent site Abort Retry Fail.

comme tout le monde le sais, plus on est intelligent, plus on a un travail bien payé

Ca fleure bon le troll du 1er avril :-)

Les IA n'ayant pas réellement de travail n'auraient pas les moyens de participer !

Alors là, gagner de l'argent ne sera sûrement pas un problème pour une future IAG. C'est même certainement comme cela qu'elle assurera sa continuité de fonctionnement et qu'elle nous dominera "pacifiquement" !

Merci beaucoup ! Je vais me faire une petite séance nostalgique :-)

il y a eu un turbo-modula2 (sous CP/M et DOS) … je l'ai dans mon répertoire Dosbox-X et CP/M ) …

D'après le lien que j'indiquais, pas chez Borland et a priori pas sous ce nom (plutôt TopSpeed Modula-2).

Si tu as une version "Turbo Modula-2", c'est peut être un super collector !

Personnellement, j'aimais bien ce langage que j'avais découvert dans le livre de Wirth "Programmer en MODULA 2" (c'était l'époque où l'on apprenait les langages de programmation dans des livres, sans Web, ni Copilot ! Sûrement acheté à la librairie "Le monde en tique", petite larme nostalgique au passage :-)), mais je n'ai rien fait de significatif avec.

Ces langages ne sont absolument pas "limités" et n'ont rien à envier au "maudit" C/C++.

Quand j'étudiais l'informatique il y a 35 ans, il nous est arrivé d'écrire le même programme en assembleur, en C et en Pascal. Je ne sais plus quel était le compilateur utilisé à l'époque, mais il n'y avait pas photo sur la faible performance du Pascal. Sans doute à cause du P-code généré ?

Je n'avais personnellement pas parlé de "limites", mais par rapport aux langages modernes il y en a beaucoup. C'est sûr qu'en Pascal, comme en assembleur, on peut probablement tout faire, mais au prix de quel effort ! Les structures de données évoluées, les bibliothèques, les classes, les paquetages, la programmation concurrente, etc. apparaissent aujourd'hui comme d'énormes limites.

Pascal a eu son heure de gloire, son intérêt pédagogique, mais est très bien dans un musée aujourd'hui.

Je ne sais pas trop en quoi le C aurait été "maudit" (après tout ce n'est qu'un outil) par contre ce n'était clairement pas fait pour les gens non rigoureux ou systématiques, c'est certain :-)

Pour illustrer mon propos sur les langages anciens, j'ai fait un peu de rétrofit de fonctionnalités sympa du Python en C comme les listes. Au final, ça m'a pris un été pour refaire ce qui est aujourd'hui communément disponible dans beaucoup de langages modernes… Mais ce qui me manque le plus en C aujourd'hui c'est un système de paquetage à la Python. Il y a bien Conan sur le marché, mais je ne l'ai pas encore essayé.

Et apprendre à programmer en "C" est une hérésie à mon avis. Pascal est bien mieux conçu pour ça (et a été conçu principalement pour ça)

Pascal était plus adapté pour apprendre à programmer. Maintenant il y a bien mieux. Python, notamment, a beaucoup de qualités pour l'enseignement de l'informatique, dont son côté "fun" en particulier (critère ultra important de mon point de vue).

De mémoire, à mon époque on apprenait l'algorithmique sur papier, puis la programmation en Pascal, puis on passait au C pour faire des choses sérieuses :-) (je suis provocateur là, ne réagissez pas au quart de tour).

Mais, au fond, ça me semble être le même débat que l'apprentissage du modèle OSI versus celui de TCP/IP. C'est bien de faire de la théorie, mais il faut passer un jour à la pratique, et une pratique si possible utile. Pendant qu'on se gargarisait de notre modèle en 7 couches, des gens pragmatiques écrivaient TCP/IP. Ce n'était pas un chef d'oeuvre, mais au final OSI TP-4 n'aura pas transporté beaucoup de paquets…

Pour en revenir à Monsieur Wirth, il faut lui reconnaître d'avoir su concilier théorie et pratique, d'avoir compris avant beaucoup d'autres les vertus de la simplicité, et d'avoir créé toute une série de langages dont on retrouve la génétique dans beaucoup des langages modernes dont je parlais plus haut.

Son Oeuvre est effectivement considérable.

On ne peut désormais plus parler de lui que par référence ?

Mais « trépas » aurait sans doute été plus approprié si je comprends bien l'esprit de votre question !

Il y a aussi cette anecdote savoureuse à propos de la prononciation de son nom en Amérique, qui aurait souvent été écorchée en Nickel's Worth (approx: qui ne vaut pas grand chose), alors qu'en Europe les gens s'en seraient à peu près sortis.

A laquelle, selon la légende, il aurait répondu :

"You can call me by name 'Wirth' or value 'Worth' ;-)"

Pascalien jusqu'au bout, en somme :-)

Autre anecdote bien moins connue, il y a failli avoir un Borland Turbo Modula-2 !

Cf. aussi la nécro sur Le Temps

Hébergeurs français

Je vois que Nos Oignons n'utilise ni OVH, ni Scaleway, comme hébergeurs.

Je me souviens qu'à une époque il était expressément stipulé dans les conditions d'utilisation de leurs serveurs dédiés et VPS qu'il était interdit d'héberger un service TOR, mais ça n'a plus l'air d'être indiqué de nos jours, ni chez OVH, ni chez Scaleway.

Peut-être est-ce pour cela qu'il était déconseillé d'y mettre des relais TOR, ou alors parce qu'il y en avait déjà trop à ces endroits ?

Qu'en est-il de la situation chez ces hébergeurs ?

Prévention des abus

Par contre, je lis chez OVH :

Sont notamment interdites […] (b) les activités d’intrusion ou de tentative d’intrusion à partir des Services (à titre non-exhaustif : les scans de ports, le sniffing, le spoofing, et plus généralement les attaques sortantes à partir des ressources mises à disposition par OVHcloud)

Ce qui peut très vite empêcher d'y mettre un relais TOR, puisqu'il est encore très courant de subir des attaques sortant de ces machines (environ 1 à 10% de celles que j'observe sur mes serveurs, de mémoire).

Du coup, quelle est la politique du projet TOR par rapport à ces utilisations frauduleuses, à part proposer un mécanisme de signalement, dont je ne sais pas trop à quoi il peut servir puisque vous ne conservez pas de logs (hormis peut-être bloquer la destination) ?

Est-ce que, par exemple, certains proposent des mécanismes de filtrage des attaques courantes en entrée ou en sortie de relais, du moins bien sûr pour ce qui n'est pas déjà chiffré en entrée, même si cela devient de plus en plus rare avec la généralisation du traffic HTTPS ?

(à propos je suggère de remplacer le terme "mécréants" par "malveillants" dans le paragraphe où cette question est abordée, ce sera plus précis)

Merci pour l'article ! (j'aime bien ces formats longs où l'on prend le temps de fouiller un sujet)

Une re-marque (au sens littéral du terme !)

WOFF : un format du renard roux

Un firefox est un panda roux et cet animal est bien l'emblème du logiciel Firefox, mais je suis sûr que vous le saviez déjà.

Un commentaire à propos des pandas et des claviers de machines à écrire et d'ordinateurs

Le biologiste de l'évolution Steven Jay Gould, dans son livre "La foire aux dinosaures", reprend l'un de ses articles intitulé "Le pouce du panda de la technologie" où il explique les mécanismes ayant déterminé l'évolution des dispositions de claviers de machines à écrire, puis d'ordinateurs. C'est assez passionnant et surprenant, et pas aussi "mécanique" qu'on ne le dit habituellement !

Une question

volontairement, il y a un minimum de références à Wikipédia

Pourquoi ? Il y a une raison particulière ? Il ne faut pas faire ça sur LinuxFr ?

Un truc sorti de nulle part pour refaire le lien entre Unicode et le monde Unix

Le format de transformation UTF-8, qui facilite l'accès à Unicode, a été inventé par Ken Thompson, et initialement co-implémenté avec Rob "Commander" Pike dans le système d'exploitation Plan 9 ayant succédé à Unix aux Bell Labs, dont les utilitaires gèrent tous nativement cet encodage.

C'était à l'occasion d'un dîner entre les deux hommes, la conception a été faite en une soirée et l'implémentation dans Plan 9 dans la semaine. Un peu plus tard, l'empire du Mal de l'époque (= IBM) a semble-t-il essayé de s'en attribuer la paternité, ce que Rob Pike a ensuite rectifié.

Merci Thierry. J'en ai parlé sur la ML FreeBSD security à l'époque, et j'ai travaillé particulièrement avec Philip Paeps de la Security team.

Bon, ce n'est pas un outil grand public non plus, mais il n'y a pas de raison que je sois le seul à l'utiliser pour le projet. J'ai d'ailleurs sous le coude plein de vulnérabilités non encore signalées, mais j'essaie de ne pas aller plus vite que la capacité de commit de ceux qui traitent les PR.

2 points à noter :
- le seul truc manuel est d'écrire le résumé en 1 ligne de la vulnérabilité, mais j'envisageais d'utiliser un "résumeur" IA pour faire un truc complètement automatisé (pas sûr que ça marche bien à moins d'entraîner le modèle à résumer des vulnérabilités)
- j'ai en cours (je n'ai pas encore écrit le générateur VuXML) une généralisation de pysec2vuxml appelée osv2vuxml qui fait la même chose pour la dizaine de langages qui ont un système de packaging. A l'occasion, il faudra que je le finisse (environ 160 vulnérabilités non répertoriées la dernière fois que je l'ai fait tourner).

Côté grand public, enfin public intéressé par la sécurité, j'ai aussi écrit un outil appelé vuxml pour interroger la base de données VuXML, en ligne de commande ou via une API Python.

La seule raison officielle que j'aie pu trouver est : parce que newegg était déjà pris :-)

Mais mon interprétation (degré de confiance faible) est que c'est parce que tu as besoin de droits super-utilisateur pour installer ton package pour tous les utilisateurs du système, en référence au wheel du monde BSD, lui même tiré de l'argot "Big wheel" (= gros poisson).

Si j'ai bien compris ton problème, tu as 4 ou 5 commandes avec des dépendances croisées résultant du split de ton code source.

C'est tout à fait gérable par un package Python.

Dans l'exemple que j'ai donné plus haut, jette un oeil au fichier setup.cfg. Tu y trouveras la section suivante :

[options.entry_points]
console_scripts =
    pipinfo = pipinfo:main
    pippin = pipinfo:main

Cette section options.entry_points définit deux exécutables installés par le package, pipinfo et pippin, qui pour cet exemple pointent tous deux vers le module main du code source. Ce sont donc des alias, mais ils auraient aussi bien pu pointer vers des modules différents (tes différents fichiers).

Même si tu restais avec des alias, tu as toujours la méthode Unix/C classique qui marche tout aussi bien en Python, qui consiste à faire varier le comportement de ton programme en fonction du nom sous lequel il a été appelé (récupéré avec les arguments de la ligne de commande).

Tu peux aussi isoler le code commun dans une bibliothèque comme je le fais avec mon package libpnu et le référencer par une dépendance de package :

[options]
install_requires =
    pnu-libpnu

Quand tu n'as pas de dépendances croisées, tu peux aussi faire des méta-paquets qui ne font que faire une collection d'autres paquets comme je le fais pour mon projet PNU.

Je pense que tu devrais trouver ton bonheur avec l'une de ces approches.