Jux a écrit 743 commentaires

Tout simplement génial, j'adore, merci pour me l'avoir fait découvrir :-)

Surtout que je me gourre tout le temps quand je dois l'écrire. La moitié du temps, c'est "pigdin" :-/
D'ailleurs en cherchant "pigdin" sur google[1], j'ai l'impression que je suis pas le seul :-D

[1]http://www.google.com/search?q=pigdin&ie=utf-8&oe=ut(...)

Deux article sur le sujet de l'intégration de la physique dans les jeux avec des bouts de code, très facilement réutilisables :
http://www.gaffer.org/game-physics/integration-basics/
http://www.gaffer.org/game-physics/fix-your-timestep/

(Je suis suisse et en suisse on votre très souvent sur plein de lois, c'est très direct de ce point de vue là)
Le problème le plus visible est que les gens ne sont pas tout le temps très bien renseignés sur la loi pour ou contre laquelle ils vont voter.

En plus dans le système suisse, comme on vote très souvent, il y a des votations où il n'y a carrément pas de débat car elles touchent des points peu médiatiques et les gens n'ont pas le temps de s'en préoccuper.

Il y a aussi le fait qu'en faisant des votations très souvent, les gens ont l'impression qu'ils n'ont pas besoin d'aller s'exprimer à chaque fois et du coup on a des taux de participation de 30%. Alors bien sûr, tu me diras que ceux qui ne sont pas allé voté l'on choisit, mais je ne crois pas que ça soit si simple. C'est parfois simplement une question de manque de temps. (oui, voter sur 2 lois tous les 4 mois, ça demande du temps si on veut savoir de quoi on parle)

On doit aussi élire tous les chef de cabinets, de services, les chargés de mission, tous ceux qui exercent réellement le pouvoir pour avoir une démocratie pure ?

Le c99 te permet d'écrire ça

MaFonction (int n, int m, int v[n][m]);

Chuis pas un pro de la chose, mais y'a un projet assez intéressant qui s'appelle vmgl.
En gros l'idée (si j'ai bien compris) c'est d'intercepter, dans la vm, les appels vers des commandes openGL et de les remonter vers l'OS hôte qui les gerera ensuite comme si c'était une application de l'OS hôte qui les avait faites.
Une présentation qui parle de ça est disponible là :
http://www.xensource.com/files/xensummit_4/vmgl_Cavilla.pdf
La page du projet en question
http://www.cs.toronto.edu/~andreslc/xen-gl/

Vu les benchmarks à la fin de la présentation (page 21), ça a l'air assez performant.
Bon, pour l'instant, ça n'a l'air de supporter que Linux comme OS hôte et Linux comme OS invité, mais l'idée est applicable à n'importe quel OS invité, faut juste écrire des drivers :-)

Il y a aussi cette discussion sur la mailing list Xen qui donne quelque éclairages à ce sujet :
http://lists.xensource.com/archives/html/xen-users/2006-08/m(...)

Une traduction du courriel de Theo :

Beaucoup de développeurs sont occupés à implémenter des contournements pour des bugs sérieux touchant les processeurs Intel Core 2.

Ces processeurs sont très gravement buggés et certains de ces bugs ne causent pas seulement des problèmes de développement/debugging, mais il vont *ASSUREMENT* être exploitable depuis du code tournant en mode utilisateur.

Comme d'habitude, les vendeurs de BIOS vont mettre beaucoup de temps à fournir des contournement/fix pour ces bugs de processeur. Certains bugs ne sont pas fixables et ne peuvent pas être coutournés. Intel donne uniquement des données détaillées concernant les fix aux vendeurs de BIOS ou aux grand groupes éditeurs de systèmes d'exploitations. Les systèmes d'exploitation open source sont laissés de côté.

Errata actuel complet de Intel :

http://download.intel.com/design/processor/specupdt/31327914(...)

* Nous parions qu'il y a beaucoup plus d'errata qui n'ont pas encore été annoncés - ce fichier grandit chaque mois
* Intel sait très bien quel est l'impact de ces errata. A peu près tous les systèmes d'exploitation seront sujets à ces bugs.
* Basiquement, la MMU ( ndt: http://fr.wikipedia.org/wiki/MMU ) ne fonctionne pas comme spécifié/implémenté dans les générations précédentes de matériel x86. Ca n'est pas simplement une question de bug, Intel est allé plus loin et a défini une "nouvelle manière de gérer les tables de pages" (voir page 58).
* Certains de ces bugs sont proches d'un dépassement de tampon; lorsqu'un bit spécifiant qu'il ne faut pas exécuter ou écrire une entrée de page est ignoré. D'autres sont des incohérences dans les instructions de calcul en virgule flottante ou des corruptions de mémoires -- en-dehors des zones d'écritures permises pour le processus -- qui arrivent en exécutant des séquences d'instructions courantes.
* Tout cela semble incroyable à beaucoup d'entre nous.

Un résumé plus facile à lire :

http://www.geek.com/images/geeknews/2006Jan/core_duo_errata_(...)

Il faut noter que certains errata comme AI65, AI79, AI43, AI90, AI99 sont terrifiants. Certains ne peuvent pas être fixé dans un code exécuté et certains sont des choses que n'importe quel système d'exploitation va faire jusqu'à environ mi-2008 parce que c'est la façon dont la MMU a toujours fonctionné sur toutes les générations de matériel Intel/AMD/autres. Maintenant, Intel dit simplement au gens de gérer le vidage des TLB (ndt: http://en.wikipedia.org/wiki/Translation_Lookaside_Buffer ) de la MMU d'une façon nouvelle et différente. En fait, même en faisant ces changements, certains bugs subsisterons.

Comme je l'ai dis précédemment, dans cette liste se cache 20-30 bugs qui ne peuvent pas être contourné par les systèmes d'exploitations et qui sont potentiellement exploitables. Je mettrais ma main au feu qu'au moins 2 ou 3 d'entre eux le sont effectivement.

Par exemple, AI90 est expoitable sur certains systèmes d'exploitations (mais pas OpenBSD tournant avec les binaires par défaut).

Actuellement, je ne peux pas recommander l'achat d'une quelconque machine basé sur un processeur Intel Core 2 jusqu'à ce que ces problèmes soit reglés. (ce qui je suppose va prendre plus d'une année).
Intel doit devenir plus transparent.

(Du moment que j'y suis, j'aimerais dire qu'AMD devient de moins en moins coopératif avec les systèmes d'exploitations open source. Peut-être parce que leurs liste d'erratas sérieux s'allonge également rapidement).

Ben moi je dis juste l'affirmation suivante est eronnée, c'est tout :-)

par contre , si tu fais un gros projet en C/C++, tu ne peux pas te contenter d un gdb en ligne de commandes, il te faut un gros debugger intégré et visuel .

Arf mince les liens ne sont pas passés :
Le journal en question : http://linuxfr.org/~Krunch/22577.html
L'avis de Linus : http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.h(...)

moi , je pense plutot que la plupart des gens qui crient au scandale dès qu on critique gdb sont des mecs qui n ont jamais eu á debugger des gros projets....

C'est quoi un "gros projet", 10'000 lignes ? 100'000 ? 1'000'000 ?

Perso, j'ai bossé sur poppler et evince qui comptent respectivement 100'000 et 60'000 lignes de codes d'après sloccount

enfin , il s agit pas de critiquer la "ligne de commandes" (ce qui relève du blasphème), mais une ligne de commandes , ce n est pas l unique solution même si c est souvent la meilleure ( enfin , je sais pas , peut être que tu regardes tes films en ascii dans un terminal ,mais tout content de transporter le son avec esd.....)

Ou ai-je dis que la ligne de commande était l'unique solution ? Ai-je dis que les interfaces pour débugger c'est _mal_ ?

Non ! J'ai simplement dis que pas mal de gens qui bossent sur des gros projets s'en sortent très bien avec vim/emacs et gdb et que les trucs graphiques ne sont _pas_ (contrairement à ce que tu affirme) une nécessité pour tout le monde, même sur des gros projets avec des programmeurs experimentés.

Pour appuyer mes dire, je te renvoie à ce journal (ou on remarque que certains programmeurs pas tout à fait débutant n'aiment carrément pas les debuggers) et notamment à l'avis d'un certain Linus.

Alors maintenant, il est clair que certains très bons programmeurs préfèrent avoir une interface graphique, ça n'enlève rien à leur compétence, c'est juste que c'est une question de choix personnel.

C'était mon coup de gueule du jour, mais j'en ai un peu marre du discours qui considère que c'est plus "pro" d'utiliser un IDE et que vim/gdb c'est pour les hackers du dimanche et les étudiants. C'est juste une question de choix...

par contre , si tu fais un gros projet en C/C++, tu ne peux pas te contenter d un gdb en ligne de commandes, il te faut un gros debugger intégré et visuel .
de ce côté la , faut un peu tatonner au debut mais quand on a trouvé,comme dab, on se rend compte que c etait debile.

(je ne suis pas sûr d'avoir compris le "débile" de la dernière phrase)
C'est un peu un mythe ça... La majorité (sinon tous) des débuggeurs visuels sous Linux sont justes des interfaces pour gdb. Après je crois que c'est essentiellement une question de préférence personnelle, certains aime la ligne de commande, d'autres n'aiment pas.

C'est un peu le même genre d'argument que dire "ouais la ligne de commande et autoconf c'est bien, mais dès que tu fais un gros projet C/C++, faut un IDE à la visual où tu peux gérer visuellement ta compilation".

Ils font comment les suisses avec leurs votations tout le temps ?

Le bureaux de votes ouvrent le vendredi soir et ferment le dimanche à midi en général (ils sont pas ouvert 24h/24 pendant cette période, y'a des plages horaire).

Pour les votations "simples" (quand il faut répondre par oui/non), on a en général les résultats (en tout cas des bonnes estimations) le dimanche en fin d'après-midi. Pour les élections, c'est le dimanche soir relativement tard ou le lundi matin.

Maintenant, il n'y a effectivement pas la même attente des résultats que ce qu'on a vu pour la présidentielle française. Ca tient certainement au fait qu'on vote très régulièrement (3-4 fois par année) et que la participation est en général assez basse (< 50%).

Il faut aussi remarquer que jusqu'au dimanche midi, personne ne s'amuse à faire des sondages à la sortie des urnes pour savoir qui est en train de gagner, on a donc pas le problème des électeurs qui vont voter alors qu'ils connaissent déjà le résultat. Je ne sais pas pourquoi ça ne se fait pas en suisse.. probablement de nouveau parce que la participation est plus basse et que l'engouement est moindre.

Ceci dit, ça empêche pas le vote électronique de progresser en suisse, avec des belles conneries comme à Genève où le vote par Internet est à l'étude :
http://www.geneve.ch/evoting/

Il me semble que pas mal d'opposants aux machines à voter le sont uniquement pour des raisons techniques. Ils demandent notamment :
- l'accès au code/spécifications de la machine histoire de pouvoir vérifier son fonctionnement
- une impression sur papier du vote de façon à permettre une vérification en cas de doute

Un autre argument est qu'avec une machine à voter, il n'est plus possible pour le citoyen non-informaticien de vérifier/comprendre le processus de vote.

Je ne vois dans aucune de ces trois raisons un quelconque bloquage psychologique.

Problème de synchro entre les miroirs peut-être ?

Mais l'annonce est passée sur debian-announce:
http://lists.debian.org/debian-announce/debian-announce-2007(...)

De tels plugins existent, va par exemple faire un tour du côté de mplayer-plugin :
http://mplayerplug-in.sourceforge.net/

Je ne sais pas si c'est le cas en France, mais Microsoft a des accords avec certains gouvernements à qui il fournit les codes sources de certains logiciels (apparement uniquement la suite Office).
source: http://www.microsoft.com/resources/sharedsource/Licensing/GS(...)

Personne n'a dis que c'était mieux avant.
Un Java sous GPL est clairement mieux qu'un Java proprio, mais ça serait _encore_ mieux pour certains projets si Java était sous GPL/APL (APL est remplaçable par n'importe quelle licence plus permissive que la GPL).

Oh et puis, du moment qu'on arrête avec la mauvaise foi, on pourrait également arrêter avec les commentaires agressifs.

IBM ne dit ni que la GPL n'est pas prête pour le business ni qu'ils aimeraient faire du proprio avec Java. Le problème soulevé est que la libération de Java sous GPL ne permettra pas à certains gros projets libres (p.ex: Apache) ayant une licence trop permissive d'incorporer du code de Java. Sachant qu'Apache a, il me semble, pas mal de projets autour de Java (Tomcat, Lucene, Jakarta, etc...) qui bénéficieraient peut-être d'une intégration de certaines parties de Java, je trouve la question pertinente...

Après, SUN va garder une double-licence GPL/proprio, donc si IBM veut faire du proprio, ils prennent la licence proprio...

J'aime bien les petites piques de redhat lors des annonces de leurs conccurents :
http://www.redhat.com

Je crois que le problème (qui n'est pas spécifique à Xen) est que les machines de bureau actuelles ne supportent pas le IOMMU ( http://en.wikipedia.org/wiki/Iommu ) et qu'il n'est pas possible d'accéder directement à la mémoire de la carte graphique depuis une machine invité.

Un fil de discussion qui donne quelques explications à ce sujet :
http://lists.xensource.com/archives/html/xen-users/2006-06/m(...)

Allez faire un tour sur http://www.redhat.com :-)

En général, les sites d'hébergement de projets proposent une rubrique recrutement :
http://sourceforge.net/people/
https://gna.org/people/

Il pourrait être intéressant de faire un aggrégateur pour ces différentes pages (avec également la possibilité d'inscrire un projet sans être hébergé sur un de ces sites).

Bonne idée en tout cas :-)

Sur cette page du wiki Gnome :
http://live.gnome.org/GnomePerformance?highlight=%28Performa(...)

Plus particulièrement:
http://mail.gnome.org/archives/performance-list/2006-July/ms(...)
http://lists.freedesktop.org/archives/cairo/2006-August/0075(...)
http://mail.gnome.org/archives/performance-list/2006-August/(...)

Pour résumer, le problème est connu des dev GTK, ils sont en train d'investiguer pour voir comment le résoudre.

Si j'ai bien compris les diverses infos glanées sur le net, la carte graphique associée au chipset de carte mère i965 porte le nom de GMA X3000 (une version sans 'X' existe également, moins puissante) et est destinée avant tout aux portables.

Je n'ai pas l'impression que la carte soit déjà disponible, mais puisque le chipset i965 est fait pour les Core 2 Duo qui sont tous récent, on devrait bientôt voir des portables les proposant.

Par contre, plusieurs sites en parlent, avec comme seul info les specifications qu'on trouve dans la doc d'intel [1]
• Vertex Shader Model 3.0 (HW)
• Hardware Pixel Shader 3.0
• 32-bit and 16-bit Full Precision Floating Point Operations
• Up to 8 Multiple Render Targets (MRTs)
• Occlusion Query
• 128-bit Floating Point Texture Formats
• Bilinear, Trilinear, and Anisotropic MipMap Filtering
• Shadow Maps and Double Sided Stencils

Ces specs sont celles de la X3000, qui devrait être compatible DirectX10/Opengl1.5 d'après [2]

Ca a l'air assez prometteur en tout cas, reste à attendre des tests :-)

Il est tout à fait possible que je n'aie rien compris à la nomenclature intel et que ce commentaire soit complètement à côté de la plaque.

[1]http://www.intel.com/design/chipsets/datashts/313053.htm
[2]http://www.infododos.com/actu/view-news-1127078907.html