Obsidian a écrit 5299 commentaires

je modifie mon ecrit => les commentaires ne veulent plus rien dire car mon ecrit est totalement different ?

Ça se fait ailleurs et ça fonctionne plutôt bien. La vraie question étant « combien de personnes vont abuser du système de la sorte ? ». Étant donné que ça demande une action volontaire et qu'il faut revenir explicitement sur ces propos un ou deux jours après, il faut être motivé pour le faire.

Du coup, ça reste gérable par les modérateurs et surtout, les lecteurs disposent toujours de l'historique pour savoir ce qui s'est dit si on a besoin de le faire.

Ça vaudrait au moins le coup d'essayer quitte à revenir en arrière si ça tourne au joyeux bazar, mais je ne crois que peu à cette dernière option…

Je ne l'ai pas vu, je ne sais pas si je vais le voir. Par contre j'ai vu les épisodes 4,5,6 étant enfant, les ait adoré. J'ai vu les épisodes 1,2,3 adulte. Je les avais trouvé à chier.

Oui mais ça, c'est le mauvais exemple à mon avis :) Tu aurais tout aussi bien pu dire « j'ai vu les épisodes 4, 5 et 6, je les ai adorés, j'ai vu les épisodes 1,2,3, je les avais trouvés à chier ». En 1977, j'avais un an, j'étais donc un peu jeune pour lire les critiques ciné. Par contre, on nous a emmenés voir le Retour du Jedi dès sa sortie et rétrospectivement, quand je regarde le making-of des trois opus originaux, je n'ai pas souvenir que les critiques allaient dans ce sens. Certes, tout le monde était très dubitatif pendant la réalisation du premier, mais le succès a été celui que l'on connaît dès sa sortie.

Personnellement, passé l'effet de surprise et le côté spectaculaire de certaines scènes, j'ai été déçu par les épisodes I, II et III, mais j'ai beaucoup plus apprécié les derniers en date et spécialement « Rogue One » qui est pourtant sorti après le 7, alors que pourtant, on aurait vraiment pu croire qu'à ce stade, c'était du réchauffé.

Rogue One a été qualifié d'épisode « III et demi » et c'est tout-à-fait ça. Loin d'être un spin-off indépendant de la saga originale, c'est véritablement un pont entre les deux séries. Là où ils ont très bien joué à mon avis, c'est qu'il n'ont pas fait qu'imiter les codes graphiques des décors et des équipements techniques (pas seulement les vaisseaux mais également les consoles dans les bases, les corridors, etc.) mais les ont suivi très fidèlement parce que c'est justement censé se passer à la même époque. Du coup, c'est un vrai bol d'air pour les fans de la saga originale mais cela insuffle aussi un vrai sentiment de cohérence pour les adultes que nous sommes devenus, et ça rend la chose agréable à regarder.

Avec cela, j'ai trouvé les personnages vraiment bien travaillés. Vador y est au mieux de sa forme (si l'on peut dire) mais j'ai trouvé le « directeur » très bien imaginé aussi, tant au niveau de l'acteur lui-même que de de son uniforme et même du choix de son titre. En tout cas, c'est mieux que « suprême leader » qu'on attribuerait tout au plus à Kim Jong Un… C'est sans doute l'épisode que je conseillerais le plus à ceux qui ont vu les trois originaux et qui auraient peur d'être déçus.

En ce qui concerne les I, II et III, Georges Lucas a un jour avoué qu'il avait fini par devenir ce qu'il combattait étant jeune réalisateur (il est passé du côté obscur, quoi) et il aurait dû s'en souvenir avant de relancer la saga. Pas pour le dissuader mais pour éviter de tomber dans des pièges sournois. Il a déclaré entre autres deux choses précises : la première est que désormais, les gens qui n'ont jamais vu la saga pourront voir tous les épisodes dans l'ordre (I, II, III, IV, V et VI) ce qui est une ânerie à mon avis parce que ça « spoile » tout ce qui faisait justement la profondeur et le mystère de la trilogie originale, surtout quand on ne l'a jamais vu.

C'est dommage d'ailleurs, parce que les trivialités comme les midichloriens (commme si c'était une maladie infectieuse), Jar Jar Binks (que les fans ont réussi à faire renvoyer) ou les blagues de (Z6|C3)PO ont fini par éclipser certains passages cultes, comme la chute de la République dans un tonnerre d'applaudissements.

En ce qui concerne Jar Jar, on le voit brièvement et discrètement réapparaître dans le cortège funéraire à la mort d'Amidala. J'ai gardé mon haut-le-cœur pour moi mais le spectateur assis juste derrière moi, dans un murmure, n'a pas pu retenir un « putain, il est là, lui ? » :-)

L'autre chose que Lucas a déclaré à cette époque est qu'avec les moyens actuels, il pouvait enfin faire son film « tel qu'il l'avait imaginé à l'époque » et du coup, ils sont bourrés d'images de synthèse et ça, pour le coup, c'était vraiment ce qu'il ne fallait pas faire. Non seulement ça se voit, mais c'est le film entier qui n'a plus d'intérêt si on met en jeu des choses complètement invraisemblables mais que tout le monde ou presque peut aujourd'hui produire soi même sur son PC. En fait, il imaginait un monde de dessin animé alors que ce qui fait que tout le monde s'est immergé dedans à l'époque, c'était justement son réalisme : les vaisseaux, vu de près, avaient vraiment l'air faits de métal et tout ce qui était, dans le film, du même niveau technologique que le nôtre se comportait exactement de la même façon.

Du coup c'est hyper difficile de plaire à tout le monde. Les adultes voudraient toujours plus de profondeur, de suspens, d'inattendu.
Les enfants ont besoin de quelque chose de plus facile à comprendre, bref tu peux pas leur servir un machin avec des concepts de
physique quantique ou un truc à la psychologie très poussée. Ils veulent juste réver de sabre à lumière, de grand méchants et de
gentils qui vont sauver le monde.

Je ne pense pas, justement : d'abord parce que c'est désormais une vraie saga légendaire qui a un rang à tenir. Ce serait comme avoir aujourd'hui un niveau Victor Hugo et vouloir le formater pour la télé (même si la comparaison n'est pas forcément du même niveau). Ensuite, parce que je me souviens également qu'à l'époque, c'était justement les tenants et aboutissants de cette saga qui en faisaient la grandeur, même si je ne les saisissais pas tous quand j'étais vraiment petit. Et cela a justement été un plaisir de les regarder à nouveau à différents âges pour cela. Donc, je pense vraiment qu'il faudra un scénario exceptionnel pour l'épisode IX et que ça n'empêchera pas les enfants d'aller le voir.

Du coup oui ça doit être compliqué de faire un Star Wars qui plait autant aux adultes qu'aux plus jeunes. C'est comme si tu montres un épisode de CHIPS ou Schériff Fais-moi peur à un adulte, à moins d'être complètement bourré ou en plein trip acide il trouvera ça proprement à chier à juste titre.

Pas forcément. Ça dépend surtout de la façon dont l'œuvre vieillit. Tu regardes Tonnerre Mécanique, par exemple, la moto et le pupitre de contrôle mériteraient d'être un peu rafraîchis. Tu prends Supercopter, par contre, ses boutons en plastique et ses écrans cathodiques lui donnent aujourd'hui l'air d'une machine qui exige d'avoir de l'expérience pour être manipulée sans la casser, ce qui était précisément les qualités qu'on voulait conférer au héros à l'époque. Et surtout, on se moquait de ces séries à l'époque, mais imaginez un peu ce que cela a dû coûter de les produire ! D'ailleurs, d'une manière générale, sur les 27 chaînes de la TNT actuelle, il n'y a pratiquement plus de fiction. Quand on constate que les seules choses proposées pour divertir les jeunes sont soit la téléréalité, soit les émissions à jury qui sont toutes construites sur le même modèle, j'en arrive presque à regretter La Cinq. :)

« 20 minutes », c'est relativement bon (en tout cas, ça l'était la dernière fois que j'ai eu une édition papier en main) et ce n'est pas tant bardé de pub que ça. C'était surtout leur deux concurrents qui étaient nettement moins à propos.

Maintenant, ça a peut-être changé puisque ça fait un moment que j'évite Paris et sa proche couronne…

En premier lieu, pardon de ramener ça sur le devant de la scène, il serait VRAIMENT profitable d'allonger la durée de grâce pendant laquelle on peut éditer ses propres contributions (à commencer par les commentaires). Il semble qu'elle soit actuellement de cinq minutes et c'est vraiment trop court, même avec la relecture préalable.

Sur certains sites, c'est 72 heures. Il y a des choses qu'on ne remarque qu'à tête reposée (voire après une bonne nuit de sommeil) et il y en a d'autres qu'on ne voit que chez les autres (comprendre par là : il nous faut un regard extérieur).

Je pense que le mieux serait dans un premier temps de laisser toute personne ré-éditer ses commentaires et de remplacer à chaque fois le dernier message en date par le nouveau tout en les conservant dans la base, et de montrer le diff lorsque l'on cliquerait sur « dernière modification le… ». Ça se fait sur les Wiki et sur la plupart des forums. J'ai même implémenté ça dans le mien.

Dans un deuxième temps, on accorderait aux volontaires qui en feraient la demande le droit de faire cela sur tous les messages mais là, chaque révision serait soumise à approbation préalable de la modération, avec règles explicites enjoignant les correcteurs à n'intervenir que sur la forme et à ne pas changer les propos de l'utilisateur. Le modérateur n'aurait alors plus qu'à cliquer sur un lien pour voir le diff, examiner rapidement les zones rouges et vertes et s'assurer que les modifs sont justifiées. Si oui, on valide en appuyant sur un bouton et c'est fini.

L'avantage, c'est que je pense que ce genre d'approche peut être facilement mise en œuvre sur le plan technique.

Personnellement, j'ai une ASUS EN9800GT (clone de la 9800GT d'nVidia et exploitée par les mêmes pilotes) qui est tombée en panne il y a deux ou trois ans. Je l'ai remplacée par une GT730 Silent, donc avec un gros radiateur en guise de ventilateur. Comme le tout est dans une grande tour bien ventilée (avec des ventilateurs à grand diamètre pour tourner lentement), ça ne pose aucun problème (les capteurs la mesurent à 26° à l'heure où j'écris mais il fait un peu froid chez moi…).

Donc pratiquement la même que la GT 710, mais la version sans ventilo la place encore au dessus des 50 €, malheureusement.

Eh bien avec cette carte, je fais encore fonctionner X-Plane 9, Team Fortress 2 ou Google Earth sans problème (avec les pilotes proprio quand même) et je bénéficie de toute l'accélération graphique en 2D.

Côté connectique, la 9800GT avait deux ports DVI et un Mini-Din. La GT730 a un port DVI, un port VGA et un port HDMI, ce qui correspond très exactement aux trois afficheurs que j'ai à ma disposition : le moniteur de mon PC acquis en même temps que lui, un vieux Dell de récupération (donc VGA uniquement) qui me sert de moniteur auxiliaire et mon téléviseur.

Donc, d'expérience, la nVidia de cette catégorie me rend très bien service et correspond à mes besoins. Je n'ai pas eu l'occasion d'essayer ATI pour comparer.

L'ironie, ce n'est pas ton fort, hein ? :)

En même temps, une roue octogonale, c'est moins efficace niveau rendement mais c'est quand même vachement plus stable…

Donc pourquoi ca en particulier?

En plus je sens bien le truc venir de la liste des choses indispensables a connaitre…

Rien de tout cela, à mon avis.

Je suis assez d'accord avec lui quand il dit qu'au départ, les bases de données sont un sujet qui a l'air rébarbatif aux jeunes programmeurs. C'est même un problème quand ça dure dans le temps, au point d'avoir un chef qui se sent obligé d'expliquer leur métier à tous les développeurs mais qui met un point d'honneur à dire que les bases de données ne sont pas dans son périmètre, justifiant ainsi ses soi-disant domaines d'expertise (en fait, ses centres d'intérêts, qui sont bien souvent les mêmes que tout le monde. Et, oui, tout le monde aura compris que c'est là encore un exemple vécu.)

L'ennui avec les DB, c'est qu'on les enseigne bien souvent avec le traditionnel annuaire ou la base de données clients (nom, prénom, adresse, numéro de client, liste des produits achetés, etc.). Déjà rien de folichon en soi mais, en général, on doit aussi construire et surtout remplir la base soi-même. Donc, des heures de insert à recommencer sans arrêt pour se retrouver au final avec une base de cinq clients et trois commandes. :-\ Il est beaucoup plus intéressant, à mon avis, de se faire les dents sur une base déjà faite et bien remplie, avec un schéma visuel et bien explicite, surtout que cela ne pose aucune difficulté technique : il est tout-à-fait possible d'accorder des droits en lecture seule sur la base à un profil donné et de lui conférer en plus la possibilité de créer les siennes dans un tablespace bien défini, avec bien sûr les contraintes d'intégrité qui s'imposent. Personnellement, j'ai totalement pris goût au SQL lorsque j'ai commencé à travailler sur la base de gènes qui m'a occupé pendant six ans. Donc en faisant des requêtes dans une base avec beaucoup de tables, énormément de données (des millions d'enregistrements par table sur une base Sybase de l'époque).

et que c'est une humilitation d'un ignorer une. Eviter la honte est plutot une mauvaise motivation d'apprentissage.

Non plus. C'est plutôt que ces notions sont intimement liées aux SGBDR et en fait, c'est même pour elles qu'ils ont été conçus ! Sinon, ils n'apportent pas grand chose de plus que de simples fichiers. Au passage, on rappelle qu'initialement, un « fichier », c'est une boîte à fiches. Et c'est bien pour faire ce genre de traitement qu'ils ont été inventés sur les ordinateurs. Comme depuis le départ, un fichier est implémenté comme une suite continue de données, on les utilise majoritairement cette fin : sauvegarder une séquence d'octets continue quelle qu'elle soit, et c'est très bien comme ça. Mais ça explique pourquoi les appels comme fread() permettent de préciser la longueur d'un enregistrement ET le nombre d'enregistrements à lire, et pourquoi un certain nombre de langages définissent les champs destinés aux fichiers comme étant de taille fixe et comblés par des espaces.

En plus, ce n'est pas forcément difficile. C'est plutôt une bonne habitude à prendre depuis le départ. Et très vite, dresser un schéma bien léché devient un plaisir de fin gourmet.

Alors naturellement, il ne s'agit pas de faire de tout un chacun un expert base de données mais en revanche, la façon dont tu poses la question laisse penser qu'en effet, pour un certain nombre de personnes, une base MySQL serait un peu l'équivalent d'une base de registre Windows. Si c'est le cas, et qu'en plus c'est en toute bonne foi, alors c'est peut-être, en effet, quelque chose à surveiller puisque l'on tenait cela pour acquis depuis longtemps.

En plus, c'est réellement important qu'il est extrêmement difficile de gérer « à la main » les contraintes d'intégrité dès lors qu'on dépasse deux ou trois tables. Il n'y a qu'à comptabiliser le nombre de fois que l'on s'est vu opposer une erreur par le SGBD au départ pour se rendre compte que chacune d'elle était en fait une catastrophe potentielle évitée. C'est un peu comme les segfaults quand on fait du langage C ou autre langage compilé en langage machine. Il faut se souvenir que même sur PC, on a attendu le 286 et surtout le 386 pour avoir un mode protégé et que même avec eux, le DOS n'a réellement pris sa retraite qu'avec les années 2000. Cela veut aussi dire qu'en fin de compte, ça ne fait qu'une petite quinzaine d'années que l'informatique grand public est proprement sécurisée de ce côté. :)

L'avantage est qu'à présent tout le site est sur Github et que c'est plus facile à la fois pour le récupérer et proposer des modifications que du temps de Templeet. Bon, 'faut se mettre au Ruby On Rails, mais à part ça, récupérer le backend de la Tribune et l'intégrer dans une boîte en s'inspirant des modules existants doit être raisonnablement envisageable.

J'ai une version du site qui tourne actuellement sur ma machine (ce qui n'a pas été facile). Ça devrait être intéressant de se pencher dessus.

L'outil de configuration nvidia nvidia-settings installé avec le pilote propose cela de manière graphique, mais il remplit visiblement les mêmes fonctions que xranr. Je ne sais pas s'il l'appelle en arrière-plan ou s'il passe directement par des appels système mais pour ces fonctionnalités là au moins, ce n'est sûrement pas une spécificité de la carte.

Après, il faut voir le gestionnaire de bureau que tu utilises.

Personnellement, j'ai un écran un 1680×1050 branché en DVI et j'ai pu y adjoindre un vieux DELL E172FP en VGA et en 1280×1024. C'est presque plus sympa qu'avoir deux fois le même moniteur, parce que le petit me sert vraiment de « moniteur auxiliaire » et que ça me permet de voir le rendu de certains éléments graphiques sur des moniteurs de moins bonne qualité (genre les aplats purement gris style #808080 qui ressortent bleutés sur les vieux LCD, ainsi que leur attitude face aux redimensionnements).

Je suis actuellement sous GNOME 3 et gnome-tweak-tool permet de régler facilement les petits détails de haut niveau. Personnellement, j'ai placé mon moniteur principal bien en face de moi, le second moniteur à droite du premier et j'ai choisi de n'activer les bureaux virtuels que sur le principal. Du coup, celui de droite me sert successivement à regarder défiler les logs ou les sorties de debug, à faire tourner des vidéos Youtube pendant que je travaille (utile pour regarder des conférences où l'audio est le plus important et où l'image ne sert qu'à présenter des graphiques ponctuels), etc. C'est aussi très utile s'en servir comme « presse-papier » : certes, passer une fenêtre d'un bureau à l'autre est trivial depuis longtemps et l'overview permet de faire cela visuellement mais là, on peut facilement faire glisser sa fenêtre sur le côté, choisir tranquillement son espace, et l'y ramener.

Et enfin, l'espace ainsi composé est continu et me permet d'étendre une fenêtre à cheval sur les deux écrans, mais une maximisation de ladite fenêtre me la maximise uniquement sur l'écran ou se trouve le pointeur, ce qui est exactement ce qu'il me fallait. Et avec ça, les demi-écrans fonctionnent toujours (maximisation de la fenêtre sur la partie gauche ou droite de l'écran uniquement, utile sur les écrans au format A3) sur les deux parties des deux écrans.

Comme il n'est pas non plus possible de rester parfois des dizaines d'heures à leur chevet, il convient dès lors de faire très attention et d'adopter de bonnes pratiques et mesures afin de limiter les risques et leurs effets (ce qui nécessite souvent de remplacer des pièces, voire d'ajouter des systèmes de refroidissement, et de prendre un soin particulier au positionnement de l'imprimante et des objets qui l'entourent).

J'ajouterais même : installer un détecteur de fumée à l'aplomb de la machine. Étant donné les dernières législations, ils sont devenus à la fois abordables et faciles à trouver. Donc…

Malheureusement, la prestation de code, ça ne marche que très rarement surtout qu'à moins d'être vraiment une toute petite structure, il y a toujours un geek quelque part qui est capable d'écrire ce genre de script dans le cadre de ses heures et qui est beaucoup plus au fait des nécessités de sa boîte (surtout que ce sont généralement les siennes aussi).

J'ai connu l'affaire aussi au début des années 2000. Je travaillais dans un centre de recherche semi-indépendant et qui avait besoin d'un LIMS depuis longtemps (une vraie arlésienne) et le patron avait confié la chose à une boîte canadienne pour le développer.

Moralité, un soft toujours pas sorti des années plus tard et une facture tenue confidentielle mais qu'un collègue avait réussi à estimer en millions de dollars. Au point ou on en était, on ne disposait que d'une interface (client Windows natif) qui permettait de nourrir une base de données… sans pouvoir la lire en retour. Celle-ci était formée d'une boîte de dialogue de taille fixe truffée de champs de saisie et de boîtes déroulantes. Entre autres tares, j'ai suggéré à un collège de faire [TAB]… [TAB]… [TAB]… pour voir comment on passait d'un champ à l'autre au clavier, sachant que cette interface devait être utilisée intensivement dans les laboratoires pour entrer les résultats de recherche. Et sans surprise, on voyait le focus partir dans tous les sens. L'interface proprement dite avait là encore dû être confiée à un stagiaire débutant (j'ai connu plusieurs stagiaires qui étaient plus compétents que les titulaires qu'ils épaulaient), qui avait dû utiliser l'interface de composition de Visual Basic et décorer bien gentiment son panneau avec ses contrôles, sans même être conscient de l'existence de la propriété « index ».

Toujours au même endroit, quelques années plus tard, un type qui faisait de la bioinfo devait reverse-complémenter une séquence de paires de bases génétiques (remplacer un A par T, un C par un G, et vice-versa, puis retourner la séquence en la lisant de droite à gauche) enregistrée en ASCII dans un fichier de 3Mo.

Le gars avait fini par me demander de l'aide parce que son programme n'avait toujours pas fini après… 2 heures de calcul ! Il avait écrit un script en Perl (encore à la mode à l'époque), il chargeait son fichier dans une grande chaîne de caractères et utilisait chomp pour grignoter le dernier caractère, le complémenter et l'ajouter à la chaîne de sortie.

Pour le fun, étant donné que la tâche à réaliser était excessivement simple, je me suis amusé à l'optimiser à outrance également, en y consacrant une petite heure. J'avais utilisé mmap() pour projeter son fichier en mémoire en laissant toute latitude au système pour charger tout cela de la façon la plus efficace possible et j'avais écrit le cœur de la boucle en utilisant xlat sur x86 (c'était surtout un prétexte pour le faire. En plus, je n'avais pas envie de me faire suer à savoir si et dans quelles conditions le compilateur aurait pu faire mieux).

On est passé de plus de 2 heures à… 2 dixièmes de secondes ! :-)

Certes, ce n'était pas très difficile, mais je pense que c'est le plus grand gain que j'obtiendrai jamais.

Il ne s'agit pas de se « restreindre », mais bien d'agir en connaissance de cause, surtout que LIMIT est aussi utile que répandu, mais que si l'on en croit ce tableau, cette fonctionnalité serait prise en charge sur un grand nombre de SGBD mais à l'exception notable de poids lourds comme Oracle ou MS SQL.

Du coup, si ça nous a toujours paru naturel de l'utiliser et qu'on a appris le SQL avec, on va vers certaines déconvenues.

À l'inverse, on n'est plus obligé non plus de s'en tenir à SQL92. On peut aujourd'hui choisir de reconnaître SQL 2003 (même s'il y a eu 2008, 2011 et 2016 depuis) et profiter des fenêtres WINDOW, et même des requêtes récursives qui sont définies depuis 1999 et avec lesquelles j'ai implémenté le forum du site de mon quartier.

… et en rappelant également que LIMIT ne fait pas partie de la norme ! ;)

De son coté cependant Firefox propose Obsidian basé sur Vulkan et dans l’héritage de Khronos.

Ah non ! Moi je n'ai rien proposé… :)

Ça y est ! Le patch est arrivé mercredi dernier dev crypto-dev/master et linux-next/master sous le numéro 4c0e22c90510308433272d7ba281b1eb4eda8209

Si l'importance du bug est bien relayée aux mainteneurs successifs, on a des chances de le voir arriver dans les prochaines rc. Peut-être pas la rc2 à venir demain soir mais encore que… les gens sont invités pendant cette période à tester intensivement le noyau et c'est le genre de correctif qu'on aime voir arriver assez vite. Surtout qu'étant très concis, il peut se permettre d'être examiné rapidement.

Donc, j'imagine qu'il va d'abord être publié avec le noyau 4.15, puis rétroporté. Les règles disent que le patch doit se trouver dans la branche de Linus pour pouvoir être ajouté à -stable, mais ne précisent pas si un noyau officiel doit être sorti ou si les -rc suffisent (sachant qu'elles servent à cela).

Autre ambiguïté : il y a aussi les règles de soumissions des patches à la branche -stable, mais impossible de savoir si cela doit être fait à l'initiative du développeur, si ces règles ne s'adressent qu'aux mainteneurs, ou si c'est ouvert aux deux. Elles précisent aussi que le patch concerné — ou un patch équivalent – doit se trouver dans la branche principale. C'est évidemment utile quand on veut rajouter un correctif au noyaux LTS et il se trouve que le dernier en date (4.14) en est un ! Mais évidemment, on peut faire des rétroportages sur de très anciens noyaux (branche 3.x par exemple) et dans ce cas, il se peut que les patches à appliquer pour corriger la même chose soient très différents.

Tout cela pour dire que c'est bon pour le noyau 4.15 à sortir le mois prochain, mais impossible de dire s'il va être automatiquement rétroporté.

« My name is looker I living at the second fourth… » Non ça c'est les paroles de la chanson tom's diner.

En fait, ce n'est pas « Tom's diner » mais « Luka », qui est l'autre (le seul autre ?) grand titre de Suzanne Vega.
Voila, voila, voila.

Donc nous avons là la mailing list, les mainteneurs, et nous pouvons déduire de https://git.kernel.org/ qu'il faut cloner le
dépôt https://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git/ pour disposer du dernier code de cette partie du
noyau.

Après un long git clone (le noyau, c'est beaucoup), on peut voir que le bug est toujours présent dans le dernier noyau.
On fait donc un patch de la ligne err = -EFAULT; pour la changer en return -EFAULT;… Et il n'y a plus qu'à préparer le tout.

Juste une petite précision, parce cette page est effectivement un point d'entrée mais qu'elle ne contient pas moins de 800 arborescences, chacune contenant au moins une branche, souvent plusieurs.

D'abord la branche de Linus, qui recèle le noyau tel qu'il sera effectivement publié à la fin est « kernel/git/torvalds/linux.git ». C'est utile de le savoir parce qu'elle n'arrive qu'en 693 position sur 800 et que de nombreuses autres arborescences, dans les répertoires de leurs propriétaires respectifs, s'appellent également linux.git.

Ensuite, toutes ces branches sont faites pour être mergées, donc in fine être intégrées dans l'arborescence principale, et elles-mêmes s'appuient sur l'existant, donc sont toujours un fork de cette même lignée au départ. Cela veut dire que si on suit une arborescence spécifique et que l'on remonte une de ses branches, on va toujours retomber tôt ou tard sur le noyau officiel. Donc, si on clone dans un dépôt local vide la branche citée ci-dessus, on télécharge en fait le noyau entier jusqu'au moment où la branche a forké pour la dernière fois, c'est-à-dire généralement à la dernière version du noyau, en gros. Et si on est sûr d'avoir la branche au complet, il nous manque justement les dernières modifications apportées au noyau officiel, alors qu'on a téléchargé le reste de l'historique jusqu'à 2005 pratiquement pour rien.

C'est important aussi parce que si on clone indépendamment plusieurs dépôts de la même façon, on va se retrouver à chaque fois avec un répertoire de 3 Go par arborescence. Et il se trouve que tous ces dépôts vont en fait contenir à 90% la même chose.

Ça va être le cas en particulier avec linux-next, qui est la branche de travail à suivre dès lors qu'on veut faire des contributions au noyau sur la durée. Ça l'est encore plus quand on débute avec Git et qu'on a l'habitude de faire git pull pour rapatrier le contenu d'une branche distante. Ça se passe toujours bien avec la branche de Linus, mais c'est une autre affaire avec linux-next qui est reconstruite à intervalles réguliers. Quand on a recloné le dépôt deux ou trois fois en re-téléchargeant à chaque fois 3 Go de données, on apprend vite à faire autrement. :)

Le mieux à faire est donc de cloner à la base la branche de Linus, et d'utiliser git remote add pour ajouter des références vers des dépôts distants à notre dépôt local. La base d'objet étant commune, seul ce qui n'a pas déjà été rapatrié le sera lors d'une mise à jour des branches. La bonne idée étant donc d'ajouter linux-next et les arborescences des sous-systèmes qui nous intéressent. Cela évite également de créer automatiquement une branche locale associée si ce n'est pas nécessaire (cas de linux-next).

Ensuite, il suffit de faire git remote update pour mettre à jour toutes les branches d'un coup et sans impacter les branches locale.

Apparemment pas :

git blame ecc.c

6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  963)       * This condition is met by the default RNG because it selects a favored
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  964)       * DRBG with a security strength of 256.
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  965)       */
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  966)      if (crypto_get_default_rng())
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  967)              err = -EFAULT;
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  968) 
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  969)      err = crypto_rng_get_bytes(crypto_default_rng, (u8 *)priv, nbytes);
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  970)      crypto_put_default_rng();
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  971)      if (err)
6755fd269d5c1 (Tudor-Dan Ambarus   2017-05-30 17:52:48 +0300  972)              return err;

… et :

git log --format='%h %an %ad %s' ecc.c

6755fd269d5c Tudor-Dan Ambarus Tue May 30 17:52:48 2017 +0300 crypto: ecdh - add privkey generation support
7380c56d2fca Tudor-Dan Ambarus Tue May 30 15:37:56 2017 +0300 crypto: ecc - rename ecdh_make_pub_key()
ad269597107e Tudor-Dan Ambarus Thu May 25 10:18:05 2017 +0300 crypto: ecc - remove unnecessary casts
099054d735a5 Tudor-Dan Ambarus Thu May 25 10:18:04 2017 +0300 crypto: ecc - remove unused function arguments
8f44df154de7 Stephen Rothwell Fri Jun 24 16:20:22 2016 +1000 crypto: ecdh - make ecdh_shared_secret unique
3c4b23901a0c Salvatore Benedetto Wed Jun 22 17:49:15 2016 +0100 crypto: ecdh - Add ECDH software support
(END)

Donc, le fichier incriminé a été créé en 2016 et n'a fait l'objet que de six patches en tout, donc les quatre derniers au printemps dernier. La ligne fautive se trouve dans le tout dernier patch, qui lui même ne modifie pas l'existant mais déclare de nouvelles fonctions, qui n'ont donc encore jamais été amendées jusqu'ici.

C'est donc un authentique bug qui a passé tous les filtres jusqu'à présent.

Absolument, et cela est même très codifié. On peut lire tout cela dans le Kernel Development Process, que l'on trouve également au format texte (et maintenant *.rst) sous Documentation/process dans l'arborescence des sources du noyau.

Le texte commence à avoir de l'âge mais on y lit notamment :

Once a stable release is made, its ongoing maintenance is passed off to the
"stable team," currently consisting of Greg Kroah-Hartman. The stable team
will release occasional updates to the stable release using the 2.6.x.y
numbering scheme. To be considered for an update release, a patch must (1)
fix a significant bug, and (2) already be merged into the mainline for the
next development kernel.

Soit littéralement :

Une fois la version stable publiée, son entretien est transmis à l'équipe « stable », actuellement formée d'un [seul] membre : Greg Kroah-Hartman. L'équipe stable publiera des mises à jour occasionnelles de la branche stable en utilisant la numérotation 2.6.x.y [aujourd'hui 4.x.y]. Pour envisager son intégration dans une mise à jour, un patch doit (1) corriger un bug non négligeable, et (2) avoir déjà été intégré dans la branche principale du développement du prochain noyau.

Donc, concrètement, ça veut dire que quoi qu'il se passe, ton patch doit suivre la procédure normale, en passant par la branche de développement linux-next, pour vérifier entre autre qu'il compile bien et qu'il ne provoque pas d'autres régressions (ce qui serait un comble). Et cela signifie aussi qu'il doit d'abord inclus dans le noyau courant avant d'être backporté aux mises à jour des versions précédentes. On n'y pense pas mais ça tombe effectivement sous le sens une fois qu'on le dit : ce serait idiot de corriger un bug dans la version qui vient de sortir pour voir réapparaître le bug dans le noyau suivant…

Tout cela est important parce que la phase d'intégration (de nouveautés ou autres) ne dure que deux semaines à chaque fois, suivies de SEPT semaines environ de phase de stabilisation : les fameuses -rc1 à -rc7 (le plus souvent car pour 4.14, on a eu une -rc8), chaque rc (release candidate) étant publiée par Linus le dimanche soir. Et quand on regarde l'arbre Git ainsi que les notes de publication sur la LKML, que l'on peut retrouver par exemple dans l'actuelle dépêche sur la sortie du noyau 4.14 en cours de rédaction, on s'aperçoit que nombreux sont les gens à soumettre des patches, voire des lignées entières de soumissions « urgent-pour-linus » le vendredi soir de la dernière semaine, ce qui a généralement le don de mettre le chef de mauvaise humeur. :)

Tout cela pour dire que c'est cuit pour le 4.14 proprement dit, mais qu'on a de bonnes chances de le voir apparaître dans le 4.14.1 ou .2 dans les prochaines semaines, avant d'attendre la stabilisation du 4.15, sachant qu'un kernel panic doit être considéré comme un bug non négligeable. :)

Je contribue beaucoup aussi et heureusement, je ne passe pas mon temps à reprendre les gens sur l'orthographe (et heureusement, parce que c'est un océan qui serait devant moi). Nous avons la chance d'être relativement bien lotis sur DLFP. Mais dans le cas présent, la faute réapparaît tout au long du fil, et est assez fréquente en règle générale.

C'est important aussi parce que « suffire » est l'un des rares (peut-être même le seul ?) verbes du TROISIÈME groupe (parce qu'il finit par un E) à se conjuguer au passé comme un verbe du deuxième.

Loin de moi l'idée de tout harcèlement mais, de grâce, « ont suffi » sans le T.

Merci.

Ça fait bien longtemps que je ne l'ai plus fait moi-même, mais un bête Nagios, ça ne suffirait pas ?

Salut,

Merci du partage (qui est un peu l'âme du site) mais juste pour info, ici, tu ne résous pas du tout ton problème initial. Au contraire, tu te limites ici à ce qui se trouve dans ton répertoire « source » SANS descendre dans ses sous-répertoires, ce qui est justement le problème qui t'amène ici.

Le problème principal est que, contrairement à d'autres commandes, « mv » ne va pas créer le sous-répertoire parent s'il n'existe pas à l'avance. Tu pourrais tout faire tenir en une seule commande find mais il faudrait pour cela tester l'existence du sous-répertoire (avec test ou avec les opérateurs de bash, le créer le cas échéant avec mkdir -p (-p pour créer les sous-répertoires parents si nécessaire) et enfin, y copier ton fichier.

Mais il y a plus rapide : « cp -R » permet de COPIER récursivement une ou plusieurs sources vers une destination donnée et par conséquent, les sous-répertoires et toute l'arborescence. Donc, si ton répertoire initial n'est pas trop lourd, je le copierais en entier avec cette commande puis j'utiliserais ensuite find pour supprimer toutes les copies des fichiers âgés de MOINS d'une semaine.

Plutôt que les supprimer directement, je les déplacerais dans un répertoire temporaire pour éviter tout accident puis, une fois m'être assuré de son contenu, je supprimerais le répertoire temporaire en question.

Enfin, si l'opération que tu comptes faire est régulière, alors tu peux te permettre de saisir directement la commande que tu cites sans même utiliser « maxdepth » puisque tu sais que les sous-répertoires de destination existeront déjà.

Et en bonus : si tu comptes mettre en place une copie de l'arborescence vide (c'est-à-dire juste les sous-répertoires sans les fichiers) justement pour l'exploiter de cette façon, tu peux utiliser l'option « -type d » de find pour lui demander de trouver tous les répertoires.

Bon courage.

Bonjour et bienvenue,

J'adorais le Linux Distribution Chooser de ZeGenieStudios qui était assez pertinent et qui avait le bon goût de poser des questions à la fois simples et en français mais, malheureusement, il semble qu'il n'existe plus. :-(

« Intel Premium » ? Je ne vois pas.

Sinon, avant toute chose, quel âge a ton PC et quelles sont ses caractéristiques ? Si c'est une machine contemporaine, tu pourras envisager toutes les distributions avant d'en choisir une, mais si c'est un ordinateur hors d'âge, il faudra t'orienter vers des distributions spécialement conçues pour.