lasher a écrit 2743 commentaires

Je réponds très tard, mais selon moi, ce qu'on apprend sur la documentation de code, etc., vient principalement pour 2 raisons:

1. Tout le monde n'est pas un real programmer¹: pas mal de gens sont « moyens » en termes de programmation, et ont besoin d'une doc « à part » pour pouvoir rapidement trouver la doc des interfaces².
2. Il y a des environnements où le turnover est plutôt énorme (et en France c'est encore plus vrai) : sans une doc un minimum plus détaillée que la « méta-doc » évoquée, tu te retrouves potentiellement avec une catastrophe ambulante…

La combinaison des deux points précédents peut être fatale je pense.

Ce n'est pas exactement la même situation : comme je le dis un peu plus bas :

• Pendant toute la période où parcoursup était ouvert, tout était ouvert 24h/24 (nuit comprise donc)
• Au mieux, on pourrait imaginer que si la date limite est le jour X du mois Y, alors on peut soumettre jusqu'à 23:59:59 au jour X.
• En pratique, on doit considérer que tout le monde n'a pas forcément accès à un PC hors heures « normales » de bibliothèques, etc., donc avoir une deadline qui correspond aux heures administratives ne me semble pas complètement déconnant. Ça correspond possiblement aussi aux horaires où du personnel peut régler des problèmes/pannes si jamais elles ont lieu, car encore officiellement au bureau.

L'image que tu postes n'est pas franchement pertinente selon moi : il ne faut pas oublier qu'on parle du dernier jour pour la soumission de vœux d'élèves, et en particulier de la dernière heure (ou des deux dernières heures). Alors oui, les élèves (et les étudiants ­— et, soyons honnêtes, beaucoup d'adultes en règle générale) s'y prennent souvent à la dernière minute, mais autant on peut conspuer l'administration car elle n'a pas prévu le cas de grosse montée en charge en prévision du dernier jour (et du coup il s'agit surtout de prévoir que pendant 8h d'affilées, on aura une grosse charge quoi qu'il arrive), autant dire « ouin c'est pas juste, moi je peux me coucher plus tard que d'autres » ça me semble un peu ridicule : parcoursup était ouvert dès le 22 janvier.

TL;DR: gueuler contre le SI de parcoursup car ils n'ont pas supporté la charge du dernier jour de soumission, je comprends. Gueuler contre le fait que ça se termine arbitrairement à 18h (heure où plus aucun personnel ne peut aider si y'a plantage/problème), je trouve que c'est un peu de la chouinerie.

Dans tous les cas, il ne s'agit pas de niveler par le bas, ni de nier leurs spécificités aux usagers (ce qui est le thème de l'image postée).

Pour faire vite : tu supposes que tout le monde a accès à un ordinateur avec une connexion internet (décente) h24. Sauf qu'on ne peut pas nécessairement faire cette supposition pour des particuliers dans le cas général.

D'ailleurs, je me souviens qu'il y a vingt ans quand j'ai utilisé l'équivalent de l'époque, l'échéance était à minuit. À 22h, le serveur (Minitel) était saturé mais à 23h30 il n'y avait plus de problème pour se connecter

Ça me semble raisonnable, mais il ne faut pas oublier que même il y a 20 ans, on pouvait louer/emprunter un minitel gratuitement aux P&T (pas d'abonnement) tant que c'était la version noir et blanc.

Pour donner un exemple dans un autre domaine : je donne cours en IUT. J'aimerais bien pouvoir supposer que tous mes étudiants ont un ordinateur (fixe ou portable) chez eux, et du coup leur dire « vous pourrez finir le TD [ou le TP] chez vous ». Sauf que je ne peux pas, car ce n'est pas équitable pour tous mes étudiants.

Enfin, il ne faut quand même pas oublier que toutes les autres nuits et tous les autres jours qui ont précédé la date limite on pouvait soumettre à n'importe quelle heure.

Tu as raison, mais après, typiquement, pour les JPO, les facs/prépas/etc. font exprès de les organiser en Décembre/Janvier/Février justement pour que ce soit encore « frais » dans la tête des lycéens et de leurs parents.

Concernant les choix entre prépa, STS, IUT, fac, etc., comme tu as 10 choix (sans compter les sous-choix dans une catégorie donnée), tu peux relativement facilement les inscrire. Il s'agit vraiment principalement d'un problème de méthode à la rache™.

C'est aussi vrai dans le supérieur, soit dit en passant. Enfin, pas moi, hein, mais les autres… O:-)

En l'occurrence, donner une deadline ferme, c'est aussi un problème d'équité/égalité devant tous les candidats : tout le monde est traité de façon égale. Parce que si on suit ton raisonnement, alors bon, franchement, 19h ou 20h, tant qu'il est pas 8h ou 9h du mat', heure à laquelle on va peut-être commencer à examiner les dossier, on s'en fout non (hint : non, on ne s'en fout pas) ?

Sauf s'il est de connivence avec d'autres collaborateurs (souvent passés) ou potes, un chercheur qui a son nom sur une publi, ça veut dire l'une des choses suivantes dans mon expérience :

• Il a effectué la majeure partie de la recherche (si c'est un « vieux » chercheur, ce serait étonnant — c'est à ça que servent les thésards [pour se former] et les jeunes profs [parce qu'ils n'encadrent pas forcément encore de thésards] !)
• Il a encadré ou dirigé une ou plusieurs personnes qui ont fait le travail en pratique (ça implique des réunions de travail, de faire des critiques constructives, etc.)
• Il est officiellement le directeur de thèse d'un des « vrais » auteurs du papier. C'est à différencier d'un « simple » encadrant : au moins en France (et dans d'autres pays aussi, comme en Chine par ex), être maître de conférences ne signifie pas qu'on a le droit de diriger la recherche d'un thésard de bout en bout. Il faut aussi avoir obtenu une HDR¹. Du coup dans plein de labos français, on a un directeur de thèse officiel (mais qui ne suit pas vraiment le travail du/des thésards), et des encadrants qui font le vrai boulot de formation². Sauf que du coup il faut bien que le directeur figure sur la liste des auteurs quand même, car c'est quand même souvent grâce à lui (enfin, à son nom) qu'un financement a pu être débloqué, un projet (et donc les sous qui vont avec) accepté, etc.

Un autre cas qui arrive de temps en temps : un des co-auteurs parle de sa recherche à quelqu'un (directement, ou bien lors d'un séminaire par exemple), et ce quelqu'un fait une remarque qui permet de débloquer une situation. Suivant le degré de pertinence de la remarque, et à quel point elle permet d'avancer sur le travail, ce genre d'aide peut être reconnu dans les remerciements en fin d'article, voire on peut proposer à cette personne d'être inscrite en tant que co-auteur (et généralement on lui donne alors un droit de regard sur l'article lui-même, et la personne peut aider à la rédaction).

EDIT: j'oubliais aussi le cas où il s'agit d'une collaboration entre différentes équipes ou labos, et où l'un des chercheurs n'a pas forcément un rapport direct avec la recherche, mais où les ressources permettant d'accomplir la recherche se situent dans son labo : nœuds de calcul (avec la partie sysadmin qui va bien), etc. (souvent ce genre de chercheur a aussi participé à la rédaction du dossier de demande de financement…).

Tout ceci étant dit, je connais des chercheurs qui continuent de chercher même à 80 ans passés, et qui publient encore en tant que premier auteur. Alors certes, leurs travaux les plus impressionnants ont été faits il y a plus de 40 ans, mais ils continuent d'améliorer leurs résultats incrémentalement (et pour au moins l'un d'entre eux, de coder eux-mêmes leurs simulateurs…).

D'ailleurs, J.Oliver se garde bien de se faire appeler journaliste (même si en pratique il fait sans doute un bien meilleur job que la plupart des journalistes US, au moins sur les sujets qu'il traite). Il se qualifierait sans doute plutôt d'humoriste…

OoOoOoh, je ne connaissais pas. Merci ! :)

Meltdown et Spectre sont si loin que ça dans les mémoires?

Du point de vue macro, les processeurs font effectivement ce qu'on leur demande : ils exécutent le code qu'on leur donne, et même s'ils utilisent la spéculation pour aller plus vite, les instructions exécutées qu'il ne fallait pas exécuter sont jetées avant que leur résultat ne soit visible pour l'utilisateur. Dans le cadre de Meltdown, le problème est réellement un « bug » de conception, car les processeurs Intel (et certains processeurs haut de gamme ARM) permettent de charger des pages noyau en cache en passant outre les bits indiquant qui a le droit de lire ce genre d'information¹. C'est donc un vrai gros défaut de conception qui dit fuck à la sécurité au nom de la performance (et qu'AMD a évité apparemment). Donc, même si ce n'est sans doute pas une faille voulue par Intel/ARM, c'est quand même un gros manquement en termes de conception.

Dans le cadre de Spectre, c'est différent : on se retrouve avec un algorithme d'exécution dans le désordre (l'algorithme de Tomasulo, qui se base sur les principes d'exécution par flot de données). L'exécution dans le désordre en elle-même n'est pas un problème : si j'ai des instructions qui mettent en œuvre des unités fonctionnelles différentes (UAL, FPU, possiblement des composants spécialisés pour accéder à la mémoire, etc.), du moment que ces instructions auraient été exécutées de toute façon, les exécuter dans le désordre pour gagner du temps n'est vraiment pas un problème. Ce qui est gênant en termes de sécurité, c'est la spéculation d'instructions, car on va chercher des informations au-delà des plages d'adressage autorisées pour un programme donné lors de branchements directs ou indirects, ce qui du coup court-circuite (pour les processeurs courants) droits d'accès.

Du coup autant Meltdown exploite une erreur relativement grossière de conception, autant pour Spectre c'est plus nuancé je trouve (ça n'empêche pas de devoir corriger les deux failles en question bien entendu).

C'est littéralement ce que nous nous disions dans mon labo y'a ~10 ans lorsqu'on a vu des papiers montrant qu'on pouvait récupérer les clefs privés de GnuPG en passant par des side-channel attacks sur le cache : « dans la vraie vie y'a trop de bruit sur un serveur à cause de tous les processus qui tournent pour que ça puisse marcher ». Et bim, 10 ans plus tard, Spectre et Meltdown arrivent.

En l'occurrence, la notion d'analyse du prédicteur de branchement et d'utilisations d'attaques par timing pour récupérer des infos du cache de données avait déjà été abordée dès 2005-2007. Voir ici par exemple.

EDIT: pas vu une autre réponse plus complète que la mienne…

Petite correction : Apple n'est pas « pas mal à l'origine de LLVM ». En fait ils ne le sont même pas du tout. Ils embauchent le mec qui a écrit LLVM, (grosse) nuance. LLVM en tant que tel est un compilateur qui a été financé par la National Science Foundation, sur la prémisse qu'il n'y avait pas de compilateur dont l'architecture était moderne et favorisait la recherche pour les techniques de compilation, et en particulier la recherche pour les transformations optimisantes indépendantes de l'architecture cible.

Par contre depuis, et en partie grâce/à cause du passage de GCC de la GPLv2 à GPLv3, Apple a largement contribué à LLVM, c'est vrai.

Sinon comme le disaient d'autres personnes, toutes ces boites participent toutes à de gros développements pour du logiciel libre (mais évidemment c'est parce que ça leur permet de garder un certain contrôle sur comment certaines briques essentielles sont développées, et malgré tout de mutualiser une partie des efforts).

Je réponds à la bourre, mais :

Je suis convaincu que GCC (ou n'importe quel compilateur) n'est pas capable de parser certains fichiers C parfaitement valides (mais complètement tordus).

Si tu actives certaines optimisations qui créent des graphes complexes (en gros, -O3 avec quelques options en plus par exemple) tu peux clairement arriver à des plantages du compilateur pour certains codes. Par exemple, le fameux code de ffmpeg a quelques fonctions qui font 3000 lignes pour cause de programmeur ne faisant pas confiance au compilo. Bon ben, si jamais on activait les directives de compilation et vectorisation dessus, on pourrait avoir quelques surprises, euh, intéressantes. :-)

Sinon, avec le compilateur d'Intel, il m'est déjà arrivé d'avoir des plantages du genre « Internal error : graph too deep » (ce n'était pas exactement dit comme ça, mais c'est plus ou moins ce que ça veut dire) : c'était la représentation interne du programme en activant toutes les grosses optimisations qui faisait que le compilateur finissait par faire trop de récursions en parcourant/mettant à jour le graphe…

En même temps, quand tu vois que GNU sort alloue (allouait ?) des GIGA octets histoire d'avoir toujours de la place quand il en a besoin (et qu'il s'appuie sur l'allocation de pages à la demande effectuée par le noyau en pratique), Debian a bien raison…

C'est aussi arrivé de façon plus ciblée (et plus dévastatrice pour sa victime) : https://www.theguardian.com/money/2012/oct/22/amazon-wipes-customers-kindle-deletes-account

Le genre est réservé aux gens, voire aux animaux. Tout le reste est neutre

Voire aux bateaux et autres véhicules (souvent au féminin), voire… L'anglais est la langue reine pour les exceptions. :-)

Je disais :

dès qu'on désire parler de façon un peu subtile/avec des constructions un peu complexes.

Tu répondais :

dès qu’on désire n’être compris que d’une élite en fait ?

Non. Je me fais parfaitement comprendre de gens anglophones, et oui, je parle et j'écris sans doute mieux (au sens de la grammaire et de l'orthographe) qu'une bonne partie de la population US pour le dialecte de l'anglais dont se servent les académiques. Ça ne veut pas dire que je parle « mieux » en termes de subtilité dans la langue, et ce, quel que soit le type de population à qui je m'adresse. De plus, il n'y a pas un anglais, mais plusieurs dialectes de l'anglais. L'anglais appris à l'école (je parle du cas US que je connais un peu mieux que le cas UK) est l'anglais « formel » et celui attendu pour écrire ses rédactions, devoirs, etc. Mais il existe différents dialectes hérités des siècles précédents qui, justement contrairement à ce que certains élitistes voudraient faire croire, sont tout aussi valides (mais ont émergé dans des contextes sociaux et géographiques différents de ceux qui rédigent les manuels¹).

Par exemple : « We don't need no education », « I can't get no satisfaction », etc., sont des vers qui m'auraient valu une mauvaise note en cours d'anglais, mais pourtant même si ces formulations trahissent une certaine origine sociale, ça ne veut pas dire qu'elles ne sont pas valides. Il serait facile de faire le parallèle avec l'argot, le verlan, etc., qui sont parlés dans certains quartiers ou certaines banlieues, ou cités, mais selon moi les deux seuls « vrais » dialectes qui existent en français sont le français québecois et le français de métropole ² (les quelques différences de langue entre le français de Suisse ou Belgique me semblent tellement mineurs que ça n'en fait pas des dialectes selon moi, mais je ne suis pas linguiste).

Bref. Pour revenir à ta question : non, je ne parle pas de constructions de langage élitistes, mais bien du parler de tous les jours qui peut être bien plus subtil que ce que tu laisses entendre. Et non, je n'ai pas d'exemple à te donner, là, maintenant, tout de suite, parce que je baigne tellement dans la langue anglaise US que je ne m'en rends plus forcément compte (il aurait fallu qu'on discute de ça il y a 4-5 ans, lorsque c'était encore relativement « nouveau » pour moi).

Ton exemple est un peut bizarre. Je pourrais écrire « Je me suis assis sur la chaise en face de la porte et elle s'est cassée. » En quoi cette phrase est-elle moins ambiguë que celle du tabouret en anglais si j'écrire « I took a seat on the stool next to the table and it broke » ?

J’ai toujours trouvé l’anglais supérieur au français dans sa logique générale, pour plein de raisons, ce « problème » de genre en français en est une de plus…

Ah ben justement, l'Anglais n'est pas spécialement meilleur que le français pour le coup. D'ailleurs, les notations de type « s/he » sont courantes justement parce qu'adresser le genre est aussi un problème en langue anglaise. Il existe une forme grammaticalement correcte, mais apparemment peu usitée, qui est d'utiliser « they » comme forme neutre, mais pas mal de profs anglophones la considèrent comme incorrecte (soit parce qu'ils n'ont jamais appris cette règle de grammaire, soit qu'ils la considèrent désuète). Du coup, ça donne des bouquins, par exemple le jeu de rôle « Vampire: The Mascarade » qui en v.o. (et peut-être aussi en v.f. ?) ont pris le parti de tout accorder au féminin — « When the vampire rises, she … », etc.

Quant à la « logique en général » de l'anglais, si la langue me semble au départ plus simple à apprendre que le français, elle montre son manque de cohérence dès qu'on désire parler de façon un peu subtile/avec des constructions un peu complexes. C'est valable tant pour la prononciation que pour l'orthographe ou la grammaire. Ça n'en excuse pas les défauts du français¹ en terme de constance et de cohérence bien entendu.

Je dis peut-être une connerie, mais si tu tapes [ -d "$REP" ] || mkdir "$REP"

… Les espaces sont gérés non ?

Tu as bien entendu conscience que du Fortran 77 ça se trouve encore dans des codes relativement modernes dans l'industrie hein ? :-)

Pendant ma thèse (entre 2006 et 2010) j'ai bossé sur des codes en Fortran. TOUS étaient écrits au mieux en Fortran 90. Sur quatre codes industriels, deux étaient écrits en F77. Et il s'agissait d'ISV, donc leurs clients faisaient aussi du code qui se servaient du leur. Certains réclamaient de se conformer à la norme IEEE 754 strictement, même si les nouvelles archis/les nouveaux compilos sont capables d'aller jusqu'à 80 bits de précision (parce que ça passe pas les tests unitaires du client sinon).

Autre exemple con : dans les cours d'info, lorsqu'on enseigne le C aux étudiants, beaucoup, beaucoup de profs continuent d'enseigner C89. Alors que depuis on a eu 2 normes qui sont sorties. Donc ils continuent de forcer les élèves à déclarer toutes leurs variables en haut d'un bloc alors que ça fait 20 ans ou presque que la norme permet de déclarer des variables n'importe où dans un bloc de code.

Je suis à fond pour utiliser F2008 (car en plus y'a Co-Array Fortran et que c'est un sous-langage rigolo :-)), mais ton affirmation selon laquelle un thésard peut dire non à son directeur de thèse n'est que partiellement vraie. Je dis aux élèves de Master/thèse qu'il y a forcément un moment pendant la thèse où il faut apprendre à dire non. Cependant, je dis aussi que généralement, la première année on se contente de fermer sa gueule et d'appliquer les méthodes. On peut (et on doit !) les questionner, mais au final, à de très rares exceptions près, le directeur de thèse en 1ère année reste le patron. Perso F77 m'emmerde, donc j'ai fourni mes codes optimisés aux boites avec qui on bossait en leur disant que je savais pas me satisfaire des contraintes désormais artificielles de F77 et que du coup j'avais codé le tout en F90 (ce qui est globalement vrai). Leur réaction a été soit « t'as accéléré mon code de 30%, et mon compilateur sait mélanger les deux, t'inquiète on gère », soit « pas de problème on réécrira le code en F77 ».

Non non, tu as bien compris. :-)

J'attendais la remarque sur "Hackers". :-)

C'est un film culte, car il a plus ou moins été l'un des premiers à montrer les hackers sous un jour relativement positif, mais aussi à utiliser de métaphores complètement débiles pour représenter l'activité de programmation et/ou piratage. Je pensais que ma citation sur le RISC montrait bien que je connais bien la nature du film… et malgré tout, un film qui m'apprend que les gentils hackers sont en Rollerblade alors que les méchants sont en skateboard ne peut être, je le répète, qu'un très grand film. :-)

Si tu parles juste de la « Sprawl Trilogy » je suis assez d'accord. Par contre, si on parle des autres trilogies que Gibson a écrites, je ne suis pas d'accord. Neuromancien en français est pas mal (et c'était un gros tour de force de l'adapter en français à l'époque), et en anglais il est encore plus spectaculaire (le style est encore plus nerveux/incisif). Comte Zéro / Mona-Lisa s'éclate sont aussi très bien, quoi qu'un cran en-dessous de Neuromancien (surtout Comte Zéro, que je trouve bien dans le contexte cyberpunk, mais sans plus)¹.

Par contre, la trilogie suivante est aussi très très bonne : la « Bridge Trilogy » se situe dans un futur moins lointain, où le « big one » (gros tremblement de terre attendu en Californie) est arrivé. « Lumière virtuelle » amorce bien la trilogie, « Idoru » la continue tout aussi bien, mais c'est surtout « Tomorrow's Parties » qui est vraiment excellent et fourni une conclusion super satisfaisante.

En fait, plus le temps passe, et moins Gibson va dans le futur, car, de ce que j'ai compris, ça y est, le futur est là, et donc ce qui est intéressant c'est de s'intéresser aux usages de la technologie et de leur impact sur les hommes. En particulier, « Identification des schémas » est pour moi un chef d'œuvre, au moins aussi intéressant à lire que « Neuromancien » (mais dans un style très différent, plus calme/lent). Les romans qui suivent sont légèrement moins bien (pas encore lu « The Peripheral », qui m'attend sagement sur une étagère), mais malgré tout passionnants.

Voilà voilà, c'étaient mes deux cents.