OK, merci pour ta réponse claire ! Elle confirme mon impression première… Mon intérêt portait sur la possibilité de programmation mixte. À ce que j'ai compris de mes lectures, les anciennes version de GHC avaient la possibilité de générer un source en langage C mais ce ne serait plus le cas aujourd'hui. J'ai vu un tutoriel où, dans le cas d'un main en C, la procédure écrite en GHC doit au préalable être initialisée (ce qui me faisait pencher pour un interpréteur embarqué).
Il en découle qu'il ne semble pas avoir d'avenir pour GHC pour jouer avec des interfaces graphiques (GTK ou QT) qui sont le plus souvent écrites en C/C++ . Reste, peut-être, les Widgets interprétées ?
Concernant GHC en tant que substitut au C++ dans le domaine du calcul intensif, je m'interroge : quitte à s'investir intellectuellement dans l'apprentissage d'un nouveau langage, pourquoi ne pas préférer Fortran (version F2015, pas F77 !) ?
Ceci étant, concernant la galère que représente la chaîne de compilation classique (autotools) du C, ou pire de Fortran, GHC est apparemment infiniment plus confortable.
En définitive, la fabrication d'un exécutable et son paquetage est une punition injuste avec les anciens langages. Le processus standard actuel est une survivance de l'époque où les ordinateurs étaient si faibles qu'il mettaient un temps fou à compiler. D'où les Makefiles actuels (et leur cortège d'utilitaires atroces) qui n'ont plus de raison d'être avec les machines d'aujourd'hui. Alors oui, qu'est-ce qui est le plus simple : créer un nouveau langage avec un processus de compilation/paquetage indolore ou bien dépoussiérer l'existant ?
Bon, je ne connaissais jusqu'ici Haskell que de nom.
J'ai installé la version 8.2.1 sur mon ordi qui est sous Gentoo. J'ai fait le classique "hello world!" en créant un source (hello.hs) contenant : main = putStrLn "Hello, World!"
À la ligne de commande, j'ai fait : ghc hello.hs
Ce qui m'a généré 3 fichiers :
hello (2 293 936 octets)
hello.hi (858 octets)
hello.o (3576 octets)
La commande file dit que que hello.o est : hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped, with debug_info
Pour hello.hi : hello.hi: data
Et pour l'exécutable hello lui-même : hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped, with debug_info
L'exécutable me semble énorme. Alors je fais un strip hello mais il fait encore 749 072 octets.
J'ai passé pas mal de temps sur les tutoriels et autre pages Wikipédia. Ce qui n'a fait que m'embrouiller un peu plus. Alors ma question : est-ce que GHC est un pur compilateur faisant du vrai code natif ou bien une bidouille embarquant un interpréteur ?
Zut, sur ce coup-là je n'ai pas vu de problème ! J'ai côtoyé des collègues dotés d'une stupéfiante mémoire des chiffres et je crois me souvenir que Chateaubriand (dans ses Mémoires d'outre-tombe) disait avoir mémorisé des tables de logarithmes.
Ce lien renvoie sur la page du règlement PAS sur l'annonce de l'évènement ! À ma connaissance, seule cette page Facebook en fait l'annonce. Mais, comme elle a été créée spécifiquement dans ce but début décembre 2016, il était impossible au public d'en connaître son existence. Sauf à ce que quelqu'un puisse apporter la preuve d'une annonce sur un site Internet ou tout autre medium de la création de ladite page.
En tant qu'ancien navigant au long cours, je confirme la véracité du récit d'Exquemelin et le recommande à toute personne intéressée par le droit maritime et le statut des marins professionnels. Le monde de la flibuste était haut en couleur et délicieusement pittoresque. Cependant le monde maritime d'aujourd'hui est largement aussi violent que jadis ! Bien des marins sont égorgés nuitamment, rançonnés ou retenus prisonnier des années… dans l'indifférence générale. Voir la carte de l'IMB Piracy Reporting Centre pour les zones où sévissent les pirates.
les brontosaures qui sont figés dans le temps, fortran, cobol etc.
Pour fortran, il faut être de bien mauvaise foi pour affirmer qu'il soit resté au congélo depuis sa version vedette f77 !
Le compilateur GCC (avec son frontal gfortran) propose les versions f95, f2003 et f2008. Les comités de normalisation travaillent assidûment pour la prochaine mouture, f2015, qui devrait sortir bientôt. Fortran est depuis longtemps un langage orienté objet qui peut s'interfacer (quoique pas encore totalement…) avec C/C++ .
Pour en avoir un avant goût, un tutoriel (qui date un peu) ou bien les normes.
Ce que je ne sais pas, par ignorance totale du C++, c'est lequel des deux langages est le plus avancé.
S'il se trouve ici quelqu'un ayant la double compétence en Fortran actuel et en C++, je serais intéressé par son témoignage sur deux points : lequel de ces deux langages est le plus avancé en POO et lequel est le plus rapide une fois compilé ?
Aujourd'hui, avec la "cloudification", on arrive aux mêmes problématiques que du temps du "tout mainframe" : hypervision (tâches uniques confinées dans un environnement hyper protégé) et architecture n-tier (empilement de machines pour une seule tâche). Il en ressort que la gestion d'une tâche (initialisation, lancement, contrôle en cours d'exécution et achèvement) doit pouvoir se faire sans trop de douleur. Dans le monde Unix, né avec des machines de taille plus modeste que celle des mainframes, on était à l'opposé : système multitâche, multi-utilisateur et distribué (/usr/local…). L'initialisation des tâches, lancement, contrôle et achèvement reposent sur le Shell. Si l'on est en mode hyper sécurisé, mono tâche et mono utilisateur, le Shell Unix est un gouffre de sécurité. D'où l'intérêt d'avoir quelque chose qui fasse ce que fait un Shell mais qui soit compilable.
Ceci étant, avec le cloud, on est dans une sorte de "mainframe de mainframe" et la comparaison de JCL comme langage de contrôle des tâches est un peu hardie, je le confesse. Il en demeure pas moins que tu as bien ressenti la nécessité d'écrire quelque chose pour assurer la gestion de machines "cloufifiées". Après, on appelle ça comme on veut…
Ma réponse était délibérément concise et, de ce fait, caricaturale. Je sais que tout n'est pas rose dans la pérennité d'un logiciel compilé ; j'en ai fait l'expérience dernièrement.
Sinon, je suis à 100% d'accord avec toi sur tout ce que tu dis ! Je suis sous Gentoo, je compile tout, et les changements de version de lib et de compilo je me les prends dans la figure tous les jours.. Et je sais aussi que bien des langages compilés tournent (ou ont tourné) sous interpréteur. D'ailleurs la norme Fortran se refuse à prononcer le mot compiler au profit de processor (Fortran a été interprété jadis).
Ma petite expérience de traduction repose essentiellement comme l'un des traducteurs du moteur de blog NanoBlogger qui est en Bash puis sur mon propre moteur de blog qui est en Fortran. Ayant vu la galère du maintien du code avec les différentes versions de Bash sur plusieurs plateformes (Mac, BSD, Linux…) j'ai bien été échaudé. Fortran, pour moi, apportait une plus grande stabilité. Quant à la préférence de tel ou tel langage, dans le monde actuel, que ce soit avec GNU ou Intel (pour C/C** vs Fortran) on est dans la traduction d'un langage normalisé vers un langage intermédiaire (non normalisé) qui génèrera ensuite de l'assembleur. Puis il y aura une édition de lien ; même ayant codé en Fortran, on se retrouve avec une libc intégré à l'exécutable…
J'ai l'avantage de la décontraction sur tous ces sujets alors qu'ils mettent gravement en jeu des vies professionnelles entières : je suis retraité et pur autodidacte en informatique. (Autant dire, un hobbyiste…) Et je suis navré de l'influence des modes, du dogmatisme des cursus de formation en informatique et de l'oubli des vielles technos faute de l'enseignement d'une Histoire de l'informatique qui aurait l'avantage de relativiser ces passions.
Les langages compilés tournent tous (pour Linux) sous l'interpréteur ELF. Cet interpréteur, du point de vue du cycle de vie d'un logiciel, est éternel. Les langages de script ont chacun leur propre interpréteur et, presque toujours, le font évoluer. L'espérance de vie d'un logiciel sous langage de script est de l'ordre de quelques années.
Il en ressort que dans le cas d'un langage compilé, une seule branche sur le repository suffit à sa seule maintenance contrairement au langage de script qui doit être maintenu dans l'ancienne version de l'interpréteur, celle en cours et celle à venir. Donc 3 branches au lieu d'une.
Le point de vue du développeur est que si se voir proposer des traductions lui fait chaud au cœur, voir lesdites traductions ne pas être actualisées lors des mises à jour de son logiciel peut lui poser d'énormes problèmes. Et c'est typiquement la situation de l'auteur de ce journal qui tend à promouvoir une action ponctuelle alors que l’œuvre de traduction nécessite un accompagnement sur des années.
C'était mon avis aussi avant que d'entendre le témoignage de Mon p'ti voisinage. De mémoire, leur effectif est de 18 personnes (je peux me tromper sur le chiffre mais, sur la photo de groupe des collaborateurs montrée dans la présentation, c'était plutôt une assez grosse équipe). Un autre témoignage (mais sans témoin en chair et en os) lors de cette keynote portait sur la "cloudification" de Villeroy et Boch. Dans les deux cas, on n'est plus vraiment dans le site vitrine de l'artisan du coin. Si quelqu'un était présent ce jour-là dans l'amphi, il peut toujours confirmer/infirmer mes dires ici-même.
Il y a trois problématiques : le langage de programmation, la localisation unique/multiple et la traduction proprement dite.
Le langage de programmation
Aujourd'hui, grosso modo, il y a deux grandes familles de langage : le langage C avec ses multiples dérivés et les langages de script comme Python. Ces langages ont, au fil des ans, développés des procédures de traduction. L'une des plus connue est gettext.
La localisation unique/multiple
Par localisation je mets dans le même sac (par simplification) la traduction pure, les variantes linguistiques et les contraintes politiques locales (mots interdits par le politiquement correct). Quand on développe un projet, surtout si l'on n'est pas anglophone, la question de la traduction de son œuvre se pose assez tôt. il y a deux voies : traduire le code source avant compilation (ce que fait gettext) ou bien intégrer toutes les traductions dans le logiciel avant sa compilation. Dans le dernier cas, la variable d'environnement (LANG, par exemple) détecte la localisation à appliquer au moment où l'utilisateur lance le logiciel.
L’œuvre de traduction
Si l'on est dans le cas de gettext, effectivement, la chose est plus facile car cet outil permet d'opérer sans grande connaissance de la programmation. Dans les autres cas, c'est beaucoup moins limpide. Et encore moins quand on touche à des langages moins main stream (comme mon projet fBlog qui est en Fortran). Reste que la traduction d'un logiciel n'est pas strictement une tâche littéraire ! En effet, une traduction mot à mot n'est pas toujours possible même dans le cas le plus simple de celle des menus de navigation à l'intérieur du logiciel. Même si les mots comme "Edit", "File", "Save"… ont leur équivalents bien connus, il y aura toujours des options de navigation qui seront nouvelles. Et c'est là où un spécialiste de la langue atteindra ses limites. De ce qui précède, une traduction suppose non seulement d'être linguiste mais aussi d'avoir une pratique réelle du logiciel que l'on veut traduire. Et si l'on ne dispose pas d'outils comme gettext, il faut être capable de se plonger dans le code source. Enfin un dialogue avec l'auteur du logiciel finira par devenir indispensable car il y aura la nécessité de synchroniser sa traduction avec les mises à jour du logiciel pour les intégrer dans son paquet. La connaissance d'une langue véhiculaire (le plus souvent l'anglais) et l'aptitude à communiquer directement (mail, par exemple) ou indirectement (push par GitHub…) est souhaitable. Il y a aussi la question du copyright des traducteurs ce qui est chose délicate dans le cas d'une traduction initiée par une structure publique au sein d'un collectif.
Je viens de compiler mon projet avec musl en statique. (Avec la distro Linux Alpine.) Effectivement, ça marche sans problème avec une machine sous glibc et aussi avec le vieux kernel de Sourceforge. Je pense à faire un journal prochainement sur le sujet.
Je n'ai pas fini de lire ces RFC mais j'ai cru comprendre que les variantes déjà existantes sont bien prise en compte ! Markdown ne sera donc jamais un format unique mais un format ayant une base commune et des variantes formant des additions. (Plus celles à venir !)
J'utilise Kate au quotidien mais je suis incapable d'ouvrir plus d'un terminal. Y a-t-il une astuce que j'ignore pour en afficher plusieurs à l'intérieur de Kate ? (Depuis plusieurs années, j'utilise Kate sans terminal sur les 2/3 gauche de mon écran et Konsole sur le 1/3 droit. Konsole permets d'avoir plusieurs consoles en onglet ; j'en ai le plus souvent besoin de trois.)
Je confirme ! Ça fait si longtemps que je suis sous Gentoo que je ne sais plus combien… Peut-être bien 7 ans. Avant j'étais sous SUSE mais c'était si stable que je m'ennuyais. J'étais à deux doigts de me mettre à LSF (Linux from scratch) mais, par acquis de conscience, j'ai voulu tester Gentoo avant que de faire le grand saut.
Globalement, c'est presque aussi stable que mon ancienne SUSE tant que l'on reste dans la version "non tilde". Et, si l'on a envie de poussées d'adrénaline en expérimentant un logiciel "en tilde" (instable), le risque est somme toute limité. En tant que programmeur amateur sous Fortran, j'apprécie de pouvoir faire cohabiter en toute sérénité sept versions différentes de GCC. (Je n'imagine même pas que l'on puisse utiliser une autre distro dès que l'on songe à faire du logiciel !)
Évidement il y la question d'openRC, mais Gentoo propose aussi le package "sys-apps/systemd". C'est aussi un aspect sympathique de cette distro que de pas trop trancher entre plusieurs orientations polémiques. Sauf en ce qui concerne la sûreté/sécurité où là on voit une forte réactivité de la part de la communauté des développeurs.
Gentoo est aussi un labo pour l'exploration d'alternatives à la glibc (comme le fait la distro Alpine Linux).
En résumé, le public potentiellement intéressé par Gentoo va du père peinard (qui ne veut plus s'embêter avec des grandes mises à jour un à deux fois l'an) à l'expérimentateur audacieux. Mais Gentoo est vraiment à déconseiller pour ceux qui ne lise pas l'anglais ou ceux qui ont un niveau en informatique tout juste moyen. Sans vouloir troller exagérément, je ne suis pas sûr qu'un vieux routier de Debian soit immédiatement à l'aise avec Gentoo.
Je n'ai pas volé depuis 30 ans (baisse de revenus, chômage chronique pour cause de mondialisation dans ma profession…)
J'ai aussi piloté, je n'ai jamais ressenti ça, personnellement. Je ne vois pas trop à quel moment ça peut arriver pendant le pilotage qu'un calcul soit une question de vie ou de mort.
Bon, un exemple au hasard. Normalement, pour une nav, on est censé prévoir un déroutement en cas de pépin. Donc forcément on a la quantité de carburant qui va bien. Sauf qu'une évolution météo inattendue peut rendre le terrain de destination et celui déroutement impraticable par exemple pour la composante latérale du vent (vent de travers trop fort). La question est donc de trouver à l'arrache un autre terrain, d'en évaluer la distance et la réserve de carburant dispo. Bon, je précise aussi qu'à l'époque le vol aux instrument était encore du luxe et pas du tout imposé à l'examen (2ème degré) et les prévisions météo pas aussi fiables qu'aujourd'hui. Pas d'horizon artificiel, pas de VOR (ni de GPS, bien sûr) !
Bien des années plus tard, j'ai retrouvé les sensations du pilotage quand je commandais des navires rapides où l'on est assis (et parfois ceinturé) dans son siège sans avoir la possibilité d'aller à la table à carte. Sachant que les navires à propulsion par hydrojet voient leur rendement diminuer en cas de ralentissement du régime pour cause de chute de rendement, ralentir fait consommer plus de carburant (contrairement aux navires à hélice). Et quand on a des centaines de passagers à bord, le stress est en proportion. Là on est obligé de faire un choix entre un ralentissement qui peut amener à une panne sèche (et tout le monde peut mourir si l'on est près de la côte) ou maintenir sa vitesse et avoir des passagers victimes de fractures (histoires vécues).
Tu présente des tas d'exemples, ça n'en fait pas une argumentation juste un vécu
Je ne peux pas faire mieux car il n'y a pas de statistiques sur l'Éducation nationale qui soit accessible au public. Ma mère a longtemps été employé de bureau dans un lycée professionnel et elle m'a dit que la question des statistiques était un sujet tabou. On en est réduit à l'empirisme ou à la lecture des statistiques établies par des étrangers sur le système éducatif français.
Le journal Ouest France avait fait un examen blanc du certif dans un département Normandie (le calvados ?) il y a quelques années. Ils avaient poussé le vice à faire venir des instituteurs retraités comme examinateurs ! Or ils n'ont jamais publié le chiffre des reçus, ni même la moyenne générale. Le journal s'est juste contenté d'une synthèse dans la langue de bois qu'il maîtrise si bien. S'il existe quelqu'un qui pouvait déterrer ces données, ça vaudrait de l'or (population ethniquement homogène dans un département fortement rural pas spécialement défavorisé).
que « EN est devenue une imposture » n'a aucun sens.
Ceci est mon sentiment et comme tel il n'a aucune valeur scientifique pris individuellement. Mais en supposant que je ne sois pas le seul à nourrir le même sentiment de "gravitude" concernant notre système éducatif et que ce soit ce que beaucoup de gens pense, on peut au moins envisager une étude scientifique de vérification. (Depuis l'étranger, bien sûr !)
Y-a-t-il une seule publication scientifique récente réfutant le catastrophisme que j'exprime ?
[^] # 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.
OK, merci pour ta réponse claire ! Elle confirme mon impression première… Mon intérêt portait sur la possibilité de programmation mixte. À ce que j'ai compris de mes lectures, les anciennes version de GHC avaient la possibilité de générer un source en langage C mais ce ne serait plus le cas aujourd'hui. J'ai vu un tutoriel où, dans le cas d'un
mainen C, la procédure écrite en GHC doit au préalable être initialisée (ce qui me faisait pencher pour un interpréteur embarqué).Il en découle qu'il ne semble pas avoir d'avenir pour GHC pour jouer avec des interfaces graphiques (GTK ou QT) qui sont le plus souvent écrites en C/C++ . Reste, peut-être, les Widgets interprétées ?
Concernant GHC en tant que substitut au C++ dans le domaine du calcul intensif, je m'interroge : quitte à s'investir intellectuellement dans l'apprentissage d'un nouveau langage, pourquoi ne pas préférer Fortran (version F2015, pas F77 !) ?
Ceci étant, concernant la galère que représente la chaîne de compilation classique (autotools) du C, ou pire de Fortran, GHC est apparemment infiniment plus confortable.
En définitive, la fabrication d'un exécutable et son paquetage est une punition injuste avec les anciens langages. Le processus standard actuel est une survivance de l'époque où les ordinateurs étaient si faibles qu'il mettaient un temps fou à compiler. D'où les Makefiles actuels (et leur cortège d'utilitaires atroces) qui n'ont plus de raison d'être avec les machines d'aujourd'hui. Alors oui, qu'est-ce qui est le plus simple : créer un nouveau langage avec un processus de compilation/paquetage indolore ou bien dépoussiérer l'existant ?
[^] # 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.
Pour le modérateur, une typo : changer le mot "embarquent" de la dernière phrase par "embarquant". Merci !
# 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. Dernière modification le 07 août 2017 à 22:30.
Bon, je ne connaissais jusqu'ici Haskell que de nom.
J'ai installé la version 8.2.1 sur mon ordi qui est sous Gentoo. J'ai fait le classique "hello world!" en créant un source (hello.hs) contenant :
main = putStrLn "Hello, World!"À la ligne de commande, j'ai fait :
ghc hello.hs
Ce qui m'a généré 3 fichiers :
La commande
filedit que quehello.oest :hello.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped, with debug_infoPour
hello.hi:hello.hi: dataEt pour l'exécutable
hellolui-même :hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, not stripped, with debug_infoL'exécutable me semble énorme. Alors je fais un
strip hellomais il fait encore 749 072 octets.J'ai passé pas mal de temps sur les tutoriels et autre pages Wikipédia. Ce qui n'a fait que m'embrouiller un peu plus. Alors ma question : est-ce que GHC est un pur compilateur faisant du vrai code natif ou bien une bidouille embarquant un interpréteur ?
[^] # Re: Ah, les joies des scénarios hollywoodiens...
Posté par Denis Bernard (site web personnel) . En réponse au journal Les Figures de l’ombre. Évalué à 4.
Excellent thread ! Il y a des liens intéressants:
[^] # Re: Ah, les joies des scénarios hollywoodiens...
Posté par Denis Bernard (site web personnel) . En réponse au journal Les Figures de l’ombre. Évalué à 2.
Zut, sur ce coup-là je n'ai pas vu de problème ! J'ai côtoyé des collègues dotés d'une stupéfiante mémoire des chiffres et je crois me souvenir que Chateaubriand (dans ses Mémoires d'outre-tombe) disait avoir mémorisé des tables de logarithmes.
[^] # Re: Pas que sur Facebook.
Posté par Denis Bernard (site web personnel) . En réponse au journal Hackathon du MAEDI. Évalué à 4.
Ce lien renvoie sur la page du règlement PAS sur l'annonce de l'évènement ! À ma connaissance, seule cette page Facebook en fait l'annonce. Mais, comme elle a été créée spécifiquement dans ce but début décembre 2016, il était impossible au public d'en connaître son existence. Sauf à ce que quelqu'un puisse apporter la preuve d'une annonce sur un site Internet ou tout autre medium de la création de ladite page.
# Typo
Posté par Denis Bernard (site web personnel) . En réponse au journal Hackathon du MAEDI. Évalué à 4.
Si un modérateur passe par là, il y a 2 coquilles :
Merci !
[^] # Re: Autre témoignage
Posté par Denis Bernard (site web personnel) . En réponse au journal [digression] L'Enfer de la flibuste - le récit inédit d'un pirate français. Évalué à 9.
En tant qu'ancien navigant au long cours, je confirme la véracité du récit d'Exquemelin et le recommande à toute personne intéressée par le droit maritime et le statut des marins professionnels. Le monde de la flibuste était haut en couleur et délicieusement pittoresque. Cependant le monde maritime d'aujourd'hui est largement aussi violent que jadis ! Bien des marins sont égorgés nuitamment, rançonnés ou retenus prisonnier des années… dans l'indifférence générale. Voir la carte de l'IMB Piracy Reporting Centre pour les zones où sévissent les pirates.
[^] # Re: Donc pour résumer…
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche C++17, Genèse d’une version mineure. Évalué à 8.
Pour fortran, il faut être de bien mauvaise foi pour affirmer qu'il soit resté au congélo depuis sa version vedette f77 !
Le compilateur GCC (avec son frontal gfortran) propose les versions f95, f2003 et f2008. Les comités de normalisation travaillent assidûment pour la prochaine mouture, f2015, qui devrait sortir bientôt. Fortran est depuis longtemps un langage orienté objet qui peut s'interfacer (quoique pas encore totalement…) avec C/C++ .
Pour en avoir un avant goût, un tutoriel (qui date un peu) ou bien les normes.
Ce que je ne sais pas, par ignorance totale du C++, c'est lequel des deux langages est le plus avancé.
S'il se trouve ici quelqu'un ayant la double compétence en Fortran actuel et en C++, je serais intéressé par son témoignage sur deux points : lequel de ces deux langages est le plus avancé en POO et lequel est le plus rapide une fois compilé ?
# Enfin !
Posté par Denis Bernard (site web personnel) . En réponse au journal Au fait RuggedPOD et OpenTower c'est quoi ?. Évalué à 5.
Enfin ! une explication claire du « Pourquoi du comment de la chose » …
[^] # Re: sysadmin
Posté par Denis Bernard (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 1.
Pour Villeroy et Boch, confirmation le 20 mai sur le site de Silicon !
[^] # Re: sysadmin
Posté par Denis Bernard (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 3.
Aujourd'hui, avec la "cloudification", on arrive aux mêmes problématiques que du temps du "tout mainframe" : hypervision (tâches uniques confinées dans un environnement hyper protégé) et architecture n-tier (empilement de machines pour une seule tâche). Il en ressort que la gestion d'une tâche (initialisation, lancement, contrôle en cours d'exécution et achèvement) doit pouvoir se faire sans trop de douleur. Dans le monde Unix, né avec des machines de taille plus modeste que celle des mainframes, on était à l'opposé : système multitâche, multi-utilisateur et distribué (/usr/local…). L'initialisation des tâches, lancement, contrôle et achèvement reposent sur le Shell. Si l'on est en mode hyper sécurisé, mono tâche et mono utilisateur, le Shell Unix est un gouffre de sécurité. D'où l'intérêt d'avoir quelque chose qui fasse ce que fait un Shell mais qui soit compilable.
Ceci étant, avec le cloud, on est dans une sorte de "mainframe de mainframe" et la comparaison de JCL comme langage de contrôle des tâches est un peu hardie, je le confesse. Il en demeure pas moins que tu as bien ressenti la nécessité d'écrire quelque chose pour assurer la gestion de machines "cloufifiées". Après, on appelle ça comme on veut…
[^] # Re: Le point de vue d'un développeur
Posté par Denis Bernard (site web personnel) . En réponse au journal Traduction des logiciels libres. Évalué à 1.
Ma réponse était délibérément concise et, de ce fait, caricaturale. Je sais que tout n'est pas rose dans la pérennité d'un logiciel compilé ; j'en ai fait l'expérience dernièrement.
Sinon, je suis à 100% d'accord avec toi sur tout ce que tu dis ! Je suis sous Gentoo, je compile tout, et les changements de version de lib et de compilo je me les prends dans la figure tous les jours.. Et je sais aussi que bien des langages compilés tournent (ou ont tourné) sous interpréteur. D'ailleurs la norme Fortran se refuse à prononcer le mot compiler au profit de processor (Fortran a été interprété jadis).
Ma petite expérience de traduction repose essentiellement comme l'un des traducteurs du moteur de blog NanoBlogger qui est en Bash puis sur mon propre moteur de blog qui est en Fortran. Ayant vu la galère du maintien du code avec les différentes versions de Bash sur plusieurs plateformes (Mac, BSD, Linux…) j'ai bien été échaudé. Fortran, pour moi, apportait une plus grande stabilité. Quant à la préférence de tel ou tel langage, dans le monde actuel, que ce soit avec GNU ou Intel (pour C/C** vs Fortran) on est dans la traduction d'un langage normalisé vers un langage intermédiaire (non normalisé) qui génèrera ensuite de l'assembleur. Puis il y aura une édition de lien ; même ayant codé en Fortran, on se retrouve avec une libc intégré à l'exécutable…
J'ai l'avantage de la décontraction sur tous ces sujets alors qu'ils mettent gravement en jeu des vies professionnelles entières : je suis retraité et pur autodidacte en informatique. (Autant dire, un hobbyiste…) Et je suis navré de l'influence des modes, du dogmatisme des cursus de formation en informatique et de l'oubli des vielles technos faute de l'enseignement d'une Histoire de l'informatique qui aurait l'avantage de relativiser ces passions.
[^] # Re: sysadmin
Posté par Denis Bernard (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 1.
Au risque de paraître un peu taquin : ne sommes-nous là pas dans la veine du JCL (Job Control Language) de l'informatique de papa ?
[^] # Re: Le point de vue d'un développeur
Posté par Denis Bernard (site web personnel) . En réponse au journal Traduction des logiciels libres. Évalué à 1.
Les langages compilés tournent tous (pour Linux) sous l'interpréteur ELF. Cet interpréteur, du point de vue du cycle de vie d'un logiciel, est éternel. Les langages de script ont chacun leur propre interpréteur et, presque toujours, le font évoluer. L'espérance de vie d'un logiciel sous langage de script est de l'ordre de quelques années.
Il en ressort que dans le cas d'un langage compilé, une seule branche sur le repository suffit à sa seule maintenance contrairement au langage de script qui doit être maintenu dans l'ancienne version de l'interpréteur, celle en cours et celle à venir. Donc 3 branches au lieu d'une.
Le point de vue du développeur est que si se voir proposer des traductions lui fait chaud au cœur, voir lesdites traductions ne pas être actualisées lors des mises à jour de son logiciel peut lui poser d'énormes problèmes. Et c'est typiquement la situation de l'auteur de ce journal qui tend à promouvoir une action ponctuelle alors que l’œuvre de traduction nécessite un accompagnement sur des années.
[^] # Re: sysadmin
Posté par Denis Bernard (site web personnel) . En réponse au journal L'informatique de papa. Évalué à 1.
C'était mon avis aussi avant que d'entendre le témoignage de Mon p'ti voisinage. De mémoire, leur effectif est de 18 personnes (je peux me tromper sur le chiffre mais, sur la photo de groupe des collaborateurs montrée dans la présentation, c'était plutôt une assez grosse équipe). Un autre témoignage (mais sans témoin en chair et en os) lors de cette keynote portait sur la "cloudification" de Villeroy et Boch. Dans les deux cas, on n'est plus vraiment dans le site vitrine de l'artisan du coin. Si quelqu'un était présent ce jour-là dans l'amphi, il peut toujours confirmer/infirmer mes dires ici-même.
# Le point de vue d'un développeur
Posté par Denis Bernard (site web personnel) . En réponse au journal Traduction des logiciels libres. Évalué à 5.
Il y a trois problématiques : le langage de programmation, la localisation unique/multiple et la traduction proprement dite.
Le langage de programmation
Aujourd'hui, grosso modo, il y a deux grandes familles de langage : le langage C avec ses multiples dérivés et les langages de script comme Python. Ces langages ont, au fil des ans, développés des procédures de traduction. L'une des plus connue est gettext.
La localisation unique/multiple
Par localisation je mets dans le même sac (par simplification) la traduction pure, les variantes linguistiques et les contraintes politiques locales (mots interdits par le politiquement correct). Quand on développe un projet, surtout si l'on n'est pas anglophone, la question de la traduction de son œuvre se pose assez tôt. il y a deux voies : traduire le code source avant compilation (ce que fait gettext) ou bien intégrer toutes les traductions dans le logiciel avant sa compilation. Dans le dernier cas, la variable d'environnement (LANG, par exemple) détecte la localisation à appliquer au moment où l'utilisateur lance le logiciel.
L’œuvre de traduction
Si l'on est dans le cas de gettext, effectivement, la chose est plus facile car cet outil permet d'opérer sans grande connaissance de la programmation. Dans les autres cas, c'est beaucoup moins limpide. Et encore moins quand on touche à des langages moins main stream (comme mon projet fBlog qui est en Fortran). Reste que la traduction d'un logiciel n'est pas strictement une tâche littéraire ! En effet, une traduction mot à mot n'est pas toujours possible même dans le cas le plus simple de celle des menus de navigation à l'intérieur du logiciel. Même si les mots comme "Edit", "File", "Save"… ont leur équivalents bien connus, il y aura toujours des options de navigation qui seront nouvelles. Et c'est là où un spécialiste de la langue atteindra ses limites. De ce qui précède, une traduction suppose non seulement d'être linguiste mais aussi d'avoir une pratique réelle du logiciel que l'on veut traduire. Et si l'on ne dispose pas d'outils comme gettext, il faut être capable de se plonger dans le code source. Enfin un dialogue avec l'auteur du logiciel finira par devenir indispensable car il y aura la nécessité de synchroniser sa traduction avec les mises à jour du logiciel pour les intégrer dans son paquet. La connaissance d'une langue véhiculaire (le plus souvent l'anglais) et l'aptitude à communiquer directement (mail, par exemple) ou indirectement (push par GitHub…) est souhaitable. Il y a aussi la question du copyright des traducteurs ce qui est chose délicate dans le cas d'une traduction initiée par une structure publique au sein d'un collectif.
[^] # Re: musl
Posté par Denis Bernard (site web personnel) . En réponse au message Compatibilité de musl avec cible sous glibc [Résolu]. Évalué à 1.
Je viens de compiler mon projet avec musl en statique. (Avec la distro Linux Alpine.) Effectivement, ça marche sans problème avec une machine sous glibc et aussi avec le vieux kernel de Sourceforge. Je pense à faire un journal prochainement sur le sujet.
[^] # Re: C'est juste un état de l'art
Posté par Denis Bernard (site web personnel) . En réponse au journal Nouvelles RFC sur Markdown. Évalué à 2.
Excellentes synthèses, comme d'habitude !
[^] # Re: Et le CommonMark ?
Posté par Denis Bernard (site web personnel) . En réponse au journal Nouvelles RFC sur Markdown. Évalué à 1.
Je n'ai pas fini de lire ces RFC mais j'ai cru comprendre que les variantes déjà existantes sont bien prise en compte ! Markdown ne sera donc jamais un format unique mais un format ayant une base commune et des variantes formant des additions. (Plus celles à venir !)
[^] # Re: Bien pour débuter, et plus…
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche IT-Edit 2.0, un éditeur de texte avec terminaux intégrés. Évalué à 1.
J'utilise Kate au quotidien mais je suis incapable d'ouvrir plus d'un terminal. Y a-t-il une astuce que j'ignore pour en afficher plusieurs à l'intérieur de Kate ? (Depuis plusieurs années, j'utilise Kate sans terminal sur les 2/3 gauche de mon écran et Konsole sur le 1/3 droit. Konsole permets d'avoir plusieurs consoles en onglet ; j'en ai le plus souvent besoin de trois.)
[^] # Re: Telnet tant qu'à faire
Posté par Denis Bernard (site web personnel) . En réponse au journal Vers un retour de Gopher ?. Évalué à 3.
C'est ce que j'ai l'intention de faire plus tard. Mais déjà mon moteur de blog peut s'administrer sous telnet ou ssh. Voir un billet sur ce site.
[^] # Re: Gentoo, c’est la vie.
Posté par Denis Bernard (site web personnel) . En réponse au sondage Quelle est votre distribution préférée ?. Évalué à 5.
Je confirme ! Ça fait si longtemps que je suis sous Gentoo que je ne sais plus combien… Peut-être bien 7 ans. Avant j'étais sous SUSE mais c'était si stable que je m'ennuyais. J'étais à deux doigts de me mettre à LSF (Linux from scratch) mais, par acquis de conscience, j'ai voulu tester Gentoo avant que de faire le grand saut.
Globalement, c'est presque aussi stable que mon ancienne SUSE tant que l'on reste dans la version "non tilde". Et, si l'on a envie de poussées d'adrénaline en expérimentant un logiciel "en tilde" (instable), le risque est somme toute limité. En tant que programmeur amateur sous Fortran, j'apprécie de pouvoir faire cohabiter en toute sérénité sept versions différentes de GCC. (Je n'imagine même pas que l'on puisse utiliser une autre distro dès que l'on songe à faire du logiciel !)
Évidement il y la question d'openRC, mais Gentoo propose aussi le package "sys-apps/systemd". C'est aussi un aspect sympathique de cette distro que de pas trop trancher entre plusieurs orientations polémiques. Sauf en ce qui concerne la sûreté/sécurité où là on voit une forte réactivité de la part de la communauté des développeurs.
Gentoo est aussi un labo pour l'exploration d'alternatives à la glibc (comme le fait la distro Alpine Linux).
En résumé, le public potentiellement intéressé par Gentoo va du père peinard (qui ne veut plus s'embêter avec des grandes mises à jour un à deux fois l'an) à l'expérimentateur audacieux. Mais Gentoo est vraiment à déconseiller pour ceux qui ne lise pas l'anglais ou ceux qui ont un niveau en informatique tout juste moyen. Sans vouloir troller exagérément, je ne suis pas sûr qu'un vieux routier de Debian soit immédiatement à l'aise avec Gentoo.
[^] # Re: Commentaire consensuel !
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Joyce Reynolds est morte :-(. Évalué à 1.
Je n'ai pas volé depuis 30 ans (baisse de revenus, chômage chronique pour cause de mondialisation dans ma profession…)
Bon, un exemple au hasard. Normalement, pour une nav, on est censé prévoir un déroutement en cas de pépin. Donc forcément on a la quantité de carburant qui va bien. Sauf qu'une évolution météo inattendue peut rendre le terrain de destination et celui déroutement impraticable par exemple pour la composante latérale du vent (vent de travers trop fort). La question est donc de trouver à l'arrache un autre terrain, d'en évaluer la distance et la réserve de carburant dispo. Bon, je précise aussi qu'à l'époque le vol aux instrument était encore du luxe et pas du tout imposé à l'examen (2ème degré) et les prévisions météo pas aussi fiables qu'aujourd'hui. Pas d'horizon artificiel, pas de VOR (ni de GPS, bien sûr) !
Bien des années plus tard, j'ai retrouvé les sensations du pilotage quand je commandais des navires rapides où l'on est assis (et parfois ceinturé) dans son siège sans avoir la possibilité d'aller à la table à carte. Sachant que les navires à propulsion par hydrojet voient leur rendement diminuer en cas de ralentissement du régime pour cause de chute de rendement, ralentir fait consommer plus de carburant (contrairement aux navires à hélice). Et quand on a des centaines de passagers à bord, le stress est en proportion. Là on est obligé de faire un choix entre un ralentissement qui peut amener à une panne sèche (et tout le monde peut mourir si l'on est près de la côte) ou maintenir sa vitesse et avoir des passagers victimes de fractures (histoires vécues).
[^] # Re: Commentaire consensuel !
Posté par Denis Bernard (site web personnel) . En réponse à la dépêche Joyce Reynolds est morte :-(. Évalué à 2.
Je ne peux pas faire mieux car il n'y a pas de statistiques sur l'Éducation nationale qui soit accessible au public. Ma mère a longtemps été employé de bureau dans un lycée professionnel et elle m'a dit que la question des statistiques était un sujet tabou. On en est réduit à l'empirisme ou à la lecture des statistiques établies par des étrangers sur le système éducatif français.
Le journal Ouest France avait fait un examen blanc du certif dans un département Normandie (le calvados ?) il y a quelques années. Ils avaient poussé le vice à faire venir des instituteurs retraités comme examinateurs ! Or ils n'ont jamais publié le chiffre des reçus, ni même la moyenne générale. Le journal s'est juste contenté d'une synthèse dans la langue de bois qu'il maîtrise si bien. S'il existe quelqu'un qui pouvait déterrer ces données, ça vaudrait de l'or (population ethniquement homogène dans un département fortement rural pas spécialement défavorisé).
Ceci est mon sentiment et comme tel il n'a aucune valeur scientifique pris individuellement. Mais en supposant que je ne sois pas le seul à nourrir le même sentiment de "gravitude" concernant notre système éducatif et que ce soit ce que beaucoup de gens pense, on peut au moins envisager une étude scientifique de vérification. (Depuis l'étranger, bien sûr !)
Y-a-t-il une seule publication scientifique récente réfutant le catastrophisme que j'exprime ?