Denis Bernard a écrit 222 commentaires

Sous Gentoo, "perf" est en "tilde" (masqué) et il y a de très nombreuses options. Ne pas oublier d'activer "slang" sinon on a une interface très réduite et il ne semble pas possible d'avoir l'équivalent de la seconde illustration.

Pour info, les options possibles : "audit crypt demangle doc gtk java libpfm lzma perl python slang systemtap unwind zlib debug numa".

La documentation de perf (dans "/usr/share/doc/perf-x.xx") est copieuse !

Tout d'abord, le lien de la page de TenFourFor.

Cameron Kaiser, le papa de TenFourFox, , est décidément un personnage comme on en rencontre peu dans sa vie.

Je ne l'ai jamais vu physiquement mais j'ai été en contact contact épistolaire car ayant envoyé un exemplaire de Linux Magazine où j'avais écrit un article sur le protocole Gopher il y a tout juste 10 ans. En effet, avec John Goerzen, il est un des piliers de la communauté Gopher.

En matière d'informatique, il est très versé dans le rétro-computing au point d'abriter à domicile une petite salle des machines. Il maintient aussi l'ancêtre de tous les moteurs de recherche : Veronica. Et, par là- même, Cameron Kaiser indexe tous les sites Gopher (en constante augmentation). Voir aussi la liste de diffusion Gopher-Projectoù l'on débat aussi de Gemini.

• Sa page "orientée rétro-computing" : http://www.floodgap.com/. Ou, celle-ci :
• http://oldvcr.blogspot.com/.

Mais il s'intéresse également à l'informatique de pointe avec les machines Raptor dont il en possède une. Voir ici une autre de ses nombreuses pages perso (dont je renonce à faire l'inventaire exhaustif !).

Sa page perso révèle aussi que son intense activité en informatique n'est pas son gagne pain. En effet, dans le civil, il est médecin hospitalier spécialisé dans la tuberculose.

Sauf homonymie, Il semblerait qu'il ait exercé un rôle public durant la pandémie d'après cet article.

Il y a des plaisirs sains (gagner au jeu sans tricher), des plaisirs malsains (gagner au jeu en trichant) et gagner coûte que coûte quand on est le dos au mur.

Lors de mon affaire, j'étais viré d'une boite jouissant d'une réputation excellente alors que son secteur professionnel était en tout début de crise économique. J'étais peu ancien et il convenait d'alléger la masse salariale sans montrer la charrette pour ne pas affoler les actionnaires. Alors, pour sa propre survie, cette entreprise respectable est sortie des clous.
Mon problème de l'époque était que ni l'administration de tutelle de l'époque, ni les syndicats ne pouvait avoir connaissance des difficultés financières de mon entreprise car sa clientèle était surtout à l'international. (elle a effectivement fermé quelques années après après plus de 100 ans d'existence.) Donc le prétexte fumeux invoqué par mon entreprise était tout à fait crédible et moi je passais pour un charlot. C'est le vice de procédure lors de mon second licenciement qui a démontré qu'il y avait malice de leur part.

Je suis donc parti dans cette affaire à la manière d'un Don Quichotte où absolument personne (ni collègue, ni ami, ni juriste) ne me donnait gagnant. Je savais que j'avais juridiquement raison mais j'étais parfaitement conscient, malgré ma relative jeunesse, que c'était juste une condition assez nécessaire mais pas suffisante pour gagner. D'un autre côté, ma branche professionnelle était en début d'écroulement et je n'avais plus rien à perdre. Donc le dos au mur et l'énergie du désespoir. C'est cette nécessité qui a fait de moi un être temporairement sournois.

Alors oui, quand on réussit l'impossible, la victoire est grisante. En fin de procès, j'avais pris contact avec une journaliste de Libé et il s'est posé la question de la médiatisation. Finalement j'ai choisi de ne pas faire de publicité car je savais que les autres entreprises de ma branche étaient elles-aussi en très fâcheuse posture et qu'il y avait le risque d'un lockout patronal généralisé. Elles ne demandaient plus que ça pour délocaliser le siège de leur activité dont la clientèle était majoritairement étrangère.

Par la suite, grâce à l'entregent de l'administration de tutelle et l'acceptation tacite des syndicats, les licenciements pour raison économique ont pu continuer à être dissimulés à l'actionnariat sous forme de discrètes primes de départ volontaire.

Plus de vingt ans après, une loi spécifique à ma branche a enfin formalisé ce traitement des "départs volontaires obligatoires" d'une manière plus élégante. Je sais que si j'avais crié victoire dans les médias à l'époque, j'aurai pu engendrer un processus de chute de domino (confidence d'un copain chez le concurrent direct à ma boite qui suivait l'affaire avec inquiétude).

<philo> Quand on est en position inconfortable, toute la difficulté réside en savoir si ce qui nous arrive est chose normale ou pas. Du genre, si on est patraque, est-ce une grippe ou un cancer ? Tant que le diagnostique n'est pas posé, on ne peut que spéculer. Mais le jour où tout s'éclaire, si c'est un cancer, il faut taper dur pour survivre. Sachant que si on ne fait rien, on meurt. Donc, foutu pour foutu… tel a été mon procès. Au début, de la stupeur, puis le combat et enfin la rémission. Mais on n'en sort jamais indemne. Pour ma part, je n'ai eu de cesse de toujours refuser les CDI, de changer de boite une à deux fois par an (quitte à y revenir plus tard) pour ne pas "appartenir" à une entreprise. Une sorte de mercenariat chronique. </philo>

Les premières audiences m'ont été très pénible. Ça m'a valu mes premiers acouphènes (à l'âge de 27 ans !). Par la suite, une sorte de dédoublement c'est produit car devant faire le job comme un avocat pro. C'est une sensation étrange que d'un côté l'on soit en un état de fureur (légitime !) et de l'autre d'un calme implacable… Il m'a fallu user de ruse (comme jouer sur les délais des lettres recommandées AR), lâcher du lest sur certain points… faire des choses qui ne sont absolument pas dans mes habitudes ni mon caractère. À la dernière audience, devenu plus décontracté, j'ai découvert l'excitation, l'adrénaline que pouvait procurer l'exercice d'une plaidoirie.

J'ai eu par le passé à faire un recours en matière prud'homale (en référé) avec décision d'incompétence de la première juridiction à la fois "en matière" et "en lieu". À la troisième audience, une fois la bonne juridiction saisie, J'ai réussi une première conciliation et j'ai été réintégré dans mon entreprise. Ladite entreprise, leader français sur son secteur, m'a ensuite à nouveau licencié trois semaines plus tard… Juste histoire de me faire pleurer, je suppose. Sauf que j'ai éclaté de rire en recevant la lettre de licenciement car ils avaient juste oublié l'entretien préalable au licenciement. J'ai donc ressaisi la justice, donc nouvelle tentative de conciliation puis audience qui m'a donné raison.

Soit, au total, cinq audiences en un an. J'ai obtenu une indemnisation équivalente à quatre mois de salaire (j'avais un an et demi d'ancienneté). J'ai vu une seule fois une avocate qui m'a conseillé de me défendre seul au vu de la qualité des courriers que j'avais déjà adressé à ma boite. Mais elle m'a été très utile pour le chiffrage de mes demandes.

Ce que j'en ai tiré comme bénéfice immédiat lors de ma victoire : une énorme satisfaction d'avoir gagné et plus encore d'avoir eu mon honneur lavé après s'être fait jeté comme un malpropre. Devant me défendre seul, j'ai dû engloutir plusieurs volumes de Dalloz (le web n'existait pas encore) et donc acquis une vaste culture juridique. Ceci m'a été extrêmement profitable toute ma vie professionnelle restante. Et c'est la seule procédure que j'ai jamais eu à intenter.

J'ai connu, les décennies suivantes, des situations encore plus aiguës mais j'ai réussi à toutes les désamorcer grâce à mes connaissances juridiques acquises. Une fois, assistant un collègue convoqué en "entretien préalable à un licenciement", j'ai réussit non seulement à le maintenir dans la boite mais aussi à faire licencier son directeur qui voulait lui faire porter le chapeau. Le pouvoir du verbe…

La faille du système juridique français est que si l'on gagne, tout ce que l'on gagne va dans la poche de votre ami l'avocat. La faille de la faille est de se passer d'avocat. Ce qui est possible dans pas mal de recours dont les prud'hommes.

Déjà annoncé en octobre dernier ici même !

Voir aussi leur site Web.

Ton premier journal (sept 2008), pose le doigt sur ce qui fait très mal : la misérable rémunération des auteurs ; et aussi sur la réactivité (lente) des maisons d'édition.

Tu as eu 3 retours positifs pour un ouvrage de niche : c'est un fantastique succès d'estime ! Les deux options de rémunération qui t'ont été faite par l'une de ces maisons ont été tout à fait dans la fourchette usuelle de leur profession. Le jour où l'on se met dans la peau d'un futur éditeur, on se rend compte qu'avec toute la meilleure volonté du monde on ne peut absolument pas offrir plus aux auteurs. C'est ce que j'ai découvert en réalisant qu'un éditeur est quelqu'un qui sous-traite beaucoup de tâches comme la relecture tant pour la mise en français, que l'orthographe voir la composition typographique. Ces sous-traitances sont des gouffres. La seule qui soit visible à nos yeux de néophyte est celle de l'imprimerie mais il y en a bien d'autres. Tout ceci se paie. Tu t'es rendu compte qu'il y avait des limites à solliciter "amicalement" l'entourage. Donc, oui, pour un seul bouquin, une fois dans sa vie, ça passe. Mais pas plus !

Cet éditeur offrait un forfait de 1500 € ou une rétribution de 1.40€ / ouvrage. Ce qui veut dire qu'il pensait en écouler un millier. D'après ce que tu dis des ventes faites par toi-même, l'estimation de l'éditeur était donc conforme au marché.

La seconde chose est la réactivité. Là aussi, il y a les usages de la profession d'éditeur. Un délai de deux à trois mois pour réagir à la réception d'un manuscrit est dans la norme. Ce que l'on sait moins et que j'ai découvert dans ma petite expérience, est l'extrême saisonnalité du marché du livre. C'est tout à fait comparable à l'agriculture ! Il y a des périodes phares comme la rentrée littéraire d'automne ou l'approche des vacances d'été. Tout ceci est particulièrement rythmé par les prix littéraires. Alors les éditeurs ont une vision tactique à 1 ou 2 semestres. Ils ont aussi leur propre production à écouler et il leur faut lisser les volumes. S'ils ont passé un deal avec des commerciaux, là aussi ils doivent assurer un certain nombre de nouveautés par an mais pas tout le même mois ! Ils doivent aussi tenir compte des délais de livraison des imprimeurs qui peuvent être extrêmement variables selon que l'on est en saison creuse ou pleine. (Compter de 2 à 8 semaines.) Sur ce dernier point, il parfois souhaitable de reporter la sortie de l'ouvrage de plusieurs mois pour retomber "à la bonne saison".

Il me vient à l'esprit une rencontre dans un salon livre en Bretagne.

Un auteur, ayant commis de nombreux ouvrages de bonne tenue sur l'histoire locale, m'a dit qu'il existait des entreprises ayant un long passé faisant faire écrire leur histoire. Une partie du tirage était pré-commandée par elles et ces livres faisaient office de cadeau d'entreprise.

Devant mon air ébahi, il a ajouté que ce genre de "publireportage" s'étendait aussi aux collectivités locales qui, elles-aussi, ne sont pas avares en mondanités. Évidement, ce digne universitaire ne mangeait pas de ce pain…

Techniquement, seule une toute petite maison d'édition peut s'accommoder de ce genre de commande, vu la faiblesse du volume ; et ainsi la fusion de la position d'auteur et d'éditeur.

Du point de vue de la commercialisation, on n'est pas dans le planétaire. Juste un site Web, la participation aux salons du livre ou foires locales et un zeste de connivence avec la presse locale.

D'un point de vue éthique, on peut quand même se dire que ce genre d'ouvrage contribue à la diversification de la vision du patrimoine local trop souvent axé sur les vieilles pierres et les paysages champêtres en passant par les recettes culinaires. Bon d'accord, je suis en Bretagne et j'ai comme une indigestion !

Je confirme. Je suis passé par ThebookEdition pour faire mes essais et le dépôt légal en France. J'en ai été très satisfait au niveau qualité.

Si on choisit de faire de l'édition électronique à l'international, ça ne coûte pas grand chose de faire un tirage court (baptisé pompeusement "édition originale") et un dépôt légal pour préserver ses droits. Les exemplaires restant pouvant servir de cadeaux à l'entourage. Et puis, si le besoin se fait sentir, de refaire une impression à la demande.

Ce genre de prestation (ils sont nombreux à le faire) peut être intéressant au niveau de l'auteur en cours d'écriture de son manuscrit s'il doit y insérer des figures, photos, tableaux… typiquement les ouvrages d'érudition, scientifiques, pédagogiques ou professionnels. Sans compter les livres pour l'enfance, marché très porteur. En effet, au niveau de son poste de travail, on a besoin de "calibrer", de déterminer les marges. Avec le rognage et le façonnage de la couverture, on a des doutes sur ses choix. Il y aussi le tracas de la couleur du papier qui ne sera pas de la même blancheur que le papier bureautique et plein d'autres détails qui nécessiterait un livre entier pour en parler. Donc, oui, même au stade de la finalisation du manuscrit ce n'est pas idiot de faire imprimer quelques exemplaires pour se faire une idée et solliciter son entourage pour avis.

Je ne sais pas si tu es un auteur qui veut s'éditer lui-même ou si tu veux éditer les autres.

Dans le premier cas, on est dans la même problématique que l'automédication. Il n'est pas conseillé conseillé de se soigner sans l'avis d'un professionnel mais parfois on n'a pas le choix. En matière de littérature générale (les romans par ex.), les manuscrits refusés par les éditeurs le sont pour cause de médiocrité. Je crois qu'il y a 98 % de refus. Mais il y a des contre-exemples célèbres. En matière de littérature technique ou scientifique, l'auteur a vraiment intérêt à s'adresser aux éditions spécialisées dans ces domaines. Reste le cas d'une niche non couverte par ces éditeurs : le mieux est d'en démarcher un et le convaincre d'ouvrir une nouvelle collection.

Dans le second cas, on a deux métiers à apprendre. Le premier est celui d'entrepreneur et le second celui d'éditeur. Ce sont des choses à aborder sérieusement ET séparément. Le côté entrepreneurial est parfaitement bien balisé avec les chambres de commerce qui font admirablement bien leur boulot. Si tu as déjà eu un numéro SIRET, si tu as déjà fait des versements à l'URSSAF, tu vois de quoi je parle. Sinon, il faut commencer par le B-A BA de l'apprentissage d'une création d'entreprise dont beaucoup de matières sont communes que ce soit pour une pizzeria ou une entreprise de nettoyage. Être éditeur c'est avant tout tenir une entreprise. Rien que ça c'est un très gros morceau à avaler. Donc, si tu n'as jamais eu d'entreprise, pointe-toi au guichet d'une Chambre de commerce quelconque, avec un sourire niait, et explique ton rêve. Tu seras chouchouté, crois-moi !

La deuxième phase est de comprendre qui fait quoi dans les métiers du livre. C'est vraiment quelque chose dont je ne suis pas certain d'avoir entièrement survolé. Ce que je sais, de façon certaine après contact auprès de nombreux professionnel, c'est que les professionnels eux-mêmes n'ont qu'une vision partielle de la chose. Dans les grosses structures éditoriales, tout le monde est spécialisé et n'a à connaître dans la chaîne que la maille précédente et la maille suivante. Les éditeurs unipersonnels (mon cas) doivent remplir les rôles de plusieurs personnes ayant fait les études qui vont bien. Rien que graphiste, ça demande au minimum 2 à 3 ans d'études. Et ça ne vous fait pas quelqu'un de très compétant en typographie fine et encore moins en tant que correcteur.

Ça c'est le côté "traitement de texte". Il y a l'autre côté qui est la commercialisation des livres. C'est là où le petit éditeur a de gros soucis. 1. parce qu'il entre dans un jeu de quille qu'il ne connaît pas ; 2. parce que la logistique est assurée par de très gros acteurs très peu nombreux et qui ne connaissent que les diffuseurs. Les diffuseurs sont ceux qui démarchent les libraires qui seront livrés par les logisticiens (les distributeurs). Le libraire voit plus dans un livre le nom du diffuseur que celui de l'éditeur. Il faut savoir que les livres en librairie sont mis en une sorte de dépôt-vente. Le libraire ne paye les ouvrages que (typiquement) trois mois après et, s'il ne le veut pas, il les retourne à l'expéditeur. C'est ce que l'on appelle "les retours". Il y a en France une hallucinante chaîne logistique qui gère ces livraisons et ces retours. Pour entrer dans la danse, ce ne m'a pas paru évident mais je dois reconnaître que je n'ai rencontré que de gentilles personnes et que j'aurais même pu faire un mini stage en librairie pour comprendre ce fatras. Une alternative, si l'on a encore une longue vie devant soi, est de d'ouvrir (ou reprendre) une librairie et de se commercialiser soi-même. Ainsi on met un pied dans le milieu, on a le temps d'apprendre puis gravir l'échelle par la suite. C'est un processus fréquent en littérature régionaliste.

Encore une facette : la gestion de l'auteur. s'il est mort depuis plus de 50/70 ans, ça peut sembler anecdotique. Mais il faut savoir que le droit moral peut se transmettre aux héritiers sur plusieurs siècles. Donc, publier un mort c'est comme la médecine légale, il faut respecter le défunt. Il y a le cas des auteurs morts depuis moins longtemps dont les héritiers sont inconnus et dont l'éditeur d'origine est mort lui-aussi. C'est ce qu'on appelle les "œuvres orphelines". La loi française a parfaitement encadré ceci et il convient de la suivre.

Si l'auteur est vivant, on tombe dans les relations humaines. On est bon dans ce domaine ou on ne l'est pas. D'un point de vue juridique ou fiscal c'est un peu comme votre employé (donc, gros soucis pour les entrepreneurs novices). Mais c'est lui qui vous fait vivre et qui peut ruiner votre réputation. C'est pourquoi j'ai cru plus prudent de débuter dans le domaine public pour limiter mes champs d'apprentissage.

Argh, une coquille ! Merci au modérateur de remplacer les deux occurrences ISBM par ISBN.

Oui, au moment de rédiger mon commentaire, j'ai délibérément laissé entendre ce fameux "Effet Dunning-Kruger". En fait, même s'il y a un peu de ça (je ne suis pas humanoïde), il y a surtout que je m'étais abstenu de développer ma pensée pour ne pas engendrer une avalanche de commentaires hostiles. Maintenant mon propos ci-après devrait passer inaperçu par noyade dans le flot des commentaires.

Certains commentaires à ce journal témoignent de la régression en performance des desktops d'aujourd'hui par rapport à ceux du temps de jadis (à la haute époque de Mandrake, par ex.). Et ça vaut quand on compare Windows 3.1 avec le produit actuel de notre excellent concurrent.

Tout comme la population humaine, nos ordis chéris sont frappés d'obésité. Mais ce sinistre est encore plus avéré avec la distro "orientée sources" Gentoo. Elle a fait le choix d'un langage de script (Python) pour son principal outil d'administration (emerge), tout en gardant le scripting SHELL pour l'init par défaut (le même que pour les BSD). Qu'il y ait un interpréteur SHELL sur un Unix n'est que de l'ordre normal des choses. Mais baser son incontournable outil d'administration sous un langage dont les propriétaires développeurs modifient autoritairement les specs à tout va, entraîne la mise à jours des paquets système bien trop fréquemment. Et toujours la trouille de casser quelque chose à ces moments-là. Et une valse des paquets non essentiels à recompiler tant la dépendance à Python frôle le grotesque. Je me demande s'il est possible aujourd'hui d'avoir un desktop fonctionnel pour madame Michu (que je salue au passage) sans Python ?

Quand j'ai débuté sur Gentoo, je n'ai pas eu trop de difficulté en suivant scrupuleusement leur manuel. Il y a un an, par cause de bris de disque dur, j'ai dû faire une réinstallation complète. Là, j'ai vu vu que le manuel avait pris de l'embonpoint (un peu) mais surtout que tout n'y était pas. Il n'était soit pas à jour, soit ne disait pas toutes les options possibles. Gentoo veut couvrir toutes les facettes du monde Unix et c'est à son honneur. Mais le monde Unix s'est considérablement complexifié et le manuel Gentoo n'a pas suivi la cadence. Il y a 12 ans, mes USE flags tenaient sur une ligne ; maintenant, c'est un long paragraphe.

Au risque de troller mal à propos, mon rêve est d'avoir un système où les machines virtuelles pour les soi-disant langages de programmation seraient optionnelles. Et puis, avoir un outil d'administration qui soit dans un langage non compilable pour une distro qui se veut vouloir compiler tout, est une incohérence. (Ou une facilité pour les développeurs non programmeurs ?) Sans compter la dépendance circulaire…

Au risque de brûler en Enfer, il m'arrive de songer à quelque chose d'aussi débile que les AS/400 d'un autre de nos excellents concurrents.

J'avais exactement le même sentiment d'ennui il y a environ 12 ans avec ma SusE Linux. Ça marchait trop bien ! Alors j'ai commencé à lire la doc de Linux from Scratch. Mais, avant ce choix extrême, juste par acquit de conscience, j'ai testé Gentoo. Et j'y suis resté depuis lors.

Je me croyais utilisateur avancé ayant pratiqué Red Hat en 1995 puis Mandrake et Suse. Quel innocent j'étais… Avec Gentoo, j'ai pu prendre conscience de ma nullité. Depuis, le malaise s'est accentuée. C'est un peu comme le mythe de Sisyphe avec son rocher. Plus on en apprend sur une distro où l'on compile tout, plus on doute de ne jamais pouvoir dire "Ça y est, je maîtrise".

J'ai lu (en diagonale) la présentation de Gemini et sa FAQ. Ma première impression est que son auteur n'a pas compris le protocole Gopher de la même manière que je le comprend. Voici mon point de vue.

Il existe une rfc 1436 "Informational" dont leurs auteurs on déclarés à l'époque de sa sortie (1993) quelle avait pour but de stabiliser la précédente version de Gopher alors qu'ils publiaient la nouvelle spécification "Gopher+" (disponible sur ce site).

Bien plus tard, en 2005, est sorti la la rfc 4266 portant "The gopher URI Scheme" qui, elle, est en catégorie "Standards Track". Clairement, la rfc 4266 fait bien état du protocole Gopher+ totalement ignoré (ou snobé ?) par le projet Gemini. Il se trouve que bien des lacunes relevées à juste titre par le projet Gemini concernant la première version stabilisée de Gopher telle que décrite dans la rfc 1436 sont comblées avec la seconde version du protocole Gopher dite "Gopher+".

Alors je m'interroge sur la démarche des porteurs du projet Gemini : le lien ci-dessus vient du site de Goerzen (personnalité bien connue du petit monde Gopher) et on trouve aisément cette feuille de route pour Gopher+ un peu partout dans le gopherspace.

Le second volet de mon commentaire concerne les définitions du Web d'une part et celle de la page Web d'autre part.

Ma définition du Web est celle d'un espace sur Internet partagé par des protocoles qui ont tous en commun le fait d'être accessible par une URI (ftp://, gopher://, http://, telnet://, etc). La notion d'URL a été gravée dans le marbre avec la rfc 1738 en 1994 par deux auteurs : T. Berners-Lee, que l'on ne présente plus, et M. McCahill qui était le leader de l'équipe Gopher. On présente souvent le projet du World Wide Web comme rival à celui de Gopher alors que les deux équipes ont toujours collaboré ensemble. Ces deux projets avaient des buts absolument différents et n'empiétaient en rien l'un sur l'autre. Il est navrant de confondre Web et World Wide Web. L'un est la toile que l'on peut parcourir avec l'un des quelconques protocole (ftp, telnet, http, gopher, wais… et j'en oublie) et l'autre une suite de protocoles porté par le W3C.

Concernant la définition de la page Web, on touche le cœur du problème ! D'abord on devrait dire "page de texte encodé en HTML" (plus divers autres encodages). Rien n'interdit de télécharger un fichier Text/html depuis un serveur ftp ou Gopher ! Certes, on peut dire que la grosse nouveauté du format HTML a été l'en-tête apportant tout un tas de renseignements intéressants. Mais Gopher+, apporte également bien des renseignements nécessaires à n'importe lequel des fichiers à télécharger (contrairement à la version première de Gopher).

Enfin, et je crois que c'est le fond du projet Gemini), la définition de "page Web". Je pense qu'on est bien d'accord que le souci principal est le côté "métier du livre" qui n'est pas un métier facile. On ne sait toujours pas bien faire un traitement de texte et seulement un ou deux squattent le marché. De même pour le format PDF. Et là, on voudrait avoir ces deux logiciels en un…

À ce que j'ai compris des fanatiques (le mot n'est pas trop fort !) du protocole Gopher : ils sont nostalgiques des anciens BBS. Alors ils détournent l'usage premier des menus Gopher, qui ne sont strictement qu'une liste ordonnée de liens, en y incluant des lignes de texte débutants par la balise de type "i" (qui est non officielle mais reconnue par "Lynx" qui domine tous les navigateurs Gopher). Ce contournement permet de présenter une "page Web" en mode texte avec des liens mais sans le très honni HTML.

Reste le volet de la sûreté des communications. Un faux problème, à mon avis ! En effet, le protocole Gopher transporte en clair et sans authentification. Mais si on veut brouiller ou authentifier, rien n'interdit d'encapsuler Gopher sous HTTP(S). Déjà, en 1996, la rfc 1945 pour HTTP/1.0 prévoyait le transport d'autres protocoles comme SMTP, NNTP, FTP, Gopher et WAIS. Et c'est toujours le cas dans la section 1.1 de la rfc 2616 pour HTTP/1.1 .

Le code sur GitHub ici.

Il y a l'art et l'artisanat. En matière d'artisanat, votre remarque est censée. En matière d'art, un artiste sans public est comme une fleur sans eau ; il crève. Un des moyens d'avoir un public est de rentrer dans le secteur marchand. Seul l'auteur, l'artiste (ou le codeur !) sait dans son cœur si sa production est une œuvre ou seulement un ouvrage. Si l'on parle d'art, l'argent n'est qu'un gaz.

Je ne suis pas graphiste. Je n'achète jamais de BD. Je n'y connais rien. Mais j'ai un doute.

J'ai vécu des décennies à quelques encablures du Quai des bulles : autant vous dire que j'ai parcouru des hectares de BD au cours de ma vie. Or ce que je vois de cet échantillon est fort prometteur.

Peut-être avez-vous besoin de vous perfectionner. Peut-être aurez-vous atteint le top à la veille de votre mort. Mais si les codeurs en informatique avaient eu tant de scrupules les logiciels ne seraient pas tant bugués !

La question est de savoir si vous êtes à un niveau de qualité suffisant pour être commercialisable. Vous avez des atouts considérables : vous pouvez être à la fois le dessinateur et le scénariste (beaucoup d'auteurs de BD sont en tandem) et vous êtes multilingue en langues parmi les plus répandues au monde.

Du Kindle direct publishing pour des textes "en noir" à l'édition de BD, c'est comme passer du petit artisanat à l'industrie lourde. Envisagez donc d'externaliser la fabrication et la vente. Prenez langue auprès d'éditeurs de BD. Et pas seulement en France. Juste pour lever le doute.

Sur le site du Collège de France, la version en vidéo.

Merci de l'information concernant l'usage de la mémoire qui ne se ferait que très peu sur le tas en calcul intensif alors que j'aurais parié (gros !) sur le contraire !

Pour information :
Par le plus grand des hasards, hier, au cours d'un dimanche oisif, voulant me documenter sur la nouvelle version 10 de gfortran, j'ai lu la version actualisée de son manuel. À la section 5.5 Thread-safety of the runtime library, voici un extrait qui apporte un peu d'eau à mon moulin :

The GNU Fortran runtime library uses various C library functions that depend on the locale, such as strtod and snprintf.

En tout cas, ce fils de discussion m'aura été bénéfique en ce qu'il m'a obligé à faire la synthèse d'éléments éparpillés dans ma cervelle ! Et puis ça m'a déjà motivé à me plonger dans la doc en programmation asynchrone avec laquelle nous allons devoir vivre dans le futur.

Votre recherche est intéressante car je ne connais rien d'existant sur l'étagère. Juste en y réfléchissant cinq minutes, je verrais bien le bricolage suivant.

Installer un serveur Web en mode statique, du genre Apache. Créer deux fichiers par capteur à monitorer (mon_capteur_OK / mon_capteur_HS). Lesdits capteurs faisant un wget sur l'un ou l'autre fichier selon que ça va bien ou pas. Configurer le logging de l'Apache. Ensuite, il y a une foultitude de moyens d'analyse des logs ; comme un script faisant son tri depuis une sortie du genre tail -200 /var/log/apache2/access_log. Dans l'hypothèse où le capteur n'a pas appelé c'est également une indication. Il y a donc trois couleurs : vert, rouge, noir.

Sauf si on reste dans un réseau domestique, La question aigüe concerne la résolution de nom d'hôte Internet de l'Apache (sauf à bénéficier d'une IP fixe). Mais peut-être avez-vous déjà un serveur chez vous ou chez un hébergeur ?

Peut-être y aurait-il un business à créer ? Mais je serais bien étonné que personne n'y ait jamais songé ! Auquel cas une recherche sur le Grand Ternet devrait le révéler ; ça pourrait faire l'objet d'un journal, d'une étude comparative.

La libc, c'est effectivement pour les interactions avec le système (allocations mémoire, i/o, …). Mais ça représente quoi sur un programme de résolution d'équation ?

Tout dépend du programme. Si ça joue sur des fonctions trigonométrique, gfortran va employer, entre autres, la bibliothèque libquadmath. Ce qui veut dire que l'on code en Fortran ou en C ça ne change que sur l'ergonomie puisque C l'utilise aussi. (Voir ce commentaire sur les bibliothèques invoquées depuis gfortran.) Si ça joue sur d'autres choses mathématiques qui ne sont pas dans libquadmath, un programme pourra invoquer une bibliothèque spécialisée comme la bien connue blas qui a aussi une déclinaison en C (cblas). Une liste des bibliothèques numériques ici.

Le compilateur Fortran fera la différence en ce que c'est son cœur de métier contrairement à C. Fortran à une approche algébrique des choses et il fait parfaitement la différence entre un entier négatif, zéro et un entier positif. Fortran, par défaut, compte à partir de un. Le langage C, par défaut, compte à partir de zéro ; il est plutôt orienté sur la logique. Voir aussi ce commentaire.

Si la tâche s'exécute en quelques secondes sur un seul cœur, on n'est pas dans le domaine du calcul intensif. À la limite, si l'on veut triturer des équations déjà disponibles en bibliothèque, peu importe le langage. Mais si on doit faire chauffer les processeurs pendant plusieurs heures, voire plusieurs jours ou même plusieurs semaines comme ça se voit dans de très grands centre de calcul, on ne peut pas occulter le rôle primordial des systèmes d'exploitation. D'où une influence de la qualité de la libc sur les performance globales.

Par exemple, 10 % de différence de perf sur un job de 10 heures ça commence à compter au niveau de la facture d'électricité et de l'immobilisation du matériel. Si on est sur une station de travail dont on est le seul utilisateur, on peut s'en ficher puisque l'on fera tourner le soft pendant la nuit. Et puis la consommation d'électricité passera en frais généraux. Mais si on est sur un cluster de plusieurs centaines de nœuds, c'est facturé !

Je ne peux absolument pas répondre à la question de jusqu'à quel point la libc influence les performances car je ne fais pas de calcul intensif. C'est pourquoi j'aimerais que ceux qui en font livrent leur témoignage. Ce type de témoignage n'est pas évident à trouver car le calcul intensif se pratique soit au profit d'une entreprise (protégée par le secret des affaires ou le secret industriel), soit au profit du monde militaire (protégé par le secret défense) ou des labos publiques où la communication est encadrée.

À noter, qu'à l'extrême opposé du calcul intensif, les micro-services hébergés dans le Cloud sont facturés au temps de fonctionnement et que la libc musl a une bonne réputation pour les containers (particulièrement avec la distro Alpine Linux qui l'emploie).

Il est difficile de généraliser sur les performances en calcul intensif car le champ des machines va d'une unique station de travail plus ou moins survitaminée à la grappe de centaines de machines pas chères. L'espace mémoire n'est pas forcément continu et les processeurs peuvent être en partie virtualisés par GPU. Certaines configurations auront obligatoirement des I/O au niveau du matériel d’interconnexion ce qui fait qu'un programme faisant des maths pures peut avoir les mêmes contingences qu'une base de données.

D'autre part, un exécutable peut se fabriquer sous deux formes principales : édition de liens statique ou dynamique.

Si on lie toutes les bibliothèques avec la routine principale on obtient un gros binaire exécutable autonome. Ça charge lentement mais ça fonctionne ensuite plus vite.

Si l'on recule l'édition de lien au moment du chargement du programme ET si on active l'option "lazy", la routine principale ne nécessitera que l'édition de lien des seules portions de bibliothèque indispensables au démarrage. Par la suite, d'autres portions de cette bibliothèque seront liées au fur et à mesure des besoins. Ça charge plus vite mais ça fonctionne plus lentement.

À noter que ces portions d'exécutables sont dispersées sur le système de fichier et que la latence de chargement "à la demande" varie selon la configuration de la variable d'environnement PATH au niveau des répertoires à explorer. Un appel système donné ne sera donc pas activé avec le même vivacité selon le référencement du répertoire de la librairie qui l'actionne. Typiquement, une lib chargera plus vite si elle est en /usr/lib plutôt qu'en /usr/local/lib.

Dans le cas de musl, on est un peu dans la même démarche qu'a eu BusyBox bien connu du monde de l'embarqué : tout mettre dans le même panier. Dans le duel "glibc" face à "musl", on retrouve la même controverse que celle des micros noyaux face aux noyaux monolithiques.

Je suppose qu'une configuration matérielle donnée sera plus avantagée par une libc donnée plutôt qu'une autre selon qu'elle soit orientée monotâche ou multitâche. Et, dans le cas de matériels poussés à l'extrême, cette différence doit être encore plus sensible qu'avec la bureautique. Sachant aussi qu'un logiciel de calcul peut être tout aussi bien fonctionner en mode monotâche ou multitâche selon qu'il est parallélisé ou non / distribué ou non.

Complètement d'accord ! Voir ma réponse à jves ci-dessus.

Mon interrogation porte sur l'influence du choix de la la libc (glic vs musl par ex.) sur les performances. J'ai constaté, sur une routine faisant massivement des écritures sur le système de fichier, qu'il y avait une différence humainement perceptible.

Mon usage de Fortran n'est pas le domaine mathématique mais celui des données. (D'un point de vue historique, avant la banalisation de Basic puis du C, Fortran 77 était couramment employé pour gérer des petites bases de données. Il peut toujours le faire par accès directs aux fichiers. Fortran 77 était réellement un langage bon à tout faire. Il a même existé une norme ISO Fortran temps réel industriel.)

Sachant que le calcul intensif (ou la programmation orientée objet) fait massivement la trituration de données sur le tas, l'appel système mmap() est forcément de la partie. Je fais la supposition que GCC se sert de la libc pour l'invoquer.

Dans le cas de mon moteur de blog, je l'ai débuté sous F77 et j'employais des fichiers de manœuvre SCRATCH pour gérer les chaînes de caractères de longueur variable. La modernisation du langage apportée par gfortran m'a permis de transférer dans la mémoire vive mes traitements intermédiaires. Ce qui fait que j'ai beaucoup moins d'entrées-sorties sur disque. Mais ils en reste beaucoup…

Ce qui m'intéresserait de savoir, par pure curiosité intellectuelle, c'est si le choix de la libc a également une influence sur les performances sur des traitements ne faisant que peu ou pas appel à des I/O sur le système de fichier. Les programmeurs en calcul intensif me semble être les personnes idoines pour satisfaire à ladite curiosité !

Je me suis mal exprimé !

Contrairement à Fortran, le langage C prévoit deux situations : programmation sur machine bare metal ou bien machine dotée d'un système d'exploitation.

Étant donné que le choix a été fait de tout mettre dans une seule librairie, la libc cumule deux emplois : une extension au langage lui-même et une interface au système d'exploitation.

Dans le cas de gfortran, on est implicitement dans le cas d'une programmation sous système d'exploitation. (D'un point de vue historique, Fortran a d'abord été implémenté sur une machine bare metal. Par la suite, il y a eu les hyperviseurs puis les OS. Le langage successeur à la programmation algébrique sur machine bare metal fut Forth.)

Mon propos est que gfortran est l'un des frontends de GCC qui gère plusieurs langages de programmation. Que ce soit du C ou du Fortran, le processus passe toujours par le tronc commun GIMPLE. Le processus GCC passe la main ensuite à la libc quelque soit le (ou les) langage(s) de programmation à l'origine du processus. (Je peux être dans l'erreur mais c'est ainsi que je vois les choses.). De ce qui précède (c'est une boutade !) gfortran est bien en amont à la libc sans laquelle rien n'est possible sous Posix.

Mille mercis à jyes et Gabbro pour cette comparaison entre Fortran et C++. Ça corrobore ce que je sentais obscurément. Mais je pense que C++ restera encore longtemps dans la course car ce langage semble posséder assez expédients (comme le préprocesseur C) pour être rapidement opérationnel sur du matériel nouveau comme les accélérateurs et autres machines hétérogènes.

Ces témoignages pourraient conduire à une aimable discussion du vendredi sur le sujet suivant : « Est-il censé de gaver de serpent des générations d'étudiants alors Fortran est une nourriture plus saine et digeste ? ».