Voici l’épisode 6 d’une histoire de l’informatique moderne…

Dans cet épisode, on revient sur les vrais débuts de la vague “micro-informatique” avec CP/M, l’Apple II et le TRS80 plus la notion de “killer app” si importante…

Publié dans Anecdotes IT, documentaires IT, Une histoire de l'informatique moderne en vidéos | Laisser un commentaire

Une course de SimRacing de 12 heures au Mans sur Automobilista 2 avec Val & Justin

Parlons de SimRacing pour changer un peu !

Avec mes fils, nous avions envie de (re)faire une course d’endurance ensemble depuis longtemps. Nous avions fait une course de 6 heures l’année dernière, il était temps de monter au cran supérieur : une course de douze heures dans le cadre somptueux du grand circuit du Mans sur Automobilista 2 (AMS2) qui, au risque de me répéter, est bien la meilleure simulation du moment. Bien entendu, nous avons aussi l’ambition de refaire une course de 24 heures,  comme j’en ai déjà fait avec Val dans les années 2000 puis 2010. Mais ça, ça se prépare sérieusement d’où cette étape à douze heures, histoire de  continuer la “formation” de Justin, 15 ans (qui est déjà plus rapide que moi dans la plupart des situations !).

On se fixe de consacrer la journée de vendredi à cette course et, le jeudi 9 mai, nous avons juste fait les derniers ajustements de préparation : validation du choix de la LMDH par Val (32 ans), mise en place du système audio par Justin (le pilote a un casque audio sur les oreilles mais un microphone et un autre casque audio lui sont reliés… ainsi, on peut parler au pilote et on peut également entendre ce qu’il entend : bruits moteurs, Crew Chief qui commente et ainsi de suite) et test de ce système avec moi. Ce système audio s’est avéré très utile car il nous a permis d’échanger avec le pilote pendant qu’il roulait et d’entendre la même chose que lui et ainsi de savoir où il en était, ce qu’en disait Crew Chief afin de prendre les bonnes décisions si nécessaire.

De plus Justin et moi, nous avons roulé avec le plein et les pneus durs afin de valider cette configuration pour la course (finalement, on utilisera plutôt les pneus médium)… Nous avons décidé de rouler avec la Cadillac parce que, suite à mes tests, je trouvais qu’elle était un poil plus facile que la Porsche 963 et puis, j’avoue, j’aime pas la BMW LMDH (sans pouvoir expliquer pourquoi, question de ressenti…).

La veille au soir, nous avons décidé de faire des double-relais pour chacun tout au long des douze heures. Val va faire les qualifs afin de se familiariser avec l’interface de choix techniques (carburant à embarquer, changement de pneus ou pas, réparation à effectuer, etc.) pour les relais.

Pendant ces tests, nous avons roulé avec 31 adversaires IA dans les catégories suivantes : LMDH, GT3 gen2, LMP2 (mod de Thunderflash) et DPI afin d’avoir un plateau plus varié que simplement plein de LDMH et de GT3…

Nous avons opté pour une course de 12 heures (c’est déjà pas mal !) avec le temps accéléré deux fois (x2) afin de simuler un cycle complet de 24 heures. Nous avons choisi de régler les IA à 95%. On pouvait sans doute mettre plus mais on a pensé que c’était bien à ce niveau… Pour ce qui est du circuit, le grand circuit du Mans dans toute sa splendeur et dans une version toute récente.

J’ai défini quatre segments météo distincts (afin d’avoir un peu de brume au lever du soleil) mais pas de pluie au programme. En roulant, je me suis dit aussi que, la prochaine fois, on optera pour le pare-brise qui se salit afin de renforcer encore le réalisme. Ceci dit, en matière de réalisme, il faut savoir se contenter d’une balance bien équilibrée afin d’être capable de la supporter pendant douze heures…

On aurait aussi pu faire cette course avec LMU (Le Mans Ultimate) mais j’estime qu’à ce stade du développement de LMU, la fiabilité est encore très discutable (j’ai eu de nombreuses mauvaises expériences dans ce cadre et ce assez rapidement, pas au bout d’une heure !!).

Le matin (vendredi 10) avant le départ de la course

Le matin avant le grand rendez-vous, nous avons fait un peu de roulage par Justin et moi sur la Cadillac pour tester les pneus médium (qu’on va finalement retenir). Val prend le volant pour les qualifs après que je lui ai montré comment se servir de l’interface avec les stands. Pendant les qualifs, Val est coaché par Justin via le système audio afin d’affiner le choix des trajectoires et des points de freinage.

Mais, mauvaise nouvelle : je m’aperçois que la voiture ne ravitaille pas en essence !

Le temps qu’on comprenne qu’il s’agit simplement d’une option mal positionnée, il est déjà 10h00, l’heure prévue pour notre départ. Donc, alors que Val avait signé la pôle lors des qualifs, je suis obligé de relancer, de supprimer les qualifs et de partir (puisque c’est moi qui est prévu pour prendre le départ) au milieu des autres LMDH (en 6ème position).

Départ à 10h10.

Comme tout se cumule, je me retrouve à devoir faire le tour de formation (encore un oubli dans les options mais j’en profite pour vérifier mes “choix de stand” afin que le prochain arrêt soit conforme à mes intentions) et, enfin, le drapeau vert nous libère !

Je reste 6ème deux/trois tours puis remonte en 3ème position et prend finalement la tête au 6ème tour. Le reste de mon relais se passe bien, arrêt au 12ème tour, je garde mes pneus médium à peine entamés et repars second. Pas pour longtemps car je retrouve la tête le tour d’après (arrêt du leader). Bon début donc. Seul souci : Crew Chief m’a prévenu que nous avons un début de dommage aux freins et j’essaye donc de les épargner en freinant un poil plus tôt.

Les LMP2 ne sont pas restées longtemps en piste : elles sont toutes arrêtées aux stands juste après le premier ravitaillement !

C’est sans doute un bug de ce mod qui ne gère pas correctement cet aspect pourtant essentiel des courses d’endurance… Eh oui, c’est pas facile de mettre bien au point un mod !

N’allez surtout pas croire que je critique gratuitement le travail de Thunderflash, tout au contraire. Je voudrais en profiter pour le remercier ici et maintenant de son travail. C’est grâce à lui et à d’autres qu’AMS2 est en train de prendre une autre dimension grâce à l’ajout des mods (voitures supplémentaires mais aussi circuits inédits). C’était à moi de tester complètement ce mod LMP2 avant de décider de l’inclure dans notre événement. Je ne l’ai pas fait et je dois ne m’en prendre qu’à moi, point.

Ce premier relais est l’occasion de savourer le ressenti sur AMS2 et de saisir combien cette simulation est aboutie désormais. Non seulement l’aspiration est sensible dans les lignes droites mais on sent également que la voiture est “déventée” lorsqu’on en suit deux ou trois dans les enchaînements de la nouvelle section et ça oblige à adapter son pilotage pour ne pas se retrouver “dans le mur” bêtement… Ces LMDH sont très réussies et je crois que j’aimerais juste que le son des voitures soit plus accentué (du niveau de LMH qui, sans conteste, est la meilleure simulation sur ce point précis, on s’en rend compte quand on peut entendre les retransmissions en caméra embarquée comme ce week-end pour les 6 heures de Spa, la troisième manche du WEC).

Au tour de Val

Je m’arrête de nouveau aux 22ème tour et passe le relais à Val. Bien qu’il conserve lui aussi les pneus médium qui tiennent bien le coup, son arrêt est plus long que prévu (plus de deux minutes) car l’équipe répare les freins. Val repart en 5ème position. Val est vite remonté en tête mais Crew Chief a de nouveau alerté sur des problèmes de freins. Nous prenons la décision de réparer tout au prochain arrêt. Le premier arrêt de Val (au 34ème tour) est très long, comme prévu : 2’50” !

Il repart 9ème du coup mais avec une voiture quasi-neuve (pneus changé aussi)… Second arrêt de Val au 45ème tour (remonté en 5ème place), Justin prend le relais et repart en 8ème position. Nous avons un tour de retard sur le leader et il reste 9h14 de course…

Justin remonte

Au 50ème tour, Justin est déjà remonté en 3ème position dans le tour du leader. Il passe second au 54ème tour peu avant de devoir s’arrêter et même reprend la tête brièvement avant de ravitailler au 55ème tour. Il repart 5ème, juste dans les roues du 4ème et recommence sa remontée. Le crépuscule tombe déjà sur le circuit…

Il passe second au 59ème tour avec une vingtaine de secondes de retard sur le premier. Il prend la tête au 60ème tour suite à l’arrêt ravitaillement du leader. Toujours nos soucis de freinage : Crew Chief nous demande de faire un stop pour les fixer. Je prend le relais au 67ème tour en gardant les pneus médiums qui ont déjà deux relais dans les roues… En pleine nuit.

Un relais difficile, très difficile !

J’ai été obligé de m’arrêter au tour 75ème tour pour changer les pneus et réparer les freins car la voiture était devenue très dure à piloter : peu de grip (pneus), presque plus de frein !

J’avais du mal à la garder sur la piste et j’étais de plus en plus lent. Je suis tout de même allé au bout de mon relais mais c’était carrément pénible et je me traîne à la fin avec une voiture carrément rétive (très peu de freins au Mans sur une LMDH, ça ne le fait pas !). Je n’arrivais même plus à doubler les DPI, il était temps de s’arrêter…

Je perds 3’15” et repart 8ème mais la voiture est transfigurée et je peux de nouveau attaquer. Quelle différence et quel plaisir !

La nuit n’est pas gênante et la voiture performe à son max : ma remontée est donc relativement facile.

Quand je rends la voiture pour Val au 88ème tour, nous sommes de nouveau en seconde position.

Val enroule

Il repart en troisième position. Val enroule son relais en seconde position à 20 secondes du leader. Arrêt (carburant) de Val dans le 99ème tour pour son relais. Il reprend la tête au 105ème tour (arrêt aux stands du leader).

Val s’arrête à la fin du 110ème tour pour ravitailler mais Crew Chief nous signale que les freins sont out (les disques passent du rouge au bleu très vite, signe certain du problème, on commence à être habitués !) et vont devoir être réparés : un arrêt long en perspective… Arrêt de 2’54” et Justin repart 6ème.

Le jour se lève

Au 120ème tour, Justin prend la seconde place et le jour commence à se lever, tout doucement (avec des traces de brume sur le circuit, ça fait très le Mans…)  !

Arrêt carburant pour Justin à la fin du 121ème tour. Seulement 42 secondes d’arrêt, Justin conserve la seconde place. Arrêt carburant de Justin au 133ème tour (alors en tête), je prend la suite en gardant ses pneus (médiums). Le soleil est désormais bien visible sur l’horizon mais il y a encore des brumes ça et là.

Tout-droit à Arnage

Je repars en tête mais, au milieu de mon relais alors que tout va bien sur la voiture, je fais un tout-droit à Arnage (en voulant doubler une GT3) et j’abîme mon capot avant (le décalage du capot par rapport à sa position normale est bien visible depuis le cockpit). Avec cette “nouvelle configuration” (!), je perds en vitesse de pointe mais pas trop en tenue de route.

C’est le genre d’erreur qu’on veut à tout prix éviter et le type même de situation sur laquelle j’ai insisté auprès de Justin et Val et c’est moi qui commet l’erreur, sans aucune circonstance atténuante… La morsure du Mans fait mal quand on la subit !

Je fais tout réparer lors de mon arrêt au 143ème tour. Arrêt de 2’50, je repars en 4ème position. Après cet arrêt, la voiture était de nouveau parfaite et j’ai pu battre mon meilleur tour (3’33”0). Plein soleil, plus de brume.

J’ai repris la tête au 147ème tour et me suis arrêté au 155ème tour : arrêt court, carburant seulement.

Bon relais de Val sous le soleil

Val prend le volant et repart en tête. Bon relais pour Val qui a un bon rythme (quelques tours en 3’31’xxx). Arrêt carburant seul, au 165 tours, 40 secondes d’attente et Val repart en tête pour son dernier relais. Il s’arrête au 176ème tour pour carburant seul (toujours en tête). 40 secondes d’arrêt et Justin repart toujours en tête. Plus que 1h09 de course, c’est Justin qui va donc finir notre course. 

Justin termine la course et sauve le résultat !

Justin a fait la même erreur que moi en voulant garder les pneus du dernier relais de Val : ils ne semblaient pas trop usés mais, en fait, le grip en est diminué (et peut-être que l’arrêt où les pneus ont le temps de refroidir joue aussi) et cela affecte la performance de la voiture.

Justin décide de s’arrêter au bout de quelques tours, en concertation avec moi (au 180ème tour), car la voiture a peu de grip et les freins qui faiblissent de nouveau. Il vaut mieux qu’il dispose d’une voiture au top pour pouvoir attaquer si ça s’avérait nécessaire.

Cet arrêt a duré 2’43” et Justin  repart en première position (avec seulement 31 secondes d’avance sur le second) pour encore 47 minutes de course. Pour économiser le carburant et d’éviter de devoir s’arrêter de nouveau, Justin est passé à la carburation à “normale” plutôt que “riche” (la position “pauvre” est également disponible au cas où ça ne suffirait pas). Justin perd un peu de vitesse de pointe mais c’est une perte limitée. On y a cru un moment mais les calculs que je fais et refais sont sans appel : à ce rythme de consommation (même un peu réduite) et avec le temps qui reste, ça ne passe pas…

Finalement, un “splash & dash” (j’ai calculé qu’il fallait au moins 20 litres mais on se décide pour 35 litres afin d’avoir une marge de sécurité) s’est avéré nécessaire et Justin s’arrête au tour 186 alors qu’il reste 24 minutes de course. Il repart après 14 secondes d’arrêt (rapide au moins ce “splash & dash”) et reste en tête (avec 38 secondes d’avance sur le second, l’écart est resté stable par la suite). Justin maîtrise la situation et pilote de façon sûre, on se met à y croire…

L’arrivée est au bout de cet effort collectif et c’est avec un certain soulagement qu’on voit le temps s’écouler jusqu’à arriver à zéro. La ligne franchie en souplesse, c’est fait, c’est à nous !

Nous avons terminé en tête avec 52 secondes d’avance (194 tours en tout) au bout de ces douze heures palpitantes de bout en bout !

Analyse d’après course

La question la plus évidente est forcément “pourquoi avons-nous eu ces problèmes de freins répétés ?”… en effet !

Nous avons été obligés de réparer les freins au moins 4 ou 5 fois… en douze heures, ça fait quand même beaucoup !

Etait-ce parce que les écopes de refroidissement n’étaient pas assez ouvertes (mais, dans ce cas, Crew chief te préviens tout de suite que “tes températures de frein sont bien trop hautes, mon pote” avec sa verve coutumière… Ou bien était-ce parce que nous avions un pilotage trop agressif ?

Tout au long de la course, nous avons tenté, avec plus ou moins de soin plus ou moins de constance, de gérer le problème et d’atténuer le phénomène. Déjà, nous avons rajouté du frein sur le train arrière (à plusieurs reprises) pour moins solliciter les freins avant mais sans que la balance soit trop impactée car cela influence beaucoup le comportement de la voiture, en particulier pour le grand droite en montée qui marque l’entrée de la nouvelle section après Arnage…

Mais il faut bien admettre que rien de ce que nous avons tenté n’a vraiment eu d’effet. Il faudra que je mène des tests pour en avoir le cœur net. La gestion des dommages mécaniques est de plus en plus fine sur AMS2 et c’est super tant qu’on en est pas victime !

Par exemple, on peut endommager le moteur en rétrogradant trop vite à la volée (voir le casser en une fois en loupant un changement de vitesse avec la boite en H, genre enclencher la seconde au lieu de la quatrième en pleine accélération !) et on peut même avoir une fuite du liquide de refroidissement (“coolant leak”, avec les conséquences qu’on imagine…) si on frotte trop le bas de caisse sur les vibreurs !

Là encore, on est confronté aux contradictions de notre quête du réalisme qui doit tout de même rester dans le cadre d’un gameplay acceptable… qui voudrait d’une voiture qui ne démarre pas parce qu’on a loupé une étape dans une procédure trop compliquée ?

On aurait pu (on aurait dû ?) mettre les IA à un niveau plus élevé mais, après réflexion, c’était quand même bien ainsi (même si certains d’entre vous vont penser “tu parles d’une perf, à 95%, c’était trop facile !”… à ceux-là je vais juste répondre “roulez pendant douze heures et on en reparle…”). 

Bilan sur AMS2

AMS2 a tenu l’épreuve sans flancher un seul instant ni même avec une baisse de FPS ou des aberrations visuelles pendant la nuit… chapeau !

Cependant, on peut quand même émettre quelques critiques. Tout d’abord, les feux de signalisation (présents tout autour du grand circuit du Mans) n’ont quasiment servi à rien : feu vert clignotant pendant le départ et plus rien après !

Pas de drapeau bleu lors des dépassements des attardés, pas de drapeau jaune pour signaler les incidents, rien. C’est vraiment dommage surtout si on compare à LMU qui est elle irréprochable sur ce point (mais critiquable sur bien d’autres). Au niveau des incidents également, on n’en a pas vu alors que la course durait douze heures tout de même !

Pendant les essais, j’ai pu voir au moins un tête à queue d’une DPI à la chicane Dunlop… Mais ça reste trop peu. Attention, je ne demande pas une “crash fest” mais un peu plus d’animation. Ceci dit, des incidents, il y en a peut-être eu mais pas devant nous et le Mans est un grand circuit…

Donc, en dépit de ces quelques critiques (on en veut toujours plus !), le bilan est largement positif : AMS2 permet de mener des longues courses d’endurance en se faisant oublier. C’est important et rassurant, merci Reiza !

Publié dans Sports mécaniques virtuels | Laisser un commentaire

Une histoire de l’informatique moderne, cinquième épisode…

Voilà déjà le cinquième épisode… Dans cet épisode, nous allons retracer les débuts de la Silicon Valley et la naissance du microprocesseur mais pas seulement : il ne faudrait pas oublier le rôle joué par les périphériques de stockage (disquettes et disques durs) et nous évoquerons le parcours d’Alan Shugart dans ce domaine…

Publié dans Anecdotes IT, documentaires IT, Une histoire de l'informatique moderne en vidéos | Laisser un commentaire

Un documentaire sur la F1 de l’année 1973, “Champions forever”

Vous avez peut-être déjà vu ces images, au moins en partie, dans d’autres documentaires sur le sujet. Mais les voilà réunies dans un film entier assez long qui romantise un peu le “formula one circus” de cette époque. La musique et le cadrage sont aussi typiquement “années 70” !

Pour les vrais amateurs d’un sport-auto disparu depuis bien longtemps

Je ne peux pas l’inclure dans cette page, il faut suivre ce lien et le regarder sur YouTube…

Publié dans Sport-auto | Laisser un commentaire

Une histoire moderne de l’informatique, l’épisode quatre est disponible

Voici déjà le 4ème épisode de notre série sur une histoire de l’informatique moderne !

Pour cet épisode, je vous propose de détailler les étapes importantes qui ont achevé de consacrer le logiciel comme élément déterminant du développement de l’informatique. En fait, cette histoire est toujours d’actualité et il est encore aujourd’hui nécessaire de répéter encore et toujours que le matériel n’apporte que des capacités qui ne sont rien, ne servent à rien s’il n’y a pas du logiciel pour exploiter et transformer ces capacités en applications… CQFD.

Publié dans documentaires IT, Informatique, Références IT, Une histoire de l'informatique moderne en vidéos | Laisser un commentaire

Une histoire moderne de l’informatique, l’épisode trois est disponible

Cette fois, j’ai mis un peu plus de temps car j’ai été malade, tout simplement !

Cela peut même s’entendre (un peu) lors de l’enregistrement car je tousse de temps à autres… Mais j’ai quand même pu l’achever et je vous le propose aujourd’hui : l’épisode 3 sur l’ère des constructeurs.

 

Dans cet épisode trois, j’évoque Seymour Cray et, si vous voulez en savoir plus sur l’histoire de CDC et de Cray Research, je recommande d’aller voir cette vidéo fort bien faite : These Computers Changed the World.

 

Publié dans documentaires IT, Livre histoire de l'informatique, Références IT, Une histoire de l'informatique moderne en vidéos | Laisser un commentaire

Le fameux challenge Can-Am en deux vidéos

ON trouve de tout sur YouTube mais il faut savoir chercher…

Aujourd’hui, je vous propose deux vidéos longues et rares centrées sur le challenge Can-Am. La première balaye la première période de 1966 à 1973 alors que la seconde nous donne un aperçu de la seconde période, la saison 1981 où les formidables voitures n’étaient plus que des F5000 avec des carrosseries enveloppantes (mais cette période est rarement traitée, d’où son intérêt.

Publié dans à travers mes découvertes, Sport-auto | Laisser un commentaire

Une histoire de l’informatique moderne (en vidéos par épisode), mon projet du moment !

== Nouveau, j’ai regroupé tous les épisodes en cours (et à venir) sur cette page ! ==

C’est un projet qui me tient à coeur depuis un bon moment… Réaliser un documentaire vidéos sur l’histoire de l’informatique moderne, un peu comme je l’avais fait il y a longtemps sur la Porsche 917

Bien entendu, j’ai déjà publié “Cow-boys contre chemin de fer ou que savez-vous vraiment de l’histoire de l’informatique” rédigé avec Laurent Poulain. Mais ce livre a presque quinze ans déjà et je voulais en faire une version deux (toujours avec Laurent) depuis au moins deux ans (c’est en cours mais ça va prendre des mois !).

Je n’avais pas envie d’attendre aussi longtemps avant de vous proposer quelque chose sur ce sujet passionnant. J’ai donc longuement muri ce projet avant de me lancer. Tout d’abord, définir la forme (des slides illustrés avec mon commentaire en voix-off). Pareil sur le fond : pas question de revenir une fois de plus (une fois de trop) sur Babagge et autres antiquités poussiéreuses, on doit se concentrer sur la période moderne de l’histoire de l’informatique, point !

Voici les trois premiers épisodes (l’intro plus épisodes 1 & 2). Chaque épisode me demande une grosse semaine de travail et j’imagine que je vais devoir faire au moins une dizaine d’épisodes (voire plus en fait, je ne sais pas trop à ce stade). Je vous proposerais donc les épisodes sur ce blog au fur et à mesure de leur production. Commençons par le commencement, voici les trois premiers, j’espère qu’ils vont vous intéresser !

Publié dans Anecdotes IT, documentaires IT, Une histoire de l'informatique moderne en vidéos | Laisser un commentaire

Nous vivons une ère de propagande grossière et insultante

Depuis la trop fameuse “crise sanitaire” qui était, en réalité, une “expérience sociale d’obéissance à grande échelle” (relisez ces mots, ils sont lourdement significatifs…) comme le souligne le rapport récent publié par le CNRS (je n’invente rien, hélas, allez le lire !), nous vivons dans un déferlement de propagande qui rappelle des heures sombres des deux premières mondiales (avec toutes les exagérations, les dramatisations et, disons-le, les mensonges qui accompagnent inévitablement les opérations de propagandes, quel qu’en soit le camp d’origine).

Nous avons pu constater que les médias sociaux comme YouTube, Facebook, Twitter et Linkedin (pour ne nommer que ceux-ci) ont pratiqué et pratiquent encore (sauf pour Twitter depuis qu’il est devenu X) une censure à grande échelle, arbitraire (oui, je sais, c’est le propre de la censure mais je crois nécessaire d’insister) et impitoyable. On pouvait penser que, du côté des médias de “divertissement” cela serait différent. Eh bien, je viens de réaliser qu’il n’en était rien et que Netflix fait partie de la bande sans aucun complexe.

En effet, il suffit de regarder le documentaire “Turning Point : l’arme nucléaire et la guerre froide” pour s’en rendre compte. J’ai rarement pu voir un contenu aussi dégoulinant de propagande que ce truc…

Pour s’en convaincre, il suffit de regarder qui est interrogé : le clown Volodymyr Zelensky et l’horrible Condoleezza Rice (j’espérais bien ne plus jamais revoir cette harpie…). Je vais vous résumer rapidement ce “documentaire”, ça vous évitera un visionnage pénible : la guerre froide a commencé à cause des Russes a heureusement été gagnée par ces nobles américains et c’est l’affreux Poutine (souvenons-nous que Poutine, c’est le diable… un petit rappel toujours utile) qui l’a réenclencha en envahissant l’Ukraine, point final.

Si, à ce stade, il n’y a rien qui vous dérange dans cette simplification historique express… Hé bien, je ne peux rien pour vous et vous vous êtes trompé de blog. 

Publié dans à travers mes découvertes, La terrible vérité | Laisser un commentaire

Trump, le retour !

Dans quelques mois, il y aura de nouveau des élections présidentielles aux USA… et c’est un rematch Trump-Biden !

Trump, encore ?

Cassons le suspense tout de suite : Trump va être élu, largement. En fait, il serait plus exact d’écrire qu’il va être réélu… Comment puis-je en être convaincu ?

Eh bien, c’est simple, si les démocrates persistent à vouloir aligner Biden de nouveau, c’est sûr, ils vont perdre. On pourrait remplacer Biden par Kamala Harris (la VP actuelle) par exemple, mais ce serait encore pire vu la popularité (méritée) de cette dernière. Les démocrates veulent se tirer un balle dans le pied mais pas à ce point !

Revenons à Trump. Bon, il va être de nouveau président, est-ce une bonne nouvelle ?
Pas vraiment car j’ai une assez piètre estime pour ce personnage qui est, selon moi, du niveau de Berlusconi. Si vous lisez ce blog, vous verrez que j’ai annoncé son élection à l’époque où cela paraissait encore impensable mais que je n’ai aucune illusion sur le personnage.

Cependant, difficile de faire pire que Biden (merci pour la guerre en Ukraine, Joe !) et Trump, au moins, ne provoque pas de nouvelle guerre quand il est au pouvoir…

Maintenant que la montée de Trump apparaît comme inéluctable, les médias “bien-pensants” s’affolent : “Trump est un monstre”, “Trump est le diable” et j’en passe… Bizarre, je pensais que c’était Poutine qui était “LE” diable… Il y en aurait deux finalement ?

Publié dans à travers mes découvertes, Ce blog, La terrible vérité | Laisser un commentaire

Il y a 60 ans, IBM lançait le 360, le premier mainframe compatible qui aillait définir le standard de l’industrie informatique pour des décennies…

En effet, le 7 avril 1964 (je suis en retard de quelques jours !), IBM annonce enfin le système 360, la gamme 360 et c’est un événement énorme !

Revenons sur cet épisode, il le mérite bien…

Situation chaotique chez IBM

Au début des années soixante, IBM est dans une situation délicate. En effet, son activité informatique commence à vraiment prendre de l’ampleur (chez IBM, le chiffre d’affaires généré par les ordinateurs dépassa celui des tabulatrices mécanographiques en 1962), mais la situation est chaotique : en effet, IBM ne produit pas moins de sept modèles d’ordinateurs différents en 1960. Ce fractionnement de l’offre vient de la politique commerciale qui consiste à adresser chaque marché séparément, à les traiter comme des niches distinctes.

De plus, avant 1960, les connaissances des besoins, des modes d’utilisation, des technologies et de leur évolution future n’étaient pas suffisantes pour définir des standards qui auraient pu servir de base à une famille d’ordinateurs universels compatibles. Et IBM a toujours encouragé la concurrence interne en matière de développement. La politique commerciale d’IBM a toujours été de coller au plus près de chaque marché, mais sa politique technique a toujours été de le faire avec le moins de matériels différents possibles (ce qu’elle n’a pas toujours été capable de faire d’ailleurs).

IBM, un géant éparpillé !

Sur le plan industriel, IBM ne tirait alors aucun bénéfice de sa taille puisque chaque type de machine était assemblé avec des composants différents. Pas moins de 2 500 circuits électroniques distincts sont fabriqués cette année-là (en 1960) pour ces ordinateurs, tous différents et qui n’ont presque rien en commun. Idem pour les périphériques.

La division ordinateurs d’IBM de cette époque ressemblait à une fédération de PME, chacune travaillant dans son coin avec ses propres équipes (tout était dupliqué : études, fabrication, marketing et même forces de vente !) sans aucune coordination ni même l’embryon d’une politique commune.

Non seulement le problème était bien présent au niveau matériel, mais il était encore plus aigu au niveau logiciel : la prolifération des lignes d’ordinateurs avait engendré la multiplication des combinaisons logicielles associées. Les équipes de programmeurs d’IBM étaient submergées par la nécessité d’écrire et de réécrire les systèmes d’exploitation et les applications pour les différentes familles de systèmes et il paraissait clair qu’à brève échéance, cette situation n’était pas tenable.

À côté de cela, la division mécanographique était bien mature et alignée sur la série 400 qui satisfaisait l’ensemble des clients. La rationalisation de la production de la série 400 avait réduit les coûts à un point tel qu’IBM n’avait plus vraiment de concurrence sur le marché des machines de bureau à cartes perforées.

La question de la migration fragilise la position de “Big Blue”

Le problème du fractionnement des gammes de systèmes touchait aussi les clients. Les ordinateurs ciblaient leurs niches de façon si étroite qu’il n’était pas possible d’étendre les capacités d’un système plus que d’un facteur deux. Donc, quand une société avait besoin d’accroître son système informatique au-delà de cette limite, elle n’avait pas d’autre choix que de changer de type de machine. Mais, bien sûr, ce passage d’une gamme à l’autre impliquait forcément la réécriture des applications (toutes !) précédemment développées

Cette migration coûtait souvent aussi cher sinon plus que le nouvel ordinateur. Et si les clients devaient changer de système complètement, ils pouvaient tout aussi bien changer de fournisseur sans augmenter l’impact négatif puisque tout était à refaire de toute façon… La direction d’IBM comprit bien qu’il y avait là un danger potentiel à tous les niveaux qu’il fallait adresser au plus vite. La solution : le concept de famille de systèmes compatibles.

Le défi d’un “système universel”…

Tous ces éléments poussaient IBM à adopter le concept d’une famille de systèmes compatibles au plus tôt. Mais, dans le cas d’IBM, c’était un challenge encore plus considérable que pour ses concurrents. Tout d’abord à cause du large spectre représenté par les clients de la compagnie. Un système “universel” devait convenir et s’adapter à toutes les tailles et à tous les secteurs.

Un vrai défi tant sur le plan matériel (une gamme étendue était nécessaire, mais cela concernait aussi les périphériques qui devaient être communs à toute la gamme de systèmes) que sur le plan logiciel (tous les logiciels devaient être capables de tourner sans aucune modification de la plus petite machine au plus gros mainframe… Sinon, le concept de famille compatible n’avait pas de sens). Ensuite parce que le fractionnement des systèmes au sein d’IBM avait aussi entraîné un fractionnement des intérêts… Des baronnies s’étaient créées et il y avait beaucoup de résistances au sein même de la compagnie pour faire “tomber les murs” et travailler enfin ensemble.

Un groupe de travail pour sortir de l’impasse : le SPREAD

En octobre 1961, la direction d’IBM avait nommé un groupe de travail (le SPREAD) afin d’établir un rapport prévisionnel sur ce projet de systèmes compatibles. À la fin de l’année 61, le SPREAD avait remis son rapport dont les conclusions étaient radicales. Les estimations de dépenses étaient à la hauteur des ambitions du projet : le groupe avait prévu qu’il faudrait dépenser $125 millions rien que pour le logiciel alors que la compagnie se contentait alors de $10 millions par an pour toute son activité logicielle… Bien entendu, ces estimations qui paraissaient alors délirantes étaient bien en dessous de la réalité et c’est quatre fois plus qui sera finalement englouti par le seul système d’exploitation du 360 (pour un résultat médiocre en plus !). 

Un projet secret et de grande ampleur

Cependant, le projet fut tout de même lancé au début de l’année 1962 et mené sur plusieurs sites (y compris en Angleterre) dans le plus grand secret. Le budget alloué était colossal : cinq milliards de dollars de l’époque, soit encore plus que pour le projet Manhattan qui permit la mise au point de la bombe atomique en 1945 !
Les études coûtèrent $500 millions à elles seules et le développement dix fois plus… C’est l’usine de semi-conducteurs qui consomma le plus de ressources (les ateliers d’assemblage classiques coûtaient $120 le mètre carré, mais la nouvelle “salle blanche” allait demander plus de $450 pour la même surface !), mais cet énorme investissement assura l’avenir d’IBM dans ce domaine pendant des années.

IBM fait un pari risqué avec le 360

Ce projet pharaonique était vraiment un “quitte ou double” pour la compagnie, mais la direction de l’époque était consciente qu’elle n’avait pas le choix. Fin 1963, le développement était en plein boom et la direction commença à réfléchir à la question du lancement… Fallait-il annoncer l’ensemble de la famille de systèmes en une seule fois ou, plus prudemment, faire une série d’annonces progressivement ?
La première option était spectaculaire et assurait un impact maximum, mais elle était aussi la plus risquée : face à cette nouveauté, les clients risquaient de délaisser les anciens systèmes complètement (et en particulier le 1401 qui était la meilleure vente de Big Blue à ce moment-là) !
Heureusement pour le management d’IBM, c’est un événement extérieur qui trancha le dilemme…

L’annonce du modèle H200 d’Honeywell précipite le lancement du 360

En décembre 1963, Honeywell mis sur le marché le modèle H200 (déjà évoqué dans le chapitre un) qui avait pour particularité d’être entièrement compatible avec l’IBM 1401. Le H200 était entièrement compatible avec le 1401, mais en utilisant une électronique plus avancée, Honeywell obtint un rapport prix/performance plus de quatre fois supérieur à la machine vedette d’IBM !

Et comme le H200 était effectivement compatible en tous points, les clients pouvaient rendre leur 1401 loué à IBM et le remplacer par un système Honeywell pour bien moins cher à performances égales ou bien plus performant pour un coût équivalent… Une proposition séduisante. Et le marché fut immédiatement séduit : durant la première semaine qui suivit l’annonce du H200, Honeywell reçut plus de commandes que lors des huit années précédentes de son activité sur ce marché informatique !
L’arrivée du H200 coupa net le flux des commandes pour le 1401 et les prévisions étaient alarmantes : chez IBM, on redoutait que plus des 3/4 des utilisateurs du 1401 allaient basculer sur le H200… Le moment était critique pour Big Blue, après avoir investi massivement sur sa nouvelle gamme, voici qu’un concurrent asséchait son cash-flow avec une nouveauté fracassante !

Le H200 d’Honeywell…

Une ultime hésitation avant le grand saut

En dépit de l’effort titanesque effectué par la compagnie sur le “new product line” (“la nouvelle ligne de produits”, nom de code interne pour le projet 360), l’engagement envers le 360 n’était pas encore définitif… Preuve des hésitations internes, une évolution du 1401 (appelée 1401S) était parallèlement en chantier. Mais l’initiative d’Honeywell décida la direction d’IBM à “mettre le paquet” sur la nouvelle ligne et de tourner ainsi résolument le dos au passé. Le lancement du 360 fut spectaculaire : une grande mobilisation médiatique et marketing qu’on n’avait encore jamais vue pour le lancement d’une gamme d’ordinateurs (les journalistes parlèrent du “projet Manhattan de l’informatique” pour qualifier le projet 360 qui, il est vrai, représentait le plus gros investissement privé de l’Histoire !).

La gamme (limitée au départ à cinq modèles) fut annoncée le 7 avril 1964. Elle comprenait 40 modèles de périphériques, dont la fameuse imprimante 1403 introduite avec l’ordinateur commercial 1401 (et qui sera utilisée jusqu’aux années quatre-vingt). De plus, le système 360 comportait en standard un émulateur de 1401. Ce dernier point n’était pas un détail, mais bien un ajout intelligent permettant à la base installée de “glisser” en douceur de l’ancien système vers le nouveau : l’émulateur était capable d’exécuter les programmes conçus pour le 1401 sur le 360 sans réécriture ni modification, de quoi effectuer la migration progressivement. Ainsi, les clients du 1401 n’étaient plus tentés de passer à Honeywell puisqu’IBM offrait une voie d’évolution vers le haut qui paraissait attrayante…

Une des brochures vantant l’IBM 360

Pari risqué, pari gagné !

Et le résultat de ce pari risqué dépassa les espérances : immédiatement, des milliers de commandes affluèrent et, pendant deux ans, IBM ne fut capable d’honorer que la moitié des 9000 commandes en attente. Dans les trois années qui suivirent le lancement du 360, les ventes et revenus des locations montèrent à plus de cinq milliards de dollars, IBM ouvrit de nouvelles usines et fit monter ses effectifs jusqu’à employer presque 250 000 personnes dans le monde… Le 360 a été décrit comme “l’ordinateur fait par IBM qui a fait IBM” et c’était tout à fait vrai : ce système a alimenté la croissance de la compagnie pendant trente ans et a défini l’architecture de base des mainframes jusque dans les années 2000 !

Thomas Watson jr posant devant le 360…

Avancée mais pas trop…

Le marketing vantait l’avancée révolutionnaire qu’apportait la nouvelle famille d’ordinateurs de Big Blue pourtant la technologie employée par IBM n’était pas si avancée que cela : les processeurs SLT (Solid Logic Technology) du 360 étaient basés sur un mixte entre la seconde et la troisième génération de l’électronique de l’époque (la première génération d’électronique était basée sur les tubes à vide, la seconde sur les transistors, la troisième sur les circuits intégrés). Pire, la plus grande faiblesse du système 360 résidait dans son système d’exploitation, OS/360, dont le développement avait coûté fort cher et pour un résultat médiocre : les milliers de développeurs avaient consommé plus de $100 millions pour aboutir à un système qui supportait à peine le temps partagé. Il y avait bien des moniteurs de télétraitement dans les premières versions d’OS/360 (BTAM et QTAM, peu utilisés il est vrai), mais, de toute façon, le traitement par lots représentait encore probablement plus de 95% de l’informatique de l’époque !

Le quasi-échec de l’OS/360

Le chef du projet OS/360 était Frederick Brooks et celui-ci expliqua dans un livre célèbre (The Mythical Man-Month) toutes les difficultés de ce projet dantesque : les retards s’accumulaient, les bugs étaient nombreux, le système était très lent et incomplet.

Pour tenter de tenir les délais et les objectifs, le management augmentait continuellement les effectifs : d’une centaine au départ, les programmeurs seront plus de 1000 au pic du projet et on compta plus de 5000 intervenants sur les différentes parties du projet (tests et documentations). Le budget (déjà conséquent au départ) explosa puisqu’IBM dépensa finalement quatre fois plus que prévu pour un OS buggé, lent et incomplet… À la suite du lancement du 360, l’OS demanda encore plusieurs années avant d’être corrigé et complété.

Fred Brooks en conférence…

Loi de Brooks : ajouter plus de programmeurs à un projet en retard ne fera que le retarder plus encore…

Ce quasi-fiasco a été très documenté (et pas seulement dans le livre de Brooks), car c’était la première “horror-story” qui concernait le logiciel, une “matière” encore relativement nouvelle à cette époque.

Mais comme le développement de ce projet avait tout de même coûté fort cher, IBM entendait bien rentabiliser un maximum cette opération et pour cela, il n’était pas encore question de miniaturiser les machines ni de faire profiter les clients des formidables avancées réalisées lors de ces années de progrès rapides. En effet, comparé à l’IBM 650 (mis sur le marché en 1954), le 360/30 arrivé dix ans plus tard avait 66 fois plus de mémoire et fonctionnait 43 fois plus vite. Le coût relatif à l’exécution d’une instruction avait diminué d’un facteur 40… Pourtant, les ordinateurs de Big Blue étaient tout de même devenus plus chers : en 1955, un mois de location d’un 650 coûtait $3500 alors qu’en 1965, un mois de location d’un 360/30 revenait à $7000… Mais l’immense majorité des clients n’était pas capable de faire cette comparaison et réclamait toujours plus de puissance, pas des petites machines moins chères.

Epilogue…

IBM ne sut pas refaire ce pari dans les années 70 avec le projet “future system” qui échoua et fut abandonné discrètement. Au lieu de cela, Big Blue fit évoluer de façon incrémental ses mainframes (370 puis 390) et la véritable évolution technique prit un autre chemin avec les minis puis surtout les PC.

Publié dans Anecdotes IT, documentaires IT, Informatique | Laisser un commentaire

Simracing : le point sur les màj récentes plus quelques anecdotes…

En matière de Simracing, on peut dire qu’on vit une période positive : les titres se disputent nos faveurs avec des mises à jour fréquentes et allant dans le bon sens.

Mais tout n’est pas parfait dans notre petit monde. Laissez-moi vous raconter pourquoi je dois ajouter une note négative à ce tableau idyllique…  Cet après-midi, j’ai disputé deux courses online : une sur Forza et l’autre sur Le Mans Ultimate (LMU). je dois dire que j’ai pu vivre les deux extrêmes en une seule après-midi !

Sur LMU, pas de problème : les adversaires se comportent comme il faut, rien à dire. Sur Forza, en revanche, c’est carrément l’horreur : en huit tours de course sur Road America, j’ai été percuté et éjecté de la piste quatre fois (cinq si je compte une fois de plus pendant les essais) !
Je ne sais pas ce que cherche les types qui roulent sur Forza mais ce n’est clairement pas pour moi.

La cohue sur Forza !

C’est dommage car, petit à petit, le titre se complète enfin… La dernière mise à jour en date (la 8ème) apporte le circuit de Brands Hatch et des voitures supplémentaires. Encore un peu de patience et on aura presque autant de contenus que sur Forza 7 !

LMU n’ajoute pas encore de contenus mais, là aussi, ça va dans le bon sens : les mises à jour, les correctifs et les patchs améliorent progressivement la stabilité. Ce n’est pas  encore parfait mais, déjà, ça plante moins. Les bugs sont encore trop nombreux (par exemple, une course online disputé dimanche n’a pas été prise en compte dans mes stats alors que j’ai terminé sans problème apparent… rageant !).

Le mode multi-joueurs fonctionne correctement la plupart du temps mais le niveau est plutôt relevé et faire un podium est vraiment difficile. Je cherche à faire progresser mes ratings mais c’est lents : je suis encore au niveau Bronze 3 (driver & safety)…

Du côté d’Automobilista 2 (AMS2), le titre se bonifie à chaque mise à jour et, franchement, je trouve dommage qu’AMS2 ne soit pas connu et utilisé à la hauteur de ce qu’il offre !

Ce WE, avec mon plus jeun fils, nous avons fait une course online (chacun sur son PC) au Mans sur des LMDh (avec des IA pour meubler) et nous avons vécu ainsi un moment grandiose : 6 tours d’une course épique, d’une intensité totale mais avec respect, c’était parfait. tellement intense que ça ne pouvait pas durer toujours : un de nous deux a fini par se sortir… Mais cela reste un des meilleurs moments que j’ai pu vivre en Simracing online et c’est AMS2 qui me l’a offert.

Publié dans Sports mécaniques virtuels | Laisser un commentaire

Livre sur l’Ukraine, une recommandation : Regard critique sur les évolutions du monde, du Rwanda à l’Ukraine en passant par le Kosovo et le Sa : Regard critique sur les causes d’une tragédie

Je viens juste de terminer “Regard critique sur les évolutions du monde, du Rwanda à l’Ukraine en passant par le Kosovo et le Sa : Regard critique sur les causes d’une tragédie” de Jacques Hogard. Je vous recommande cette lecture, vraiment !

Je ne connaissais pas cet auteur que j’ai découvert grâce à la chaine Youtube Tocsin :

Que dire sur ce livre ?
Tout d’abord, il est documenté, les sources sont indiquées tout au long de l’ouvrage, c’est donc un travail sérieux… Ceci dit, des livres de ce genre sur l’actuelle crise en Ukraine (c’est plus qu’un conflit local, c’est une crise qui a entrainé toute l’Europe !), il y en a déjà quelques-uns !
Pourquoi celui-ci plutôt qu’un autre (souvent cités d’ailleurs par Jacques Hogard dans ces pages) ?

En fait, je recommande ce dernier parce que je l’ai lu et pas les autres !

Mais je recommande avant tout de lire des livres qui s’appuient sur une vraie réflexion et une vraie expérience de terrain, tout plutôt que de se laisser abrutir par la propagande écrasante actuelle où si vous n’êtes pas à fond pour la victoire Ukrainienne (quel qu’en soit le coût, dans tous les sens du terme), vous êtes un traitre, un défaitiste (syndrome de Munich), un pro-Putine et j’en oublie…

On vit en ce moment un autre acte de la triste comédie qu’on nous joue depuis la crise sanitaire : propagande écrasante, mensonges multiples et ridicules, ostracisation et harcèlement systématique pour tout ceux qui seraient seulement tièdes et ainsi de suite, je n’ai pas besoin de rentrer dans les détails, vous l’avez vécu et ça continue.

Garder son regard critique et s’informer à d’autres sources que le torrent de la “normalité” (!), voilà un acte de résistance. Résistance minimum, certes mais c’est déjà cela.

 

Publié dans à travers mes découvertes, divers, La terrible vérité | Laisser un commentaire

Ce qui ne change pas (ou très lentement) dans le secteur informatique

On dit continuellement que tout change très vite dans le secteur informatique et dans les techniques utilisées dans l’électronique et l’informatique. C’est en partie vrai mais en partie seulement. Aujourd’hui, dans cet article, nous allons plutôt parler des choses immuables, celle qui ne change jamais (ou presque jamais !) et vous allez voir qu’il y en a plein de ce genre dans l’informatique justement.

Une architecture Von Neumann omniprésente

Déjà un élément qui n’a jamais changé depuis le début c’est l’architecture des ordinateurs qui encore aujourd’hui répond à un formalisme qu’on appelle l’architecture Von Neumann.

Eh oui, c’est peut-être une surprise pour vous mais c’est toujours la même architecture depuis le début. C’est aussi parce que cette organisation des composants s’est avérée être efficace et relativement facile à mettre en œuvre. La technique informatique a évolué (un peu) sur les matières utilisées pour les composants et la structure même de ses composants mais l’architecture de base, elle, n’a jamais évolué. Cela peut enfin changer à l’avenir avec l’avènement des ordinateurs quantiques qui eux, sont radicalement différents mais comme cet avènement est encore lointain je gage que l’architecture Von Neumann a encore de beaux jours devant elle.

Le silicium irremplaçable ?

Autre chose qui n’a pas bougé depuis les débuts de l’informatique moderne : c’est l’usage du silicium pour les composants électroniques. Alors il est important de préciser qu’on parle de l’informatique moderne c’est-à-dire depuis le début des années 60 pas avant ou les ordinateurs étaient encore équipés quelquefois de lampe à vide et là ce n’était pas (du tout !) du silicium. J’ai beau être un ancêtre, avoir connu la carte perforée, mon ancienneté ne remonte tout de même pas jusque-là !

Donc le silicium semble être irremplaçable, indétrônable puisque depuis le début on n’a pas fait sans y avoir recours. Pourtant il y a eu quelques tentatives, dans les années 80 par exemple, avec l’utilisation de l’arséniure de gallium mais ça n’a pas été très loin. Donc encore un domaine qui se caractérise par un certain immobilisme.

Les projets, toujours un bain de sang !

Ce qui ne change toujours pas et qui est à la limite du désespérant, c’est la difficulté de mener des projets informatiques et d’aboutir dans les délais prévus et dans le budget prévu. En vérité, plus de la moitié des projets engagés par les clients, les constructeurs ou les éditeurs n’aboutissent tout simplement pas (pas du tout !). Depuis toujours, le développement logiciel est une activité difficile qui finit le plus souvent par un échec cuisant. Les méthodes évoluent, les outils évoluent mais ce qui ne change pas c’est la difficulté d’écrire des programmes et surtout de les mettre au point de manière satisfaisante. Une percée radicale ou une évolution significative sont annoncées régulièrement mais, presque 50 ans après le livre de Frédéric Brooks (The mythical man-month, à lire absolument !), on constate toujours qu’il n’y a toujours pas de balle d’argent (there is no silver bullet) et que les projets informatiques peinent à sortir du puits à goudron (tar pit).

La hype règne en maître !

Une autre constante du secteur de l’informatique, c’est ce qu’on appelle “la hype”. Il s’agit du battage médiatique à l’occasion d’une nouvelle mode technique. Ici tous les mots sont importants en particulier le fait qu’il s’agit de mode et non pas de techniques établies. Rappelons que le principe d’une mode c’est que ça se démode !

Alors dire que ça ne change pas est légèrement inexact car en fait la hype empire d’année en année donc quelque part ça change quand même un peu. Il y a quelques décennies il était raisonnable de parler de battage médiatique à chaque fois qu’une nouvelle mode technique apparaissait et semblait prometteuse. Puis on est passé à l’exagération médiatique et maintenant j’affirme qu’on en est à l’hystérie médiatique. En effet, à chaque fois qu’une nouvelle mode technique ou une pseudo mode technique apparaît et semble être plus ou moins prometteuse, on constate un déchainement hystérique (non, le mot n’est pas trop fort) de promesses extravagantes qui n’ont évidemment aucune chance de se réaliser. Le pire a été atteint avec le web 3 qui non seulement n’apportait pas grand-chose sur le plan technique mais en plus était tout simplement une escroquerie dans sa nature même.

Des promesses, toujours des promesses

Autre chose qui paraît immuable, qui semble ne jamais changer, ce sont les promesses commerciales pour vendre l’informatique au sens large ou des nouveaux systèmes ou des nouveaux logiciels ou des nouvelles architectures. Dernièrement on en a encore eu l’exemple avec la montée puis la généralisation du Cloud, la promesse était, encore une fois, que ça allait revenir moins cher. Combien de fois ai-je entendu cela pendant mes 40 ans de carrière dans le secteur ? 

Et, à chaque fois (chaque fois, j’insiste !), cela s’est avéré inexact. Il n’y a pas que l’argument économique qui revient constamment dans les promesses exagérées du discours commercial du secteur informatique, il y a également des affirmations du genre “ça va être plus facile à développer” ou encore “l’exécution des programmes sera bien plus rapide”. Je simplifie un peu (à peine !) mais vous avez tout de suite perçu l’idée générale derrière ces affirmations car vous aussi; vous les avez entendues encore et encore…

L’immobilisme n’est pas une fatalité

J’insiste ici sur les éléments qui ne changent pas mais cela ne veut pas forcément dire que des choses sont destinées à rester toujours les mêmes y compris dans les domaines déjà cités. Je voudrais prendre comme exemple la fameuse loi de Moore qui s’était toujours vérifiée depuis le milieu des années 60 mais qui a fini par s’effacer récemment. Donc, même une situation qui perdure année après année, décennie après décennie, n’a pas vocation à être en place éternellement, comme on a pu le voir justement avec la loi de Moore. Ceci pour dire que je ne prétends pas que toute l’informatique est condamnée à l’immobilisme et que rien ne change jamais, bien évidemment. Je veux juste mettre l’accent sur des exemples significatifs qui montrent que le progrès frénétique et les changements tout azimut ne sont pas une généralité en informatique contrairement aux idées reçues.

Pas un techno-réfractaire !

J’insiste aussi sur le fait que je ne suis pas contre l’évolution technique, je ne suis même pas un sceptique de l’évolution technique. Je voudrais juste qu’on en prenne la mesure exacte plutôt que de basculer systématiquement dans les fantasmes les plus délirants dès qu’on parle de l’évolution technique et de son inévitable accélération, qui est tout ce qu’on veut sauf prouvée. La meilleure preuve que je ne suis pas un “techno-réfractaire”, c’est que ce texte que vous êtes en train de lire, je ne l’ai pas directement rédigé mais plutôt dicté directement à mon Mac puisque, désormais, cette technique est suffisamment au point pour être utilisable (après, il faut bien le dire, des décennies d’efforts). Et d’ailleurs, dicter un texte n’est pas tellement plus facile ni même plus rapide que de le taper directement au clavier parce qu’il faut savoir à l’avance ce qu’on veut exprimer.

En conclusion

Il ne s’agit pas ici de seulement dénoncer une fois de plus les idées reçues trop nombreuses et trop stupides dans ce secteur comme dans de nombreuses autres. Tout au long de ma carrière en informatique j’ai justement essayé de promouvoir de façon équilibrée ce qui me paraissait être légitime, intéressant, utilisable, applicable en un mot. et c’est pour cela que j’insiste autant à travers mes livres ou dans des articles comme celui-ci sur le côté nocif de la hype ou sur les impasses que représentent les idées reçues.

Publié dans Anecdotes IT, Informatique, Références IT | Laisser un commentaire

Sortir enfin de l’hallucination générale des IA génératives

Alors, comme tout ne peut pas être dit en quelques minutes dans une vidéo, voici un complément…

La situation actuelle est tellement absurde que les promoteurs de ces systèmes essayent même de faire passer le recours au prompt pour rédiger les instructions comme un progrès… Mais enfin, pensez-y quelques minutes : le prompt, c’est rien de plus que le retour à la “ligne de commandes” !

Et on voudrait nous faire croire que c’est un progrès ?
C’est une régression oui !

Et tout est à l’avenant avec cette mode absurde. Les effets démo qui sont si bluffant ne sont rien d’autre que cela : des démos !
Essayez donc de faire pareil avec vos configurations, vos moyens, etc. Vous allez vite vous rendre compte que vous n’obtenez pas les mêmes résultats que ce que vous pouvez voir sur les médias…

Donc, arrêtons de rêver : les vrais progrès demandent du temps et la “percée formidable” de cette nouvelle vague d’IA est une impasse, une de plus. On se croirait de retour en 2016 avec les voitures autonomes : mêmes illusions, mêmes exagérations, mêmes hyperboles et, je le dis, cela finira de la même façon… Par une cuisante déception.

Publié dans Informatique, La terrible vérité, Références IT | Laisser un commentaire

Que pensez de “Drive to survive” saison 6

Cette fois, je vais vous proposer un article ultra-court !

En effet, il m’est facile de répondre à la question “que pensez de la saison 6 de DTS ?”… Rien de bon !

Cela fait un moment que cette série présent de moins en moins d’intérêt pour les amateurs de sport-auto et de plus en plus de propagande en faveur de la F1 (qui en a bien besoin vu comme elle continue à s’enfoncer, année après année !). J’ai déjà expliqué cela ici…
Avec la saison 6 il n’y a rien de nouveau sinon que c’est encore pire qu’avant !

Je constate aussi que, progressivement, Netflix devient de plus en plus un instrument de propagande pour tenter des garder les normies dans leur sommeil hypnotique. Par exemple, la série documentaire récente “Turning Point : l’arme nucléaire et la guerre froide” est dégoulinante de propagande anti-Poutine à chaque occasion…

C’est d’autant plus dommage que, sur bien des points (rôle et exactions de la CIA par exemple), cette série est plutôt intéressante et instructive…

Mais il semble que Netflix est en train de s’aligner sur Facebook, Linkedin et consorts…

Publié dans à travers mes découvertes, La terrible vérité, Sport-auto | Laisser un commentaire

Le tournant des évolutions techniques rejetées par les mainframes

Dans les années 70, le petit monde des mainframes est confronté à des évolutions techniques majeures dans le domaine du logiciel et qui ont été systématiquement rejetées alors qu’elles apportaient plus de confort pour les développeurs ou les utilisateurs et souvent même les deux. Pourquoi ?

Pourquoi avoir rejeté des évolutions techniques si elles étaient aussi bénéfiques ?
Et quelles ont été les conséquences de ces rejets ?

Commençons tout d’abord par établir quelles étaient ces fameuses évolutions techniques décisives : il s’agissait de l’interface caractère, des L4G et des SGBDR. Ces trois éléments, individuellement ou ensemble, permettaient d’améliorer considérablement le confort des utilisateurs et, souvent aussi, des développeurs.

1- Pourquoi ces blocages et ces rejets ?

Le mode bloc : rustique et frugal

Détaillons cela en commençant par l’affrontement entre les modes d’interface…

L’interface en mode caractère représentait un vrai progrès en termes d’ergonomie et de réactivité par rapport à l’interface en mode “bloc”. Mais elle consommait aussi plus de ressources et générait plus de trafic réseau. Et c’est pour cela que le monde des mainframes est resté campé sur le mode bloc plus frustre mais bien plus économe. Voyons cela…

Le mode caractère : tout, tout le temps 

Le fonctionnement du “mode caractère” est facile à comprendre : à chaque fois que l’utilisateur frappe au clavier de son terminal, ce dernier envoie le caractère (d’où le nom du mode) entré à l’ordinateur central via la liaison réseau. Cet envoi systématique a pour conséquence qu’on demande beaucoup de transmissions de petite taille au réseau en question. Quand il s’agissait de liaisons séries sur la distance de l’étage d’un immeuble, cela ne posait pas de problème (contexte typique des applications départementales où on retrouvait le plus de mini-ordinateurs, ces derniers s’appuyant majoritairement sur le mode caractère). En revanche, sur des liaisons à grandes distances, les performances pâtissaient sensiblement de cette utilisation à répétition du réseau.

Le terminal emblématique du mode caractère, c’est le VT100 de DEC introduit en août 1978 et qui est devenu par la suite le standard pour les terminaux en mode caractère. La configuration du VT100 était réalisée au moyen d’écrans interactifs affichés sur le terminal lui-même. Les paramètres étaient sauvegardés dans une mémoire non volatile. Le VT100 a été le premier terminal de DEC à être équipé d’un microprocesseur standard du marché, le 8080 d’Intel. On pouvait adjoindre au terminal une imprimante externe et un dispositif de graphisme et de mémoire supplémentaire. On le voit, le VT100 avait un côté “terminal intelligent” qui était séduisant. 

Terminal DEC VT100 au Living Computer Museum

Le mode bloc : en une seule fois, de temps en temps

Si le mode caractère était omniprésent dans les minis, le mode bloc lui était la norme dans le domaine des mainframes, car il était plus adapté aux transmissions longues distances : la saisie de l’utilisateur n’était transmise qu’à l’initiative de ce dernier (quand il appuyait sur la touche Enter) et elle était envoyée complète, y compris avec les éléments de décors de la “page” sous la forme d’une “image après”. L’ordinateur central recevait cette image en bloc (d’où le nom du mode) et comparait avec “l’image avant” qu’il avait gardé en mémoire afin d’en déduire les différences. Ce type de fonctionnement était conçu pour s’adapter aux moniteurs transactionnels de l’époque (comme CICS) et était particulièrement bien adapté au découpage en trames des premiers réseaux informatiques (Transpac basé sur X25 par exemple). Le 3270 d’IBM était le terminal emblématique du mode bloc tout comme le VT100 était celui qui venait à l’esprit quand on pensait au mode caractère.

Terminal d’affichage couleur IBM 3279 (1979)

Une ergonomie réduite au minimum

Ceci dit, le mode bloc, s’il était économe en ressources techniques, imposait une ergonomie très fruste : l’utilisateur n’avait droit à aucune aide ou aucun contrôle de saisie tant qu’il n’avait pas “transmis” sa transaction… Au contraire, les applications reposant sur le mode caractère pouvaient guider et réagir immédiatement aux saisies de l’utilisateur tout au long du processus, au niveau le plus fin et même en fonction du contexte !

À cause de la contrainte des réseaux longues distances (dans le cas du départemental avec des liaisons séries, ça ne posait pas de problème), il était encore trop tôt dans l’évolution de la technique informatique pour que le confort de l’utilisateur prime, en mettant à sa disposition des interfaces capables de réagir immédiatement à la moindre saisie ou avec des langages évolués, simples à programmer. C’est donc fort logiquement que le mode bloc l’emporta dans la bataille qui l’opposa au mode caractère. 

Voyons maintenant l’épisode du rendez-vous raté avec les SGBDR et L4G…

L’impératif de la production bloque les évolutions

Il faut d’abord se représenter le niveau de rigidité imposée par l’informatique traditionnelle reposant sur des mainframes dans les années 60 et 70. Ici, l’impératif est d’assurer la “production” et même une production de masse : répondre à des utilisateurs nombreux de façon fiable et rapide sur des applications bien balisées permettant de traiter l’essentiel des affaires courantes. On peut résumer cet ensemble d’impératifs par le transactionnel. Le transactionnel était admirablement servi par les mainframes faisant tourner des applications développées dans les années 60 et en recourant à des techniques éprouvées : du Cobol et assez peu de vrais systèmes de bases de données (l’accès à des fichiers suffisait bien).

Les applications de production (celles qui nécessitaient des saisies intensives et des temps de réponses très courts) avaient été développées lors des décennies soixante et soixante-dix. À la fin des années soixante-dix, elles étaient désormais opérationnelles et stabilisées. Le transactionnel pouvait être considéré comme achevé.

Les demandes des utilisateurs se reportaient donc naturellement vers des besoins complémentaires et c’est ainsi qu’on est passé progressivement au décisionnel. Les L4G étaient particulièrement bien taillés pour ces applications d’aide à la décision puisqu’ils étaient tous plus ou moins orientés vers la production de rapports basés sur des extractions issues des systèmes de bases de données.

Un cycle trop long et trop lourd

Car, même avec une base de données classique, vous ne pouviez pas obtenir le résultat d’une requête sur votre écran simplement en la tapant depuis le clavier de votre terminal connecté au système central de votre organisation… Non, il fallait passer par un programmeur qui allait coder votre requête dans un programme qui, une fois mis au point, sera exécuté en batch et le résultat vous arrivera sur un listing… Avec un processus aussi lourd, on imagine facilement la frustration de l’utilisateur en s’apercevant que la requête était incomplète ou pire, erronée !

Il fallait recommencer tout le parcours en espérant avoir un accès rapide au programmeur capable de s’y retrouver dans la structure de la base de données… 

Les SGBDR permettent l’interrogation interactive

L’évolution vers des bases de données relationnelles (SGBDR) permettait de résoudre tout cela en une seule fois : on avait enfin une structure de base de données à peu près lisible, un langage d’interrogation (SQL le plus souvent) assez facile à manipuler sinon à apprendre (en tout cas, bien moins complexe et rébarbatif qu’un langage de programmation, même le plus basique…) et, cerise sur le gâteau, un logiciel permettant de saisir la requête au clavier et d’avoir le résultat immédiatement (enfin, plus ou moins rapidement selon la complexité de la requête, la taille de la base de données et la qualité de son indexation…) à l’écran, un vrai paradis par rapport à la boucle programme-batch-listing !

Pour optimiser encore ce recours à l’informatique décisionnelle (c’est ainsi qu’on s’est vite mis à appeler tout ce qui n’était pas du ressort de l’informatique traditionnelle de production, le transactionnel), les L4G représentaient le couplage idéal avec les SGBDR. Voyons maintenant comment ces nouveaux langages (nouveaux pour l’époque) sont apparus…

Faire face au goulot d’étranglement

Certains éditeurs eurent l’idée de faire évoluer les langages de développement vers un plus haut niveau d’abstraction. Cette évolution fut vite appelée quatrième génération et ces langages des L4G. Les L4G représentaient bien une réponse appropriée à un besoin qui était latent lors des années soixante-dix et quatre-vingt (surtout dans les environnements mainframes) : le goulot d’étranglement des programmes était surtout dû au fait qu’il fallait passer par le service informatique et ses programmeurs pour la moindre intervention sur les applications. Si un cadre avait besoin d’un nouveau rapport sur les ventes, il fallait écrire une nouvelle application pour cela et ce “simple” rapport se transformait en projet qui durait des mois (sans compter qu’il fallait des mois sinon des années avant que cette demande soit seulement prise en compte…).

La solution au problème de l’ingénieur

Un exemple de la puissance des L4G par rapport au Cobol est illustré par la solution à une question classique connue sous le nom du “problème de l’ingénieur” : donner une augmentation de 6% aux ingénieurs dont la note moyenne est de sept ou mieux. Pour résoudre ce problème, James Martin (un célèbre consultant, très fan des L4G) rédigea une douzaine de pages de code Cobol et seulement deux pages de code Mark IV. Avec Nomad (un L4G bien connu), ce problème pouvait être résumé en une simple ligne : CHANGE ALL SALARY = SALARY*1.06 WHERE POSITION = ‘ENG’ AND AVG (INSTANCE (RATING)) GE 7…

Une simplicité qui se paye, hélas…

Mais, bien entendu, cette simplicité se payait via une consommation de ressources importante : les L4G étaient bien plus lents en exécution que les programmes rédigés avec des langages traditionnels (tout simplement parce que les L4G étaient exécuté en mode “interprété” alors que les programmes écrits en langages traditionnels étaient eux compilés avant exécution…). Encore une fois, c’est la consommation de ressources informatique qui a fait barrage à leur adoption sur mainframe et ce aussi bien pour les L4G que pour les SGBDR. Lorsqu’on essayait de faire tourner une application développée en L4G et faisant appel à un SGBDR de façon intensive, le pauvre mainframe s’effondrait, tout simplement. Ses temps de réponse grimpaient dramatiquement au détriment de tous et d’abord des applications de gestion habituelles dont le fonctionnement correct était critique pour la bonne marche de l’entreprise… Évidemment inacceptable et les L4G et autres SGBDR étaient bientôt rejetés en raison de leurs exigences en ressources tout comme l’avait été le mode caractère des terminaux évolués.

Des montres de puissance ? En fait, non.

Car nous faisons une erreur fondamentale en voyant ces mainframes comme des monstres débordant de puissance. Monstrueux, ils l’étaient (par la taille au moins), certes. Mais puissants, pas tellement en fait. Si on compare avec nos machines d’aujourd’hui (y compris celle que vous tenez dans la main ou portez à votre poignet), les mainframes affichaient une puissance et des capacités (mémoire, stockage) ridicules…

Ces ordinateurs centraux coûteux ne pouvaient pas faire tourner des programmes trop exigeants et c’est pourquoi les applications développées pour eux étaient particulièrement optimisées (une notion importante mais qu’on a oublié depuis !). Optimisées dans tous les compartiments, y compris dans leur stockage (ce n’est pas pour rien que les programmeurs s’étaient résolus à ne stocker les années des dates que sur deux digits pour économiser de la place… ce qui conduisit au trop fameux “bug de l’an 2000” !). Des pratiques parfaitement légitimes à l’époque même si elles nous paraissent désormais absurdes et désuètes.

Tout cela pour se rendre compte qu’effectivement, les mainframes d’alors ne pouvaient pas se permettre le luxe du mode caractère, des L4G et des SGBDR… Bien entendu, à l’époque, on était conscient de ces limites et on commençait à envisager la notion de traitements distribués entre plusieurs ordinateurs reliés en réseau. On en parlait mais ça restait encore une perspective lointaine (seul DEC a commencé à le mettre en œuvre avec DECNet qui permettait de voir plusieurs VAX en réseau comme une seule et même machine).

Plus prosaïquement, tout ce qu’on savait faire de concret à l’époque, c’était de proposer des mainframes toujours plus gros, suivant en cela la loi de Grosch (voir à https://fr.wikipedia.org/wiki/Loi_de_Grosch) qui s’est ensuite avérée être erronée (pas de chance, hein !).

Un exemple vécu

Lors d’une mission de mise en place d’un infocentre autour de DB2 pour les groupe André (les chaussures) à la fin des années 80, j’ai pu constater la voracité de DB2 (le SGBDR vedette d’IBM alors). Le DB2 en question n’était pas installé sur le 3090 qui était réservé (préservé !) aux applications de production et qu’il n’était pas question de perturber d’aucune façon. Notre DB2 était donc installé à part sur un 4381 (un mainframe d’IBM mais considéré comme “entrée de gamme”) qui était l’ordinateur de réserve d’André (au cas où le 3090 aurait une défaillance, le 4381 était capable de faire tourner les applications en “mode dégradé”…). Sur ce 4381, notre SGBDR était à son aide et prenait même toute la place : à part le système (MVS/SP) et son interface TSO, rien d’autre ne tournait (ni même ne pouvait tourner !). Nous avions un petit mainframe rien que pour notre infocentre et ça allait tout juste comme cela !

C’est donc la gourmandise en ressources techniques des évolutions telles que les L4G et les SGBDR qui ont provoqué leur rejet par les techniciens mainframes. En conséquence, toutes les initiatives “progressistes” qui avaient commencé à apparaître comme les L4G et la notion d’infocentre furent mises en sommeil (nous y reviendrons).

Mais cette première victoire des “conservateurs” sur les “progressistes” eut un effet pervers : persuadés de détenir la bonne architecture, les tenants du mainframe restèrent figés par la suite dans une posture où les revendications en faveur du confort des utilisateurs furent systématiquement ravalées au rang de caprices sans importance ou impossibles à satisfaire au nom des contraintes techniques (alors qu’il était simplement trop tôt).

2- Les conséquences de ces rejets

Nous venons de voir pourquoi ces évolutions positives, nécessaires mêmes, avaient été rejetées par le monde des mainframes. Monde rigide et incapable de prendre en compte (pour des raisons bien réelles de ressources limitées) autre chose que le sacro-saint transactionnel.

Comment allaient réagir les partisans et promoteurs de ces évolutions ?
Les abandonner, les laisser mourir dans les fossés de l’Histoire de l’évolution technique ?

Certes non et deux camps bien distincts se formèrent : d’une part le clan des mainframes qui campait sur leur pré carré et, d’autre part, le clan des “évolutionnistes” qui trouva un terrain d’expression avec les minis-ordinateurs…

C’est que, quasiment au même moment (au virage des années 70), une nouvelle classe de machines était apparue et avait trouvé sa niche : les minis. Bien moins coûteux à acquérir et bien plus simples à exploiter que les ordinateurs centraux habituels (qui eux tendaient à être de plus en plus gros), ces nouvelles machines permettaient d’apporter l’informatique à un autre niveau : l’échelon départemental.

C’est sur ce terrain que s’est jouée la première vraie scission (quasiment l’équivalent d’un schisme !) de l’histoire de l’informatique. Les acteurs traditionnels restaient sur les mainframes, les nouveaux acteurs tentaient leur chance sur les minis.

Des raisons financières

Déjà, les éditeurs de SGBD traditionnels préféraient s’affronter sur le terrain des mainframes plutôt que sur celui des mini-ordinateurs pour deux raisons : 1) le prix des licences sur mainframe était plus élevé que sur mini-ordinateur (alors que l’effort de vente était quasiment le même) 2) les mini-ordinateurs étaient plus destinés à faire tourner des progiciels que de servir de plateformes pour des applications spécifiques “développées à la maison” (in house programming), terrain de prédilection des SGBD sur grands systèmes.

De plus, au début des années quatre-vingt, la technologie relationnelle apparaissait (avec quelques raisons) comme trop immature pour intéresser les fournisseurs de SGBD traditionnels (sauf IBM) permettant à Oracle et consorts de se développer au sein de leur “niche”… Et que s’est-il passé ensuite ?

Pas grand-chose au final : les minis ont comblé les utilisateurs sur la niche où ils étaient bien dimensionnés mais ils n’ont pas été capables d’aller au-delà. Non, pour cela, il fallut attendre une autre vague majeure de l’évolution technique : les micro-ordinateurs (PC).

La vague PC relance l’innovation

Les PC permettaient d’adresser les besoins individuels des utilisateurs : du jamais vu dans le monde codifié et bien balisé de l’informatique traditionnelle !

Au début, cela est resté relativement modeste et confiné à la bureautique (le tout avec une interface caractère héritée de ce que proposaient les minis). Et puis les choses se sont mises en route : l’interface graphique est apparue puis s’est imposée et, dans la foulée, on a voulu développer de vraies applications en réseau capables de servir des dizaines, voire des centaines de PC reliés en réseau. Et, pendant ce temps, le monde des mainframes apparaissait comme immuable, figé, inamovible, comme une forêt pétrifiée par un cataclysme inexplicable…

En rejetant des évolutions techniques immatures qui étaient arrivées un poil trop tôt, les mainframes se sont coupés du mouvement et se sont rétractés sur eux-mêmes. Ce fut cela la principale conséquence de ce tournant manqué. L’innovation technique n’était pas la bienvenue dans ce monde fossilisé ?
Pas de problème, elle trouva un terrain d’expression enthousiaste sur les PC en réseau !

Le modèle client-serveur s’impose

Pour développer des applications qui reposent à la fois sur l’interface graphique côté utilisateurs et sur les SGBDR côté serveurs, il fallait une architecture qui permette la distribution des traitements de façon simple et pratique. Le modèle client-serveur s’est alors imposé comme la solution évidente, naturelle. Il permettait de combiner le “meilleur des deux mondes” : d’une part l’interface évoluée (graphique) côté utilisateur et, d’autre part, les fonctions avancées des SGBDR modernes sur des serveurs puissants (minis d’abord, stations de travail ensuite, PC montés en grade -comme le Compaq SystemPro- enfin).

Un serveur Compaq SystemPro, un des premiers PC a vraiment pouvoir jouer le rôle de serveur : puissant et sécurisé.

On a même cru que ces configurations client-serveur allaient pouvoir rivaliser avec les mainframes et permettre un “downsizing” révolutionnaire en déboulonnant les grosses machines et en les envoyant dans les poubelles de l’Histoire !

Un règne assez court

Bien entendu, cette révolution promise par les plus enthousiastes des partisans du client-serveur (et j’en étais !) n’a pas eu lieu : les mainframes n’ont pas été déboulonnés, ils sont restés en place pour faire tourner les fameuses applications de production que les organisations n’avaient aucun intérêt (ni envie !) à refaire. Ensuite, ni l’avènement du Web ni le bug de l’an 2000 n’ont remis en cause les mainframes mais ont accentué leur isolement.

Pour finir, la vague du cloud a encore érodé leur position mais sans les faire disparaître tout à fait pour autant. Ils sont toujours là à chaque fois que, par exemple, vous payez avec votre carte de crédit. Ils sont devenus les fossiles vivants d’une époque révolue, témoignages figés d’une épopée commencée au tout début des années soixante et qui s’est arrêtée à son apogée à la fin des années soixante-dix.

Leçons et enseignements

La leçon de ce tournant manqué c’est que l’innovation technique, la vraie, celle qui s’appuie sur des avantages concrets, mesurables, des bénéfices durables, cette innovation là trouve toujours sa voie. Même quand l’environnement dominant la rejette, elle renaît sous d’autres cieux et se met à fleurir grâce à ce nouveau terreau.

Un domaine technique qui n’évolue plus (même pour de bonnes raisons) est un domaine condamné. Même si les machines sont toujours utilisées, la dynamique les a déserté et est partie ailleurs exercer ces effets bénéfiques.

 

Publié dans Anecdotes IT, Informatique, Références IT | Laisser un commentaire

Le Mans Ultimate : ce qu’on peut en dire, à ce stade…

Pour résumer mes impressions et découvertes sur la nouvelle simulation WEC “Le Mans Utlimate”, je vous ai préparé une petite vidéo d’un peu plus de quinze minutes (ben oui, y a des trucs à dire !) :

Je me répète encore mais garder en tête que c’est une “early access” et attendez la version complète si vous n’êtes pas prêt à assumer un stade “pas terminé et buggé”…

Selon moi, le plus gros défaut actuel de LMU, ce sont les temps de chargements (les circuits sont super longs à charger). Et, aussi, le fait que mon Buttkicker ne fonctionne pas encore avec LMU et que Crew Chief non plus (mais, pour ce dernier, c’est en cours, déjà dispo en beta).

Publié dans Sports mécaniques virtuels | 5 commentaires

Pourquoi Le Mans Ultimate était-elle aussi attendue ?

Il est clair que la nouvelle simulation “Le Mans Ultimate” était très attendue et voici enfin qu’une “early access” est disponible en ce mardi 20 février… Pas trop tôt, l’attente a été longue !
Mais justement, pourquoi ce titre a-t-il fait l’objet d’une pareille attente ?

Tout d’abord, à cause de son contenu : à ma connaissance, c’est la toute première simulation à être dédiée au championnat du Monde d’Endurance, il était temps !
D’un autre côté, c’est logique : au vu de l’actuelle popularité du WEC (justifiée et méritée), c’était plutôt un “smart move” que de s’y consacrer.

L’autre raison, moins importante, était de voir si Motorsport Games, un studio qui a accumulé les bourdes (trop d’argent dépensé sur trop de licences pas utilisées… Vraiment pas un “smart move” là par contre !) allait être enfin capable de sortir un titre correct et, éventuellement, sortir la tête de l’eau grâce à cela. Car il faut bien dire que la récente évolution de rFactor2 (le titre phare de Studio397) n’est pas du tout à mon goût : de plus en plus instable au point que ça en devient inutilisable (au moins pour moi). J’ai trouvé que cette “descente aux enfers” de rFactor2 était très triste car c’est un titre que j’aimais beaucoup avant qu’AMS2 prenne le dessus.

Vous pensez donc que dès que cette “early access” (à 29€) a été disponible (le mardi 20/02 à 13:00) je me suis précipité dessus !

Achetée, installée, lançée… Allez, quoi, arrêtes ton suspence à deux balles !
La seule question, c’est “ça donne quoi, alors ?”… Eh ben c’est plutôt pas mal en fait… Déjà, ça fonctionne, volant/pédalier (Fanatec) reconnus, triple-screen reconnus, ça rassure. Et une fois sur la piste (Le Mans bien sûr), c’est carrément plaisant.

Le FFB est bon, le comportement des voitures semblent bon mais rien d’étonnant à cela puisque la physique du titre est basée sur rFactor2 (qui est excellent sur ces points). On reconnait tout de suite qu’on est en terrain connu même si l’interface utilisateur (assez réussie d’ailleurs) est comme une grosse couche de maquillage sur rFactor2 qui est bien présent avec ses bons et ses mauvais côtés (temps de chargement hyper longs !).

J’ai encore relativement peu roulé, évidemment (seulement trois Hypercars et deux GTE mais j’ai quand même pu faire un peu de online et ça fonctionnait !) mais j’ai déjà une très bonne première impression (et c’est déjà beaucoup).

Je ne peux pas me prononcer sur les éléments clés tels que la stabilité et autres points cruciaux mais je dirais que la première étape est franchie sans dommage (on pouvait craindre le pire). Dans les prochains jours, je vais sans doute faire une vidéo où je pourrais en dire plus sur ce titre après l’avoir approfondi (un peu).

En attendant, voici les premiers avis de quelques Youtubers de référence :

 

Publié dans Sports mécaniques virtuels | Un commentaire

L’actualité de mes livres à l’occasion d’une nouvelle couverture pour “Perdu dans le temps”…

La nouvelle couverture avec une illustration de Jean-Charles Poupart.

Une nouvelle couverture pour “Perdu dans le temps” à l’occasion de son 20ème anniversaire !
Mais pas seulement : prochainement, une seconde édition de notre “Histoire de l’informatique” rédigée avec Laurent Poulain.

Publié dans Mes livres | Un commentaire

Automobilista 2 & Le Mans et les réglages de refroidissement plus Nascar Full Speed de Netflix

Tout est résumé dans le titre de cet article. Bonus, une bande annonce plus longue sur Full Speed… Merci qui ?

Plus de 1000 heures sur Autmobilista 2, ça indique clairement ma préférence !

Publié dans Sport-auto, Sports mécaniques virtuels | Laisser un commentaire

Quelques nouvelles du front du Simracing : Forza, ACC, LMU et AMS2

Dans cette vidéo, je fais référence aux vidéos de Naga Racing que je vous recommande ici

Je me suis amusé à appliquer un filtre qui m’évoque le film Mars Express que je recommande d’aller voir, j’en parle ici : Un film de SF français et en animation ? Oui, c’est Mars Express !

J’évoque aussi ma vidéo de test de Forza et c’est à retrouver là. Enfin, j’évoque également la vidéo sur la démarche de réglage qui est toujours ici

Publié dans Sports mécaniques virtuels | Laisser un commentaire

Le mod que je souhaiterais avoir dans AMS2

Comme vous le savez, je suis très fan d’Automobilista 2 (AMS2) et même si le titre n’est pas réputé pour son accueil des mods, ça commence à venir avec ce que fait Thunderflash (en convertissant des voitures venant de PCARS 2) ou du côté de Virtual Racing Cars (avec l’Audi 90 GTO vraiment très réussie). Alors, certes, on est encore loin (très loin) de ce qui est disponible pour rFactor2 ou Assetto Corsa mais il est permis de rêver, n’est-ce pas ?

Alors voilà, je vais vous expliquer ce que j’aimerais avoir comme Mod pour AMS2 : le plateau (ou, au moins, une partie du plateau…) des 24 heures du Mans 1974.

Et tant qu’on en est à rêver, pourquoi ne pas y inclure également certaines des voitures qui aurait pu (ou dû !) y participer comme l’Alfa T33 ?

Ce mod comprendrait, au minimum, les voitures suivantes : 

La Matra 670B

La Gulf Mirage GR7

L’Alfa Roméo 33T12 (oui, je sais, elle n’a pas couru au Mans cette année là mais elle disputa quelques courses du championnat du Monde des marques et elle a réussi à battre la Matra à Monza…)

La Porsche Carrera Turbo RSR

La Ligier JS2

La Ferrari 365 GTB4 (Daytona)

Bon, ce serait déjà fantastique d’avoir ces voitures bien réalisées !

Et, bien sûr, il faudrait pouvoir les faire tourner sur le tracé du Mans correspondant à la période… Je ne demande pas que ce soit pile la version 1974 mais, disons, si c’est conforme dans les grandes lignes à la version utilisée entre 1972 et 1978 (comme celle -superbe- qu’avait fait VirtuaLM pour rFactor !), je serais ravi (et d’ailleurs, c’est peut-être ce que prépare Reiza pour une de ces versions “historiques” du circuit du Mans !).

Et pourquoi choisir cette année des 24 heures du Mans ?

Eh bien parce qu’elle représente la fin d’une ère : celle des prototypes ouverts à moteur atmosphériques des années soixante-dix. Et aussi parce que l’édition 74 de ces 24 heures aurait pu être tout aussi passionnante que la précédente (en 73 avec le duel épique entre Matra et Ferrari…). Et, justement, le SimRacing et les mods nous permettent de voir cela… Ce serait bête de s’en priver, non ?

Et pourquoi choisir ces voitures plutôt que les Porsche 917 que tu aimes tant ?

Là aussi, la réponse est facile : les 917 ont souvent été représentées dans différentes déclinaisons du SimRacing (rFactor2, PCARS2, Assetto Corsa et même le tout récent Forza). Alors que les Matra et Alfa (sans parler des Mirages), très peu…

Certes, en fouillant bien, on trouve des mods qui se rapprochent de cet idéal tel que le mod Sportscar 70’ de ChiefWiggum. J’ai testé ce mod (depuis ses débuts) et c’est intéressant mais encore loin du niveau souhaité : les voitures sont d’aspect un peu “cartoonesques” et le comportement est assez “plat”, selon moi. Attention, c’est facile de critiquer mais c’est autre chose de s’y mettre !

Je suis très reconnaissant à ChiefWiggum de ce qu’il a fait pour ce mod et les autres (son mod F1 70’ est également très intéressant) et je ne pourrais faire le dixième (le centième même !) de ce qu’il a fait. Donc, mes “critiques” sont juste mon ressenti personnel, rien de plus.

Est-ce que ce vœux restera un souhait sans lendemain ?

Si on ne fait rien pour que cela arrive, oui, ce vœux restera sans lendemain à moins d’un hasard (ou d’un développement spécifique de la part de Reiza qui, coup de chance, serait pile ce que je souhaite…) plus ou moins improbable. “Si on ne fait rien…” mais que pourrait-on faire ?

Avec une grosse somme d’argent disponible, je peux prendre contact avec le studio Virtual Racing Cars (ou un autre studio qui a publié des “pay mods” de haute qualité) et leur dire “je veux cela, quel est votre prix ?”… Ou alors, en faire un effort collectif : trouver des passionnés ayant différentes compétences techniques et unir nos forces pour faire en sorte que ce mod devienne une réalité…

Si vous êtes intéressé, faites-le moi savoir dans les commentaires.

Publié dans Sports mécaniques virtuels | Laisser un commentaire

Automobilista 2 au Mans sous la pluie

Une anecdote significative qui permet de mesurer où en est arrivé Automobilista 2… Dernièrement, j’ai roulé avec mon fils sur le grand circuit du Mans avec une Porsche 963 (LMHd). Et c’est justement cette expérience que je veux vous relater ici.

Ceci dit, j’entends déjà certains d’entre vous qui vont dire “oui ça existe depuis longtemps dans Automobilista 2 ou dans Assetto Corsa ou encore dans un autre titre, il n’y a rien de nouveau dans ce que tu nous racontes, on sait déjà tout ça”. Admettons mais j’ai quand même envie de vous raconter mon expérience récente… Merci d’avance pour votre attention !

Donc, c’est mon fils qui était au volant et, alors qui roulait déjà depuis deux relais, il a commencé à se mettre à pleuvoir : pas fort au début et la piste restait sèche. Avec des pneus slick à bonne température, ça tient encore très bien même s’ il se met à pleuvoir régulièrement. Il a voulu rentrer au stand tout de suite pour passer les pneus pluie bien que je l’ai prévenu que, sur une piste sèche, ses pneus pluie allaient s’user très rapidement tout en offrant une adhérence moindre que des bons slick. C’est quand même ce qu’il a fait et, évidemment, au bout de 5 tours, les températures de pneus étaient montées dans le jaune et, bien sûr, les pneus se sont usés prématurément très rapidement. Ci-fait que quand la piste est devenue réellement bien mouillée, là où les pneus pluie sont vraiment nécessaires, il a été obligé de s’arrêter de nouveau pour passer des pneus pluie en bon état. Là où la simulation des conditions météo par ams2 était vraiment fascinante, c’est qu’au début, quand il y avait peu d’eau sur la piste, on pouvait s’en rendre compte à l’absence de spray soulevé par les autres voitures. Et puis au fur et à mesure que la piste se trempait, le spray était de plus en plus présent. En suivant les GT3, on pouvait voir que l’intensité du spray montait et descendait en fonction de la vitesse des voitures et ça aussi c’était vraiment un plus. 

Une fois la piste bien mouillée, les pneus pluie sont nécessaires mais ne permettent pas de faire n’importe quoi et le style de pilotage de mon fils accentuait encore le problème. Par rapport à moi, il a un pilotage beaucoup plus agressif, il attaque plus fort mais comme il a un bon “car control”, il arrive à garder la voiture sur la piste à peu près en toute circonstance. Par exemple, en arrivant au virage d’Indianapolis, dans le droite rapide qui précède, il l’avale en 6e, juste en levant le pied alors que je freine un peu et rétrograde en 5e. Je préfère faire comme cela de façon à ce que ma voiture soit bien à droite et bien en ligne avant le freinage important pour le virage d’Indianapolis justement. Lui, il arrive à gérer que la voiture  parte au large et à la ramener pour le freinage mais au prix d’une manœuvre périlleuse. Grâce à sa dextérité, ça passe une fois, deux fois, trois fois mais j’ai des doutes sur la durée d’une course d’endurance. 

Bref, il éprouvait beaucoup de problèmes en sortie de virage car, sous la pluie, la motricité est assez pauvre et même le système de “traction control” ne suffit pas à compenser les pertes d’adhérence. Dans ses mains, la voiture pouvait patiner longtemps et perdre beaucoup de temps à chaque sortie de virage lent. Quand j’ai pu prendre le volant, je lui ai montré qu’on pouvait compenser ce handicap par un pilotage plus coulé en appliquant une sorte de traction control volontaire et en utilisant des rapports supérieurs pour conduire sur le couple et limiter l’arrivée de la puissance. Par exemple, dans les chicanes des hunaudières, j’enroulais en 3e au lieu de rétrograder jusqu’en seconde. Dans ces conditions, mon pilotage à l’ancienne était beaucoup plus efficace que son attaque à outrance en permanence. 

Un autre aspect fascinant de la simulation permise par ams2 dans ces conditions de pluie c’est justement sur le grand circuit du Mans le fait que, selon les endroits, le niveau de l’eau sur la piste variait beaucoup. En effet, sur un grand circuit les conditions météo peuvent être différentes d’un bout à l’autre du tracé et c’est justement ce qui était en jeu ici. Presque tout le circuit commençait à être sérieusement mouillé alors que dans la ligne droite des hunaudières, c’était encore à peu près sec. Et le tour d’après, là c’était mouillé partout.

Tous ces petits détails renforcent beaucoup l’immersion et le plaisir qu’on prend au volant.

Bien sûr, tout n’est pas encore parfait mais force est d’avouer que c’est de mieux en mieux et de plus en plus impressionnant !

Une vidéo trouvée sur YouTube pour illustrer (ce n’est pas moi ni mon fils au volant !!).

Publié dans Ce blog, récit SimRacing, Sports mécaniques virtuels | Laisser un commentaire

Une critique objective de la biographie sur Elon Musk, c’est possible ?

Ah, la question de l’objectivité !

Bon, répondons tout de suite à la question du titre : non. Non, ce n’est pas possible d’être totalement objectif sur tel ou tel sujet car nous sommes fait d’émotions et de préférences. Nous basculons vite dans le subjectif même quand nous croyons rester objectif (en fait, on ne l’est tout simplement jamais !). Donc, je ne vais pas ici vous proposer une critique *objective* de cette biographie mais, au moins, puis-je en parler de façon apaisée.

En effet, pour moi, il n’y a pas d’enjeu dans ce sujet : Musk ne m’est pas particulièrement sympathique tout comme il ne m’est pas franchement antipathique.  En fait, je me fiche un peu de sa personne, je m’intéresse plutôt à ce qu’il a fait et les enseignements qu’on peut en tirer…

C’est le sujet de la petite vidéo que je vous propose ci-dessous :

J’avais déjà évoqué cette biographie dans un article précédent que vous pouvez retrouver ici…

Publié dans à travers mes découvertes, Livres | Un commentaire

Une réfutation du manifeste “techno-optimiste” de Marc Andreessen

De quoi s’agit-il ?

Le 16 octobre 2023, Marc Andreessen a publié un document intitulé “The techno-optimist manifesto” (le manifeste des techno-optimistes) où il proclame que “toute la technique est bonne, la technique va nous sauver, il suffit d’y croire” (en résumé !).

Presque trop facile !

La première fois que j’ai lu ce manifeste, je me suis dit immédiatement que c’était pile pour moi : Marc y exprimait, de manière presque caricaturale, le point de vue des solutionnistes et il apparaissait évident que cela se prêtait (exigeait même !) à une réfutation en bonne et due forme. C’était même presque trop facile !

Bien entendu, je n’ai pas détaillé et répondu à ce texte paragraphe par paragraphe car le document en question est assez long. Mais l’argument principal est clair et bien identifié. C’est sur celui-ci que j’ai fait porter ma réponse.

Ignorants la nature de la technique !

En plus d’être un florilège d’affirmations gratuites et de contre-vérité criantes (voire risibles), tout le contenu de ce manifeste est une preuve criante que Marc et ses “adeptes” sont fondamentalement ignorants de la nature réelle et profonde de la technique. Leur mantra préféré peut se résumer à “il n’y a pas de problème posé par la technique -comme la pollution par exemple” qui ne puisse se résoudre par plus de technique !”… Hum, on voit d’ici l’absurdité de cette affirmation où la cause du problème deviendrait, comme par magie, la clé de la solution… D’ailleurs, cette croyance magique dans la technique est à la base de l’aveuglement de ce groupe d’exaltés. Quand ils clament “plus de technique, toujours plus de technique”, ce n’est pas suite à un raisonnement rationnel basé sur des expérimentations (l’approche empirique essais/erreurs est à la base de bien des découvertes, tant sur le plan technique que scientifique) ou à une démarche scientifique rigoureuse, rien de tout cela. C’est simplement une foi aveugle dans l’équation “technique = bien” qui débouche sur le raisonnement biaisé “encore plus de technique = encore plus de bénéfices pour tous !”. Or, il suffit de se pencher un peu sérieusement sur l’histoire de l’évolution technique pour comprendre que la nature même de la technique n’est certainement pas “gratuite et toujours bénéfique”…

La vraie nature de la technique

La vraie nature de la technique peut se résumer en trois points : la technique est ambivalente (elle n’est pas neutre), elle n’est pas omnipotente et elle n’est pas soumise.. Ambivalente car La technique n’est pas neutre. Un progrès technique n’est pas forcément un progrès pour l’humanité !

Il y a toujours un prix à payer et, en ce sens, on peut dire qu’elle est ambivalente. Toute évolution technique présente des avantages ET des inconvénients. On pourrait croire que remplacer une technique obsolète par une nouvelle plus performante est toujours un gain, mais ce n’est pas aussi simple : la nouvelle technique n’est utilisable qu’avec son contexte (par exemple, les ressources dont elle a besoin pour fonctionner). Le progrès technique n’est pas gratuit, il se paye toujours même si on ne s’en rend pas compte tout de suite.

La technique n’est pas omnipotente (toute puissante) : elle n’a pas réponse à tout, il restera toujours des problèmes insolubles. C’est important de le dire et de le redire pour barrer la route au solutionnisme. Si vous gardez cela en tête, il vous sera facile de reconnaître quand on essaye de vous vendre l’impossible. Si on vous dit que tout est possible, que c’est gratuit et sans conséquence, méfiance…

Et enfin, la technique n’est pas soumise, elle ne l’a jamais été. Depuis le feu qui n’a jamais été “maîtrisé” (si cela avait été le cas, pourquoi avons-nous besoin des pompiers pour éteindre les incendies ?) jusqu’à l’atome qui l’est encore moins. La cruelle vérité est que nous ne maîtrisons pas vraiment ce que nous utilisons et que, de temps en temps, cet usage dérape, nous échappe et provoque quelques conséquences (le plus souvent jamais imaginées !). 

Un manifeste mal rédigé

En plus d’être basé sur des axiomes erronés, ce manifeste est très mal rédigé : il déborde d’une emphase et d’une prétention qui le rendent pénible à lire, en particulier dans les paragraphes sur “l’ennemi” et “l’avenir” situés à la fin de ce pensum, si vous arrivez jusque-là… Et pour ajouter l’insulte à la blessure, Marc a beaucoup recours au “name dropping” : il cite des personnalités pour montrer l’étendue de sa culture… C’est vite lassant et ça donne l’impression inverse. Marc, nous ne sommes pas vraiment sûrs que Richard Feynman (entre autres) serait ravi de voir tes emprunts.

Exagérons, exagérons, il en restera toujours quelque chose !

Plusieurs fois, Marc emploi des formules qui illustrent parfaitement sa tendance à exagérer sans vergogne : “pour toujours”, “sans limite supérieure”… Pour ceux qui croient encore que “les arbres peuvent monter jusqu’au ciel”, ce discours pourra passer. Les autres sauront que le détecteur de conneries s’est allumé en rouge vif !

Un autre exemple significatif avec cet extrait : 

Ray Kurzweil définit sa loi des retours accélérés : Les progrès technologiques ont tendance à se nourrir d’eux-mêmes, augmentant ainsi le rythme des progrès ultérieurs.

Nous croyons en l’accélérationnisme – la propulsion consciente et délibérée du développement technologique – pour garantir le respect de la loi des rendements accélérés. Pour garantir que la spirale ascendante du techno-capital se poursuive pour toujours.

Ray Kurzweil peut bien avancer ce qu’il veut, ça n’est pas pour autant que c’est valide !

Dans le cas présent, c’est même plutôt le contraire : ce qu’on peut constater depuis plus de 150 ans, c’est la loi des retours décroissants

Les retours décroissants

On sait bien que toute nouvelle application produit ses plus grands résultats au début de sa mise en œuvre. Et ensuite, il faut de plus en plus d’efforts et de moyens pour récolter de moins en moins de résultats (du moins en proportion des efforts investis). C’est ça le principe des “retours décroissants” qui est le mieux et le plus facilement illustré par l’exemple de la mine. Au début, l’extraction du minerai, quand on tombe sur le filon, pas très loin de la surface, est relativement facile : en gros, il n’y a qu’à se baisser pour ramasser les pépites. Donc, résumons : peu d’efforts, des résultats spectaculaires, une très grosse rentabilité. Encouragés par ces débuts formidables, vous allez être prompts à investir pour augmenter les volumes : on commence à creuser plus loin, plus profond, à étayer les galeries, à poser des rails pour les wagonnets et à installer des pompes pour garder tout cela au sec. De plus en plus d’efforts pour une extraction qui, certes, croît en volume, mais à un prix évidemment plus élevé (y compris sur le plan proportionnel) qu’au début… On retrouve la même analogie partout : la percée est spectaculairement rentable, la suite beaucoup moins.

Source https://www.penserchanger.com/la-loi-des-rendements-decroissants/ 

Partout et tout le temps

Ce phénomène des retours décroissants, il est à l’œuvre partout et tout le temps sans qu’on en soit conscient. Si on prend les smartphones comme exemple, le gros du progrès a été réalisé avec la première génération d‘iPhone. Dès la troisième, nous sommes passés à un rythme d’innovation beaucoup moins fort, chaque nouvelle itération ne propose que des avancées marginales (retours décroissants ET ralentissement progressif), on est passé en mode “plateau” sans même s’en apercevoir, car, entretemps, une autre mode a pris le dessus sur la précédente et qui fait qu’on a toujours l’impression d’être dans le même courant d’innovations submergeantes, qui sature les possibilités de perception d’un public non-spécialisé qui, du coup, en déduit fort logiquement que “tout va toujours plus vite” même si, incontestablement, ce n’est pas le cas. 

Beaucoup d’argent, toujours plus d’argent mais peu de résultats

Les retours décroissants affectent tous les domaines et tous les secteurs. Dans le domaine militaire, il est de plus en plus coûteux de concevoir des nouveaux systèmes (comme des avions de combat ou les blindés) pour des gains de performances de plus en plus réduits. Pareil dans le domaine des médicaments : beaucoup d’argent et de moyens sont disponibles et pourtant, les résultats se font de plus en plus rares, comme si la technique ralentissait (tiens, tiens…). Dans le cadre des médicaments, le phénomène est tellement évident qu’il a même donné lieu à une “loi”, la loi Eroom. Voir à https://en.wikipedia.org/wiki/Eroom%27s_law

La loi d’Eroom fait observer que la découverte et la mise en production de nouveaux médicaments devient plus lente et plus coûteuse avec le temps, malgré les améliorations techniques (criblage à haut débit, biotech, chimie combinatoire et conception de médicaments), une tendance observée dans les années 1980. Le coût de développement d’un nouveau médicament double à peu près tous les neuf ans (ajusté en fonction de l’inflation).

Le fait que la découverte de nouveaux médicaments ralentit progressivement depuis des décennies est une bonne illustration supplémentaire de la loi des retours dégressifs.

Source https://www.crossfit.com/health/erooms-law 

Ni techno-pessimiste, ni techno-sceptique

Je peux parfois donner l’impression que je nie le progrès technique… Mais rien n’est plus faux !

Le problème essentiel vient de la façon dont les nouveautés techniques sont présentées au grand public. À chaque fois, la nouvelle technique à la mode est accompagnée de promesses faramineuses à grands coups d’adjectifs ronflants (“révolutionnaire” est le terme le plus souvent utilisé). Mais ça ne veut pas dire que c’est forcément un pétard mouillé pour autant. L’Internet, par exemple, n’a pas tenu toutes les promesses du temps de la bulle des dotcoms, mais il n’en a pas moins changé beaucoup de choses (depuis le commerce en ligne qui a redéfini nos pratiques de consommation jusqu’au cloud qui a redéfini notre façon de gérer l’informatique). Finalement, l’Internet peut être vu comme une déception seulement si vous avez cru à toutes les fables proclamées dans les années quatre-vingt-dix. 

Nous savons tous que la technique finit toujours par progresser, presque inexorablement, et ce dans quasiment tous les domaines. Mais cette progression prend simplement plus de temps (toujours plus de temps !) que ce qui en est dit (un exemple : les “autoroutes de l’information” de Bill Gates sont bien là avec les CDN, mais quarante ans après avoir été annoncées… une paille !).

Une arrogance qui appelle à une correction

Allez, un dernier exemple pour situer le niveau d’exagération et d’arrogance de l’auteur de ce document :

Nous croyons en la nature, mais nous croyons aussi en surmonter la nature. Nous ne sommes pas des primitifs craignant la foudre. Nous sommes le prédateur suprême ; la foudre travaille pour nous.

S’il en était besoin, voici une preuve de plus de l’hubris du personnage : “la foudre travaille pour nous”… Voici qui appelle un “et la foudre le frappa” !

Rien de bon, vraiment ?

N’y a t-il rien de bon dans ce (long) document ?

Eh bien en étant ultra-indulgent, on peut approuver son rejet du dogmatisme et du communisme. Mais c’est un peu comme être très poli (ou très hypocrite) quand on approuve une personne qui vous dirait “le bien, c’est mieux que le mal”…

En fait, c’est comme si Marc en était resté coincé à sa période Netscape où l’Internet était censé “sauver la démocratie et la faim dans le monde” (ce n’est même pas exagéré : ce mantra ridicule était répété à l’envie par des gens comme Marc Andreessen… Aujourd’hui, on peut constater que ces promesses ont été, disons, survendues !). Mais ce serait oublier les faces sombres de ce personnage : cette “baleine de la crypto” n’oublie jamais de prendre son bénéfice d’abord et surtout au détriment des gogos qui veulent bien le croire (demandez à tous ceux qui se sont fait “rincer” par la vague récente des cryptos bidons…).

Les accélérationistes existent et ils ont même un mouvement

Le pire, c’est que Marc n’est pas seul à proclamer cette “foi”, il a des adeptes (les e/acc) et même une place de marché pour afficher leurs convictions (https://accelerate.shop/en-eur/ les goodies pour les e/acc !) et ils ont trouvé un nom pour leur “mouvement” : accélérationnisme efficace

https://en.wikipedia.org/wiki/Effective_accelerationism

https://effectiveacceleration.tech/

Bon, on pourrait croire à une pochade de la Silicon Valley mais il est à craindre que cela soit très sérieux (Marc et ses adeptes ont l’air d’y croire) tout en étant totalement loufoque (aucun de leurs arguments ne résiste à une analyse rationnelle). Mais, à notre époque, le bon sens se perd (combien de fois, ces derniers mois, avez-vous lu que ChatGPT était une “révolution et allait tout changer ?” alors qu’il est désormais clair que les “réponses” de ce logiciel sont souvent sujettes à caution…).

Conclusion : ne pas croire au solutionnisme

Le solutionnisme est une impasse. C’est une idéologie fallacieuse qui nous pousse à ne pas corriger les erreurs déjà commises dans le passé. Si nous voulons vraiment progresser et aller de l’avant, il ne faut pas se laisser aller à des solutions de facilité du genre “plus de technique, toujours plus de technique” alors que c’est précisément l’excès de technique mal pensée et mal implémentée qui est la cause des problèmes que nous affrontons désormais.

Les solutionnistes sont des illusionnistes qui veulent nous leurrer pour que leurs petites affaires puissent se poursuivre sans entrave.

Addendum par Laurent Poulain (un ami de longue date avec lequel j’ai rédigé notre “Histoire de l’informatique moderne”):

Il est indéniable que l’humanité a énormément bénéficié des progrès techniques au cours des siècles, et il est à parier que cette tendance va continuer.

Mais les techno-solutionnistes nous présentent une fausse dichotomie. Ils sous-entendent que n’importe quelle startup tech est dans la lignée d’Henri Ford, Robert Noyce ou Steve Jobs. Marc Andreessen affirme que la technologie est la solution à TOUS les problèmes, et que toute tentative de réguler une nouvelle technologie qui pourrait sauver des vies dans le futur est similaire à un meurtre. Certains techno-solutionnistes semblent également avoir une vision fort simpliste de la technologie. La Loi de Moore double magiquement la vitesse de nos ordinateurs tous les deux ans, et continuera à la faire éternellement. Bien entendu, toute critique de cette vision est vue comme anti-progrès. Soit vous êtes à 100% dans notre camp soit vous êtes contre nous.

En d’autres termes: nous autres élites de la tech savons mieux que quiconque comment résoudre tous les problèmes du monde, laissez nous en paix. Ce n’est pas comme si nous n’avions jamais abusé de notre pouvoir ou parfois promis du vent.

La guerre est sans doute le plus grand contre-exemple où plus de technologie ne résout pas le problème. Richard Gatling, inventeur de la mitrailleuse du même nom, pensait que son invention allait mettre un terme aux guerres. Qui allait être assez fou pour démarrer un conflit lorsqu’une arme tellement destructrice que la mitrailleuse est utilisée ?
La Grande Guerre a prouvé le contraire.

“Donnez-nous un problème réel et nous pourrons inventer une technologie qui le résoudra” clame Marc Andreessen. Il peut commencer par San Francisco qui a son lot de problèmes (prix du logement, sans-abris, vols à l’étalage croissants). Et s’il veut un problème dont la résolution lui attirera l’admiration du monde entier (dont votre serviteur), suggérons-lui de s’attaquer à la corruption.

Mais en quoi l’exagération des techno-solutionnistes peut-elle être une mauvaise chose ? Après tout, ils génèrent du buzz qui alimente l’industrie. Sauf qu’à trop promettre, on court le risque d’un retour de bâton pour l’industrie tech tout entière. Dans les années 90 c’est toute l’industrie de l’IA qui a pâti des trop grandes promesses des années 80.

Au final, M. Andreessen résume la situation mieux que quiconque, probablement sans ironie aucune : “Notre ennemi est la tour d’ivoire, la vision du monde des experts je-sais-tout, se livrant à des théories abstraites, des croyances de luxe, de l’ingénierie sociale, déconnectées du monde réel, délirantes, non élues et irresponsables – jouant à Dieu avec la vie de tous les autres, avec une isolation totale contre les conséquences.”

Publié dans Anecdotes IT, divers, Informatique, La terrible vérité, Le fait technique | Laisser un commentaire

La simulation idéale en SimRacing, suite et fin ?

Voici le troisième volet de la série d’articles que je vous propose sur ce sujet. Mais je pense qu’on ne peut l’épuiser aussi facilement donc, je me réserve d’y revenir encore mais plus tard !

Dans les deux précédents volets (voir ici et là), je revenais sur l’offre du marché et ce qu’on pouvait en espérer mais aussi sur la personnalisation que chacun est en droit de mettre en place autour de la notion de simulateur de pilotage automobile (et de courses !). Vous connaissez mes préférences et, cette fois, je vais vous faire part d’expériences récentes.

Toujours dans le but d’améliorer la capacité immersive (c’est bien dit, hein !) de mon simulateur, je creuse et j’essaye des solutions dans tel ou tel domaine. Dernièrement, j’ai testé et rejetté le HF8 de Next Level Racing (évoqué dans l’épisode précédent), cette fois, je vais vous relater un autre test négatif : le Delanclip Fusion Pro. Il s’agit d’une alternative à TrackIR bien connu qui permet de faire du suivi d’affichage en fonction de la position de votre tête…

En gros, grâce à ces systèmes, vous avez l’équivalent de la vision VR mais sans le casque. Bon, mon expérience s’est avérée négative (au final, je n’ai pas conservé le Delanclip Fusion Pro) car, d’une part, j’ai eu du mal à le faire fonctionner dans un premier temps. Une fois que j’ai surmonté ces inévitables problèmes de mise en service, j’ai constaté que le rendu ne me convenait pas. C’est seulement en l’expérimentant que j’ai pu me rendre compte que ce système ne m’apportait rien, me gênait plutôt en fait. C’est aussi parce que mon triple-screens me convient très bien. Je m’y suis tellement habitué que la moindre perturbation de l’affichage me gêne tout de suite.

Cette expérience négative ne l’a pas été complètement, négative. Car elle m’a permit de me confirmer, une fois de plus, que “le mieux est l’ennemi du bien” et que “plus” est quelquefois synonyme de “moins”. Désormais, je suis plutôt prudent sur les évolutions possibles de mon simulateur ce qui peut être compris comme un bon signe : ça veut dire que je suis arrivé à un niveau satisfaisant dans l’ensemble.

C’est pourquoi, par exemple, je n’ai pas encore changé la base de mon volant pour un Direct Drive. Mon Fanatec Elite CSL me parait encore en très bon état et me donne un retour convaincant. Donc, je le garde plutôt que de céder à la mode actuelle. Cela peut largement attendre !

Ces différentes expériences récentes ont achevé de me convaincre que la simulation idéale est en fait un système : un ensemble de composants travaillant en symbiose. La simulation elle même est le composant centrale avec donc une grande importance mais qui ne peut donner son plein potentiel sans l’apport des autres (composants) : écran(s), volant+pédalier, chassis+baquet et les autres éventuels “accessoires”. C’est grâce aux choix judicieux effectués autour de la simulation logicielle que vous allez construire votre “simulateur de pilotage idéal”.

Publié dans Sports mécaniques virtuels | Laisser un commentaire

Voilà pourquoi vous devez passer à Automobilista 2 !

Le circuit du Mans et trois protos LMDh dans la toute dernière mise-à-jour d’Automobilista 2 (AMS2), que demander de plus ?
Et que va-t-il rester à LeMans Ultimate (si jamais il sort !) ?

Sérieusement, ce package “spécial Le Mans” est grandiose : le circuit est magnifique (comme d’habitude avec Reiza) et les nouvelles voitures sont top !

Spécialement la Porsche 963 qui est un régal à piloter : rapide et facile, elle est particulièrement adaptée aux pilotes habitués aux GTE/GT3 car les LMDh sont plutôt lourdes mais dotées de pas mal d’appuis et de puissance. Ce mélange bien dosé donne un résultat très plaisant, même pour moi qui ne suis pas trop fan des voitures modernes pourtant.

Si vous hésitiez encore à plonger sur AMS2, il est temps, il est grand temps !

Publié dans Sports mécaniques virtuels | Laisser un commentaire

Un film de SF français et en animation ? Oui, c’est Mars Express !

C’est un ovni (un film français de SF et en animation ?) mais c’est une pépite aussi : je viens de découvrir Mars Express !

Déjà, voici la bande-annonce de cet “ovni” :

Ensuite, je recommande de regarder cette interview du réalisateur par Nexus VI (toujours excellent !) :

Une autre critique positive à voir :

Mon avis : c’est du bon et c’est du lourd. Déjà, le fait que c’est en animation s’oublie très vite, bravo !
Ensuite, l’écriture et la réalisation sont au top : on ne vous prend pas pour des débiles. Enfin, l’univers dépeint est très cohérent et ça aussi c’est bien. Bref, vous l’aurez compris : allez le voir, sans restriction.

Publié dans divers, Science-fiction | Laisser un commentaire

Que peut-on encore dire d’intéressant sur l’IA ? Cosmotech propose une réponse juste et équilibrée !

La vague actuelle d’hystérie et d’exagérations ridicules sur l’IA m’exaspère au plus haut point. Mais, en cherchant bien, on peut trouver des acteurs raisonnables qui proposent un discours intéressant et qui apporte quelque chose sur le sujet… C’est le cas de Cosmotech (un start-up française spécialisée sur la simulation et les jumeaux numériques) et je vous invite à regarder la série de courtes vidéos présentées par Michel Morvan, le co-fondateur de cette société… Je précise que je n’ai aucun lien avec Cosmotech (que je viens de découvrir !) et que j’approuve à 100% ce que dit Michel Morvan dans ces vidéos !

Publié dans Anecdotes IT, Informatique, Références IT | Laisser un commentaire