Rémi Hérilier a écrit 206 commentaires

peut être que la réponse est dans la question : *co*processeur ;)

bibifox doit alors connaitre pleins de manchots :))

/me -> []

Ben oui, ton "quasiment" est important, les multi-cores mettent N cores sur le même support (donc 1 socket sur la carte mère) et les multi-proc, c'est 1 core par socket (donc N sockets sur une carte mère).

c'est une grosse différence architecturale (donc une différence de nom s'impose) mais la finalité est la même : ton OS verra N processeurs.

Bof, tout dépend de la manière de voir les choses.

Si on restreint le concept de processeur à l'objet que l'on achète, oui, un bi-core est un mono-processeur.

Si on considère qu'un processeur est une entité de traitement autonome, en avoir d'autre en parallèle implique du multi-processeur.

Si on compare simplement l'architecture d'un bi-processeur mono-core et d'un mono-processeur bi-core, on verra qu'il s'agit de la même chose.

Personnellement, j'appelle ça un bi-processeur pour 2 raisons :
1/ fondamentalement, c'en est un,
2/ mon OS le voit comme tel.

mes 2 ¢

Pour faire court, le Postscript est à l'imprimante ce que le PDF est à l'ordinateur.

Pour le GPU (Graphic Processing Unit), on peut utiliser ses capacités calculatoires en mettant les données d'entrée dans les textures et/ou dans le flux de géométrie, on charge un shader qui va effectuer les calculs et on récupère le résultat dans le buffer de sortie.

Si on prend le GPGPU (comme dit plus haut : General Purpose GPU), le fait de pouvoir modifier des registres/zones mémoire devrait permettre de ne plus être contraint d'utiliser le pipeline graphique pour effectuer les calculs (plus de contexte graphique à initialiser entièrement, plus de contraite sur comment fournir des données et comment récupérer les résultats, etc.)

Bref, un GPU est un circuit programmable dédié au graphisme. Le GPGPU est plus à voir comme un coprocesseur mathématique bien plus puissant que peuvent l'être les FPU/MMXx/SSEx/3dnow de nos CPU.

M'enfin ?! il ne me verra pas avec le tas de courrier en retard sur mon bureau.

attends moi ;-)

Par contre si la sortie de Vista est un flop...

L'action de Microsoft tombera à 0, Billou et l'excité de première se ruineront pour sauver leur firme qui fermera malgrès tout. Le monde s'écroulera et renaîtra de ses cendres.

merde ! voilà que je m'endors sur mon clavier et que je fais de doux rêves /o\

La peau qu'on prie ?

yapluka ouvrir un wiki sur les vins et hop !

J'trouve ça bien qu'il y ait une version windows avec toutes les dépendances d'intégrées. Ça leur évite de passer 3 heures à télécharger et installer les dépendances.

Un petit détail qui aidera sans doute à démocratiser le format OpenDocument.

J'viens de faire le tour de la page de Nec pour regarder le matos composant ton ordi et je n'ai pas trouvé de portable ... juste des formats desktop et (moyen|mini)-tour ...

et les sites marchant (kelkoo & co) font aussi référence à des machines de bureau ...

bref, difficile de donner son avis sur un truc qui semble ne pas exister ...

t'es sûr que c'est bien un portable ?!

Question con : ce n'est plus polluant de produire des panneaux solaires (référence aux déchets de silicium) ?

J'vais rajouter mon grain de Cell 0:-)

Si je ne me gourre pas, ce n'est que le processeur ... il reste le support du reste du hardware à coder ...

bref, on verra quand ça sortira :)

Pour couper le feu du rasoir et soigner les coupures, rien ne vaut la pierre d'alun : efficace, pas cher, dure longtemps et en plus, c'est naturel :)

Faut juste penser à avoir la peau humide avant de s'en servir et à la sécher après usage.

J'aimerai bien savoir ce que tu as contre le C. À chacun des programmes que je développe, je choisis le langage qui me parait le plus adapté car chercher le Langage (attention à la majuscule:) s'est avéré être une absurdité. Et oui, s'il existait, tout le monde n'utiliserait aucun autre langage. Mais revenons au C :

- Langage très puissant. Il est rapide car il est bas niveau et on sait depuis longtemps l'optimiser.

- Langage certes plus difficile à prendre en main mais connaître toutes les subtilités d'un langage prend du temps. La gestion de la mémoire est effectivement à la charge du développeur mais un code bien structuré élimine la majorité des risques. De plus, les risques de fuites de mémoire dépendent de la compléxité du programme. Si on ajoute à cela une documentation du code, ces risques s'amenuisent encore lorsque l'on reprend son code quelques semaines ou mois plus tard.

- Énormement de bibiliothèques de fonctions.

- Portable (mais bon, le code du programme l'est mais qu'en est-il des bibliothèques de fonctions ?)

Bref, Le choix est large mais il ne dépend pas que des possibilités de tel ou tel langage/bibliothèque. En plus de ses besoins/contraintes, il dépend aussi de ses propres connaissances et de ses affinités. Mais là, on ne peut pas grand chose pour Nicolas ... Le plus simple est effectivement d'aller sur irc et de demander des avis puis de forger sa propre expérience.


Perso, je reste fidèle au C++/SDL/OpenGL (je ne fais que de la 3D) pour 2 raisons essentielles :

- imposer un minimum de contraintes à l'utilisateur de mon programme. Un linuxien n'a aucun problème pour rajouter un paquetage (qui est sûrement déjà installé car un autre programme en dépend déjà) alors que pour un windowsien ou un maceux, c'est moins sûr.

- faire en sorte que mes programmes fonctionnent decemment sur les petites configurations.

bon, j'vais arrêter là, il se fait tard ^_^

PS: en plus de #nekeme, essaye #codefr =)

Pour ce qui est des marges et des interlignes, je ne trouve pas ça malin de dire "méchants profs, par pur dédain de vos pratiques, je vais faire un document avec des marges de 2*sqrt(3) cm et un interligne de PI/2" ... à moins que les profs de Jérome ne prennent pas la peine de lire les rapports de stage, il y a quand même une utilité à cette présentation : laisser de l'espace pour que le correcteur puisse prendre des notes.

mes 2¢

DVZEEC est prog de *conversion* de flux DV en xvid et, de plus, il automatise la génération d'un fichier iso. Bref, un de ces petits outils tout simple et qui risque d'intéresser plus d'un libriste possédant une caméra DV.

diva et pitivi sont 2 logiciels de montage vidéo (linéaire pour le premier et non-linéaire pour le second). Certes, convertir est dans leur corde *mais* ils ne font ni de génération d'iso ni de manipulation de sous-titres et leurs possibilités de montage ne semblent pas être utiles pour les besoins de Roozeec.

Bref, pas besoin d'utiliser oo.org pour taper un fichier README, il y a <insérez votre éditeur de texte préféré>.

Je ne sais pas si un mode batch est prévu mais ça pourrait être pas mal pour ceux qui vont découvrir cette application et qui ont une quantité de cassette DV à passer en xvid :)

Que trouves tu de surprenant ? que la société du nom de Microsoft cherche à avoir le monopole dans tous les domaines (et donc ne supporte que ses propres solutions pour pouvoir les imposer) ? Pourtant, cela fait longtemps que Microsoft a cette démarche et ce n'est pas les coups médiatiques à la "embrace and extend" qui ont marqué un changement significatif de sa politique.

De plus, il existe encore une solution où OpenGL sera exploitable : en utilisant des drivers ICD (Nvidia, ATI, 3dlabs et les autres en fournissent donc ce n'est pas une condition rare à satisfaire) et en désactivant l'interface delamortquitue (tm). Il y aurait une réelle raison de gueuler si OpenGL disparaissait complètement de la plateforme de Microsoft.

Il ne faut pas non plus prendre les utilisateurs pour des idiots finis ... ceux qui auront réellement besoin d'OpenGL et qui seront obligés de rester sous Ms Windows se passeront de la super interface et cela sans l'ombre d'un remord.

Je n'approuve pourtant pas cette démarche mais je l'accepte bien qu'elle ne correspond pas à ma logique.

Pour ce qui est de la 3D, 3DSMax migrera sans difficultés (il supporte aussi bien OpenGL que Direct3D pour l'affichage) mais les Maya et autre Softimage XSI sont en OpenGL pur ... je vois mal les sociétés derrière ces 2 logiciels réécrirent toute la partie affichage ... bref, Microsoft va sans doute forcer des sociétés à faire le pas mais d'autres entreprises vont, par contre, faire le choix d'abandonner la plateforme de Microsoft (les plateformes GNU/Linux ou Mac vont sans doute y gagner). Mais j'espère seulement que certaines ne vont pas continuer comme si rien n'avait changé car l'utilisateur y sera encore plus perdant (comme toujours):

... à mon avis, tu aurais plus vite fait de rajouter du code à ton boot loader pour qu'il récupère la sortie du boot de Linux et qu'il te l'affiche comme tu le souhaite ...

Comme quelqu'un a réussi à insérer la compilation de Linux lors du boot, ce n'est pas chose impossible =)

mes 2 ¢

tank à faire

ya -> il y a
ya (suivit de pas) -> il n'y a (pas)
ya -> y a (formule usitée, certes originellement à l'oral, à Lyon et sans doute ailleurs). Messieurs les flemmards, merci de rajouter l'espace manquant =)

mes 2 ¢

De plus, il n'est pas dit sur quoi il(s) porte(nt).

S'il c'est sur le type d'écran (oled comme dit plus haut), je le trouve justifié, par contre, si c'est du genre "clavier avec écran sur les touches", c'est triste.

Au contraire, ce clavier est une bénédiction pour les "raccoucis barbares".

Tu appuies sur control, hop ! tout les touches sans raccoucis deviennent noires, ceux de ton wm sur fond rouge et ceux que tu as ajouté sur fond vert. plus besoin de ressortir la page d'aide pour retrouver de quelle touche il s'agit. Dans le même genre, sous les emacs, après un "C-x", tu n'as de visible que les raccoucis commençant par "C-x".

C'est donc un magnifique outils pour apprendre à utiliser au mieux ces programmes aux raccoucis multiples et divers.

Et comme c'est un bon outils pour apprendre ... et ... heu ... qu'après tu n'en auras plus besoin, je te le rachète au tiers de son prix dans 3 mois ;)

pouik pouik pouik oumba \o/

/me -> []