HubTou a écrit 19 commentaires

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.

Bien sûr, et l'outil dont j'ai parlé, pysec2vuxml, génère justement une entrée VuXML pour tous ceux qui ont une vulnérabilité de sécurité non signalée, ainsi qu'un index permettant de contacter l'ensemble des mainteneurs concernés.

Je mets mainteneur entre guillemets car le terme est souvent inapproprié. Beaucoup de gens (et j'en ai fait partie) créent des ports pour des outils annexes pour pouvoir créer un port pour un de leurs logiciels ou pour un logiciel tiers qui les intéresse, mais ils ne maintiennent plus particulièrement ces ports annexes par la suite. Dans le cas de ports pour des logiciels Python avec des vulnérabilités PYSEC connues, soit il n'y a pas de correctif connu, soit le logiciel source a été abandonné, soit le mainteneur a abandonné l'affaire depuis longtemps !

Tout d'abord un grand merci pour ce chouette article, copieux et bien documenté, et mettant en avant un pan de l'Histoire de notre discipline, ce que j'adore !

En vue du prochain épisode, je voudrais signaler la catégorie quelques-trucs-en-un avec une production personnelle nommée pip-info (ou pippin :-) ) qui, à ce jour, propose un équivalent tout-en-un des commandes "pip list", "pip list --outdated", "pip show" et "pip-audit". J'ai fait ça à l'origine pour explorer ce que je considérais être des bugs de "pip list --outdated", et puis, comme souvent, je me suis laissé emporter… Dans une version non publiée, j'ai travaillé sur les arborescences de dépendances, amont et aval, des packages Python… avec l'idée d'aller jusqu'aux packages système.

Je mentionne ce lien avec le packaging système car dans mon système favori, FreeBSD (mais je pense que c'est pareil dans Linux), on encapsule des outils ou packages Python dans des packages systèmes, sans toujours être à jour des dernières versions disponibles. Du coup, quand on a pour politique d'être à la pointe de la modernité, on souffre de l'absence d'interdépendances entre les outils de gestion de packages systèmes et ceux de packages Python… Je gère ça à la main pour le moment, mais je sens qu'un jour je vais écrire quelque chose pour automatiser ce travail.

Vous êtes peut-être en train de vous dire que c'est un peu extrême de vouloir tout mettre à jour à la fois dans le système et dans Python, mais la réalité c'est que les packages Python systèmes ont parfois pas mal d'écart avec ceux de PyPI (du moins pour les moins courants) et que beaucoup proposent des versions qui ont des problèmes de sécurité connus.

Pour contrôler cela, j'ai écrit un autre outil, pysec2vuxml, qui m'a permis de montrer que sur près de 4000 packages Python encapsulés dans des packages FreeBSD, environ 1 à 2% avaient des problèmes de sécurité non signalés (NB: c'est la même chose avec les systèmes de packaging de plein d'autres langages…). Cet outil me servait du coup à préparer le signalement de ces problèmes de sécurité au niveau système. Je ne sais pas s'il existe un équivalent de cet outil sur Linux, mais je suis à peu près sûr que le problème y est le même.

Voilà. J'ai hâte de lire la suite de l'article !

En complément du complément, je m'aperçois que Lorinda Cherry est probablement l'autrice de la commande prep en parcourant cette entrée dans ses références :
- McMahon, L.E. Cherry, L.L. Morris, R. UNIX Time‐Sharing System : Statistical Text Processing (1978) Bell System Technical Journal, 57 (6), pp. 2137-2154, DOI : 10.1002/j.1538-7305.1978.tb02146.x

Cette commande ayant été abandonnée depuis longtemps, je l'avais backportée, puis réécrite en Python pour voir ce que ça faisait.

Je mets les liens pour ceux qui voudraient eux-aussi s'en faire une idée en mode nécrocomputing…

Pour ceux qui souhaiteraient un complément d'informations historiques sur Unix et les outils de traitement de texte, j'avais écrit il y a 2 ans une petite histoire des "dictionnaires sous Unix" qui donne des détails sur le contexte des Bell Labs à l'époque, l'intérêt pour les applications de traitement de texte, le Writer's workbench (où Lorinda Cherry avait notamment écrit les utilitaires diction et style), etc.

Lorinda était co-autrice de bc et dc avec Robert Morris (senior - le père de l'auteur du ver Internet), et de eqn avec Brian Kernighan.