C'était en ROM, et c'est ce qui est intéressant. Il n'y avait donc pas de système d'exploitation à charger au préalable mais, à contrario, il n'y avait rien d'utilisable en soi intégré directement à l'ordinateur non plus, qui ne servait donc que de plateforme de lancement. Comme on ne pouvait faire de programmation — de fait — comme exposé ci-dessus et que c'était encore limite pour un usage professionnel, et comme par ailleurs l'Atari ST avec un bon processeur graphique (avec l'équivalent d'un Copper) et une puce sonore caractéristique, et bien il servait principalement de plateforme de jeu, avec des disquettes bootables la plupart du temps, sinon lancées depuis le bureau GEM qui donc, ne servait à rien la plupart du temps.
Et pourtant, il a été extrêmement populaire ! En ce sens, c'était un peu l'équivalent avec clavier de la Playstation qui sortira quelques années plus tard (même s'il se rêvait en concurrent du Mac).
Ce qui me fascinait, à l'époque, c'est que pour moi, en ce temps, chaque machine avait son architecture propre et donc sa propre interface utilisateur (quelle qu'elle soit, d'ailleurs, bureau ou interpréteur). Et là, non seulement GEM ressemblait beaucoup au Mac (on peut lire aujourd'hui que ce n'était pas fortuit) mais c'était quelque chose que j'avais vu en premier lieu… sur PC ! Avant Windows (à partir de 3.0) mais surtout sur une machine où l'on utilisait principalement DOS ! Il faut dire que, sans disque dur, il fallait lancer le DOS, puis changer de disquette et lancer GEM, puis changer de disquette et lancer le logiciel qui nous intéressait. Donc, ça limitait un peu l'intérêt… mais j'avais fini par le trouver sur une de nos disquettes (5'1/4, 360Ko) et ce justement parce notre compatible PC un peu miteux (de marque « PC Land » à l'époque) ne faisait pas bien tourner MS/DOS, mais fonctionnait parfaitement avec… DR/DOS, de Digital Research, donc.
Le plus drôle, c'est que je m'aperçois que la boîte de 5'1/4 est toujours sur mon étagère. Ça fait donc 20 ans qu'elle n'a pas bougé. ^ ^
C'est à ça que je pensais aussi, effectivement, mais comme je ne les ai jamais essayés, je ne me suis pas prononcé sur ce point non plus. En revanche, j'ai les mêmes craintes que toi, parce que si on constate que beaucoup de monde maîtrise encore la chose, je me suis aperçu que la totalité ou presque des personnes concernées sont justement les gens qui ont connu l'époque des huit bits ou, en tout cas, qui ont commencé sur autre chose qu'un PC ou Mac récent.
Il me semble d'après ce que j'en ai compris que l'atari ST avait le basic intégré en ROM. Mais comme j'en avais pas (j'avais une meilleure machine, la meilleure de tous les temps : l'Amiga), je ne peux pas le confirmer. Quelqu'un dans la salle pour expliquer comment démarrait un Atari ST ?
Pour les bases de programmation de µcontrôleur, sûrement, oui. J'ai aussi codé en mode réel sur du 16bits, c'était clairement plus simple. Plus simple aussi de cramer la machine en se trompant d'adresse mémoire.
Pour les microcontrôleurs, c'est certain. C'est ce qui s'en rapproche le plus aujourd'hui (même si les microcontrôleurs existaient déjà à cette époque et étaient à peu près du même niveau de puissance).
Le mode réel sur 16 bits, c'était plus simple aussi, même si à l'époque on s'arrachait les cheveux pour comprendre à quoi ça correspondait quand on était habitués aux « banques » de mémoire paginée. Et surtout : c'était déjà du PC. C'était quand même intéressant de pouvoir constater qu'un ordinateur n'est pas nécessairement un ersatz de l'IBM PC et de son 8086. En plus, à ce stade, on parle déjà d'assembleur et pour le coup, le grand débat de l'époque, c'était l'opposition Intel vs. Motorola. On disait que les premiers avaient été pensés par des électroniciens, les seconds par des programmeurs.
Du coup, même si on a eu toute la vague des Atari ST/Falcon vs Amiga, les huit bits branchés sur le téléviseur familial (ou déjà sur leur propre avec les Amstrad CPC) étaient vraiment une époque particulière, ne serait-ce parce que chaque machine était en elle-même une architecture propre et distincte des autres, même (et surtout) si tous les ordinateurs fonctionnent suivant le même principe. C'était vraiment la même différence qu'il pouvait y avoir entre un avion de ligne et un avion de chasse.
Par contre, pour des trucs plus compliqués, pas vraiment non. D'ailleurs, c'était passionnant, le graphisme en 16 couleurs… ou pas. Bon, j'exagère, je sais: c'était 256 couleurs en 320x200, vive le mode 13h.
Oui, le mode X aussi, toussa. Mais là encore, c'est le contraire même de ce que l'on parle, puisqu'il s'agit déjà d'assembleur sur PC. Note que l'assembleur, c'est génial en soi, même sur PC, mais ce n'est pas l'objet de ce qui nous intéresse. Quand tu faisais LINE en BASIC, tu mettais le numéro de couleur à la fin. Du coup, que tu disposes de 16 couleurs ou de 4294967296, ça ne changeait pas la syntaxe du langage, et ça ne change pas non plus celle des langages actuels.
Vraiment? Pas de POST, pas de BIOS?
Oui, vraiment.
Quand tu allumais un MO5 ou un CPC 6128, tu tombais immédiatement sur le BASIC. Il y avait environ une demi-seconde d'initialisation. Quand tu allumais un MO6 ou un TO8, tu tombais sur une page d'accueil où tu tapais un chiffre qui t'orientait immédiatement vers le BASIC de ton choix parce qu'il en proposait deux, ou vers de menus utilitaires, le tout étant contenu en ROM. Et tout cela parce que pendant très longtemps, les ordinateurs personnels, y compris PC, n'étaient pas dotés de disques durs.
Rien que le POST de mes 1ères machines (16bits, encore une fois… quoique, si ça se trouve j'ai connu du 8bits et je m'en souviens pas.
Oui mais tes machines étaient-elles des compatibles PC ? On rappelle bien que PC veut dire « Personal Computer » et que c'est à la base une marque et un modèle déposé d'IBM. Ça n'a jamais été un nom commun. Comme ils ont (volontairement) laissé leurs concurrents les imiter, ceux-ci ont dès le départ produit des ordinateurs « compatibles PC » (ou « compatible IBM », comme on le disait à l'époque) mais c'était une hypocrisie avouée dès le départ : il ne s'agissait pas d'une architecture complètement indépendante mais capable d'exécuter les programmes prévus pour l'IBM, mais bien d'un clone, à chaque fois.
C'est quand même malheureux parce que c'est à une époque où l'informatique n'a jamais été aussi répandue qu'il y a le moins de diversité et, paradoxalement, parce qu'il n'existe justement plus d'ordinateur grand public non-PC, hormis le mac, les gens ne sont plus capables de s'apercevoir qu'il s'agit bien du même, même s'il a tellement évolué en 35 ans qu'il n'a presque plus rien à voir avec l'original.
C'est vraiment un destin à la John Spartan : « et alors maintenant, tous les restaurants sont des Pizza Hut ». On en rigole en voyant le film mais il est de fait que c'est ce qui est arrivé à l'informatique grand public et quand on sait l'importance que ça a aujourd'hui, ça n'est pas réjouissant.
Je veux dire, en tant que PC pour bosser, sinon c'est certain que j'ai connu) mettait plusieurs secondes… passer l'étape complète du BIOS mettait plusieurs dizaines de secondes.
BIOS et POST sont des terminologies propres à l'IBM PC, même si les autres ordinateurs étaient dotés en ROM de routines d'initialisation similaires puisqu'on ne peut pas s'en passer.
Le PC, c'est vraiment le Vigor de l'informatique : une machine industrielle reconditionnée à petite échelle pour l'adapter à l'utilisateur individuel. Sur les grosses machines, la procédure d'initialisation n'avait pas beaucoup d'importance parce qu'elles sont vouées à rester allumées en permanence et parce qu'elles font souvent, par ailleurs, l'objet d'un contrat de maintenance une fois vendues aux structures auxquelles elles sont destinées. Sur AS/400, le démarrage s'appelle même « IPL » (Initial Program Load).
Le PC, par contre, outre le fait qu'il a été dès le départ une grosse boîte lourde, imposante et majoritairement vide, était doté d'équipements qui, pendant très longtemps, ne servaient vraiment à rien. Par exemple, le ventilateur. Aujourd'hui, ce serait difficile de faire sans mais à l'époque, la technologie était guère différente de celle des huit bits et même l'Amiga 1200, qui était un 32 bits sorti en 1992 et contemporain du 486 (68020, pas x86) s'en passait fort bien.
Pendant longtemps, le PC m'est apparu comme étant à la fois la machine la plus chère et la plus mal conçue, jusqu'à ce que ces défauts soient compensés par un moteur de fusée.
Il me semble bien que c'est le cas également de tous les langages interprétés que je connais, anciens ou modernes.
Oui, il me semblait que certains étaient moins adaptés que d'autres à cet usage mais comme, à y réfléchir, je n'ai pas d'exemple probant en tête, je ne te contredirai pas sur ce point.
Hum. De nos jours, il est possible au néophyte de faire des choses très élaborées avec Excel, sans jamais taper la moindre ligne de code. Malheureusement pour les devs qui doivent rattraper les dégâts, d'ailleurs :)
Oui mais là encore, c'est l'opposé de ce qui nous intéresse ici. Excel propose d'ailleurs le VBA, dont on pense ce que l'on veut, mais qui permet effectivement de faire pas mal de choses dans une feuille de calcul (à commencer par des âneries). Mais il s'agit quand même d'un logiciel dédié à une utilisation précise, qu'il faut lancer dans un environnement déjà opérationnel, et par des utilisateurs déjà grands.
À contrario, le PC, le Minitel et le TO7 sont sortis à la même époque, qui correspondait pour moi à la classe de CP (où on était venu nous présenter le dernier) et mes premiers vrais programmes, c'était en CM2 sur les machines du plan Informatique pour tous. L'idée est de faire en sorte que l'interface par défaut, même à destination des plus jeunes, puisse permettre de faire ce genre de choses sans que ce soit obligatoire.
Les notices ont été supprimées parce que ça coûte cher à imprimer et que de toute façon les gens ne les lisent pas. Ironiquement, c'est moi qui lis le plus souvent les notices des appareils dans ma famille, alors que je suis celui qui a la plus grande maîtrise de cet outil. Et je râle pas mal quand je dois aller chercher la doc sur le net ou dans les tréfonds d'un CD…
Oui mais ça, ça s'appelle de l'expérience. :)
La notice a disparu aussi parce qu'il n'y a plus grand chose à y mettre. Mais c'est surtout parce qu'on peut l'installer directement dans l'interface si on a un ordinateur qui démarre normalement. Et là, on pourrait y mettre les mêmes indications.
Dans mes souvenirs de jeunesse, j’utilisais des langages tels que le Basic ou le Logo. Une capacité à pouvoir faire simplement de petites choses, avec parfois même un soupçon de graphisme.
Des langages pour les quels quelques minutes et à peine quelques commandes, faisait apparaitre un résultat à l’écran.
C'est exactement l'impression que j'en ai moi aussi et plus le temps passe, plus je trouve que l'ère des 8 bits a été une époque bénie pour apprendre l'informatique. Et il ne s'agit pas d'une vaine nostalgie mais bien d'un temps particulièrement propice que j'ai été heureux de vivre.
Et c'est vrai que les machines de l'époque étaient très faciles à aborder : quand on les allumait, elle étaient immédiatement utilisables (pas de temps de boot), elle ne faisaient aucun bruit (sauf si on leur demandait d'en faire, bien sûr) et on tombait directement dans le BASIC (qui était en fait une caractéristique du premier PC XT qui, lui, paradoxalement, a vite abandonné la chose).
Ce qui était intéressant, c'est que le BASIC était présenté d'emblée comme langage de programmation (ce qui est effectivement sa vocation), mais qu'il servait à la fois d'interface utilisateur et de système d'exploitation. Et surtout : il était doté d'un mode direct ! On pouvait exécuter directement une commande et avoir son résultat, mais on pouvait également commencer à écrire un programme en mémoire en utilisant les numéros de ligne.
Du coup, on écrivait PRINT "BONJOUR" et on avait directement le résultat, on tapait BOX et on avait un carré à l'écran. Non seulement le néophyte avait tout de suite une réaction de sa machine la première fois qu'il la sollicitait, mais on pouvait très rapidement enchaîner tout de suite sur des choses plus élaborées… avant même de connaître la commande pour sauver son programme ! Chose qui, d'ailleurs, était paradoxalement compliquée surtout quand on utilisait des cassettes. :)
De coup, même quelqu'un qui ne se servait de son ordinateur que pour lancer ses logiciels faisait de fait de la programmation puisqu'il fallait au moins faire « RUN"…" » pour les exécuter (ce qui était donc précisé sur l'étiquette, en général). Et ça, c'est très différent des machines actuelles où l'interface des OS est un « bureau », soit une chose effectivement conçue pour le travail en entreprise, à la base, puis à destination d'un « usager » plus qu'un opérateur.
Du coup, il serait intéressant de réintroduire un standard (oui, je sais, XKCD) qui permettrait de faire la même chose, à savoir une interface minimaliste (même une ligne de commande) mais disponible partout, qui contiendrait par défaut un nombre d'instructions limité fixe mais parfaitement défini, d'usage général (tracer des figures, jouer du son, lancer une application, écrire à l'écran) et qui serait immédiatement utilisable sans même avoir à faire le moindre « @import ». En précisant que cela pourrait quand même s'appuyer sur l'existant, qui continuerait à être utilisé normalement en dehors de ce contexte particulier. Il faudrait aussi minimiser tout le sucre syntaxique pour ces commandes élémentaires (genre pas de point-virgule, ni de tabulations obligatoires).
C'est déjà en substance ce que fais le shell dans une certaine mesure et c'était l'idéal imaginé au départ par pas mal de langages de scripts, et il y a bien des consoles Javascript dans un certain nombre d'environnement (par exemple Looking Glass dans GNOME 3 avec Alt+F2 puis « lg ») mais si c'était partout et immédiatement accessible, on pourrait mettre ça dans la notice d'un ordinateur neuf (ce qui se faisait en fait à l'époque) et ce serait la première chose que découvriraient les nouveaux utilisateurs.
Hmm. J'avais répondu à ce commentaire et il semblerait qu'il ait disparu. Bizarre…
Je crois bien que j'ai parlé trop vite : ton patch, comme ton journal, est daté du 12 novembre 2017. Je ne sais pas si cela correspond à ton propre commit en local où si c'est la date à laquelle tu l'as soumis, mais toujours est-il que c'est aussi exactement le jour de la sortie du noyau 4.14.
Donc, normalement, c'était aussi le début de la fenêtre d'intégration des patches qui dure typiquement 14 jours (deux semaines, du lundi au… lundi). Bon, il est entendu qu'en principe, un patch doit d'abord passer par linux-next et y être intensivement testé mais étant donné la chose, on aurait pu faire ça en accéléré et faire tenir toute la procédure dans les deux semaines critiques.
Normalement, la fenêtre a dû se refermer le 25 au soir et la commit date de ton patch est marquée du… 29 :-\ Je ne sais pas si c'est délibéré (dans le sens où le mainteneur doit se charger de faire intégrer les patches déjà en attente, puis s'occuper de préparer les nouveaux une fois la fenêtre refermée) ou si c'est parce que ça a traîné mais quoi qu'il en soit, le noyau 4.15 doit sortir soit lundi prochain, soit dans dix jours. Donc, ce sera pour l'intégration du 4.16 à venir incessamment, mais il faudra bien te faire rappeler à leur bon souvenir pour être sûr que ce soit fait…
Reste à savoir si ce correctif critique va pouvoir être immédiatement rétroporté comme indiqué dans les directives présentées ailleurs, ou s'il va falloir attendre deux mois que le 4.16 sorte officiellement avant d'envisager la chose… et d'attendre ensuite la publication d'une nouvelle branche stable.
Je ne vois pas où est le problème de recalculer toutes les sommes de contrôle. C'est ce que fait Git à chaque fois qu'on clone un dépôt afin justement de vérifier qu'aucune version n'a été altérée.
Oui mais justement : on est censé retrouver les MÊMES sommes, et c'est entre autres ce qui permet de travailler de façon décentralisée sans avoir besoin de coordonnateur.
Changer de fonction de hachage n'altère en rien le fonctionnement théorique du logiciel (ce qui, en soi, est la marque d'une conception très bien pensée) et serait relativement facile à implémenter. Par contre, ce serait un cauchemar pour les administrateurs systèmes car cela implique de migrer l'intégralité des objets d'un dépôt ET d'amender tous les commits puisque ceux-ci contiennent en clair la somme de leur ou de leurs parents. On ne pourrait pas se contenter de les renommer, donc.
Ensuite, la grosse difficulté viendrait du fait que tout dépôt basé sur l'ancienne somme serait incompatible avec la nouvelle. Il n'y aurait donc pas de transition douce : tous les acteurs d'un même projet seraient donc d'abord obligés de mettre leur version de Git à jour, puis de migrer tous leur dépôts avant de pouvoir continuer à travailler ensemble. Et cela ne concernerait pas seulement les développeurs actifs : toute personne ayant cloné le noyau sur kernel.org serait concernée.
Enfin, cela rendrait caduques toutes les sommes publiées sous forme texte, que soit par mail, sur Usenet, sur le Web et sur les différents outils collaboratifs, que ce soit la LKML ou les commentaires des tickets Github. En outre, et par définition, les dépôts clonés cesseraient d'être des clones, puisqu'il pourrait y avoir plusieurs versions différentes d'un même objet : non seulement les sommes d'un commit serait différentes selon la fonction choisie, mais leur propre contenu le serait aussi puisqu'ils se référeraient à des sommes différentes. Il n'y aurait pour ainsi dire plus rien d'officiel pour indiquer facilement qu'ils sont les homologues de ceux calculés avec l'ancienne somme.
Le pire, c'est qu'il n'y aurait pas moyen de faire une conversion de l'ancienne somme vers la nouvelle a posteriori. Il faudrait dresser « pour l'histoire » une table de correspondance au moment où la migration se fait et ne surtout pas la perdre après cela.
Je dis peut-être des bêtises, mais d'après ce que j'ai compris c'est justement ce qui fait que les processeurs AMD ne sont pas touchés par Meltdown : ils vérifient les permissions avant l'exécution spéculative, alors que les Intel le font tout à la fin, comme tu dis.
Je ne suis pas allé vérifier si c'est vrai ou faux, donc je ne me prononcerai pas sur le fond, mais si c'est le cas, alors à moins d'avoir une MMU extrêmement performante (ce qui est peut-être le cas aussi), alors cela mettrait complètement à mal l'exécution spéculative puisqu'elle serait obligée d'attendre sa décision avant d'être exécutée. Donc, ce ne serait plus de l'exécution spéculative. Et c'est un problème puisque cela concernerait TOUS les accès mémoire, aussi bien en lecture qu'en écriture, puisqu'il est par définition impossible de savoir si un accès est en dehors de sa plage avant de l'avoir examiné (sauf modes indexés spéciaux avec un offset notoirement local, parce que défini dans un petit registre (par exemple, sur 8 bits)). Donc, ce serait extrêmement fréquent dans un programme.
Reste à savoir si c'était quelque chose qui était réellement imaginable à l'avance, surtout au moment où les premières puces à pipeline ont été produites, puisque les rares qui sont encore en fonctionnement aujourd'hui sont menacées aussi. Autrement dit : est-ce vraiment une faute grave du constructeur compte tenu de son expérience et de son expertise, ou est-ce vraiment la faute à pas de chance ?
Parce qu'à ce compte-là, des compromissions de ce genre, on en a connu beaucoup dans le domaine logiciel mais, elles, peuvent être facilement patchées. Les générations de collisions pour MD5 et SHA1, par exemple, sont dans leur genre des petites bombes elles aussi et la dernière concernait particulièrement Git. Alors, certes, il « suffit » de passer à une nouvelle fonction de hachage pour pallier le problème jusqu'à ce qu'elle soit cassée à son tour, mais étant donné la diffusion du logiciel, il n'est pas concevable de réécrire toutes les sommes de tous les objets de tous les dépôts du monde, qui parfois contiennent des objets qui sont aussi vieux que Git lui-même, à commencer par le dépôt du noyau Linux. La seule solution consisterait à faire cohabiter les deux versions en marquant la première comme dépréciée.
Ici, c'est particulièrement grave parce que la faille se produit à très bas niveau, et a donc un impact très large en conséquence mais étant donné la complexification toujours plus forte des systèmes et le point auquel ils sont répandus, je pense qu'il va falloir s'attendre à faire face à ce genre d'incident à intervalles relativement régulier.
Pour ce que j'ai lu de la même page, c'est PRESQUE cela, en effet, mais à quelques détails près et qui feraient, entre autres, que l'approche par indexation en particulier ne pourrait justement pas marcher. Par ailleurs, tout repose sur le fait que l'on mesure un temps d'accès pour savoir si une donnée est ou non dans le cache. Et comme la réponse à cette question est forcément « oui » ou « non », ça implique de distiller l'info bit par bit, d'où l'exemple de la page Wikipédia et de son bit 0.
En gros :
On flushe le cache à deux adresses légitimes mais différentes et qui, selon moi, doivent également correspondre à deux pages de cache DISTINCTES, donc relativement éloignées l'une de l'autre (d'où le problème avec l'indexation) ;
On lit la valeur d'une adresse « hors zone » dans un registre R ;
On laisse volontairement le programme segfaulter à cause de cela (on rattrapera le problème avec un handler de signal) ;
On continue ensuite comme si de rien n'était, en extrayant de R le bit qui nous intéresse et en faisant un calcul pour résulter, selon sa valeur, à l'une ou l'autre des adresses légitimes évoquées au départ ;
On lit le contenu de l'adresse calculée ;
On lit le contenu les contenus respectifs de ces deux adresses en mesurant le temps que cela prend (par exemple, avec RDTSC, j'imagine).
La page précise qu'il vaut mieux éviter les branchement conditionnels pour faire ces calculs pour éviter de mettre en branle les mêmes mécanismes prédictifs (en gros, faire le calcul avec des opérateurs logiques plutôt qu'avec des « if »).
On se moque, en fait, de ce que contiennent les deux adresses légitimes mais toute l'astuce s'appuie sur le fait que la segfault va prendre un certain temps pour être déclenchée, et que les points 3, 4 et 5 auront le temps d'être honorés même si le CPU fait marche arrière ensuite si elle l'est. Après, sachant qu'on avait au départ vidé le cache, le point numéro 5 l'aura rechargé quand même. Donc, si l'une des pages est lente à accéder et que l'autre est rapide, on peut en déduire la valeur du bit recherché.
Évidemment, c'est très sioux et tout le problème réside dans le fait que ce n'est pas du tout un problème algorithmique. Tout microprocesseur doté d'un système de protection, d'un mécanisme de prédiction ET utilisant de la mémoire cache est potentiellement affecté.
On pourrait déjà circonvenir au problème en invalidant TOUT le cache en cas de segfault, mais on pourrait encore contourner la chose en faisant lire les adresses concernées par un thread ou un processus distinct qui, lui, n'aurait rien à se reprocher. Et qui pourrait presque le faire, en le synchronisant bien, avant le déclenchement de la segfault. C'est déjà compliqué à gérer en soi, mais ça devient particulièrement gênant sur les multicœurs et les systèmes distribués.
Et là où ça devient vraiment désespérant, c'est qu'apparemment la solution envisagée est : « puisque c'est une faille qui s'appuie sur la mesure des performances, alors on va sacrifier les performances ».
Bon, j'arrive un peu après la bataille, mais j'étais occupé à d'autres choses plus techniques (que je vais produire ici même quand j'aurai fini).
Techniquement, j'ai appris l'anglais au collège en classe de sixième, comme pas mal de monde. C'était en 1987, ce qui ne nous rajeunit pas. Je n'étais pas franchement mauvais, j'aimais ça, mais je n'ai jamais été un premier de classe non plus. J'ai donc pu pendant très longtemps me revendiquer d'un simple « anglais scolaire ». Ça me permettait tout juste de le baragouiner un peu si jamais je devais me faire comprendre quelque part (dans un aéroport, par exemple) mais guère plus côté oral. Par contre, ça me permettait de le lire relativement facilement, et la programmation exercée depuis « le plus jeune âge » sur les MO6 de l'école m'avait permis d'aborder facilement l'anglais technique.
Par la suite, j'ai commencé par essayer de lire des romans en anglais avec un dictionnaire à côté. C'est une bonne idée en soi mais franchement, pour chaque page du livre, on se réfère dix fois au dico et ça devient vraiment ingérable. Mais ça fait son effet quand même à la longue.
Le premier coup d'accélérateur est venu avec les DVD quand, après avoir vu les épisodes qui me plaisaient le plus, je les revisionnais en version originale sous-titrée (VOST). À l'époque, j'essayais aussi d'aller voir les films en VO au cinéma du quartier mais à défaut d'un niveau suffisant, on reste le nez collé sur les sous-titres, on se concentre ni sur le film ni sur l'histoire et au final, on en ressort fatigué sans avoir gagné grand chose. Mais les séries ont fini par donner des résultats et une jeune prof d'anglais connue plus tard nous avait confirmé que c'était ce qui, à l'usage, donnait le plus de résultats.
Quand j'ai commencé à me sentir suffisamment à l'aise en lecture, j'ai commencé à faire des traductions. En 1997, j'avais entrepris de traduire le painless guide to CRC error detection algorithms, à l'époque où l'ADSL était expérimentale et où on partageait encore l'info en s'envoyant des CD.
Les moteurs de recherche étaient déjà au point mais quand Google a commencé à se démocratiser, c'est devenu plus facile d'accéder à beaucoup de documents en anglais ciblant les centres d'intérêts mais surtout, il est devenu très facile de voir si tel ou tel idiome existait ou non, et la recherche par image sur un terme en anglais a permis de constater instantanément quelle est l'acception la plus fréquente d'un mot dans le langage courant. Et ça, c'est devenu un vrai atout si on ne peut pas s'immerger directement dans une population anglophone.
Mais malgré cela, ce qui m'a réellement fait faire les plus gros progrès, c'est le fait de me retrouver en environnement professionnel, dans un centre de recherche, avec des collaborateurs de toutes les nationalités (même si le centre en lui-même était à quatre kilomètres de mon domicile). L'anglais était donc de rigueur vis-à-vis de toutes les personnes dont le français n'était pas la langue native.
J'y suis entré en étant capable de comprendre mon interlocuteur mais en répondant en français. À peine un an plus tard, j'avais acquis un anglais courant. En 2007, au terme d'études d'ingénieur en partenariat (études à l'âge adulte en alternance et en convention avec sa propre boîte), j'ai obtenu 955 au TOEIC. Ça ne fait toujours pas de moi un native speaker ni ne me permet de prétendre en l'état au Cambridge Certificate, par exemple, mais j'ai maintenant suffisamment de confiance en moi pour téléphoner à une hotline située aux États-Unis, par exemple.
Enfin, aujourd'hui, il y a Youtube. Donc il est très facile, si on le souhaite, d'écouter en permanence des contenus en anglais ou en américain (surtout), qui soient tout autant des émissions formatées pour la télévision que des témoignages de particuliers qui font leur propre chaîne. Et plus récemment, il m'est arrivé de faire plusieurs sous-titres pour les épisodes de Veritasium, MinutePhysics ou 3Blue1Brown, mais d'autres aussi. Bon, un peu moins ces temps-ci parce que si on veut le faire sérieusement, en étant sûr de ce que l'on écrit, sans faire de contresens, en soignant son français, sa typologie, en utilisant l'UTF-8 et en ajustant bien les blocs pour qu'ils restent agréables à lire quand ils se succèdent, il faut 1h30 pour traduire une minute de vidéo.
Tout ceci fait que mon anglais est surtout de l'américain, mais c'est très bien comme ça.
Aujourd'hui, je pratique en traduisant entre autres les diatribes de Linus dans les annonces des releases -rc du noyau. :)
Effectivement, j'ai beaucoup aimé cette scène également et surtout sur la forme, comme tu l'expliques.
Pourtant, ce n'est pas tant le fait que ce soit une attaque kamikaze en soi qui faisait la beauté de la chose, mais effectivement les effets employés et surtout choisis. C'était éloquent comme peut l'être une jolie fin de chapitre dans un livre bien écrit, et les cinéphiles savent combien les passages cultes des grands romans, quand ils sont purement narratifs, sont difficiles à retranscrire à l'écran.
Pourtant, une grande partie de ces effets ne sont pas originaux. Les scènes « violentes » où le silence annonce le bruit, comme le tonnerre, ont été plusieurs fois employées, mais sa durée dans cette scène-là a été mûrement choisie pour qu'elle se termine juste après que les spectateurs aient totalement pris acte en leur for intérieur de la fin du cycle qu'elle impliquait.
Je pense que les cinéphiles qui ne sont justement pas fans de Star Wars l'auront beaucoup apprécié aussi s'ils ont la patience d'attendre jusque là.
L'idée était intéressante, d'ailleurs : un appareil où l'on décolle « allongé », comme dans les fusées lunaires, et où on adopte très vite sa position normale. Mais tout le monde l'avait immédiatement nommé de la même façon, pour les mêmes raisons. Du coup, c'est plus qu'une autoparodie : c'est un joli tour joué aux spectateurs.
Et en effet, c'était une bonne idée mais à condition que ça ne dépasse pas les deux secondes que dure la scène. Et ça a été bien tourné de ce côté…
Moi pas. Certes, la scène en question a bien été enjolivée mais buter d'un coup la princesse Leïa des origines de la Saga de cette façon, ça aurait paru un peu trop rapide aux fans et ils auraient eu raison. A fortiori si, en plus, ce n'était même pas ce qui était prévu au départ.
Sans compter qu'ils ont fait exactement le même coup à Han Solo (qui, dans la vie réelle, devait en avoir marre) et que c'est une des principales faiblesses de l'épisode VII.
N'empêche qu'à ce stade, c'est Luke Skywalker, Han Solo et Leïa (en vrai) qui sont partis. Si on suit cette logique, ils leur reste à buter C3PO et R2D2. Ce serait décevant mais inattendu. :)
Ouille ! C'est vrai que ça commence à faire beaucoup. En effet, la dernière fois que j'en ai eu un, c'était il y a cinq-six ans également.
Maintenant, sur une publication quotidienne offerte et qui, en plus, n'est pas destinée à être conservée, ça ne me dérange pas trop. Les deux pleines pages en couverture, j'avais l'habitude de les sauter immédiatement et, en fait, elles servent surtout à protéger le contenu de la pluie. :-)
Pour le reste, l'avantage par rapport au web est qu'on est sûr que la pub ne va pas recouvrir le contenu, qu'on ne va pas avoir de vidéo en lecture automatique dès qu'on tourne la page, ni de mention « votre contenu dans n secondes ». De ce côté, ça fait un point pour la publication papier.
Avec ça, la période se prête un peu à ça aussi. J'ai noté une augmentation palpable de spams dans mes boîtes e-mail également. J'imagine que ça va se calmer quand même un peu après les fêtes.
[^] # Re: bien choisir son clavier logiciel
Posté par Obsidian . En réponse au message émuler les touches clavier "<" et ">" . Évalué à 7.
Probablement un produit de la gamme « Big Q » :)
[^] # Re: login
Posté par Obsidian . En réponse au journal Tiens ? Voilà Nextcloud Talk !. Évalué à 4.
Même ça, ça devient difficile à trouver !
[^] # Re: Les 8 bits
Posté par Obsidian . En réponse au message Basic, Logo ou alternative. Évalué à 3.
C'était en ROM, et c'est ce qui est intéressant. Il n'y avait donc pas de système d'exploitation à charger au préalable mais, à contrario, il n'y avait rien d'utilisable en soi intégré directement à l'ordinateur non plus, qui ne servait donc que de plateforme de lancement. Comme on ne pouvait faire de programmation — de fait — comme exposé ci-dessus et que c'était encore limite pour un usage professionnel, et comme par ailleurs l'Atari ST avec un bon processeur graphique (avec l'équivalent d'un Copper) et une puce sonore caractéristique, et bien il servait principalement de plateforme de jeu, avec des disquettes bootables la plupart du temps, sinon lancées depuis le bureau GEM qui donc, ne servait à rien la plupart du temps.
Et pourtant, il a été extrêmement populaire ! En ce sens, c'était un peu l'équivalent avec clavier de la Playstation qui sortira quelques années plus tard (même s'il se rêvait en concurrent du Mac).
Ce qui me fascinait, à l'époque, c'est que pour moi, en ce temps, chaque machine avait son architecture propre et donc sa propre interface utilisateur (quelle qu'elle soit, d'ailleurs, bureau ou interpréteur). Et là, non seulement GEM ressemblait beaucoup au Mac (on peut lire aujourd'hui que ce n'était pas fortuit) mais c'était quelque chose que j'avais vu en premier lieu… sur PC ! Avant Windows (à partir de 3.0) mais surtout sur une machine où l'on utilisait principalement DOS ! Il faut dire que, sans disque dur, il fallait lancer le DOS, puis changer de disquette et lancer GEM, puis changer de disquette et lancer le logiciel qui nous intéressait. Donc, ça limitait un peu l'intérêt… mais j'avais fini par le trouver sur une de nos disquettes (5'1/4, 360Ko) et ce justement parce notre compatible PC un peu miteux (de marque « PC Land » à l'époque) ne faisait pas bien tourner MS/DOS, mais fonctionnait parfaitement avec… DR/DOS, de Digital Research, donc.
Le plus drôle, c'est que je m'aperçois que la boîte de 5'1/4 est toujours sur mon étagère. Ça fait donc 20 ans qu'elle n'a pas bougé. ^ ^
[^] # Re: Les 8 bits
Posté par Obsidian . En réponse au message Basic, Logo ou alternative. Évalué à 3.
C'est à ça que je pensais aussi, effectivement, mais comme je ne les ai jamais essayés, je ne me suis pas prononcé sur ce point non plus. En revanche, j'ai les mêmes craintes que toi, parce que si on constate que beaucoup de monde maîtrise encore la chose, je me suis aperçu que la totalité ou presque des personnes concernées sont justement les gens qui ont connu l'époque des huit bits ou, en tout cas, qui ont commencé sur autre chose qu'un PC ou Mac récent.
[^] # Re: Les 8 bits
Posté par Obsidian . En réponse au message Basic, Logo ou alternative. Évalué à 3.
On utilisait le bureau GEM :) avec son magnifique fond vert.
[^] # Re: Les 8 bits
Posté par Obsidian . En réponse au message Basic, Logo ou alternative. Évalué à 4.
Pour les microcontrôleurs, c'est certain. C'est ce qui s'en rapproche le plus aujourd'hui (même si les microcontrôleurs existaient déjà à cette époque et étaient à peu près du même niveau de puissance).
Le mode réel sur 16 bits, c'était plus simple aussi, même si à l'époque on s'arrachait les cheveux pour comprendre à quoi ça correspondait quand on était habitués aux « banques » de mémoire paginée. Et surtout : c'était déjà du PC. C'était quand même intéressant de pouvoir constater qu'un ordinateur n'est pas nécessairement un ersatz de l'IBM PC et de son 8086. En plus, à ce stade, on parle déjà d'assembleur et pour le coup, le grand débat de l'époque, c'était l'opposition Intel vs. Motorola. On disait que les premiers avaient été pensés par des électroniciens, les seconds par des programmeurs.
Du coup, même si on a eu toute la vague des Atari ST/Falcon vs Amiga, les huit bits branchés sur le téléviseur familial (ou déjà sur leur propre avec les Amstrad CPC) étaient vraiment une époque particulière, ne serait-ce parce que chaque machine était en elle-même une architecture propre et distincte des autres, même (et surtout) si tous les ordinateurs fonctionnent suivant le même principe. C'était vraiment la même différence qu'il pouvait y avoir entre un avion de ligne et un avion de chasse.
Oui, le mode X aussi, toussa. Mais là encore, c'est le contraire même de ce que l'on parle, puisqu'il s'agit déjà d'assembleur sur PC. Note que l'assembleur, c'est génial en soi, même sur PC, mais ce n'est pas l'objet de ce qui nous intéresse. Quand tu faisais LINE en BASIC, tu mettais le numéro de couleur à la fin. Du coup, que tu disposes de 16 couleurs ou de 4294967296, ça ne changeait pas la syntaxe du langage, et ça ne change pas non plus celle des langages actuels.
Oui, vraiment.
Quand tu allumais un MO5 ou un CPC 6128, tu tombais immédiatement sur le BASIC. Il y avait environ une demi-seconde d'initialisation. Quand tu allumais un MO6 ou un TO8, tu tombais sur une page d'accueil où tu tapais un chiffre qui t'orientait immédiatement vers le BASIC de ton choix parce qu'il en proposait deux, ou vers de menus utilitaires, le tout étant contenu en ROM. Et tout cela parce que pendant très longtemps, les ordinateurs personnels, y compris PC, n'étaient pas dotés de disques durs.
Oui mais tes machines étaient-elles des compatibles PC ? On rappelle bien que PC veut dire « Personal Computer » et que c'est à la base une marque et un modèle déposé d'IBM. Ça n'a jamais été un nom commun. Comme ils ont (volontairement) laissé leurs concurrents les imiter, ceux-ci ont dès le départ produit des ordinateurs « compatibles PC » (ou « compatible IBM », comme on le disait à l'époque) mais c'était une hypocrisie avouée dès le départ : il ne s'agissait pas d'une architecture complètement indépendante mais capable d'exécuter les programmes prévus pour l'IBM, mais bien d'un clone, à chaque fois.
C'est quand même malheureux parce que c'est à une époque où l'informatique n'a jamais été aussi répandue qu'il y a le moins de diversité et, paradoxalement, parce qu'il n'existe justement plus d'ordinateur grand public non-PC, hormis le mac, les gens ne sont plus capables de s'apercevoir qu'il s'agit bien du même, même s'il a tellement évolué en 35 ans qu'il n'a presque plus rien à voir avec l'original.
C'est vraiment un destin à la John Spartan : « et alors maintenant, tous les restaurants sont des Pizza Hut ». On en rigole en voyant le film mais il est de fait que c'est ce qui est arrivé à l'informatique grand public et quand on sait l'importance que ça a aujourd'hui, ça n'est pas réjouissant.
BIOS et POST sont des terminologies propres à l'IBM PC, même si les autres ordinateurs étaient dotés en ROM de routines d'initialisation similaires puisqu'on ne peut pas s'en passer.
Le PC, c'est vraiment le Vigor de l'informatique : une machine industrielle reconditionnée à petite échelle pour l'adapter à l'utilisateur individuel. Sur les grosses machines, la procédure d'initialisation n'avait pas beaucoup d'importance parce qu'elles sont vouées à rester allumées en permanence et parce qu'elles font souvent, par ailleurs, l'objet d'un contrat de maintenance une fois vendues aux structures auxquelles elles sont destinées. Sur AS/400, le démarrage s'appelle même « IPL » (Initial Program Load).
Le PC, par contre, outre le fait qu'il a été dès le départ une grosse boîte lourde, imposante et majoritairement vide, était doté d'équipements qui, pendant très longtemps, ne servaient vraiment à rien. Par exemple, le ventilateur. Aujourd'hui, ce serait difficile de faire sans mais à l'époque, la technologie était guère différente de celle des huit bits et même l'Amiga 1200, qui était un 32 bits sorti en 1992 et contemporain du 486 (68020, pas x86) s'en passait fort bien.
Pendant longtemps, le PC m'est apparu comme étant à la fois la machine la plus chère et la plus mal conçue, jusqu'à ce que ces défauts soient compensés par un moteur de fusée.
Oui, il me semblait que certains étaient moins adaptés que d'autres à cet usage mais comme, à y réfléchir, je n'ai pas d'exemple probant en tête, je ne te contredirai pas sur ce point.
Oui mais là encore, c'est l'opposé de ce qui nous intéresse ici. Excel propose d'ailleurs le VBA, dont on pense ce que l'on veut, mais qui permet effectivement de faire pas mal de choses dans une feuille de calcul (à commencer par des âneries). Mais il s'agit quand même d'un logiciel dédié à une utilisation précise, qu'il faut lancer dans un environnement déjà opérationnel, et par des utilisateurs déjà grands.
À contrario, le PC, le Minitel et le TO7 sont sortis à la même époque, qui correspondait pour moi à la classe de CP (où on était venu nous présenter le dernier) et mes premiers vrais programmes, c'était en CM2 sur les machines du plan Informatique pour tous. L'idée est de faire en sorte que l'interface par défaut, même à destination des plus jeunes, puisse permettre de faire ce genre de choses sans que ce soit obligatoire.
Oui mais ça, ça s'appelle de l'expérience. :)
La notice a disparu aussi parce qu'il n'y a plus grand chose à y mettre. Mais c'est surtout parce qu'on peut l'installer directement dans l'interface si on a un ordinateur qui démarre normalement. Et là, on pourrait y mettre les mêmes indications.
# Les 8 bits
Posté par Obsidian . En réponse au message Basic, Logo ou alternative. Évalué à 8. Dernière modification le 12 janvier 2018 à 11:26.
C'est exactement l'impression que j'en ai moi aussi et plus le temps passe, plus je trouve que l'ère des 8 bits a été une époque bénie pour apprendre l'informatique. Et il ne s'agit pas d'une vaine nostalgie mais bien d'un temps particulièrement propice que j'ai été heureux de vivre.
Et c'est vrai que les machines de l'époque étaient très faciles à aborder : quand on les allumait, elle étaient immédiatement utilisables (pas de temps de boot), elle ne faisaient aucun bruit (sauf si on leur demandait d'en faire, bien sûr) et on tombait directement dans le BASIC (qui était en fait une caractéristique du premier PC XT qui, lui, paradoxalement, a vite abandonné la chose).
Ce qui était intéressant, c'est que le BASIC était présenté d'emblée comme langage de programmation (ce qui est effectivement sa vocation), mais qu'il servait à la fois d'interface utilisateur et de système d'exploitation. Et surtout : il était doté d'un mode direct ! On pouvait exécuter directement une commande et avoir son résultat, mais on pouvait également commencer à écrire un programme en mémoire en utilisant les numéros de ligne.
Du coup, on écrivait
PRINT "BONJOUR"et on avait directement le résultat, on tapait BOX et on avait un carré à l'écran. Non seulement le néophyte avait tout de suite une réaction de sa machine la première fois qu'il la sollicitait, mais on pouvait très rapidement enchaîner tout de suite sur des choses plus élaborées… avant même de connaître la commande pour sauver son programme ! Chose qui, d'ailleurs, était paradoxalement compliquée surtout quand on utilisait des cassettes. :)De coup, même quelqu'un qui ne se servait de son ordinateur que pour lancer ses logiciels faisait de fait de la programmation puisqu'il fallait au moins faire «
RUN"…"» pour les exécuter (ce qui était donc précisé sur l'étiquette, en général). Et ça, c'est très différent des machines actuelles où l'interface des OS est un « bureau », soit une chose effectivement conçue pour le travail en entreprise, à la base, puis à destination d'un « usager » plus qu'un opérateur.Du coup, il serait intéressant de réintroduire un standard (oui, je sais, XKCD) qui permettrait de faire la même chose, à savoir une interface minimaliste (même une ligne de commande) mais disponible partout, qui contiendrait par défaut un nombre d'instructions limité fixe mais parfaitement défini, d'usage général (tracer des figures, jouer du son, lancer une application, écrire à l'écran) et qui serait immédiatement utilisable sans même avoir à faire le moindre « @import ». En précisant que cela pourrait quand même s'appuyer sur l'existant, qui continuerait à être utilisé normalement en dehors de ce contexte particulier. Il faudrait aussi minimiser tout le sucre syntaxique pour ces commandes élémentaires (genre pas de point-virgule, ni de tabulations obligatoires).
C'est déjà en substance ce que fais le shell dans une certaine mesure et c'était l'idéal imaginé au départ par pas mal de langages de scripts, et il y a bien des consoles Javascript dans un certain nombre d'environnement (par exemple Looking Glass dans GNOME 3 avec Alt+F2 puis « lg ») mais si c'était partout et immédiatement accessible, on pourrait mettre ça dans la notice d'un ordinateur neuf (ce qui se faisait en fait à l'époque) et ce serait la première chose que découvriraient les nouveaux utilisateurs.
[^] # Re: Il est arrivé !
Posté par Obsidian . En réponse au journal D'un kernel panic à un patch…. Évalué à 3.
Hmm. J'avais répondu à ce commentaire et il semblerait qu'il ait disparu. Bizarre…
Je crois bien que j'ai parlé trop vite : ton patch, comme ton journal, est daté du 12 novembre 2017. Je ne sais pas si cela correspond à ton propre commit en local où si c'est la date à laquelle tu l'as soumis, mais toujours est-il que c'est aussi exactement le jour de la sortie du noyau 4.14.
Donc, normalement, c'était aussi le début de la fenêtre d'intégration des patches qui dure typiquement 14 jours (deux semaines, du lundi au… lundi). Bon, il est entendu qu'en principe, un patch doit d'abord passer par linux-next et y être intensivement testé mais étant donné la chose, on aurait pu faire ça en accéléré et faire tenir toute la procédure dans les deux semaines critiques.
Normalement, la fenêtre a dû se refermer le 25 au soir et la commit date de ton patch est marquée du… 29 :-\ Je ne sais pas si c'est délibéré (dans le sens où le mainteneur doit se charger de faire intégrer les patches déjà en attente, puis s'occuper de préparer les nouveaux une fois la fenêtre refermée) ou si c'est parce que ça a traîné mais quoi qu'il en soit, le noyau 4.15 doit sortir soit lundi prochain, soit dans dix jours. Donc, ce sera pour l'intégration du 4.16 à venir incessamment, mais il faudra bien te faire rappeler à leur bon souvenir pour être sûr que ce soit fait…
Reste à savoir si ce correctif critique va pouvoir être immédiatement rétroporté comme indiqué dans les directives présentées ailleurs, ou s'il va falloir attendre deux mois que le 4.16 sorte officiellement avant d'envisager la chose… et d'attendre ensuite la publication d'une nouvelle branche stable.
[^] # Re: On va enfin
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 5.
Si ça pullule, il y a des chances que ce soit des Zerg mais globalement, c'est bien ça. ^
[^] # Re: On va enfin
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 5.
D'ailleurs, on dirait bien que les derniers lamers ont disparu avec les disquettes. Ils ont été remplacés par les noobs…
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.
Oui mais justement : on est censé retrouver les MÊMES sommes, et c'est entre autres ce qui permet de travailler de façon décentralisée sans avoir besoin de coordonnateur.
Changer de fonction de hachage n'altère en rien le fonctionnement théorique du logiciel (ce qui, en soi, est la marque d'une conception très bien pensée) et serait relativement facile à implémenter. Par contre, ce serait un cauchemar pour les administrateurs systèmes car cela implique de migrer l'intégralité des objets d'un dépôt ET d'amender tous les commits puisque ceux-ci contiennent en clair la somme de leur ou de leurs parents. On ne pourrait pas se contenter de les renommer, donc.
Ensuite, la grosse difficulté viendrait du fait que tout dépôt basé sur l'ancienne somme serait incompatible avec la nouvelle. Il n'y aurait donc pas de transition douce : tous les acteurs d'un même projet seraient donc d'abord obligés de mettre leur version de Git à jour, puis de migrer tous leur dépôts avant de pouvoir continuer à travailler ensemble. Et cela ne concernerait pas seulement les développeurs actifs : toute personne ayant cloné le noyau sur kernel.org serait concernée.
Enfin, cela rendrait caduques toutes les sommes publiées sous forme texte, que soit par mail, sur Usenet, sur le Web et sur les différents outils collaboratifs, que ce soit la LKML ou les commentaires des tickets Github. En outre, et par définition, les dépôts clonés cesseraient d'être des clones, puisqu'il pourrait y avoir plusieurs versions différentes d'un même objet : non seulement les sommes d'un commit serait différentes selon la fonction choisie, mais leur propre contenu le serait aussi puisqu'ils se référeraient à des sommes différentes. Il n'y aurait pour ainsi dire plus rien d'officiel pour indiquer facilement qu'ils sont les homologues de ceux calculés avec l'ancienne somme.
Le pire, c'est qu'il n'y aurait pas moyen de faire une conversion de l'ancienne somme vers la nouvelle a posteriori. Il faudrait dresser « pour l'histoire » une table de correspondance au moment où la migration se fait et ne surtout pas la perdre après cela.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 6.
Je ne suis pas allé vérifier si c'est vrai ou faux, donc je ne me prononcerai pas sur le fond, mais si c'est le cas, alors à moins d'avoir une MMU extrêmement performante (ce qui est peut-être le cas aussi), alors cela mettrait complètement à mal l'exécution spéculative puisqu'elle serait obligée d'attendre sa décision avant d'être exécutée. Donc, ce ne serait plus de l'exécution spéculative. Et c'est un problème puisque cela concernerait TOUS les accès mémoire, aussi bien en lecture qu'en écriture, puisqu'il est par définition impossible de savoir si un accès est en dehors de sa plage avant de l'avoir examiné (sauf modes indexés spéciaux avec un offset notoirement local, parce que défini dans un petit registre (par exemple, sur 8 bits)). Donc, ce serait extrêmement fréquent dans un programme.
Reste à savoir si c'était quelque chose qui était réellement imaginable à l'avance, surtout au moment où les premières puces à pipeline ont été produites, puisque les rares qui sont encore en fonctionnement aujourd'hui sont menacées aussi. Autrement dit : est-ce vraiment une faute grave du constructeur compte tenu de son expérience et de son expertise, ou est-ce vraiment la faute à pas de chance ?
Parce qu'à ce compte-là, des compromissions de ce genre, on en a connu beaucoup dans le domaine logiciel mais, elles, peuvent être facilement patchées. Les générations de collisions pour MD5 et SHA1, par exemple, sont dans leur genre des petites bombes elles aussi et la dernière concernait particulièrement Git. Alors, certes, il « suffit » de passer à une nouvelle fonction de hachage pour pallier le problème jusqu'à ce qu'elle soit cassée à son tour, mais étant donné la diffusion du logiciel, il n'est pas concevable de réécrire toutes les sommes de tous les objets de tous les dépôts du monde, qui parfois contiennent des objets qui sont aussi vieux que Git lui-même, à commencer par le dépôt du noyau Linux. La seule solution consisterait à faire cohabiter les deux versions en marquant la première comme dépréciée.
Ici, c'est particulièrement grave parce que la faille se produit à très bas niveau, et a donc un impact très large en conséquence mais étant donné la complexification toujours plus forte des systèmes et le point auquel ils sont répandus, je pense qu'il va falloir s'attendre à faire face à ce genre d'incident à intervalles relativement régulier.
[^] # Re: Comment une faille peut-elle toucher plusieurs processeurs de plusieurs fondeurs ?
Posté par Obsidian . En réponse à la dépêche Deux failles critiques : Meltdown et Spectre. Évalué à 10.
Pour ce que j'ai lu de la même page, c'est PRESQUE cela, en effet, mais à quelques détails près et qui feraient, entre autres, que l'approche par indexation en particulier ne pourrait justement pas marcher. Par ailleurs, tout repose sur le fait que l'on mesure un temps d'accès pour savoir si une donnée est ou non dans le cache. Et comme la réponse à cette question est forcément « oui » ou « non », ça implique de distiller l'info bit par bit, d'où l'exemple de la page Wikipédia et de son bit 0.
En gros :
La page précise qu'il vaut mieux éviter les branchement conditionnels pour faire ces calculs pour éviter de mettre en branle les mêmes mécanismes prédictifs (en gros, faire le calcul avec des opérateurs logiques plutôt qu'avec des « if »).
On se moque, en fait, de ce que contiennent les deux adresses légitimes mais toute l'astuce s'appuie sur le fait que la segfault va prendre un certain temps pour être déclenchée, et que les points 3, 4 et 5 auront le temps d'être honorés même si le CPU fait marche arrière ensuite si elle l'est. Après, sachant qu'on avait au départ vidé le cache, le point numéro 5 l'aura rechargé quand même. Donc, si l'une des pages est lente à accéder et que l'autre est rapide, on peut en déduire la valeur du bit recherché.
Évidemment, c'est très sioux et tout le problème réside dans le fait que ce n'est pas du tout un problème algorithmique. Tout microprocesseur doté d'un système de protection, d'un mécanisme de prédiction ET utilisant de la mémoire cache est potentiellement affecté.
On pourrait déjà circonvenir au problème en invalidant TOUT le cache en cas de segfault, mais on pourrait encore contourner la chose en faisant lire les adresses concernées par un thread ou un processus distinct qui, lui, n'aurait rien à se reprocher. Et qui pourrait presque le faire, en le synchronisant bien, avant le déclenchement de la segfault. C'est déjà compliqué à gérer en soi, mais ça devient particulièrement gênant sur les multicœurs et les systèmes distribués.
Et là où ça devient vraiment désespérant, c'est qu'apparemment la solution envisagée est : « puisque c'est une faille qui s'appuie sur la mesure des performances, alors on va sacrifier les performances ».
[^] # Re: Facile !
Posté par Obsidian . En réponse au message [HELP] programme python. Évalué à 3.
Pourquoi « récursive » d'ailleurs ? C'est purement itératif, ce genre de chose…
# Éditeur spécifique ?
Posté par Obsidian . En réponse au journal Marie-Stéphanie, Markdown, GIT, Jekyll et Jenkins. Évalué à 4.
Donc, c'est VIM. D'accord.
(Ok, j'aurais pu attendre demain…)
# Via ma boîte
Posté par Obsidian . En réponse au journal Votre rapport à l’anglais ?. Évalué à 2.
Bon, j'arrive un peu après la bataille, mais j'étais occupé à d'autres choses plus techniques (que je vais produire ici même quand j'aurai fini).
Techniquement, j'ai appris l'anglais au collège en classe de sixième, comme pas mal de monde. C'était en 1987, ce qui ne nous rajeunit pas. Je n'étais pas franchement mauvais, j'aimais ça, mais je n'ai jamais été un premier de classe non plus. J'ai donc pu pendant très longtemps me revendiquer d'un simple « anglais scolaire ». Ça me permettait tout juste de le baragouiner un peu si jamais je devais me faire comprendre quelque part (dans un aéroport, par exemple) mais guère plus côté oral. Par contre, ça me permettait de le lire relativement facilement, et la programmation exercée depuis « le plus jeune âge » sur les MO6 de l'école m'avait permis d'aborder facilement l'anglais technique.
Par la suite, j'ai commencé par essayer de lire des romans en anglais avec un dictionnaire à côté. C'est une bonne idée en soi mais franchement, pour chaque page du livre, on se réfère dix fois au dico et ça devient vraiment ingérable. Mais ça fait son effet quand même à la longue.
Le premier coup d'accélérateur est venu avec les DVD quand, après avoir vu les épisodes qui me plaisaient le plus, je les revisionnais en version originale sous-titrée (VOST). À l'époque, j'essayais aussi d'aller voir les films en VO au cinéma du quartier mais à défaut d'un niveau suffisant, on reste le nez collé sur les sous-titres, on se concentre ni sur le film ni sur l'histoire et au final, on en ressort fatigué sans avoir gagné grand chose. Mais les séries ont fini par donner des résultats et une jeune prof d'anglais connue plus tard nous avait confirmé que c'était ce qui, à l'usage, donnait le plus de résultats.
Quand j'ai commencé à me sentir suffisamment à l'aise en lecture, j'ai commencé à faire des traductions. En 1997, j'avais entrepris de traduire le painless guide to CRC error detection algorithms, à l'époque où l'ADSL était expérimentale et où on partageait encore l'info en s'envoyant des CD.
Les moteurs de recherche étaient déjà au point mais quand Google a commencé à se démocratiser, c'est devenu plus facile d'accéder à beaucoup de documents en anglais ciblant les centres d'intérêts mais surtout, il est devenu très facile de voir si tel ou tel idiome existait ou non, et la recherche par image sur un terme en anglais a permis de constater instantanément quelle est l'acception la plus fréquente d'un mot dans le langage courant. Et ça, c'est devenu un vrai atout si on ne peut pas s'immerger directement dans une population anglophone.
Mais malgré cela, ce qui m'a réellement fait faire les plus gros progrès, c'est le fait de me retrouver en environnement professionnel, dans un centre de recherche, avec des collaborateurs de toutes les nationalités (même si le centre en lui-même était à quatre kilomètres de mon domicile). L'anglais était donc de rigueur vis-à-vis de toutes les personnes dont le français n'était pas la langue native.
J'y suis entré en étant capable de comprendre mon interlocuteur mais en répondant en français. À peine un an plus tard, j'avais acquis un anglais courant. En 2007, au terme d'études d'ingénieur en partenariat (études à l'âge adulte en alternance et en convention avec sa propre boîte), j'ai obtenu 955 au TOEIC. Ça ne fait toujours pas de moi un native speaker ni ne me permet de prétendre en l'état au Cambridge Certificate, par exemple, mais j'ai maintenant suffisamment de confiance en moi pour téléphoner à une hotline située aux États-Unis, par exemple.
Enfin, aujourd'hui, il y a Youtube. Donc il est très facile, si on le souhaite, d'écouter en permanence des contenus en anglais ou en américain (surtout), qui soient tout autant des émissions formatées pour la télévision que des témoignages de particuliers qui font leur propre chaîne. Et plus récemment, il m'est arrivé de faire plusieurs sous-titres pour les épisodes de Veritasium, MinutePhysics ou 3Blue1Brown, mais d'autres aussi. Bon, un peu moins ces temps-ci parce que si on veut le faire sérieusement, en étant sûr de ce que l'on écrit, sans faire de contresens, en soignant son français, sa typologie, en utilisant l'UTF-8 et en ajustant bien les blocs pour qu'ils restent agréables à lire quand ils se succèdent, il faut 1h30 pour traduire une minute de vidéo.
Tout ceci fait que mon anglais est surtout de l'américain, mais c'est très bien comme ça.
Aujourd'hui, je pratique en traduisant entre autres les diatribes de Linus dans les annonces des releases -rc du noyau. :)
[^] # Re: Je suis sûr qu'il y aurait un gros pourcentage pour...
Posté par Obsidian . En réponse au sondage Travailler pour les GAFAM. Évalué à 4.
C'est-à-dire que des amazones, y en a plus beaucoup non plus…
[^] # Re: Barre de recherche
Posté par Obsidian . En réponse à la dépêche Firefox Quantum, première partie du projet Quantum de Mozilla, est disponible. Évalué à 4.
Ce serait plutôt Trifouillis-les-Ouailles, en l'occurrence. :-)
[^] # Re: LA scène de l'espace
Posté par Obsidian . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 2.
Effectivement, j'ai beaucoup aimé cette scène également et surtout sur la forme, comme tu l'expliques.
Pourtant, ce n'est pas tant le fait que ce soit une attaque kamikaze en soi qui faisait la beauté de la chose, mais effectivement les effets employés et surtout choisis. C'était éloquent comme peut l'être une jolie fin de chapitre dans un livre bien écrit, et les cinéphiles savent combien les passages cultes des grands romans, quand ils sont purement narratifs, sont difficiles à retranscrire à l'écran.
Pourtant, une grande partie de ces effets ne sont pas originaux. Les scènes « violentes » où le silence annonce le bruit, comme le tonnerre, ont été plusieurs fois employées, mais sa durée dans cette scène-là a été mûrement choisie pour qu'elle se termine juste après que les spectateurs aient totalement pris acte en leur for intérieur de la fin du cycle qu'elle impliquait.
Je pense que les cinéphiles qui ne sont justement pas fans de Star Wars l'auront beaucoup apprécié aussi s'ils ont la patience d'attendre jusque là.
[^] # Re: Fer à repasser de l'espace
Posté par Obsidian . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 4.
Il faut aussi signaler que c'est une référence directe au vaisseau de Boba Fett de la Trilogie originale (et du probable meilleur épisode de tous jusqu'ici), à 3m19s : https://www.youtube.com/watch?v=1UjVUZhaDiI&feature=youtu.be&t=3m19s
L'idée était intéressante, d'ailleurs : un appareil où l'on décolle « allongé », comme dans les fusées lunaires, et où on adopte très vite sa position normale. Mais tout le monde l'avait immédiatement nommé de la même façon, pour les mêmes raisons. Du coup, c'est plus qu'une autoparodie : c'est un joli tour joué aux spectateurs.
Et en effet, c'était une bonne idée mais à condition que ça ne dépasse pas les deux secondes que dure la scène. Et ça a été bien tourné de ce côté…
[^] # Re: star wars et réalisme
Posté par Obsidian . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 4.
Pas la peine : aucun risque qu'il parle. :)
[^] # Re: Tu touches juste !
Posté par Obsidian . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 3.
Il est déjà très laid. Ça devrait suffire. :)
[^] # Re: star wars et réalisme
Posté par Obsidian . En réponse au journal Parlons un peu de Star Wars VIII - Les derniers Jedi (Attention : SPOILERS). Évalué à 2.
ATTENTION SPOILERS ### ATTENTION SPOILERS ### ATTENTION SPOILERS ### ATTENTION SPOILERS ### ATTENTION SPOILERS
Moi pas. Certes, la scène en question a bien été enjolivée mais buter d'un coup la princesse Leïa des origines de la Saga de cette façon, ça aurait paru un peu trop rapide aux fans et ils auraient eu raison. A fortiori si, en plus, ce n'était même pas ce qui était prévu au départ.
Sans compter qu'ils ont fait exactement le même coup à Han Solo (qui, dans la vie réelle, devait en avoir marre) et que c'est une des principales faiblesses de l'épisode VII.
N'empêche qu'à ce stade, c'est Luke Skywalker, Han Solo et Leïa (en vrai) qui sont partis. Si on suit cette logique, ils leur reste à buter C3PO et R2D2. Ce serait décevant mais inattendu. :)
ATTENTION SPOILERS ### ATTENTION SPOILERS ### ATTENTION SPOILERS ### ATTENTION SPOILERS ### ATTENTION SPOILERS
# Explications…
Posté par Obsidian . En réponse au message Programmation linéaire. Évalué à 6.
Bonjour,
Tu peux déjà commencer en précisant, pour ceux qui ne le savent pas, que la programmation linéaire n'a rien à voir avec la rédaction des logiciels.
Ensuite, tu pourrais nous exposer brièvement ce que tu as fait jusqu'ici et ce qui te bloque en particulier.
Bon courage.
[^] # Re: Journal bookmark ultime
Posté par Obsidian . En réponse au journal Un comparatif de banques en ligne sauvage apparaît !. Évalué à 4.
Ouille ! C'est vrai que ça commence à faire beaucoup. En effet, la dernière fois que j'en ai eu un, c'était il y a cinq-six ans également.
Maintenant, sur une publication quotidienne offerte et qui, en plus, n'est pas destinée à être conservée, ça ne me dérange pas trop. Les deux pleines pages en couverture, j'avais l'habitude de les sauter immédiatement et, en fait, elles servent surtout à protéger le contenu de la pluie. :-)
Pour le reste, l'avantage par rapport au web est qu'on est sûr que la pub ne va pas recouvrir le contenu, qu'on ne va pas avoir de vidéo en lecture automatique dès qu'on tourne la page, ni de mention « votre contenu dans n secondes ». De ce côté, ça fait un point pour la publication papier.
Avec ça, la période se prête un peu à ça aussi. J'ai noté une augmentation palpable de spams dans mes boîtes e-mail également. J'imagine que ça va se calmer quand même un peu après les fêtes.