Frédéric RISS a écrit 70 commentaires

Je ne sais pas si tu as lu l'article de Wired que je donne en lien, mais par un détour assez ardu par la neuro-science, c'est à peu près la même direction que ton interprétation (mais en plus poussé).

En plus, l'histoire est racontée comme s'il n'y avait qu'une seule interprétation possible alors que l'internet se déchire quant à savoir ce que Nolan à voulu illustrer. J'ai l'impression que ceux qui pensent avoir 'compris' le film n'ont pas vraiment réfléchit à ce qu'ils ont vu.

Pour ma part, j'ai trouvé l'idée intéressante à défaut d'être originale. Tout l'intérêt du film vient de l'imbrication des rêves, hors on ne passe même pas 5 minutes à nous expliquer comment il se fait que le cerveau réagisse à ce genre de truc. En plus, le film semble truffé d'incohérences, je cite les 3 qui me perturbent le plus:
- Je veux bien qu'on se retrouve dans les limbes suite à une mort dans le rêve si le corps réel ne se réveille pas, mais comment Leo et sa copine y rentrent-ils en ajoutant un niveau de rêve supplémentaire?
- Pourquoi l'architecte se jette-t-elle de l'immeuble? La décharge provoquée par le faussaire au niveau du dessus devrait suffire à la réveiller.
- Pendant la poursuite en van, les gus font des tonneaux qui sont bien plus violent que la chute du pont qui sert à les réveiller.

La seule explication qui me convainque est celle de cette article de Wired : [http://www.wired.com/wiredscience/2010/07/the-neuroscience-o(...)]. Malheureusement, je ne crois pas une seconde à une réflexion de cet ordre là par le réalisateur.

Comme dis plus haut, je suis d'accord sur le fond, mais une petite correction sur la forme: ICE JTAG n'est pas un produit d'Atmel et ce n'est pas du tout un émulateur (du moins pas au sens ou tu sembles l'entendre). Le JTAG ([http://fr.wikipedia.org/wiki/JTAG]) est un bus de données qui permet au débogueur d'accéder aux ressources du chip et l'ICE ([http://en.wikipedia.org/wiki/In-circuit_emulator], je mets l'article anglais, car le français est daté sinon carrément faux) est le morceau de hardware qui fournit la connectivité JTAG vers l'extérieur. Il s'agit de termes génériques et non pas du nom d'un produit.

Et pourquoi devrait-elle être corrigée? Cette description est tout à fait sensée pour quelqu'un que le package intéresse. Expliciter les acronymes (ou pire essayer de les traduire) n'apportera rien d'autre que de la confusion. C'est un package extrêmement spécialisé qui utilise donc du jargon de son domaine (et AVR décrit un type de puce, comme PPC ou ARMv7).

C'est le Brain Fuck Scheduler (et pas fucker) ... c'est bien moins vulgaire

et il conseille de désactiver le tick dynamique et pas de l'activer comme tu le dis.

Le bugzilla est plus utilisé comme un moyen de tracking que comme une source de rapports de bug. Le plus efficace reste le mail à la LKML. Pas besoin d'être abonné, la pratique veut que toutes les personnes concernées restes en Cc:. Et il ne faut pas avoir peur, les discussions avec les bug-reporters sont normalement cordiales.

Par contre envoyer un mail par problème et essayé de cibler les destinataires en fonction du sous-système (voir le fichier MAINTAINERS) est une bonne pratique. Pour ton problème avec MPD, il serait certainement bon de mettre en CC (avec son accord) le ou les devs de MPD qui disent que c'est un problème noyau.

glib et son modèle GObject est totalement gnome-centriques, c'est le coeur même du modèle objet de Gnome (et pas du tout celui de KDE)

Je te conseille de jeter un oeuil à ce blog d'un développeur de chez Trolltech: http://blogs.qtdeveloper.net/archives/2006/02/24/qt-and-glib(...)

surtout la dernière phrase.

A noter que je n'ai pas d'avis tranché à propos de Phonon, par contre j'ai du mal avec les avis plus qu'orientés qu'émettent les soi-disant défenseurs de chaque camp ( « {K|G} c'est de la merde » ). Les développeurs pour la plupart sont devenus beacoup plus raisonnables et au moins ils travaillent à faire avancer les choses (d'ailleurs ce qui est ici décrit comme une flamewar ressemble plus à un échange constructif d'idées entre amis).

Je travaille sous emacs et j'ai essayé de passer mon environement sous eclipse 3 fois dans la dernière année. Il n'y a pas moyen que quelqu'un utilise CDT sur un project C++ un tant soit peu compliqué. Les indexeurs sont à la rue, prennent tout le CPU pendant 4/5 minutes à chaque modifcation de fichier et surtout ne sont pas capable de s'en sortir avec des templates ce qui les rend totalement inutiles pour moi.
De plus, le mode de saisie par défaut ne me plait pas et malgré des menus contextuels avec 50 options, pas moyen de lui dire comment identer mes sources.
Pour information, le debugueur d'eclipse est GDB, alors ta remarque me fait 'doucement sourire' :). En plus l'interfacage est très limité même au niveau des fonctionalités exposées par l'interface (impossible d'afficher l'assembleur brut, il y a toujours les lignes sources, ce qui fout la merde sur du code optimisé). La perspective de debug n'offre pas d'avantages 'graphiques' (comme la zone de graphe de gdv) et interdit l'usage de fonctions avancées...
Les parseurs d'erreurs GNU make/gcc sont extremement mauvais, ce qui fait qu'il faut regarder dans la console pour avoit le message d'erreur correpsondant au marqueur mis dans la marge.
Bref, Eclipse pour du Java c'est l'outil le plus formidable du monde, mais pour du C++ il n'est tout simplement pas prêt.

Si le programmeur C peut utiliser ces en-têtes pour compiler son programme avec ces libs sans problème, il n'y a aucune raison qu'un autre langage ne puisse pas le faire à partir de ces seuls en-tête.

Ta phrase est juste, tu parles bien de compiler. Par contre pour programmer, le profile d'une fonction ne suffit pas, il faut la description du comportement (par exemple de quel type sont les éléments d'une liste, exemple que tu sembles vouloir ignorer). La partie utile de ce comportement est fournie par l'introsection sous une forme normalisée ce qui n'est pas le cas d'un simple header.

G++ utilise la 'common vendor ABI' ( http://www.codesourcery.com/cxx-abi/(...) ) qui a pour but de permettre ce genre de chose. Malheureusement pour toi MS n'a semble t-il pas l'intention d'adhérer à cette ABI (peut-être que ce n'est techniquement pas possible, je ne dis pas qu'ils y mettent de la mauvaise volontée).
Pour le boulot j'avais essayé de faire cohabiter des libs C++ mingwin et msvc sans succès ; par contre ca marche bien avec du code C (ming|cyg)win et une DLL C++ msvc.

Je sais pas si tu réalises à quel point tu racontes n'importe quoi sur des choses desquelles tu n'as visiblement aucune connaissance pratique. Je ne parle pas seulement de ce dernier point, mais de l'ensemble de la discussion.
Mais alors là, je craque total. Ose seulement répondre que tu as regardé comment fonctionne SELinux (ou l'équialent Windows que je ne connais pas) avant de poster ton commentaire débile...

Je suis un grand fan du couple GCC/GDB pour le développement, je développe toute la journée avec GCC et je fais de temps en temps un port VC.NET et il est évident pour moi que ta dernière phrase marche très bien dans l'autre sens.

En règle générale, le fait d'utiliser plusieurs compilateurs/platformes sur un projet apporte un énorme gain en robustesse.

Enfin bon, ce qu'on lit sur http://www.xfree86.org(...) tend à contredire cet argument :

XFree86 is platform-independent,
[...]
Our goal at XFree86 is to have X run on every platform available

C'est marrant parce que sur un PII-400, mozilla est correct et Galeon ultra-rapide...

Tu as déjà regardé par là pour ton problème de compose ?

http://bugzilla.mozilla.org/show_bug.cgi?id=110344(...)

il faut le corriger, il manque un /quick-reference/ au milieu. Le bon lien est :
http://www.debian.org/doc/manuals/quick-reference/index.fr.html(...)

Ecoute dans le menu kde et blackbox, j'avais evolution, gaim, abiword, gnumeric etc. Après avoir faire l'install de ximian desktop, je ne les avais plus que sous gnome ximian.

Ximian fourni une distribution de gnome... Et si tu n'installes que du Ximian, tout marche correctement (tu l'as dit toit même, tu avais accès à ces programmes depuis le menu gnome). Avant que tu installes Ximian Gnome, tu avais des liens dans les menus BlackBox et KDE parce que c'était des packages de distribution et comme chaque distribution a sa propre façon d'organiser les menus, seuls ses paquets peuvent garantir d'avoir les liens partout.
Ximian fourni des paquets qui vont sur plusieurs distribs, je ne vois pas comment ils pourraient gérer les choses qui sont extérieures à leur paquets.

nb : je n'utilise pas Ximian Gnome, je dis pas que c'est bien, je dis juste qu'il faut un peu réfléchir avant de hurler et de raconter des conneries.
nb2 : Quand une appli gnome plante, c'est normal de voir un rapport de crash de Gnome.

Ouais, t'as raison... c'est nul ce manque de diversité. D'ailleurs je l'ai toujours dit, si un jour il y a un trou de sécurité dans la libc on est mal !
Non, franchement ton argument tient pas.

A mon avis, ce qui font parti des « linux-wise-users » ne laisserons jamais leur lecteur de mails exécuter automatiquement les pièces-jointes... alors cette précaution semble un poil exagérée

Tout à fait d'accord. Néanmoins, tous les points discutés au Kernel Summit seront traités en priorité. Mais comme le dit Linus, le noyau à sa vie propre et il ne doit pas être pensé à l'avance, donc il est clair que comme d'habitude, des nouveautés non annoncées attendrons les testeurs de la branche 2.5...

Comme je l'ai dit, je ne mets pas en doute l'article de 01. J'apporte juste une source complémentaire...

Je ne pense pas qu'il mérite de remplacer celui de 01. En effet, il est bon de signaler que la presse généraliste s'intéresse à Linux. En plus, mon lien commence à dater (avril), et certains points ne sont plus pertinents (je pense en particulier à la VM).

Je ne mets pas en doute l'article de O1net, mais je n'aime pas trop quand la presse grand public parle du développement du noyau. Alors voila un lien vers un résumé de ce qu'on décidé les « kernel hackers » au dernier Kernel Summit à propos des changements dans le noyau 2.5 :
http://lwn.net/2001/features/KernelSummit/(...)

Est-ce que tu sais si ce qui a été cassé c'est du DES ou du triple-DES ? Parce que ça change beaucoup de choses... Il me semble que l'usage du triple DES reste extrèmement sûr malgré tout ce qu'on dit de mal sur cet algo.

;o)
Pas de problème. J'avoue que j'ai alluciné en lisant ta réponse. Je cherchais où je m'étais foiré dans mon post... Je devrais avoir plus confiance en moi