Concernant les performances des compilo, c'est un peu la bouteille à l'encre… En effet, tous les compilateurs Fortran sont en fait des compagnons aux compilateurs C et C++ et ont en commun la libc. (Est-il exagéré dire que gfortran n'est jamais qu'un frontend de la libc ?)
Il y a quelques années, j'ai été dans l'impossibilité de faire tourner mon moteur de blog sur une machine distante car la glibc avec lequel mon binaire avait été compilé refusait le kernel trop ancien. J'ai alors procédé à une recompilation (en édition de liens statique) sur la distro Alpine Linux sachant que sa libc était "musl". Cet exécutable fonctionnait parfaitement sur ma Gentoo sous glibc et tout aussi bien que sur la machine distante fossilisée. Or, sur ces deux machines, la rapidité d'exécution était absolument surprenante. Évidement, sur un seul job de quelques secondes, il est impossible de conclure. Mais pour un job sur dix heures…
Le module "Varying length character strings" n'est plus d'actualité aujourd'hui depuis que les allocations dynamiques sont devenues possibles.
Il y a donc deux possibilités pour la déclaration des chaînes de caractères :
1. À l'ancienne, avec une longueur prédéterminée (option LEN);
2. Avec l'option ALLOCATABLE pour une longueur variable inconnue à la déclaration.
Dans les deux cas, il faut procéder à leur initialisation. Cette initialisation doit être précédée du mot clé ALLOCATE pour les chaînes de longueur variable. Et si cette allocation est faite en dehors d'une procédure, ne pas oublier DEALLOCATE (l'équivalent de free() en C) pour les fuites de mémoire. Tout ceci est décrit dans mon article de GLMF de sept 2019 à la page 46.
Depuis F77, il y a eu d'autres procédures prédéfinies (l'équivalent de la "libc") ajoutées concernant les manipulations sur les chaînes comme ADJUSTL et ADJUSTR qui permettent de justifier à droite ou à gauche une chaîne. À INDEX ont été ajoutés SCAN et VERIFY.
Du fait des allocations dynamiques, le recours à Valgrind est plus que recommandé. Au passage, il permet de dépister des variables non initialisées qui n'ont pas été dépistées par gfortran. À noter que Valgrind a ses exigences concernant la compilation de la libc. (Il est très possible que Valgrind ne soit pas immédiatement utilisable sur votre distribution.) Et, tant qu'on y est, il y a aussi gdb. Ces deux outils sont contraignants pour la machine hébergeant la chaîne de compilation. Personnellement, je suis sous Gentoo et je suis obligé d'activer l'option [FEATURES="splitdebug"] dans "/etc/portage/make.conf". Ceci fait que tout exécutable de la distro est scindé en deux : l'exécutable strippé étant dans "/usr/bin" et la partie contenant les symboles de débug étant dans "/usr/lib/debug". Mais ceci concerne seulement les sources packagées par la distro ; penser à activer les options de compilation GCC "-Og" et "-ggdb" pour vos propres compilations.
Pour paraphraser un des principes de la philosophie UNIX, et en caricaturant, Fortran ne fait qu'une seule chose : calculer vite.
Tout d'abord, merci pour le journal ! Mais je me permets d'apporter la contradiction… (On est quand même sur LinuxFr !)
Je suis l'auteur de deux des sept contenus taggés en référence : ils faisaient la promotion d'un moteur de blog rédigé en Fortran moderne. De toute évidence, nous ne sommes pas là dans des jobs de calcul intensifs prenant des heures (voire des semaines !) mais sur des traitements de l'ordre de la seconde. Et il n'y a point de maths, juste de la manipulation de chaînes de caractères.
En effet, depuis Fortran 77, la norme a introduit le type caractère et une capacité de traitement sur les fichiers assez conséquent. Fortran 2003 et 2008 ont considérablement étendu la capacité de traitement des chaînes de caractère avec la gestion de l'unicode, les allocations ET les réallocations dynamiques. Comparé au langage C, jouer avec les lettres en Fortran c'est un délice. (Je suis en train de coder un projet qui impose des routines en C pour des accès Internet et, vraiment, quand on doit se coltiner des concaténations de chaîne en C, c'est grosse galère !)
Fortran a eu un concurrent autrefois : Basic. Ce qui était alors reproché au vieux Fortran c'était sa concision héritée des cartes perforées. Avec la norme F90-F95, ce langage s'est fortement rapproché de l'ergonomie de Basic. Depuis les années 2000, la programmation orientée objet en a fait un outil vraiment polyvalent.
Oui, Fortran est fort en maths. Mais pas que… C'est pour tordre le cou à cette idée reçue que j'ai commis un article dans Linux Magazine l'été dernier.
Accessoirement, J'ai longtemps partagé la croyance ci-près :
A noter que l'évolution du langage est pilotée par ces normes, et il faut attendre pas mal d'années avant que l'intégralité d'une norme soit supportée par un compilateur.
Sauf que Cray existe toujours et a un compilateur Fortran prétendument à jour de F2008 et presque entièrement de la dernière norme F2018. Je n'ai pas vérifié si c'était vrai car leur compilo ne tourne que sur leur matériel. (Je n'ose même pas imaginer leurs tarifs…)
Enfin je profite de l'occasion pour suggérer qu'un codeur, ayant la double compétence en C++ et Fortran, ponde un article comparatif entre ces deux langages tant ils semblent partager les mêmes fonctionnalités. (Je ne sais lequel est le plus puissant des deux mais je suis certain que la facilité d'apprentissage est bien en faveur de l'ancêtre.)
Le Journal officiel a publié postérieurement à la parution de l'arrêté un document qui met fin à toutes mes spéculations. Je viens de mettre en ligne le correctif.
Le Journal officiel a publié postérieurement à la parution de l'arrêté un document qui met fin à toutes mes spéculations. Je viens de mettre en ligne le correctif.
On parle depuis le début de « menace susceptible de porter atteinte à la sécurité des systèmes d'information des autorités publiques [ou des OIV]».
À la fin du troisième paragraphe de ma première réponse (le 07/03/20 à 21:17) :
Un rapide survol des textes en référence confirme cette double casquette. Mon sentiment (mais je ne suis pas qualifié en la matière) est que ce texte est d'une portée extrêmement générale (en matière de communication, les conversations téléphoniques sont intégrées dans les trames Ethernet) et vise tout autant à la lutte contre l'espionnage (militaire ou industriel) ou le sabotage que la lutte contre la contrefaçon.
il y a "la lutte contre la contrefaçon".
Le vol d'image ou le téléchargement sauvage de film ne relève-t-il pas du Code de la propriété intellectuelle tout comme la contrefaçon à l'ancienne ? Et n'est pas une forme moderne de contrefaçon ?
On peut ergoter indéfiniment sur la propriété intellectuelle et tout cela a été largement discuté lors de la loi dite "Hadopi".
Je n'ai pas varié dans mon affirmation qu'il n'y avait pas seulement que l'ANSSI impliqué dans cet arrêté. Dans des temps plus lointains, il y aurait eu deux arrêtés pris chacun par le ministre concerné. Un pour la Défense, l'autre pour le business. C'est le coup de la double signature qui m'a interpellé. Autrefois, un arrêté était propre à une administration. Aujourd'hui, la tendance est à produire moins de textes mais à les allonger considérablement. Ils sont devenus des fourre-tout et la veille juridique particulièrement pénible à assumer.
Désolé, je reste sur ma position. Cet arrêté est signé par deux personnes : C. Landais, secrétaire générale de la défense et de la sécurité nationale pour le Premier ministre et T. Courbe, directeur général des entreprises, pour le ministre de l'économie et des finances.
Il me semble que s'il n'y avait que l'ANSSI intéressée, seule la signature de C. Landais aurait été requise. Il me semble que la définition les personnes relevant du 1. du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique sont ce qu'on appelle des "hébergeurs".
Je cite le I-1 : 1. Les personnes dont l'activité est d'offrir un accès à des services de communication au public en ligne informent leurs abonnés de l'existence de moyens techniques permettant de restreindre l'accès à certains services ou de les sélectionner et leur proposent au moins un de ces moyens. Les personnes visées à l'alinéa précédent les informent également de l'existence de moyens de sécurisation permettant de prévenir les manquements à l'obligation définie à l'article L. 336-3 du code de la propriété intellectuelle et leur proposent au moins un des moyens figurant sur la liste prévue au deuxième alinéa de l'article L. 331-26 du même code.
Mais en lisant l'article L. 321-26 du Code de la propriété intellectuelle :
Après consultation des concepteurs de moyens de sécurisation destinés à prévenir l'utilisation illicite de l'accès à un service de communication au public en ligne, des personnes dont l'activité est d'offrir l'accès à un tel service ainsi que des organismes de gestion collective régis par le titre II du présent livre et des organismes de défense professionnelle régulièrement constitués, la Haute Autorité rend publiques les spécifications fonctionnelles pertinentes que ces moyens doivent présenter. Au terme d'une procédure d'évaluation certifiée prenant en compte leur conformité aux spécifications visées au premier alinéa et leur efficacité, la Haute Autorité établit une liste labellisant les moyens de sécurisation. Cette labellisation est périodiquement revue. Un décret en Conseil d'Etat précise la procédure d'évaluation et de labellisation de ces moyens de sécurisation.
les personnes intéressées me semble être alors aussi les organismes de gestion collective des droits et les organismes de défense professionnels !
Les I-2 et I-3 exonèrent l'hébergeur civilement et pénalement en cas d'ignorance d'hébergement de contenus illicite et sa promptitude à faire cesser le trouble.
À ce qu'il me semble, l'hébergeur n'est pas tenu d'inspecter les contenus de ses abonnés. Mais l'hébergeur peut être saisi par toute personne, disons pour des affaires de mœurs, mais aussi en matière de propriété intellectuelle. Dans ce dernier cas, ce n'est pas l'ANSSI qui est compétente mais la Haute autorité au sens du Code de la propriété intellectuelle.
Ce qui explique la double signature de l'arrêté. Quant à savoir le périmètre des organismes de gestion collective, je ne suis pas du tout versé en la matière… Et pour les organismes de défense professionnels, la définition est pour le moins vague et semble laisser un large champ à tous les porte-drapeaux.
Je suppose que si on se fait se fait voler des images mises en ligne depuis son site Internet, le recours devrait se faire auprès desdits organismes de gestion collective et non pas l'ANSSI. OK, et après qui va payer pour faire établir la preuve du piratage ? Je suppose qu'il sera demandé au piraté de donner quelque argent tout comme il le ferait pour un constat d'huissier. Sauf qu'au lieu de s'adresser à l'huissier il devra le faire auprès de la Haute autorité.
De ce qui précède, je persiste à dire que de très nombreuses personnes sont concernées par le tarif de cet arrêté ; à tout le moins, tout titulaire d'un site Web.
a) Tableau de l'annexe 1, ligne EH1 : installation de matériel appartenant à l'ANSSI, tarif 100€ ;
b) Tableau de l'annexe 1, ligne EH2 : Installation du matériel appartenant à l'opérateur de communications électroniques ou à la personne mentionnée aux 1. ou 2. du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 (…), tarif 150€ + 99€/mois;
c) Tableau de l'annexe 3 : ligne EH3, enlèvement du matériel appartenant à l'ANSSI ou à la personne mentionnée (…)
De ce qui précède, nous en sommes en face de deux "clients" à qui l'on va facturer une prestation de duplication d'un flux de réseau :
1) L'ANSSI que l'on ne présente pas sur ce forum;
2) La personne mentionnée aux " 1. ou 2. du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique";
Autrement dit, une poignée de fonctionnaires relevant de l'ANSSI, la totalité des opérateurs FAI et la totalité des entreprises (ou des particuliers) diffusant du contenu numérique (donc potentiellement victime de contrefaçon ou de DOS) sont intéressé par cet arrêté.
Au bas mot, des centaines de milliers de personnes concernées y compris : les personnes physiques ou morales qui assurent, même à titre gratuit, pour mise à disposition du public par des services de communication au public en ligne, le stockage de signaux, d'écrits, d'images, de sons ou de messages de toute nature.
Mais bon, je le dis une fois encore, je peux me tromper… Toutefois, si un modérateur de ce site pouvait confirmer ou infirmer le précédent paragraphe, ce ne serait pas de refus.
Pas besoin d'être bien introduit dans le milieu, il y a pas mal de choses disponibles quand on accepte de lire un peu le journal officiel :)
Ben oui, et comment ai-je eu connaissance de ce texte si je ne suis pas un lecteur du JO ? D'autre part dire que les armées relèvent du Gouvernement c'est ignorer que le Chef des armées n'est pas le Premier ministre mais le président de la république. Et même certains fonctionnaires, comme les préfets, ne sont pas sous l'autorité du Premier ministre ou d'un de ses ministres mais directement sous celle du Président (qui signe personnelle le décret de nomination desdits préfets.)
En tant qu'ancien militaire (malgré moi, pour cause de Service nationale) et en tant que civil ayant été toute sa vie professionnelle sous tutelle militaire, je puis assurer qu'il y a loin, très loin, de la théorie du Journal officiel à la vraie vie. C'est pour ça que je suis preneur d'avis de personnes sachant réellement de quoi on parle ; ce qui ne me semble pas être la cas pour vous. Mais, je peux me tromper…
La police judiciaire n'est pas la seule organisation policière. De même les services de renseignement ne sont pas uniques. Certains relèvent du gouvernement, d'autres des armées.
Un opérateur d'importance vitale intéresse tout autant les autorités civiles que militaires. Et la frontière est vague entre ces deux autorités. La notion de réseau interne à de grands groupes (tel qu'EDF ou Airbus) est une vue de l'esprit à l'heure du Cloud. D'autant que leurs employés sont géographiquement dispersés à travers la planète sans parler de leur nationalité.
Le tarif exposé par le texte me semble être une base de remboursement aux prestataires du Cloud qui assumeraient l'externalisation partielle des services informatiques des opérateurs d'importance vitale.
Mais si quelqu'un d'autre, bien introduit dans ces milieux, a un autre avis, je suis preneur.
Oui, je suis d'accord sur le fait que mon titre sous-entend "écoutes téléphonique" et donc n'est pas approprié.
Mais, attention, ce texte est sous double-signature ! Le premier signataire représente le monde de la défense alors que le second représente celui du business.
Un rapide survol des textes en référence confirme cette double casquette. Mon sentiment (mais je ne suis pas qualifié en la matière) est que ce texte est d'une portée extrêmement générale (en matière de communication, les conversations téléphoniques sont intégrées dans les trames Ethernet) et vise tout autant à la lutte contre l'espionnage (militaire ou industriel) ou le sabotage que la lutte contre la contrefaçon.
Ma première idée de titre était "1984, Big Brother is watching you." mais j'ai trouvé que ça faisait trop parano.
Probable que ce choix de supporter moins de trucs serait de nos jours plutôt supporté par "pas assez de ressources" ou "la flemme" (bon, la, je troll, certes) qu'un argument de sécurité.
Le blocage du port 70 par Firefox est assez récent (j'ai la flemme de retrouver la date mais ça doit dater de 3 ans) et ce n'est pas l'argument de la sobriété qui a été invoqué mais un risque de sécurité. Il est à noter que les gens de Firefox n'ont pas expliqué en quoi Gopher craignait ni qu'il me semble n'exister aucune littérature sur ce soupçon de sécurité. Par contre il est bon de rappeler que le premier moteur de recherche de l'histoire du Web était le Veronica du monde Gopher (il existe toujours !) et que le fait de bookmarquer les ressources au niveau de chaque site permettait de lui dispenser de lire l'intégralité des ressource pour en tirer les mots-clés. C'était donc rapide, léger et efficace. Si l'intégralité des ressources du Web d'aujourd'hui étaient décrites par chaque site au format Gopher, Google (partenaire de Firefox) aurait du souci à se faire pour son modèle économique. Nonobstant ce qui précède, loin de moi l'idée que les gens de Firefox aient pu y songer.
Perso, j'ai du mal a m'y mettre, parce que je ne comprend pas trop la logique derrière. Ça semble attractif, si on passe au-delà de l'aspect "mode texte brut" qui, comme tu le dis, est plutôt lié au fait que ça soit anté-diluvien (par rapport à l'histoire de l'informatique, hein).
Bon, c'est exactement la remarque que je craignais : Gopher est un protocole pas une application ! Alors, que l'on soit clair : gopher n'est pas une sorte de navigateur en mode texte. Certes il existe et il a existé des navigateurs Gopher en mode texte. Mais aussi des navigateurs Gopher en mode graphique et même en 3D dans les années 90.
Gopher se décline en deux versions :
La plus ancienne est l'équivalent des marques-pages des navigateurs Internet d'aujourd'hui. Un site Gopher première génération est juste un serveur qui crache un "site map". Ensuite avec un navigateur Gopher (graphique ou non) on clique sur la ressource qui peut être un fichier sur un disque dur quelque part ou un service (du genre telnet 3270 du monde IBM). Si le fichier est une page "text/html", la page Web s'affiche. Si c'est un fichier texte plat, il est le remplacement d'un serveur ftp.
La seconde version (Gopher+) complète la première. Si on clique sur une ressource, il est possible de connaître ses variantes. Par exemple, ici sur LinuxFr, chaque ressource existe sous les formats "epub" et "markdown". Un navigateur Gopher peut être réglé par un utilisateur pour privilégier les formats PDF, par exemple. Ou bien, sur un site de vidéo en ligne, de privilégier par avance une définition en fonction de la qualité de la connexion. Et aussi, à chaque fichier est associé des métadonnées comme la licence, la taille, les mots-clés… Rien que cet aspect (les métadonnées) avec Gopher+ est hautement intéressant. Certes les en-têtes HEAD des fichiers HTML (ou EXIF pour les images) emportent certaine de ces métadonnées mais pas toutes. Avec la seconde mouture de Gopher, on peut adjoindre un nombre illimité de métadonnées à n'importe quelle ressource (à la "Dublin core").
Si c'est "juste" implémenter un outil graphique, je me demande a quel point ça peut être complexe
De ce qui précède, un navigateur Gopher moderne se doit d'être capable d'afficher n'importe quelle page HTML qui a été sélectionnée depuis le "site map". Ce qui serait facile à faire à partir d'un navigateur existant puisque Gopher n'est jamais que l'affichage d'une page bookmark distante. Et Gopher+ un "clic droit souris".
Mes explications ont-elles été suffisantes ou bien dois-je développer certains points ?
Je suis quand même surpris que, justement, gopher n'ait pas été abordé. Ça aurait été un sujet de réflexion intéressant, dans le sens ou gopher est resté a une époque ou l'on faisait attention aux ressources, contrairement au web. Je n'ai personnellement jamais réellement expérimenté gopher, parce qu'il est difficile d'y trouver quoi que ce soit sans info initiale.
Concernant les informations sur les protocoles Gopher, j'ai déjà contribué à plusieurs publications sur DLFP et écrit un article publié en mars 2011 dans GNU-Linux-Magazine qui est en libre téléchargement ici. Il y a aussi les notices Wikipédia fr et en.
Malgré tout, je suis d'accord sur le fait que l'on puisse voir le monde Gopher comme étant un monde dissimulé (d'ailleurs Gopher vient de l'animal souterrain éponyme !).
Peut-être est-ce du à la sociologie de ses pratiquants, presque exclusivement des particuliers, distinguables en deux groupes :
Les "politiques" se complaisant dans l'underground,
Les "techniciens", vivant en zones rurales, affligés d'une connexion Internet bas débit.
Le premier groupe a un niveau de culture informatique proche de zéro et se contrefiche de la technique Gopher pourvu que leurs messages puisse circonvenir les canaux GAFA.
Le second groupe a un niveau de culture technique plus élevé (assez souvent des radio amateurs) mais encore insuffisant pour produire un navigateur Internet moderne depuis la fin du support de Gopher par Firefox sous motif de sécurité (au sens de "security" semble-t-il). Dans la pratique, il ne reste que le vieux navigateur en mode texte "Lynx".
Toujours dans la pratique, les actuels sites Gopher ont une forte similitude aux anciens BBS et sont donc attractifs en tant que tel. Ce qui peut expliquer l'improbable coexistence des susdits groupes.
Je ne vois pas Gopher comme étant une alternative au sites HTTP/HTML actuels mais un complément (déjà expliqué ici). Mais la vérité oblige à dire que c'est une techno qui peut vraiment faire du mal aux GAFA.
Je mentionnais dans mon commentaire précédent le projet Hyper-G. Sur le coup, je n'avais pas trouvé de lien le décrivant mais, maintenant oui (en anglais).
Les personnes qui seraient intéressées par l'histoire du Web dans les années 90 gagneraient à lire les messages postés sur comp.infosystems.gopher . Par exemple, Google les met en ligne. Évidement, c'est copieux mais instructif. En remontant au 25 sept 1995, on a une petite bombe hautement géopolitique.
À titre personnel, je considère que les trois grands compétiteurs du Web de l'époque (Gopher, WWW et Hyper-G), s'ils jouaient dans le même cyberespace, possédaient chacun une technologie qui ne faisait pas exactement la même chose. Grosso modo : La spécialité de WWW est l'édition électronique de document, Gopher est pour la gestion des métadonnées des documents ET des ressources, et Hyper-G est (ou plutôt était) pour la gestion en mode cluster des documents.
J'ajoute aussi que le protocole Gopher est mentionné nommément dans les rfc 1945, 2068 et 2616 portant sur HTTP. La rfc 7230 dit encore "HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems.". En conséquence de quoi, je suppose qu'il serait légal de transporter le protocole Gopher via HTTP voire HTTPS. Il est possible que ça se soit fait, je n'en sais rien sinon que j'ai vu passer cette suggestion de "Gopher over HTTP" dans une discussion en ligne (je ne sais plus où, ni quand).
Plutôt que d'essayer vainement de repopulariser un protocole à moitié oublié et mal supporté
La vérité historique est que le protocole Gopher a été officiellement déclaré obsolète par son équipe de développeurs menée par Mark P. McCahill au profit de son successeur Gopher+. Ce second protocole est considérablement différent du premier, fait plus de choses, et serait parfaitement intégrable dans une page HTML (au niveau de la gestion des barres de menu).
Une autre vérité historique est que l'univers du Web incluait bien le monde Gopher, ne serait-ce que sur deux points :
1. C'est le monde Gopher qui a porté à la connaissance du public le World Wide Web,
2. McCahill collaborait avec Tim Berners-Lee (voir le lien ci-dessus).
On fait trop souvent confusion entre le mot "Web" qui était un ensemble de protocoles et d'applications avec le seul nom d'une application nommée "Word Wide Web". Gopher était bien un acteur du Web, parmi d'autres. Il n'y a jamais eu d'hostilité, à l'époque, entre le monde Gopher et celui du www. "WWW" a remplacé Gopher de façon naturelle, pas à la suite d'une quelconque guerre. Malheureusement, personne n'a vu, à l'époque, les fantastiques perspectives qu'ouvrait son successeur Gopher+. Et je crains que les aficionados d'aujourd'hui de la première version de Gopher n'aient toujours pas une vision claire de la seconde.
je préférerais qu'on se concentre et popularise des sites webs moins lourds/inaccessibles.
Reste la mentalité "fromage ou dessert" qui veut que l'on choisisse l'un ou l'autre à la fin d'un repas (Gopher vs WWW). Et si l'on prenait les deux ?
J'attends avec impatience que GNUStep retrouve sa splendeur grâce à un navigateur Gopher dernier cri…
Tss, tss… On peut télécharger le module OverbiteFF pour avoir un navigateur Gopher dans Firefox !
Il est vrai que le mainteneur de ce module a des soucis avec les changements de techno pour Firefox. Mais, si l'on en croit cette liste de discussion, il se trouve encore quelques uns à s'intéresser à ce protocole qui est presque aussi ancien que HTTP.
Autrement dit, puisque les IO dominent le temps CPU, un langage interprété doit être capable de faire aussi bien qu'un langage compilé
Nous sommes au cœur du sujet : "(…) un langage interprété doit faire aussi bien qu'un langage compilé".
L'informatique est-elle une science ou une techno ?
Dans le premier cas, est-ce une science spéculative. ou bien une science expérimentale ? Pour le premier, nos écoles et nos instituts en tous genres regorgent d'enseignants très bavard sur le sujet. Dans le second, on trouve beaucoup moins de bavards.
En seconde hypothèse, avons nous une alternative carrément différente avec les logiciels disponibles à la vente en matière de langage de programmation ? Ainsi, y a-t-il des interfaces graphiques natives écrites autrement qu'avec C/C++ ? Avons-nous des suites bureautiques écrites autrement qu'avec C/C++ ? Et ainsi de suite.
Alors reste la presse spécialisée. Qui reste très consensuelle. Et si la vérité établie ne collait pas à la réalité ? Et si les langages de programmation vedette n'étaient que daube ? Tant qu'on n'a pas essayé, c'est la bouteille à l'encre.
Tu as des benchmark à l'appui pour ce que tu dis ? Je serais vraiment interessé.
Non, je n'ai rien sous la main aujourd'hui. Mes évaluations datent de tant d'années… En plus comme le matériel évolue (surtout avec l'arrivée des SSD) tout est absolument à refaire. J'ai, de toute façon, besoin de faire des tests tant sur ma machine que sur celle de l'hébergeur de mes blog statiques.
Aussi ai-je créé sur GitHub un banc de test GPL_Torture.
J'y mettrai le source Fortran d'un test qui se passera en deux temps :
Mise en mémoire de la version texte de la licence GPL-v3 puis création de n fichiers texte identiques et dont le nommage sera 1.txt, 2.txt, 3.txt … n.txt. Le temps de création de ces fichiers sera un test en écriture.
Lecture des fichiers texte créés, un par un, et ajout des balises HTML pour en faire des pages HTML dotées d'un titre reprennant le n° de fichier, d'un menu avec les liens "home - prev - next -last", et le texte de la licence elle-même encadrée par les balises PRE. Leur nommage sera 1.html, 2.html, 3html … n.html . Ce sera donc un test en lecture - écriture.
L'intérêt de la chose, outre de voir les capacités de son système, est que l'on peut zipper les fichiers HTML et les uploader chez l'hébergeur. Ainsi on peut voir la latence de son prestataire.
En toute humilité je n'ai pas le niveau intellectuel suffisant pour avoir saisi, ne serait-ce que le sens général, du concept de fusion en Haskell à la lecture du lien. Certes l'exemple qui y est donné avec le module Data.Text me parle un peu plus car c'est pile dans le domaine que doit traiter un moteur de blog.
Mais, à ce que je suppose, on n'est plus dans le domaine du langage de programmation mais dans celui de l'optimisation par le compilateur. En ce cas, quel que soit le langage compilable en natif la question se pose à l'identique. Alors, toujours si j'ai bien compris, les langages compilables permettent usuellement d'ajouter des directives de compilation ; ainsi en fortran où l'on peut déclarer une fonction comme étant "pure", "elemental" ou même "impure" (et aussi, maintenant, la gestion du parallélisme).
Que Haskell soit tout à la fois un langage de programmation et un compilateur est une nouvelle donne. Et elle est intéressante car elle peut intégrer plus finement la phase d'optimisation. Le compilateur Fortran que j'utilise est GCC et suit à peu près le même processus que C dans le sens où il converti le source en Gimple puis en assembleur. Il s'en suit que l'on doit posséder de bonne base théorique en informatique pour produire un exécutable performant. Et ensuite c'est l'édition de lien et, là encore, le bagage intellectuel requis est assez lourd (du moins pour ma petite tête !). J'appréhende le jour où je devrai me plonger dans l'apprentissage du LTO…
Le gros avantage des interpréteurs est qu'ils lissent toutes ces contingences puisqu'ils créent leur univers et donc les règles qui leur sont propre ; c'est excellent pour la portabilité d'un logiciel. A contrario, en natif, la compilation et l'édition doivent être ajustées à la machine.
Donc, je suis (et je l'étais déjà avant) d'accord avec toi à 100% sur le fait qu'un langage interprété peu s'approcher de la performance globale d'un langage compilé non optimisé pour une machine donnée. Et je suis tout à fait conscient que l'optimisation "aux petits oignons" n'est guère portable et nécessite tout autant du temps et le bagage intellectuel adéquat. Et je suis pleinement d'accord qu'une perte de 10% de performance est acceptable et que c'est immensément compensé par la facilité de mise en production dans les délais les plus courts. Et je n'ignore pas non plus que absolument tous les exécutables sous Linux tournent sous l'interpréteur ELF…
Là où j'ai un souci avec les interpréteurs en général (mais je n'ai jamais essayé Haskell donc je n'ai pas d'opinion à son sujet) c'est quand on a à générer un très grand nombre de fichiers en lecture / écriture. En ce cas l'interpréteur doit sortir de son monde intérieur pour se tourner vers le système d'exploitation et il me semble bien que c'est une situation où les performances s'effondrent. (Là encore, je suis un modeste autodidacte et peut-être que je dis des sottises.) Alors oui, la parade consiste à charger en mémoire vive lesdits fichiers et les recracher en bloc après traitement. Mais ce n'est pas toujours possible s'ils sont très volumineux et nombreux. En ce cas, on tombe dans un traitement séquentiel par lot et la performance tombe à cause du double traitement des I/O (une fois dans l'interpréteur et l'autre dans l'appel système sous-jacent).
Dans le cas de mon moteur de blog, je me suis fixé comme règle que le nombre de fichiers de données traitables ne doit être limité que par le système de fichier. Ou, à tout le moins, de générer les billets de blog (stockés en fichiers plats) sur la base d'un post par jour pendant 30 ans. Ce qui fait dans les 10950 fichiers individuels pour les données. Et je fais mes tests sur cette base en générant un blog où toutes les pages contiennent la version HTML de la GPL. Sachant qu'un billet de blog a sa déclinaison en version imprimable, qu'il y a les pages d'indexation année par année et mois par mois, on arrive à nombre de fichiers à générer conséquent. Autre règle que je me suis fixé : une empreinte mémoire minimale. aussi n'ai-je en mémoire globale durant le traitement que les métadonnées des billets limitées aux dates et titres.
Ceci étant dit, je le répète, je n'ai pas d'opinion sur Haskell en particulier et je suis dans le flou le plus total quant à la performance des interpréteurs en lectures/écritures massives. Je ne sais même pas s'il est procédé des essais comparatifs sur des PC familiaux.
Le fil de discussion portait sur un langage de programmation précis et non pas sur les moteurs de blog. Incidemment la conversation a dérivée sur la vitesse à l'exécution d'un code Haskell. L'auteur de la dépêche disait :
Haskell (et GHC) sont capable de générer du code natif assez performant. Dans mes applications habituelles, je suis, dans le pire des cas, 3x plus lent que du code de calcul C++ pure, mais souvent je suis dans les 10/15% plus lent.
et, dans un autre commentaire :
Si tu te qualifies d'hobbyiste, je suis près à parier que n'importe quel langage (et implémentation) doit pouvoir convenir à ton besoin tant que tu n'as pas des problématiques d'embarqué ou de performance particulières.
À l'époque où j'ai débuté l'écriture de mon moteur de blog, il en existait déjà bien d'autres. Je participais à la traduction de l'un deux et c'est là que j'ai pris conscience qu'il ne passait pas l'échelle au-delà d'une centaine de billets postés. Aujourd'hui, avec les disques SSD et l'augmentation des performances globale des machines, il redevient utilisable. Ceci était le premier point.
Le second point, était que l'on devait pouvoir poster un billet dans le cadre d'un voyage long et lointain depuis un cyber café sur une machine Windows. J'ai choisi de le rendre compatible avec Putty. Incidemment, la liaison pouvant être rompu, le logiciel devait pouvoir faire avec. Ceci impliquait d'abandonner la notion de session. Or opter pour une régénération partielle imposait un suivi de session.
Le troisième point était que je voulais un onglet "archive" plus efficace que ce que l'on voit avec habituellement où l'on n'indexe les billets que par mois mais sans les classer au préalable par année. Au début ça le fait mais au bout de dix ans on a 120 mois. Je voulais en plus pouvoir faire un classement jour par jour dans un mois donné. (Ce n'est pas encore implémenté dans mon projet.)
De tout ce qui précède, la solution la plus sûre était celle d'une régénération totale à chaque mise à jour. J'ai eu la colossale surprise, en testant les billets rapatriés depuis des blogs tenus depuis longtemps par de grands bavards, de voir que le temps mis à générer la totalité était ridiculement bas. Ce qui se passe est que l'on a des I/O massives et que passer par un interpréteur ça ralenti considérablement. Mais en natif, il m'est apparu que le surcout d'une génération totale comparée à une génération partielle était infime. Compte tenu de mon problème de ne pas pouvoir assumer un suivi de session ça tombait bien.
Voilà la raison de mon entêtement au sujet des performance en vitesse. Reste un dernier point qui me fait lorgner ailleurs qu'avec Fortran : l'interface graphique. Sous Windows, on peut faire des fenêtres avec Fortran aisément mais pas aussi facilement sous Linux. Donc soit je mets à la programmation mixte soit je vais voir ailleurs. Je n'ai pas pris encore de décision.
WordPress n'est pas un générateur de pages statiques, donc ce n'est pas comparable. De plus, les systèmes dynamiques utilisent généralement un cache qui évite d'avoir à recréer les pages.
WordPress est archi dominant sur le marché des moteurs de blog. Si tu ne me crois pas, va sur le site de OVH (par exemple) et regarde combien de logiciels de blog il propose : tu as le choix entre WordPress et WordPress. Si on veut comparer un quelconque moteur de blog, le bon sens le plus élémentaire est de le faire par rapport à WordPress. Cependant la vérité oblige à dire qu'il n'est seulement en mode dynamique que pour la partie HTML. Les illustrations, elles, sont traitées comme les pages de blog statique. Autant dire, sur un blog banal, la partie générée par PHP-MySQL ne représente pas la majorité de la bande passante consommée. Concernant la mise en cache d'un blog généré dynamiquement, elle est tout aussi faisable (et même indiquée !) pour un blog en pages statiques.
Le temps de génération des pages statiques n'a pas beaucoup d'importance. Prendre une 1s ou 1mn pour la mise à jour quotidienne d'un blog, ça ne change vraiment rien.
Honnêtement, tiens-tu un blog que tu héberges toi-même ? Si oui, peux-tu me jurer que tu rédiges tes billets d'un façon si absolument parfaite que jamais tu ne ressentes la nécessité d'une correction ? Personnellement, je suis dans l'incapacité de rédiger ma copie sans de nombreux brouillons jetés à la corbeille. Dans ce cas, entre un logiciel qui prend une seconde et celui qui prend une minute ça fait une sacrée différence. Mais bon, si tu es un super écrivain, ça peut le faire. Ah, au fait, il est où ton blog ?
Et là aussi, les générateurs statiques modernes ne recalculent que les pages qui ont changé.
Ça, c'est une remarque pertinente ! Elle me met du baume au cœur à un point que tu ne peux pas imaginer… Je suis bien d'accord, absolument tous les blogs statiques que j'ai pu voir sont en mode page unique. C'est pour ça que j'ai créé mon propre moteur ! Avec le mien, les pages sont liées les unes aux autres. Ce qui veut dire que si l'on est sur une page, on peut cliquer sur celle qui précède ou qui suit. Ce qui veut dire qu'à chaque fois que l'on intercale une page, il faut générer au moins deux autres. Et si en plus on pousse le vice à proposer un menu pour retrouver un billet à une date donnée, il faut tenir à jour l'index des pages. Donc, le plus simple à coder est de tout regénérer. On peut faire une regénération partielle comme avec NanoBlogger autrefois. Mais, pour l'avoir vécu, c'est source de bien des soucis. Et comme si le vice précédent ne suffisait pas, je propose aussi une version imprimable de chaque billet. La double peine. Alors, crois-moi, Fortran est bon pour moi.
La "grâce d'un langage compilé" n'a aucun sens ici. Personnellement, je génère des docs statiques avec sphinx qui produit également les diagrammes UML, les graphes, le code formaté et les équations inclus dans ces docs; l'interpréteur python qui est utilisé pour cela n'a jamais été un problème (par contre bon courage pour coder un outils équivalent en fortran).
Absolument d'accord avec toi. Python bénéficie d'une somme considérable de modules en tout genre et c'est sa qualité première. (Peut-être même la seule ?). Mais le Fortran moderne est un tout autant un langage orienté objet et tout autant modulaire. La facilité à développer en Python vient surtout de son environnement : plus il y a de modules, de dépôts de source, d'outils en tout genre, plus c'est facile de créer de nouveaux modules. Partir from scratch est une toute autre affaire ! Pour Fortran, il n'existe guère que de vieilles bibliothèques scientifiques et quasiment aucun module écrit au 21ème siècle. Donc, rien que pour parser un fichier de configuration, une ligne de commande. Alors il faut agiter ses petits doigts sur le clavier. Mais bon, c'est ce que j'aime. Je ne suis pas payé pour, c'est pour le fun !
Concernant l'intérêt des interpréteurs, je n'ai rien n'a ajouter de plus de ce que dit Backus dans son papier The IBM Speedcoding system (Journal of the ACM, Volume 1, Issue 1, Janv 1954, pp. 4-6). Leur intérêt est évident. Et ils existent depuis plus longtemps que le premier langage de programmation jamais commercialisé par la même équipe du susdit.
Cependant, malgré leur indéniable (et irremplaçable) utilité, les interpréteurs ont leurs limites. Car si une fonction est codable en soft, elle est tout aussi parfaitement codable en hard dans un CPU. Et là, la question des performances se pose. L'équipe qui a créé Speedcoding est la même qui a créé peu après Fortran : la technologie ayant permis de coder en dur une unité de calcul sur les flottants, il n'y avait plus de raison de continuer avec un interpréteur. Pour ceux qui ont connu les premiers PC d'avant les Pentium, ils étaient livrés avec un coprocesseur optionnel. Ceux qui n'avaient pas les sous choisissaient le modèle sans qui faisait tout aussi bien mais plus lentement car passant par un émulateur.
Pour donner un exemple vécu et que j'ai développé sur ce site au travers plusieurs journaux : le cas d'un générateur de pages HTML pour un blog statique. Il en existe une multitude mais presque tous codés sous interpréteur. Quand on arrive à une certain nombre de billets de blog, le logiciel rame. La seule issue est de coder en natif. Donc, à un moment, il faut bien mettre les mains dans le cambouis. L'alternative existe : vous prenez WordPress, vous installez une base de donnée qu'il vous faudra maintenir, vous mettez PHP qu'il faudra bien mettre à jour de temps à autre et vous croisez les doigts pour que vous ne fassiez pas pirater. Personnellement, je me suis mis au Fortran pour la seule nécessité de développer un moteur de blog statique. Il est capable de générer une centaine de pages HTML là où WordPress en génère une seule pour le même laps de temps. Et mon moteur de blog n'est pas hackable car il ne réside pas sur le site Web. Et je n'ai pas besoin d'ingurgiter une dose massive de SQL et PHP pour savoir comment marche le bousin. Tout ça par la seule grâce d'un langage compilé. Mais j'aurais pu tout aussi bien opter pour ADA car mon passé en Basic me permettait un auto apprentissage des langages "verbeux". Je précise qu'à l'époque je ne connaissais pas de compilo Basic sous Linux et que je ne voulais plus entendre parler de Windows ni utiliser de Basic en mode interpréteur. Sur ce dernier point, j'ai été échaudé par le fait que l'interpréteur rattrapant assez facilement des erreurs d'écriture logicielle, et même fournissant des avertissements (cas du QBasic de MS) là où un compilo natif refuserait d'aller plus loin, on n'est pas assez rigoureux dans son codage. En natif, les erreurs détectées sont implacables ! Même si on ne les voit pas toutes de prime abord.
À bon escient, les interpréteurs ont leur utilité. Là où il y a une dérive, c'est quand une organisation humaine (typiquement une université ou un industriel du logiciel) fait la promotion d'une nouvelle-machine-virtuelle-qui-va-bouleverser-la-planète c'est qu'elle entraîne dans ses filets une multitude de gens qui deviennent comme les adeptes d'une nouvelle religion. Le nombre de ces miroirs aux alouettes brisés ou encore scintillants est inouï.
Concernant la distinction entre développement et programmation, elle me semble évidente ! Dans un cas on assemble des composants logiciels écrits par d'autres, dans l'autre on tape avec ses petits doigts sur le clavier pour fabriquer un par un lesdits composants. C'est la même différence qu'entre ouvrir une boite de conserve de petits pois et les réchauffer en 3 minutes ou les prendre à l'état cru, les écosser et attendre 3/4 d'heure que ça cuise. Au quotidien, j'opte pour la conserve. Mais je sais aussi le faire à l'ancienne ! Et je sais même aussi les faire pousser !
Selon quels critères qualifies-tu un langage d'impasse
Il est vrai que les langages interprétés sont au moins aussi fiables que ceux compilés. Mais, en "mode parano", leur avenir est suspendu au bon vouloir de soit un très petit comité (pas toujours ouvert sur la communauté), soit d'un industriel qui peut mettre la clé sous la porte du jour au lendemain. Et le miroir aux alouettes est alors brisé.
Dans le cas d'un langage compilé le risque est mieux réparti. D'une part parce que tant que le CPU et la plateforme continue d'exister, la maintenance est possible même si son fournisseur disparaît. Et dans la mesure où il normalisé, il devient légal de créer un compilateur substitutif. Si une machine virtuelle, breveté ou sous licence, a une faille de sécu et qu'elle n'est plus maintenue c'est la mort du petit cheval.
C'est, pour moi une première impasse. La seconde concerne la création de nouveaux composants logiciel en assemblant des composants de base. j'ai évoqué le cas du processeur de texte LaTeX où l'on l'empilement de macros peut produire des effets indésirables. Ah, j'aimerai avoir une connaissance a minima du JavaScript pour donner d'autres exemples illustrant les inconvénients de la stratification logicielle…
Merci pour ces précisions ! Effectivement les FFI sont chose intéressante pour la programmation mixte. Ça existe maintenant en Fortran (blocs INTERFACE). Pas plus tard qu'il y a une semaine, je me suis amusé à jouer avec gettimeofday() de la libc (voir ici).
Mon agacement au sujet des langages interprétés (que ce soit avec interpréteur externe ou runtime embarquée dans l'exécutable) est qu'ils font confusion entre les notions de programmation et de développement. Ayant biberonné avec Basic, j'ai eu à pâtir de cette ambiguïté et en définitive éprouvé des frustrations dès que l'on pousse le langage dans ses limites. Je pense qu'il est malhonnête de présenter un langage comme relevant de la programmation alors qu'il est définitivement limité au développement. Ou, pour parler plus clairement, si l'on souhaite étendre les fonctionnalités de base par modules à l'aide de ce même langage, on provoque des instabilités au delà d'un certain niveau d'imbrication des modules à l'intérieur des modules. Ce genre de choses se voit couramment en TeX/LaTeX. Ceci n'a pas trop d'importance pour quiconque ayant fait de longues études en informatique (car pouvant toujours se rabattre sur le langage C ou un assembleur). Mais, pour un hobbyiste de mon genre, quel temps perdu à apprendre un langage qui se révèle être une impasse !
Du peu que je connais de Fortran, j'ai l'impression que Haskell a une syntaxe et un système de type bien plus agréable à utiliser, mais je peux me tromper ;)
Le langage Fortran évolue à toute vitesse. Il est bien difficile de se faire une opinion sur des bases anciennes… Rien que l'introduction des modules (et tout récemment des sous-modules) change totalement la donne en génie logiciel. Mais on ne trouve que très peu de code lisible en ligne qui soit rédigé en Fortran moderne comme ici (un module pour les fichiers JSON).
Ceci me fait prendre conscience qu'il serait opportun de rédiger une dépêche sur le Fortran moderne. Mais, clairement, je n'ai pas le niveau ! Cependant brosser un historique de ce langage sexagénaire, au travers d'une dépêche sur ce site, devrait être à ma portée.
[^] # Re: Performance des compilateurs libres
Posté par Denis Bernard (site web personnel) . En réponse au journal Des nouvelles de Fortran. Évalué à 3.
Concernant les performances des compilo, c'est un peu la bouteille à l'encre… En effet, tous les compilateurs Fortran sont en fait des compagnons aux compilateurs C et C++ et ont en commun la libc. (Est-il exagéré dire que gfortran n'est jamais qu'un frontend de la libc ?)
Il y a quelques années, j'ai été dans l'impossibilité de faire tourner mon moteur de blog sur une machine distante car la glibc avec lequel mon binaire avait été compilé refusait le kernel trop ancien. J'ai alors procédé à une recompilation (en édition de liens statique) sur la distro Alpine Linux sachant que sa libc était "musl". Cet exécutable fonctionnait parfaitement sur ma Gentoo sous glibc et tout aussi bien que sur la machine distante fossilisée. Or, sur ces deux machines, la rapidité d'exécution était absolument surprenante. Évidement, sur un seul job de quelques secondes, il est impossible de conclure. Mais pour un job sur dix heures…
[^] # Re: Pas que le calcul
Posté par Denis Bernard (site web personnel) . En réponse au journal Des nouvelles de Fortran. Évalué à 4.
Le module "Varying length character strings" n'est plus d'actualité aujourd'hui depuis que les allocations dynamiques sont devenues possibles.
Il y a donc deux possibilités pour la déclaration des chaînes de caractères :
1. À l'ancienne, avec une longueur prédéterminée (option LEN);
2. Avec l'option ALLOCATABLE pour une longueur variable inconnue à la déclaration.
Dans les deux cas, il faut procéder à leur initialisation. Cette initialisation doit être précédée du mot clé ALLOCATE pour les chaînes de longueur variable. Et si cette allocation est faite en dehors d'une procédure, ne pas oublier DEALLOCATE (l'équivalent de free() en C) pour les fuites de mémoire. Tout ceci est décrit dans mon article de GLMF de sept 2019 à la page 46.
Depuis F77, il y a eu d'autres procédures prédéfinies (l'équivalent de la "libc") ajoutées concernant les manipulations sur les chaînes comme ADJUSTL et ADJUSTR qui permettent de justifier à droite ou à gauche une chaîne. À INDEX ont été ajoutés SCAN et VERIFY.
Du fait des allocations dynamiques, le recours à Valgrind est plus que recommandé. Au passage, il permet de dépister des variables non initialisées qui n'ont pas été dépistées par gfortran. À noter que Valgrind a ses exigences concernant la compilation de la libc. (Il est très possible que Valgrind ne soit pas immédiatement utilisable sur votre distribution.) Et, tant qu'on y est, il y a aussi gdb. Ces deux outils sont contraignants pour la machine hébergeant la chaîne de compilation. Personnellement, je suis sous Gentoo et je suis obligé d'activer l'option [FEATURES="splitdebug"] dans "/etc/portage/make.conf". Ceci fait que tout exécutable de la distro est scindé en deux : l'exécutable strippé étant dans "/usr/bin" et la partie contenant les symboles de débug étant dans "/usr/lib/debug". Mais ceci concerne seulement les sources packagées par la distro ; penser à activer les options de compilation GCC "-Og" et "-ggdb" pour vos propres compilations.
# Pas que le calcul
Posté par Denis Bernard (site web personnel) . En réponse au journal Des nouvelles de Fortran. Évalué à 10.
Tout d'abord, merci pour le journal ! Mais je me permets d'apporter la contradiction… (On est quand même sur LinuxFr !)
Je suis l'auteur de deux des sept contenus taggés en référence : ils faisaient la promotion d'un moteur de blog rédigé en Fortran moderne. De toute évidence, nous ne sommes pas là dans des jobs de calcul intensifs prenant des heures (voire des semaines !) mais sur des traitements de l'ordre de la seconde. Et il n'y a point de maths, juste de la manipulation de chaînes de caractères.
En effet, depuis Fortran 77, la norme a introduit le type caractère et une capacité de traitement sur les fichiers assez conséquent. Fortran 2003 et 2008 ont considérablement étendu la capacité de traitement des chaînes de caractère avec la gestion de l'unicode, les allocations ET les réallocations dynamiques. Comparé au langage C, jouer avec les lettres en Fortran c'est un délice. (Je suis en train de coder un projet qui impose des routines en C pour des accès Internet et, vraiment, quand on doit se coltiner des concaténations de chaîne en C, c'est grosse galère !)
Fortran a eu un concurrent autrefois : Basic. Ce qui était alors reproché au vieux Fortran c'était sa concision héritée des cartes perforées. Avec la norme F90-F95, ce langage s'est fortement rapproché de l'ergonomie de Basic. Depuis les années 2000, la programmation orientée objet en a fait un outil vraiment polyvalent.
Oui, Fortran est fort en maths. Mais pas que… C'est pour tordre le cou à cette idée reçue que j'ai commis un article dans Linux Magazine l'été dernier.
Accessoirement, J'ai longtemps partagé la croyance ci-près :
Sauf que Cray existe toujours et a un compilateur Fortran prétendument à jour de F2008 et presque entièrement de la dernière norme F2018. Je n'ai pas vérifié si c'était vrai car leur compilo ne tourne que sur leur matériel. (Je n'ose même pas imaginer leurs tarifs…)
Enfin je profite de l'occasion pour suggérer qu'un codeur, ayant la double compétence en C++ et Fortran, ponde un article comparatif entre ces deux langages tant ils semblent partager les mêmes fonctionnalités. (Je ne sais lequel est le plus puissant des deux mais je suis certain que la facilité d'apprentissage est bien en faveur de l'ancêtre.)
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 1.
Le Journal officiel a publié postérieurement à la parution de l'arrêté un document qui met fin à toutes mes spéculations. Je viens de mettre en ligne le correctif.
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 1.
Le Journal officiel a publié postérieurement à la parution de l'arrêté un document qui met fin à toutes mes spéculations. Je viens de mettre en ligne le correctif.
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 1.
À la fin du troisième paragraphe de ma première réponse (le 07/03/20 à 21:17) :
il y a "la lutte contre la contrefaçon".
Le vol d'image ou le téléchargement sauvage de film ne relève-t-il pas du Code de la propriété intellectuelle tout comme la contrefaçon à l'ancienne ? Et n'est pas une forme moderne de contrefaçon ?
On peut ergoter indéfiniment sur la propriété intellectuelle et tout cela a été largement discuté lors de la loi dite "Hadopi".
Je n'ai pas varié dans mon affirmation qu'il n'y avait pas seulement que l'ANSSI impliqué dans cet arrêté. Dans des temps plus lointains, il y aurait eu deux arrêtés pris chacun par le ministre concerné. Un pour la Défense, l'autre pour le business. C'est le coup de la double signature qui m'a interpellé. Autrefois, un arrêté était propre à une administration. Aujourd'hui, la tendance est à produire moins de textes mais à les allonger considérablement. Ils sont devenus des fourre-tout et la veille juridique particulièrement pénible à assumer.
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 1.
Désolé, je reste sur ma position. Cet arrêté est signé par deux personnes : C. Landais, secrétaire générale de la défense et de la sécurité nationale pour le Premier ministre et T. Courbe, directeur général des entreprises, pour le ministre de l'économie et des finances.
Il me semble que s'il n'y avait que l'ANSSI intéressée, seule la signature de C. Landais aurait été requise. Il me semble que la définition les personnes relevant du 1. du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique sont ce qu'on appelle des "hébergeurs".
Je cite le I-1 :
1. Les personnes dont l'activité est d'offrir un accès à des services de communication au public en ligne informent leurs abonnés de l'existence de moyens techniques permettant de restreindre l'accès à certains services ou de les sélectionner et leur proposent au moins un de ces moyens.
Les personnes visées à l'alinéa précédent les informent également de l'existence de moyens de sécurisation permettant de prévenir les manquements à l'obligation définie à l'article L. 336-3 du code de la propriété intellectuelle et leur proposent au moins un des moyens figurant sur la liste prévue au deuxième alinéa de l'article L. 331-26 du même code.
Mais en lisant l'article L. 321-26 du Code de la propriété intellectuelle :
Après consultation des concepteurs de moyens de sécurisation destinés à prévenir l'utilisation illicite de l'accès à un service de communication au public en ligne, des personnes dont l'activité est d'offrir l'accès à un tel service ainsi que des organismes de gestion collective régis par le titre II du présent livre et des organismes de défense professionnelle régulièrement constitués, la Haute Autorité rend publiques les spécifications fonctionnelles pertinentes que ces moyens doivent présenter.
Au terme d'une procédure d'évaluation certifiée prenant en compte leur conformité aux spécifications visées au premier alinéa et leur efficacité, la Haute Autorité établit une liste labellisant les moyens de sécurisation. Cette labellisation est périodiquement revue.
Un décret en Conseil d'Etat précise la procédure d'évaluation et de labellisation de ces moyens de sécurisation.
les personnes intéressées me semble être alors aussi les organismes de gestion collective des droits et les organismes de défense professionnels !
Les I-2 et I-3 exonèrent l'hébergeur civilement et pénalement en cas d'ignorance d'hébergement de contenus illicite et sa promptitude à faire cesser le trouble.
À ce qu'il me semble, l'hébergeur n'est pas tenu d'inspecter les contenus de ses abonnés. Mais l'hébergeur peut être saisi par toute personne, disons pour des affaires de mœurs, mais aussi en matière de propriété intellectuelle. Dans ce dernier cas, ce n'est pas l'ANSSI qui est compétente mais la Haute autorité au sens du Code de la propriété intellectuelle.
Ce qui explique la double signature de l'arrêté. Quant à savoir le périmètre des organismes de gestion collective, je ne suis pas du tout versé en la matière… Et pour les organismes de défense professionnels, la définition est pour le moins vague et semble laisser un large champ à tous les porte-drapeaux.
Je suppose que si on se fait se fait voler des images mises en ligne depuis son site Internet, le recours devrait se faire auprès desdits organismes de gestion collective et non pas l'ANSSI. OK, et après qui va payer pour faire établir la preuve du piratage ? Je suppose qu'il sera demandé au piraté de donner quelque argent tout comme il le ferait pour un constat d'huissier. Sauf qu'au lieu de s'adresser à l'huissier il devra le faire auprès de la Haute autorité.
De ce qui précède, je persiste à dire que de très nombreuses personnes sont concernées par le tarif de cet arrêté ; à tout le moins, tout titulaire d'un site Web.
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 1.
Revenons à l'arrêté PRMD2004467A.
a) Tableau de l'annexe 1, ligne EH1 : installation de matériel appartenant à l'ANSSI, tarif 100€ ;
b) Tableau de l'annexe 1, ligne EH2 : Installation du matériel appartenant à l'opérateur de communications électroniques ou à la personne mentionnée aux 1. ou 2. du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 (…), tarif 150€ + 99€/mois;
c) Tableau de l'annexe 3 : ligne EH3, enlèvement du matériel appartenant à l'ANSSI ou à la personne mentionnée (…)
De ce qui précède, nous en sommes en face de deux "clients" à qui l'on va facturer une prestation de duplication d'un flux de réseau :
1) L'ANSSI que l'on ne présente pas sur ce forum;
2) La personne mentionnée aux " 1. ou 2. du I de l'article 6 de la loi n° 2004-575 du 21 juin 2004 pour la confiance dans l'économie numérique";
Autrement dit, une poignée de fonctionnaires relevant de l'ANSSI, la totalité des opérateurs FAI et la totalité des entreprises (ou des particuliers) diffusant du contenu numérique (donc potentiellement victime de contrefaçon ou de DOS) sont intéressé par cet arrêté.
Au bas mot, des centaines de milliers de personnes concernées y compris : les personnes physiques ou morales qui assurent, même à titre gratuit, pour mise à disposition du public par des services de communication au public en ligne, le stockage de signaux, d'écrits, d'images, de sons ou de messages de toute nature.
Mais bon, je le dis une fois encore, je peux me tromper… Toutefois, si un modérateur de ce site pouvait confirmer ou infirmer le précédent paragraphe, ce ne serait pas de refus.
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 2.
Ben oui, et comment ai-je eu connaissance de ce texte si je ne suis pas un lecteur du JO ? D'autre part dire que les armées relèvent du Gouvernement c'est ignorer que le Chef des armées n'est pas le Premier ministre mais le président de la république. Et même certains fonctionnaires, comme les préfets, ne sont pas sous l'autorité du Premier ministre ou d'un de ses ministres mais directement sous celle du Président (qui signe personnelle le décret de nomination desdits préfets.)
En tant qu'ancien militaire (malgré moi, pour cause de Service nationale) et en tant que civil ayant été toute sa vie professionnelle sous tutelle militaire, je puis assurer qu'il y a loin, très loin, de la théorie du Journal officiel à la vraie vie. C'est pour ça que je suis preneur d'avis de personnes sachant réellement de quoi on parle ; ce qui ne me semble pas être la cas pour vous. Mais, je peux me tromper…
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 2.
La police judiciaire n'est pas la seule organisation policière. De même les services de renseignement ne sont pas uniques. Certains relèvent du gouvernement, d'autres des armées.
Un opérateur d'importance vitale intéresse tout autant les autorités civiles que militaires. Et la frontière est vague entre ces deux autorités. La notion de réseau interne à de grands groupes (tel qu'EDF ou Airbus) est une vue de l'esprit à l'heure du Cloud. D'autant que leurs employés sont géographiquement dispersés à travers la planète sans parler de leur nationalité.
Le tarif exposé par le texte me semble être une base de remboursement aux prestataires du Cloud qui assumeraient l'externalisation partielle des services informatiques des opérateurs d'importance vitale.
Mais si quelqu'un d'autre, bien introduit dans ces milieux, a un autre avis, je suis preneur.
[^] # Re: Rien à voir avec les écoutes
Posté par Denis Bernard (site web personnel) . En réponse au lien Le tarif des écoutes. Évalué à 1.
Oui, je suis d'accord sur le fait que mon titre sous-entend "écoutes téléphonique" et donc n'est pas approprié.
Mais, attention, ce texte est sous double-signature ! Le premier signataire représente le monde de la défense alors que le second représente celui du business.
Un rapide survol des textes en référence confirme cette double casquette. Mon sentiment (mais je ne suis pas qualifié en la matière) est que ce texte est d'une portée extrêmement générale (en matière de communication, les conversations téléphoniques sont intégrées dans les trames Ethernet) et vise tout autant à la lutte contre l'espionnage (militaire ou industriel) ou le sabotage que la lutte contre la contrefaçon.
Ma première idée de titre était "1984, Big Brother is watching you." mais j'ai trouvé que ça faisait trop parano.
[^] # Re: Et si on jetait le bébé avec l'eau du bain?
Posté par Denis Bernard (site web personnel) . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 7. Dernière modification le 31 décembre 2019 à 22:38.
Le blocage du port 70 par Firefox est assez récent (j'ai la flemme de retrouver la date mais ça doit dater de 3 ans) et ce n'est pas l'argument de la sobriété qui a été invoqué mais un risque de sécurité. Il est à noter que les gens de Firefox n'ont pas expliqué en quoi Gopher craignait ni qu'il me semble n'exister aucune littérature sur ce soupçon de sécurité. Par contre il est bon de rappeler que le premier moteur de recherche de l'histoire du Web était le Veronica du monde Gopher (il existe toujours !) et que le fait de bookmarquer les ressources au niveau de chaque site permettait de lui dispenser de lire l'intégralité des ressource pour en tirer les mots-clés. C'était donc rapide, léger et efficace. Si l'intégralité des ressources du Web d'aujourd'hui étaient décrites par chaque site au format Gopher, Google (partenaire de Firefox) aurait du souci à se faire pour son modèle économique. Nonobstant ce qui précède, loin de moi l'idée que les gens de Firefox aient pu y songer.
Bon, c'est exactement la remarque que je craignais : Gopher est un protocole pas une application ! Alors, que l'on soit clair : gopher n'est pas une sorte de navigateur en mode texte. Certes il existe et il a existé des navigateurs Gopher en mode texte. Mais aussi des navigateurs Gopher en mode graphique et même en 3D dans les années 90.
Gopher se décline en deux versions :
La plus ancienne est l'équivalent des marques-pages des navigateurs Internet d'aujourd'hui. Un site Gopher première génération est juste un serveur qui crache un "site map". Ensuite avec un navigateur Gopher (graphique ou non) on clique sur la ressource qui peut être un fichier sur un disque dur quelque part ou un service (du genre telnet 3270 du monde IBM). Si le fichier est une page "text/html", la page Web s'affiche. Si c'est un fichier texte plat, il est le remplacement d'un serveur ftp.
La seconde version (Gopher+) complète la première. Si on clique sur une ressource, il est possible de connaître ses variantes. Par exemple, ici sur LinuxFr, chaque ressource existe sous les formats "epub" et "markdown". Un navigateur Gopher peut être réglé par un utilisateur pour privilégier les formats PDF, par exemple. Ou bien, sur un site de vidéo en ligne, de privilégier par avance une définition en fonction de la qualité de la connexion. Et aussi, à chaque fichier est associé des métadonnées comme la licence, la taille, les mots-clés… Rien que cet aspect (les métadonnées) avec Gopher+ est hautement intéressant. Certes les en-têtes HEAD des fichiers HTML (ou EXIF pour les images) emportent certaine de ces métadonnées mais pas toutes. Avec la seconde mouture de Gopher, on peut adjoindre un nombre illimité de métadonnées à n'importe quelle ressource (à la "Dublin core").
De ce qui précède, un navigateur Gopher moderne se doit d'être capable d'afficher n'importe quelle page HTML qui a été sélectionnée depuis le "site map". Ce qui serait facile à faire à partir d'un navigateur existant puisque Gopher n'est jamais que l'affichage d'une page bookmark distante. Et Gopher+ un "clic droit souris".
Mes explications ont-elles été suffisantes ou bien dois-je développer certains points ?
[^] # Re: Et si on jetait le bébé avec l'eau du bain?
Posté par Denis Bernard (site web personnel) . En réponse au journal Que penser du navigateur internet Brave ? (Et pourquoi je privilégie Firefox…). Évalué à 3.
Dans :
Concernant les informations sur les protocoles Gopher, j'ai déjà contribué à plusieurs publications sur DLFP et écrit un article publié en mars 2011 dans GNU-Linux-Magazine qui est en libre téléchargement ici. Il y a aussi les notices Wikipédia fr et en.
Malgré tout, je suis d'accord sur le fait que l'on puisse voir le monde Gopher comme étant un monde dissimulé (d'ailleurs Gopher vient de l'animal souterrain éponyme !).
Peut-être est-ce du à la sociologie de ses pratiquants, presque exclusivement des particuliers, distinguables en deux groupes :
Le premier groupe a un niveau de culture informatique proche de zéro et se contrefiche de la technique Gopher pourvu que leurs messages puisse circonvenir les canaux GAFA.
Le second groupe a un niveau de culture technique plus élevé (assez souvent des radio amateurs) mais encore insuffisant pour produire un navigateur Internet moderne depuis la fin du support de Gopher par Firefox sous motif de sécurité (au sens de "security" semble-t-il). Dans la pratique, il ne reste que le vieux navigateur en mode texte "Lynx".
Toujours dans la pratique, les actuels sites Gopher ont une forte similitude aux anciens BBS et sont donc attractifs en tant que tel. Ce qui peut expliquer l'improbable coexistence des susdits groupes.
Je ne vois pas Gopher comme étant une alternative au sites HTTP/HTML actuels mais un complément (déjà expliqué ici). Mais la vérité oblige à dire que c'est une techno qui peut vraiment faire du mal aux GAFA.
[^] # Re: web ou gopher
Posté par Denis Bernard (site web personnel) . En réponse au journal Site Gopher du magazine Taz. Évalué à 2.
Je mentionnais dans mon commentaire précédent le projet Hyper-G. Sur le coup, je n'avais pas trouvé de lien le décrivant mais, maintenant oui (en anglais).
[^] # Re: web ou gopher
Posté par Denis Bernard (site web personnel) . En réponse au journal Site Gopher du magazine Taz. Évalué à 4.
Les personnes qui seraient intéressées par l'histoire du Web dans les années 90 gagneraient à lire les messages postés sur comp.infosystems.gopher . Par exemple, Google les met en ligne. Évidement, c'est copieux mais instructif. En remontant au 25 sept 1995, on a une petite bombe hautement géopolitique.
À titre personnel, je considère que les trois grands compétiteurs du Web de l'époque (Gopher, WWW et Hyper-G), s'ils jouaient dans le même cyberespace, possédaient chacun une technologie qui ne faisait pas exactement la même chose. Grosso modo : La spécialité de WWW est l'édition électronique de document, Gopher est pour la gestion des métadonnées des documents ET des ressources, et Hyper-G est (ou plutôt était) pour la gestion en mode cluster des documents.
J'ajoute aussi que le protocole Gopher est mentionné nommément dans les rfc 1945, 2068 et 2616 portant sur HTTP. La rfc 7230 dit encore "HTTP is also designed for use as an intermediation protocol for translating communication to and from non-HTTP information systems.". En conséquence de quoi, je suppose qu'il serait légal de transporter le protocole Gopher via HTTP voire HTTPS. Il est possible que ça se soit fait, je n'en sais rien sinon que j'ai vu passer cette suggestion de "Gopher over HTTP" dans une discussion en ligne (je ne sais plus où, ni quand).
[^] # Re: web ou gopher
Posté par Denis Bernard (site web personnel) . En réponse au journal Site Gopher du magazine Taz. Évalué à 6.
La vérité historique est que le protocole Gopher a été officiellement déclaré obsolète par son équipe de développeurs menée par Mark P. McCahill au profit de son successeur Gopher+. Ce second protocole est considérablement différent du premier, fait plus de choses, et serait parfaitement intégrable dans une page HTML (au niveau de la gestion des barres de menu).
Une autre vérité historique est que l'univers du Web incluait bien le monde Gopher, ne serait-ce que sur deux points :
1. C'est le monde Gopher qui a porté à la connaissance du public le World Wide Web,
2. McCahill collaborait avec Tim Berners-Lee (voir le lien ci-dessus).
On fait trop souvent confusion entre le mot "Web" qui était un ensemble de protocoles et d'applications avec le seul nom d'une application nommée "Word Wide Web". Gopher était bien un acteur du Web, parmi d'autres. Il n'y a jamais eu d'hostilité, à l'époque, entre le monde Gopher et celui du www. "WWW" a remplacé Gopher de façon naturelle, pas à la suite d'une quelconque guerre. Malheureusement, personne n'a vu, à l'époque, les fantastiques perspectives qu'ouvrait son successeur Gopher+. Et je crains que les aficionados d'aujourd'hui de la première version de Gopher n'aient toujours pas une vision claire de la seconde.
Reste la mentalité "fromage ou dessert" qui veut que l'on choisisse l'un ou l'autre à la fin d'un repas (Gopher vs WWW). Et si l'on prenait les deux ?
[^] # Re: Hou là, ça ne nous rajeunit pas...
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche CD amorçable GNUSTEP 2.5.1 (AMD64) et 2.6 (Raspberry Pi). Évalué à 1.
Tss, tss… On peut télécharger le module OverbiteFF pour avoir un navigateur Gopher dans Firefox !
Il est vrai que le mainteneur de ce module a des soucis avec les changements de techno pour Firefox. Mais, si l'on en croit cette liste de discussion, il se trouve encore quelques uns à s'intéresser à ce protocole qui est presque aussi ancien que HTTP.
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à -5. Dernière modification le 13 août 2017 à 16:18.
Nous sommes au cœur du sujet : "(…) un langage interprété doit faire aussi bien qu'un langage compilé".
L'informatique est-elle une science ou une techno ?
Dans le premier cas, est-ce une science spéculative. ou bien une science expérimentale ? Pour le premier, nos écoles et nos instituts en tous genres regorgent d'enseignants très bavard sur le sujet. Dans le second, on trouve beaucoup moins de bavards.
En seconde hypothèse, avons nous une alternative carrément différente avec les logiciels disponibles à la vente en matière de langage de programmation ? Ainsi, y a-t-il des interfaces graphiques natives écrites autrement qu'avec C/C++ ? Avons-nous des suites bureautiques écrites autrement qu'avec C/C++ ? Et ainsi de suite.
Alors reste la presse spécialisée. Qui reste très consensuelle. Et si la vérité établie ne collait pas à la réalité ? Et si les langages de programmation vedette n'étaient que daube ? Tant qu'on n'a pas essayé, c'est la bouteille à l'encre.
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
Non, je n'ai rien sous la main aujourd'hui. Mes évaluations datent de tant d'années… En plus comme le matériel évolue (surtout avec l'arrivée des SSD) tout est absolument à refaire. J'ai, de toute façon, besoin de faire des tests tant sur ma machine que sur celle de l'hébergeur de mes blog statiques.
Aussi ai-je créé sur GitHub un banc de test GPL_Torture.
J'y mettrai le source Fortran d'un test qui se passera en deux temps :
Mise en mémoire de la version texte de la licence GPL-v3 puis création de
nfichiers texte identiques et dont le nommage sera 1.txt, 2.txt, 3.txt … n.txt. Le temps de création de ces fichiers sera un test en écriture.Lecture des fichiers texte créés, un par un, et ajout des balises HTML pour en faire des pages HTML dotées d'un titre reprennant le n° de fichier, d'un menu avec les liens "home - prev - next -last", et le texte de la licence elle-même encadrée par les balises PRE. Leur nommage sera 1.html, 2.html, 3html … n.html . Ce sera donc un test en lecture - écriture.
L'intérêt de la chose, outre de voir les capacités de son système, est que l'on peut zipper les fichiers HTML et les uploader chez l'hébergeur. Ainsi on peut voir la latence de son prestataire.
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
En toute humilité je n'ai pas le niveau intellectuel suffisant pour avoir saisi, ne serait-ce que le sens général, du concept de fusion en Haskell à la lecture du lien. Certes l'exemple qui y est donné avec le module Data.Text me parle un peu plus car c'est pile dans le domaine que doit traiter un moteur de blog.
Mais, à ce que je suppose, on n'est plus dans le domaine du langage de programmation mais dans celui de l'optimisation par le compilateur. En ce cas, quel que soit le langage compilable en natif la question se pose à l'identique. Alors, toujours si j'ai bien compris, les langages compilables permettent usuellement d'ajouter des directives de compilation ; ainsi en fortran où l'on peut déclarer une fonction comme étant "pure", "elemental" ou même "impure" (et aussi, maintenant, la gestion du parallélisme).
Que Haskell soit tout à la fois un langage de programmation et un compilateur est une nouvelle donne. Et elle est intéressante car elle peut intégrer plus finement la phase d'optimisation. Le compilateur Fortran que j'utilise est GCC et suit à peu près le même processus que C dans le sens où il converti le source en Gimple puis en assembleur. Il s'en suit que l'on doit posséder de bonne base théorique en informatique pour produire un exécutable performant. Et ensuite c'est l'édition de lien et, là encore, le bagage intellectuel requis est assez lourd (du moins pour ma petite tête !). J'appréhende le jour où je devrai me plonger dans l'apprentissage du LTO…
Le gros avantage des interpréteurs est qu'ils lissent toutes ces contingences puisqu'ils créent leur univers et donc les règles qui leur sont propre ; c'est excellent pour la portabilité d'un logiciel. A contrario, en natif, la compilation et l'édition doivent être ajustées à la machine.
Donc, je suis (et je l'étais déjà avant) d'accord avec toi à 100% sur le fait qu'un langage interprété peu s'approcher de la performance globale d'un langage compilé non optimisé pour une machine donnée. Et je suis tout à fait conscient que l'optimisation "aux petits oignons" n'est guère portable et nécessite tout autant du temps et le bagage intellectuel adéquat. Et je suis pleinement d'accord qu'une perte de 10% de performance est acceptable et que c'est immensément compensé par la facilité de mise en production dans les délais les plus courts. Et je n'ignore pas non plus que absolument tous les exécutables sous Linux tournent sous l'interpréteur ELF…
Là où j'ai un souci avec les interpréteurs en général (mais je n'ai jamais essayé Haskell donc je n'ai pas d'opinion à son sujet) c'est quand on a à générer un très grand nombre de fichiers en lecture / écriture. En ce cas l'interpréteur doit sortir de son monde intérieur pour se tourner vers le système d'exploitation et il me semble bien que c'est une situation où les performances s'effondrent. (Là encore, je suis un modeste autodidacte et peut-être que je dis des sottises.) Alors oui, la parade consiste à charger en mémoire vive lesdits fichiers et les recracher en bloc après traitement. Mais ce n'est pas toujours possible s'ils sont très volumineux et nombreux. En ce cas, on tombe dans un traitement séquentiel par lot et la performance tombe à cause du double traitement des I/O (une fois dans l'interpréteur et l'autre dans l'appel système sous-jacent).
Dans le cas de mon moteur de blog, je me suis fixé comme règle que le nombre de fichiers de données traitables ne doit être limité que par le système de fichier. Ou, à tout le moins, de générer les billets de blog (stockés en fichiers plats) sur la base d'un post par jour pendant 30 ans. Ce qui fait dans les 10950 fichiers individuels pour les données. Et je fais mes tests sur cette base en générant un blog où toutes les pages contiennent la version HTML de la GPL. Sachant qu'un billet de blog a sa déclinaison en version imprimable, qu'il y a les pages d'indexation année par année et mois par mois, on arrive à nombre de fichiers à générer conséquent. Autre règle que je me suis fixé : une empreinte mémoire minimale. aussi n'ai-je en mémoire globale durant le traitement que les métadonnées des billets limitées aux dates et titres.
Ceci étant dit, je le répète, je n'ai pas d'opinion sur Haskell en particulier et je suis dans le flou le plus total quant à la performance des interpréteurs en lectures/écritures massives. Je ne sais même pas s'il est procédé des essais comparatifs sur des PC familiaux.
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à -1.
Le fil de discussion portait sur un langage de programmation précis et non pas sur les moteurs de blog. Incidemment la conversation a dérivée sur la vitesse à l'exécution d'un code Haskell. L'auteur de la dépêche disait :
et, dans un autre commentaire :
À l'époque où j'ai débuté l'écriture de mon moteur de blog, il en existait déjà bien d'autres. Je participais à la traduction de l'un deux et c'est là que j'ai pris conscience qu'il ne passait pas l'échelle au-delà d'une centaine de billets postés. Aujourd'hui, avec les disques SSD et l'augmentation des performances globale des machines, il redevient utilisable. Ceci était le premier point.
Le second point, était que l'on devait pouvoir poster un billet dans le cadre d'un voyage long et lointain depuis un cyber café sur une machine Windows. J'ai choisi de le rendre compatible avec Putty. Incidemment, la liaison pouvant être rompu, le logiciel devait pouvoir faire avec. Ceci impliquait d'abandonner la notion de session. Or opter pour une régénération partielle imposait un suivi de session.
Le troisième point était que je voulais un onglet "archive" plus efficace que ce que l'on voit avec habituellement où l'on n'indexe les billets que par mois mais sans les classer au préalable par année. Au début ça le fait mais au bout de dix ans on a 120 mois. Je voulais en plus pouvoir faire un classement jour par jour dans un mois donné. (Ce n'est pas encore implémenté dans mon projet.)
De tout ce qui précède, la solution la plus sûre était celle d'une régénération totale à chaque mise à jour. J'ai eu la colossale surprise, en testant les billets rapatriés depuis des blogs tenus depuis longtemps par de grands bavards, de voir que le temps mis à générer la totalité était ridiculement bas. Ce qui se passe est que l'on a des I/O massives et que passer par un interpréteur ça ralenti considérablement. Mais en natif, il m'est apparu que le surcout d'une génération totale comparée à une génération partielle était infime. Compte tenu de mon problème de ne pas pouvoir assumer un suivi de session ça tombait bien.
Voilà la raison de mon entêtement au sujet des performance en vitesse. Reste un dernier point qui me fait lorgner ailleurs qu'avec Fortran : l'interface graphique. Sous Windows, on peut faire des fenêtres avec Fortran aisément mais pas aussi facilement sous Linux. Donc soit je mets à la programmation mixte soit je vais voir ailleurs. Je n'ai pas pris encore de décision.
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à -2.
WordPress est archi dominant sur le marché des moteurs de blog. Si tu ne me crois pas, va sur le site de OVH (par exemple) et regarde combien de logiciels de blog il propose : tu as le choix entre WordPress et WordPress. Si on veut comparer un quelconque moteur de blog, le bon sens le plus élémentaire est de le faire par rapport à WordPress. Cependant la vérité oblige à dire qu'il n'est seulement en mode dynamique que pour la partie HTML. Les illustrations, elles, sont traitées comme les pages de blog statique. Autant dire, sur un blog banal, la partie générée par PHP-MySQL ne représente pas la majorité de la bande passante consommée. Concernant la mise en cache d'un blog généré dynamiquement, elle est tout aussi faisable (et même indiquée !) pour un blog en pages statiques.
Honnêtement, tiens-tu un blog que tu héberges toi-même ? Si oui, peux-tu me jurer que tu rédiges tes billets d'un façon si absolument parfaite que jamais tu ne ressentes la nécessité d'une correction ? Personnellement, je suis dans l'incapacité de rédiger ma copie sans de nombreux brouillons jetés à la corbeille. Dans ce cas, entre un logiciel qui prend une seconde et celui qui prend une minute ça fait une sacrée différence. Mais bon, si tu es un super écrivain, ça peut le faire. Ah, au fait, il est où ton blog ?
Ça, c'est une remarque pertinente ! Elle me met du baume au cœur à un point que tu ne peux pas imaginer… Je suis bien d'accord, absolument tous les blogs statiques que j'ai pu voir sont en mode page unique. C'est pour ça que j'ai créé mon propre moteur ! Avec le mien, les pages sont liées les unes aux autres. Ce qui veut dire que si l'on est sur une page, on peut cliquer sur celle qui précède ou qui suit. Ce qui veut dire qu'à chaque fois que l'on intercale une page, il faut générer au moins deux autres. Et si en plus on pousse le vice à proposer un menu pour retrouver un billet à une date donnée, il faut tenir à jour l'index des pages. Donc, le plus simple à coder est de tout regénérer. On peut faire une regénération partielle comme avec NanoBlogger autrefois. Mais, pour l'avoir vécu, c'est source de bien des soucis. Et comme si le vice précédent ne suffisait pas, je propose aussi une version imprimable de chaque billet. La double peine. Alors, crois-moi, Fortran est bon pour moi.
Absolument d'accord avec toi. Python bénéficie d'une somme considérable de modules en tout genre et c'est sa qualité première. (Peut-être même la seule ?). Mais le Fortran moderne est un tout autant un langage orienté objet et tout autant modulaire. La facilité à développer en Python vient surtout de son environnement : plus il y a de modules, de dépôts de source, d'outils en tout genre, plus c'est facile de créer de nouveaux modules. Partir from scratch est une toute autre affaire ! Pour Fortran, il n'existe guère que de vieilles bibliothèques scientifiques et quasiment aucun module écrit au 21ème siècle. Donc, rien que pour parser un fichier de configuration, une ligne de commande. Alors il faut agiter ses petits doigts sur le clavier. Mais bon, c'est ce que j'aime. Je ne suis pas payé pour, c'est pour le fun !
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
Merci de l'info. Elle remet Haskell dans ma liste des langages à étudier lors des longues soirées d'hiver !
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
Concernant l'intérêt des interpréteurs, je n'ai rien n'a ajouter de plus de ce que dit Backus dans son papier The IBM Speedcoding system (Journal of the ACM, Volume 1, Issue 1, Janv 1954, pp. 4-6). Leur intérêt est évident. Et ils existent depuis plus longtemps que le premier langage de programmation jamais commercialisé par la même équipe du susdit.
Cependant, malgré leur indéniable (et irremplaçable) utilité, les interpréteurs ont leurs limites. Car si une fonction est codable en soft, elle est tout aussi parfaitement codable en hard dans un CPU. Et là, la question des performances se pose. L'équipe qui a créé Speedcoding est la même qui a créé peu après Fortran : la technologie ayant permis de coder en dur une unité de calcul sur les flottants, il n'y avait plus de raison de continuer avec un interpréteur. Pour ceux qui ont connu les premiers PC d'avant les Pentium, ils étaient livrés avec un coprocesseur optionnel. Ceux qui n'avaient pas les sous choisissaient le modèle sans qui faisait tout aussi bien mais plus lentement car passant par un émulateur.
Pour donner un exemple vécu et que j'ai développé sur ce site au travers plusieurs journaux : le cas d'un générateur de pages HTML pour un blog statique. Il en existe une multitude mais presque tous codés sous interpréteur. Quand on arrive à une certain nombre de billets de blog, le logiciel rame. La seule issue est de coder en natif. Donc, à un moment, il faut bien mettre les mains dans le cambouis. L'alternative existe : vous prenez WordPress, vous installez une base de donnée qu'il vous faudra maintenir, vous mettez PHP qu'il faudra bien mettre à jour de temps à autre et vous croisez les doigts pour que vous ne fassiez pas pirater. Personnellement, je me suis mis au Fortran pour la seule nécessité de développer un moteur de blog statique. Il est capable de générer une centaine de pages HTML là où WordPress en génère une seule pour le même laps de temps. Et mon moteur de blog n'est pas hackable car il ne réside pas sur le site Web. Et je n'ai pas besoin d'ingurgiter une dose massive de SQL et PHP pour savoir comment marche le bousin. Tout ça par la seule grâce d'un langage compilé. Mais j'aurais pu tout aussi bien opter pour ADA car mon passé en Basic me permettait un auto apprentissage des langages "verbeux". Je précise qu'à l'époque je ne connaissais pas de compilo Basic sous Linux et que je ne voulais plus entendre parler de Windows ni utiliser de Basic en mode interpréteur. Sur ce dernier point, j'ai été échaudé par le fait que l'interpréteur rattrapant assez facilement des erreurs d'écriture logicielle, et même fournissant des avertissements (cas du QBasic de MS) là où un compilo natif refuserait d'aller plus loin, on n'est pas assez rigoureux dans son codage. En natif, les erreurs détectées sont implacables ! Même si on ne les voit pas toutes de prime abord.
À bon escient, les interpréteurs ont leur utilité. Là où il y a une dérive, c'est quand une organisation humaine (typiquement une université ou un industriel du logiciel) fait la promotion d'une nouvelle-machine-virtuelle-qui-va-bouleverser-la-planète c'est qu'elle entraîne dans ses filets une multitude de gens qui deviennent comme les adeptes d'une nouvelle religion. Le nombre de ces miroirs aux alouettes brisés ou encore scintillants est inouï.
Concernant la distinction entre développement et programmation, elle me semble évidente ! Dans un cas on assemble des composants logiciels écrits par d'autres, dans l'autre on tape avec ses petits doigts sur le clavier pour fabriquer un par un lesdits composants. C'est la même différence qu'entre ouvrir une boite de conserve de petits pois et les réchauffer en 3 minutes ou les prendre à l'état cru, les écosser et attendre 3/4 d'heure que ça cuise. Au quotidien, j'opte pour la conserve. Mais je sais aussi le faire à l'ancienne ! Et je sais même aussi les faire pousser !
Il est vrai que les langages interprétés sont au moins aussi fiables que ceux compilés. Mais, en "mode parano", leur avenir est suspendu au bon vouloir de soit un très petit comité (pas toujours ouvert sur la communauté), soit d'un industriel qui peut mettre la clé sous la porte du jour au lendemain. Et le miroir aux alouettes est alors brisé.
Dans le cas d'un langage compilé le risque est mieux réparti. D'une part parce que tant que le CPU et la plateforme continue d'exister, la maintenance est possible même si son fournisseur disparaît. Et dans la mesure où il normalisé, il devient légal de créer un compilateur substitutif. Si une machine virtuelle, breveté ou sous licence, a une faille de sécu et qu'elle n'est plus maintenue c'est la mort du petit cheval.
C'est, pour moi une première impasse. La seconde concerne la création de nouveaux composants logiciel en assemblant des composants de base. j'ai évoqué le cas du processeur de texte LaTeX où l'on l'empilement de macros peut produire des effets indésirables. Ah, j'aimerai avoir une connaissance a minima du JavaScript pour donner d'autres exemples illustrant les inconvénients de la stratification logicielle…
[^] # Re: Haskell pour les nuls
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Sortie de GHC 8.2.1. Évalué à 1.
Merci pour ces précisions ! Effectivement les FFI sont chose intéressante pour la programmation mixte. Ça existe maintenant en Fortran (blocs INTERFACE). Pas plus tard qu'il y a une semaine, je me suis amusé à jouer avec
gettimeofday()de la libc (voir ici).Mon agacement au sujet des langages interprétés (que ce soit avec interpréteur externe ou runtime embarquée dans l'exécutable) est qu'ils font confusion entre les notions de programmation et de développement. Ayant biberonné avec Basic, j'ai eu à pâtir de cette ambiguïté et en définitive éprouvé des frustrations dès que l'on pousse le langage dans ses limites. Je pense qu'il est malhonnête de présenter un langage comme relevant de la programmation alors qu'il est définitivement limité au développement. Ou, pour parler plus clairement, si l'on souhaite étendre les fonctionnalités de base par modules à l'aide de ce même langage, on provoque des instabilités au delà d'un certain niveau d'imbrication des modules à l'intérieur des modules. Ce genre de choses se voit couramment en TeX/LaTeX. Ceci n'a pas trop d'importance pour quiconque ayant fait de longues études en informatique (car pouvant toujours se rabattre sur le langage C ou un assembleur). Mais, pour un hobbyiste de mon genre, quel temps perdu à apprendre un langage qui se révèle être une impasse !
Le langage Fortran évolue à toute vitesse. Il est bien difficile de se faire une opinion sur des bases anciennes… Rien que l'introduction des modules (et tout récemment des sous-modules) change totalement la donne en génie logiciel. Mais on ne trouve que très peu de code lisible en ligne qui soit rédigé en Fortran moderne comme ici (un module pour les fichiers JSON).
Ceci me fait prendre conscience qu'il serait opportun de rédiger une dépêche sur le Fortran moderne. Mais, clairement, je n'ai pas le niveau ! Cependant brosser un historique de ce langage sexagénaire, au travers d'une dépêche sur ce site, devrait être à ma portée.