Je ne disais pas de préciser la quantité de RAM pour améliorer les perfs (ce serait idiot en effet :) ), mais pour éviter de crasher si le jeu consomme beaucoup de RAM et empêche la carte d'en allouer (ce chip n'utilise pas une quantité de RAM fixe, il en réserve davantage suivant l'usage qui en est fait).
Si le driver n'arrive pas à allouer de RAM, il bloque X.
En gros, conséquent = "consomme de la RAM comme un goret" dans mon commentaire. Pas besoin d'un jeu récent pour ça ¬¬
Vu l'utilisation que j'ai de mon PC, je préfère mille fois avoir un GPU "qui fait émuler par le CPU la moitié des fonctions habituellement câblées dans un GPU d'Ati ou nvidia" et ne pas avoir à me soucier de la compatibilité douteuses de drivers propriétaires avec mon noyau ou mon serveur X (ou les deux à la fois)... L'autonomie supplémentaire due à l'absence d'une plaque chauffante hi-tech est également appréciable.
Et non, le dernier FPS à la mode avec les effets de la morts ne me tente plus, Steam obligatoire pour jouer à HL2 ça a été la dernière goutte. Le jeu vidéo a finit sa transformation en industrie et se fout de la gueule de ses clients au moins autant que l'industrie musicale.
C'est le chip qui équipe les centrino duo. Je n'ai pas testé XGL avec, simplement composite (je suis en Xorg 6.9).
Composite est très fluide avec, et OpenGL fonctionne sans problème avec composite activé. La seule chose qui ne me fait pas l'activer pour un usage quotidien, c'est que superkaramba utilise toujours la fausse transparence, et avec son taux de rafraichissement, ça fait des traces noires à l'emplacement des widgets quand on met une vidéo ou une appli opengl en plein écran ('fin ça dépend pas du gpu ça :) ).
Question performances, je n'ai rien testé d'extraordinaire, mais TuxRacer et Counter Strike 1.5 sous Wine tournent à pleine vitesse sans problèmes, ça me suffit :)
Pour la vidéo, j'en suis très content aussi. Xv marche très bien (on peut même configurer la couleur de fond par défaut si on n'aime pas le bleu :]), mais on peut aussi utiliser la sortie gl2 de MPlayer avec la même qualité. Sur mon ancienne nVidia, l'image en gl2 était apparemment scalée en software, donc pas terrible (surtout les sous-titres /o\), alors que là ça donne visuellement le même résultat que Xv (scaler hardware). 'fin, je peux lire des vidéo en x264 + AAC de bonne résolution (genre 704x480) à un peu moins de ~20% d'occupation CPU en Xv, c'est tout ce qui m'importe :)
Apparemment le driver gère aussi l'accélération MPEG2 hardware via XvMC (motion compensation) mais je n'utilise quasiment jamais de DVDs, je ne peux donc pas te dire si ça améliore vraiment les choses ou pas.
Par contre, si tu es un console junky, il n'y a pas de support cvidix pour les intel apparemment, donc pas de films en console comme avec une radeon R200.
Au final, j'en suis bien plus satisfait que ma GeForce 5700 ou ma Radeon 9250 - plus de driver fermé à recompiler régulièrement, et pas de bugs graphiques non plus (la Radeon 9250 en a avec TuxRacer, pas l'Intel). L'accélération 2d est aussi bien meilleure que celle de ma R200, pas besoin d'optimiser quoi que ce soit, ça marche très bien de base.
/!\ Par contre, si tu veux jouer à quelque chose de conséquent, pense à bien spécifier la mémoire réservée au GPU dans ton xorg.conf (j'ai mis 256 megs), sinon le driver peut couiner qu'il n'arrive pas à allouer de mémoire vidéo et sciemment bloquer X (oui c'est prémédité, il signale qu'il va lockup dans les logs...). 'Fin je préfère un comportement fâcheux mais bien documenté comme celui-là à l'horrible bug XID qui m'arrivait sans prévenir avec le driver nVidia (cause toujours inconnue d'ailleurs il me semble).
Hmm, j'ai rien dit, j'avais pas fait attention au fait que c'était arrivé il y a un an... Enfin, le bout de config noyau pourra toujours servir à ceux qui veulent faire marcher ce genre de contrôleurs maintenant :)
Je comprend pas pourquoi tu as voulu flasher le BIOS...
Il suffit de configurer ton noyau (de préférence un 2.6.17) comme ça:
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
(là je laisse le NOT SET car c'est important, sinon c'est NOT SET par défaut pour tous les symboles omis)
#
# SCSI device support
#
CONFIG_SCSI=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
CONFIG_BLK_DEV_SR=y
CONFIG_CHR_DEV_SG=y
Avec un noyau un peu moins récent on peut avoir besoin d'ajouter "libata.atapi_enabled=1" en paramètre au boot, mais c'est tout.
Tu as lu les tutoriaux ou tu as simplement utilisé le kernel par défaut de ta distro ? Typiquement le problème de DMA est du à un conflit entre la libata et le driver IDE, donc ça doit arriver systématiquement avec un kernel générique à moins de passer le paramètre magique. C'est pour ça que j'ai giclé le support IDE de mon noyau.
Sinon, personnellement je suis aussi très content de ma carte intégrée Intel :) Difficile d'avoir un chip mieux géré sous Linux (bon après, les perfs c'est autre chose, mais je ne suis pas un gamer).
Posté par JaguarWan .
En réponse au journal Kickoff.
Évalué à 2.
Pour "enlarge your productivity", on pourrait aussi commencer par dissocier ce menu du stupide bouton en bas à gauche.
Le menu clic droit original du bureau (changer de fond d'écran etc...) ne sert quasiment jamais...
Je préfère *largement* cliquer droit sur un interstice entre deux fenêtres, qui laisse transparaître un bout de fond d'écran, pour appeler le menu K, que devoir lamentablement traîner le pointeur en bas à gauche (sachant que le bouton peut être couvert par une fenêtre...).
En faisant comme ça, on a en plus l'avantage d'avoir le curseur de la souris à une dizaine de pixel de l'application la plus utilisée (si bien sûr la zone "Most used applications" est activée dans les options).
Bref, c'est uniquement grâce à sa configurabilité que j'apprécie autant KDE; si j'étais contraint d'utiliser les settings par défaut, je pense que je le détesterais cordialement :)
Posté par JaguarWan .
En réponse au journal Kickoff.
Évalué à 7.
La fonction de recherche à l'air sympa et bien foutue, mais il a l'air énorme ce menu (dans le sens trop gros, passera pas sur un 15").
Les onglets "My Computer" et "Leave" entre autre prennent beaucoup de place pour rien. 'pis c'est au moment où MS arrête enfin cette mode ridicule des "My Machin" qu'ils s'y mettent, pitié /o\
Enfin vu qu'on peut toujours configurer KDE dans tous les sens, j'espère qu'on pourra au moins gicler les deux onglets idiots histoire de retrouver une largeur raisonnable, et changer les noms douteux.
Je trouve l'ergonomie de l'onglet "All programs" plutôt douteuse aussi, ce machin force à avancer dans l'arborescence, donc on ne peut pas regarder vite fait le contenu de chaque catégorie en "glissant" comme avec le menu actuel (ouais, je me trompe régulièrement entre les catégories "System", "Settings" et "Utilities" entre autres).
Bon, au final, je vais prendre la Broadcom. Le driver est déjà libre (m'étonnerait qu'Atheros ou même la dernière Intel passe en libre rapidement), et le hack sanglant qui permet l'injection actuellement laisse à penser qu'un support complet plus tard est possible. Si le code n'est pas trop obscur il y aura peut être même moyen de le hacker un peu :)
J'ai écarté l'option OpenBSD car le support de l'ACPI n'est pas (encore) au niveau de Linux... J'aurais certes une carte wifi opérationnelle mais l'autonomie générale de la machine prendrait un sacré coup. Je ne suis pas sûr non plus que le chip son sigmatel soit géré. Bref, ça résoudrais un problème mais en créerais plusieurs autres :)
Pour le portage, je ferais ça avec plaisir si j'avais les connaissances nécessaires :) Je me dépatouille un peu en C pour des applis userland, mais bricoler des driver en mode noyau ce n'est pas le même niveau. Il ne suffira pas de remplacer des strlcat() quoi :( Il y a aussi le facteur temps, j'en aurais beaucoup moins dès la rentrée...
Bah le reste du matériel de ce laptop est excellent, difficile de trouver un autre portable avec un chip graphique aussi bien géré, et une puissance/autonomie équivalente pour le même prix.
Je ne vois donc pas en quoi c'est idiot de changer la seule pièce qui ne m'apporte pas entière satisfaction sur la machine; au niveau de la consommation, je ne pense que changer de chipset fasse une énorme différence sur batterie, mais ça fera une énorme différence pour moi :)
Et ce n'est pas (seulement) pour raisons "idéologiques", mais aussi car j'aimerais bien pouvoir bidouiller ma Nintendo DS avec (donc injection de frames), et pouvoir mettre à jour kernel et/ou driver rapidement s'il y a un trou, (sans "ah bah non si je passe en 2.6.19 ça casse le driver" ou "ah bah le fabriquant s'en fout de mon bug rare").
A priori, ces deux souhaits sont compromis avec ma carte actuelle et l'Atheros/MadWifi.
Ça peut servir, entre autre, à exécuter du code sur Nintendo DS (wifime). Et non, pas de jeux commerciaux, on ne peut uploader que 4 megs maximum :)
L'idéal pour ça serait du ralink, mais le code de libnifi me laisse penser que toute carte gérant l'injection proprement sous Linux et capable d'émettre à 2 Mbps en mode monitor marcherait avec.
Le gros avantage, c'est que ça permet de tester vite fait un programme raisonnable, sans avoir à le mettre sur une carte etc...
Merci, tu viens de m'éviter une belle bourde: je comptais m'acheter une bcm4311 pci-e (dell truemobile 1390) pour remplacer l'intel3945 de mon laptop :/
Et dire que si seulement il y avait un moyen de plugger du mini pci sur du mini pci-e, je pourrais lui mettre une prism54 fullmac aux fesses...
Tu te focalise sur les backends et sur le point de vue utilisateur, c'est pour ça que tu trouves ça idiot. Le truc c'est d'éviter au développeur qui code une appli de gestion de rendez vous, par exemple, de se casser la tête s'il a besoin d'animer son appli (genre message personnalisé, "fais gaffe, ton train part dans dix minutes !", ou que sais-je).
Actuellement, le dev en question doit d'abord choisir un framework pas forcément intégré à kde et en assimiler la doc, ensuite coder en espérant que tous les utilisateurs disposent de la lib.
L'avantage de phonon, c'est que là le dev n'a pas à se poser de question, c'est intégré à kde. Donc il utilise gentiment l'api prévue (hint: l'avantage sur utiliser xine en dur c'est l'api plus simple et l'absence de dépendance dure), et c'est kde qui se débrouille avec les moyens du bord pour que le son sorte par les enceintes, avec probablement peu de pertes de performance vu que sur le fond c'est juste un wrapper. Réutilisation (en utilisant un backend tout fait), et mutualisation du code (via le wrapper, au lieu de forcer les gens à mettre de grosses boilerplates pour utiliser une api plus complexe), c'est exactement ce que tu prône non ?
Si phonon n'utilisait pas de backends mais se débrouillait pour sortir le son tout seul tu n'aurais probablement rien contre :)
Le fait que phonon se réduise au plus petit dénominateur commun n'est pas génant vu son objectif (faire des trucs multimédia pouet pouet *simples* facilement et de manière portable). Évidemment qu'une appli de MAO n'utilisera pas phonon, mais une interface plus élaborée genre jack.
C'est vraiment un excellent exemple, je suis tombé complètement par hasard sur Tracker en parcourant un troll Mono sur OSnews... :/
Beagle est une abomination à installer à partir des tarball, j'ai du prendre des binaires précompilés sur linuxpackages pour l'installer sur ma machine de test. C'est très lourd (~100 megs de RAM occupés rien que pour lui), lent à indexer et chercher. Pourtant, quelle popularité sur google... SPOTLIGHT KILLER ! mouarf.
Si on recherche Meta Tracker sur google, on ne trouve que la page du projet, et en cherchant mieux deux trois messages sur des blogs ou des ML (enfin, le nom assez générique n'aide pas non plus ;) ).
Tracker s'installe à la main très facilement à condition d'avoir dbus, trackerd consomme très peu de mémoire, et l'ensemble est considérablement plus nerveux que Beagle :) ('fin je n'ai pu joué qu'avec tracker-search et tracker-query).
J'espère que la sphère Linux n'est pas encore suffisamment intoxiquée par le marketing et la corporate-friendly attitude, et que tracker pourra s'imposer naturellement par sa supériorité technologique. Déjà, j'ai vu qu'il pouvait être intégré à Nautilus (pas testé par contre, pas de Gnome sur Slack de base :) ), c'est peut être le pied dans la porte.
Bref, tout ça pour dire que le front des "linuxiens" qui crie à la standardisation des packages manager, veulent un /etc unifié style base de registre, ABI stable dans le noyau sinon le driver nvidia est cassé, LSB sinon installer Oracle c'est compliqué, LGPL c'est mieux car on peut faire du proprio, "linux va mourir s'il gère X" où X est un buzzword à la mode, Mono C# c'est l'avenir, bref, un Windows® légalement gratuit... il me donne très très vite envie de troller :]
Je trouve d'ailleurs vraiment dommage que beaucoup de ces gens là soient du côté de Gnome (à cause de la LGPL de GTK, des grosses boîtes qui le soutiennent et d'Icaza entre autres), car ça ternis considérablement l'attrait que ce desktop - par ailleurs encore tout à fait respectable - pourrait avoir sur certains, dont moi (même si la politique de 'less is more' m'agace :þ).
J'espère simplement que GNOME, né pour contrer un KDE alors non-libre, ne se fera pas assimiler par les borgs marketing (l'inclusion de Mono est peut être un symptôme inquiétant), et surtout que KDE ne sera pas contaminé ! (comme par hasard, les devs de gstreamer travaillent à intégrer un support des DRM à leur framework (http://blogs.gnome.org/view/uraeus/2005/12/03/0 )... sayvrai, si linusque gère pas les déairem, yva creuver !!!!1!!)
Quand je parle d'élitisme, je fais référence au fait qu'une fois le standard de jure énoncé par un Mollah gnome, les fanboys vont pouvoir s'abattre comme des sauterelles sur tous ceux qui -à leurs yeux- ne suivent pas la fatwa assez bien (et débattre sans fin sur les subtilités du "standard"), lourdant tout ceux qui codent vraiment au lieu de bavasser.
On voit déjà les prémices, avec un gnomiste ici et sur le blog que tu cites qui couinent "ohlala pourquoi ils prennent pas le standard GST par défaut" alors que de toute façon ils n'utilisent pas KDE, et que le KDEiste moyen n'a rien à foutre de GST vu que Xine marche bien mieux.
D'ailleurs, pourquoi Xine ne pourrait pas l'être, le fameux le standard... Il me semble, que, de facto, Xine est bien plus utilisé que GST :þ
'fin tout ça c'est pas génant, ça ne fait que générer du bruit de fond sur la toile.
Phonon c'est une API multimédia basique, elle a été conçue *généreusement* de façon a proposer à l'utilisateur différents back-ends. Si le besoin se faisait sentir, ils pourraient très bien remplacer les calls vers les back-ends par une solution maison en dur, ça marcherait pareil. Ça permet simplement aux devs d'applis KDE qui ont besoin de jouer un son, par exemple, de le faire facilement sans chercher une lib adéquate et se farcir sa doc, phonon fait tout le sale boulot.
Je ne vois pas ce qu'il y a de réellement polémique dans cette démarche, m'enfin un petit troll de temps en temps ça ne se refuse pas :)
Ah, si tu trouves que les codeurs KDE sont des l33t pour réussir à faire phonon et l'interfacer avec différent backends, c'est sympa et fairplay de ta part, et je suis tout à fait de ton avis ! :)
Pour la fascination des Gnomistes pour Windows, c'est du pur troll de ma part :) M'enfin, quand on voit les décisions de Miguel de Icaza et Ximian avec Mono dans Gnome (duplication d'effort d'ailleurs, y a déjà .GNU), Evolution pour "remplacer" Outlook-Exchange, Novell-Ximian qui pousse XGL au détriment de AIGLX (supporté par les codeurs de Xorg, lui) pour "concurrencer Vista"... Y a quand même une volonté de faire comme (mieux que ?) MS.
Je trouve que ça serait plus sain, vu la qualité des trucs précités, de simplement chercher à faire de bonnes applis sans s'occuper d'MS: Evolution est vraiment une horrible usine à gaz, par contre des clients GTK comme Sylpheed sont vraiment intéressants; XGL est un hack horrible, qui utilise deux serveurs X et casse OpenGL, pourquoi le favoriser à AIGLX ? (d'ailleurs le patch glucose qui s'appuie sur AIGLX a l'air très intéressant en attendant Xegl).
Faire comme/mieux qu'MS c'est se condamner à toujours avoir un métro de retard, et ça peut même étouffer les bons projets originaux qui n'ont pas les même moyens marketing que Novell/Ximian (tout le monde connait Evolution, mais s'il n'y avait pas régulièrement des news sur Sylpheed ici...).
En bref, les KDEistes ne vont jamais couiner que Gnome n'utilise pas dcop ou les kparts, je me donc demande quelle force mystérieuse pousse les Gnomistes à râler systématiquement quand KDE n'utilisent pas leurs machins. Si ça se trouve, Gnome va se dire que finalement GST c'est pas super finalement, et sortir une lib similaire nommée Gazouilli qui fera la même chose, mais là ce sera présenté comme visionnaire :)
Les deux: à l'installation, tu as le choix entre saveurs du terroir (un kernel 2.4.33 de caractère) ou nouvelle cuisine (le cru 2.6.16.27, un peu jeune mais ne manque pas de cuisse).
Enfin, rien ne vaut le kernel qu'on a crafté soi-même en fût avec amour, donc ça n'est vraiment important que lors des premiers boots.
Ce n'est pas avec ça qu'on va concurrencer Windows Media Player
On s'en fout complètement de Windows Media Player®. En plus il me semble qu'on a largement les même fonctionnalités (sauf le bouton "Acheter" et les DRM, un manque à combler d'urgence je suppose) depuis MPlayer (MPlayer vaincra !).
Je ne comprend pas pourquoi les gnomistes sont toujours à crier à la "standardisation" et à vouloir concurrencer Windows (C#, ta référence à WMP...). En plus, la standardisation, c'est toujours dans le sens "faites comme Gnome", comme par hasard.
Par contre, je commente ce choix de KDE car il est préjudiciable à Gstreamer.
Pourquoi les devs KDE n'auraient pas le droit de faire leurs designs comme ils veulent sans devoir préserver l'égo des codeurs Gnomistes ? Ça ne t'ai pas venu à l'idée qu'ils n'en avaient peut être rien à foutre de GST ?
Des gars créent une API s'autoproclamant "standard pour le multimédia sous Unix" et il faudraient automatiquement les suivre car il y a le mot "standard" dedans ? Faudrait peut être qu'ils fassent leurs preuves aussi, et pour l'instant c'est loin d'être le cas.
Avec ton raisonnement, faudrait recoder KDE en GTK (duplication d'effort ! la GPL de QT c'est pas corporate friendly !* un autre toolkit, c'est préjudiciable à GTK !)
* et tout le monde sait que si Linux n'est pas corporate-friendly, il va 'se casser la gueule'®.
Si KDE continue dans cette esprit, KDE va se casser la gueule.
Ah ça oui, dès qu'on ne suit pas les standardiseurs autoproclamés, on court droit dans le mur ;)
Au lieu de chercher à unifier GNU/Linux pour le corporate desktop et devenir une alternative crédible au grand méchant Microsoft®, les gnomistes feraient mieux de simplement chercher à coder le meilleur desktop possible.
Je préfère l'ambiance "on code ce qu'on aime comme il nous plait et si on détruit MS ce sera un effet secondaire tout à fait involontaire" prônée par Linus et suivie par les devs KDE que l'élitisme hautain des Gnomistes qui passent leur temps à tout vouloir standardiser* (qui bien souvent, comme la LSB, ne serviraient qu'aux devs d'applications propriétaires) pour "concurrencer Windows".
* et couiner ensuite que personne ne suit leurs standards qu'ils sont seuls à utiliser
Exact, quand j'avais voulu essayer Kororaa sur ma grosse tour avec une radeon 9250, ce fourbe n'a jamais voulu utiliser le driver radeon libre et plantait lamentablement en essayant d'initialiser l'immonde fglrx.
J'avais tenté de lui forcer la main, mais comme il faisait la forte tête et que je n'avais pas envie de passer une demi heure à éplucher ses scripts d'init pour simplement voir des fenêtres molles, j'ai préféré abandonner /o\
Evidemment, les industriels ont trouvé une justification imparable pour justifier tout ça le terrori^M^M^M^Mles virus.
^M c'est Carriage Return (on en croise souvent quand on ouvre avec vi un document impur qui utilise des CRLF diaboliques en fin de ligne [ :%s/^V^M//g pour un exorcisme express ]).
Si tu veux effacer un truc à la Rache®, ^H (backspace) voire ^W (giclage d'un mot) ça marche mieux.
Sinon je suis d'accord avec toi, l'avenir semble inquiétant pour l'informatique grand public, si une collusion entre hardware et software a lieu... Déjà que les périphériques Windows-only posent actuellement problème, je n'ose imaginer les conséquences sous Linux de périphériques requérant un OS signé ou ce genre d'abominations. On a apparemment mangé notre pain blanc :(
Je pense néanmoins que vu les parts de marché d'Unix (et dérivés) dans les serveurs, et le juste courroux des admins qui ne manquera pas de sanctionner ceux qui voudront mettre des mouchards dans leurs engins, on pourra toujours obtenir quelque chose de propre en y mettant le prix...
Et puis au pire, toutes les vieilles machines ne disparaitrons pas du jour au lendemain, et je ne pense pas que ce genre de matériel traître puisse un jour être requis pour accéder au net en dehors des États-Unis et de l'Europe. Le russe lingua franca des geeks d'ici vingt ans ? ;)
Donc à priori le programme prend en compte tout ce qu'il ya dans mon fichier en entrée. Mais suis je bien sure qu'il prend TOUT en compte et que cela ne dépend pas (même peu) de mes paramètres date_deb et nbjour. Car je dois en avoir la certitude.
Les paramètres date_deb et nbjour ne sont en fait utilisés que par MainScript, pour sélectionner toutes les images de la période donnée et les grouper dans le fichier "appendfile" (le programmeur original y fait référence par ce nom, c'est le fichier donné en entrée à syntheseV).
D'après ce que tu me dis sur la nature des traitements, je suppose que ces paramêtres ne devraient pas intervenir dans les calculs de syntheseV, et je peux t'assurer que c'est le cas :) Dans syntheseV, date_deb et nbjour sont lus mais ne sont jamais utilisé par la suite.
En ce qui concerne le nombre de valeur à partir de laquelle l'image est crée le problème venait du fait que le fichier en sortie n'écrase pas ce qu'il y avait avant, je dois créer un nouveau fichier. Et alors quelque soit la valeur des paramètres tappés j'obtiens toujours la même valeur .
Tu fais référence aux messages comme "Image cree à partir de: 5774570 valeurs" ?
Sinon, pour utiliser syntheseV directement, il faudrait qu'il lise lui même les images traitées par MainScript, mais apparemment MainScript fait son travail correctement (donc ça serait une perte de temps). En fait, ça ressemble à un repentir du programmeur; au début, syntheseV aurait probablement du faire le travail de MainScript mais le codeur a probablement du trouver plus rapide et commode de déléguer la sélection des images à un script externe (d'où les paramètres inutilisés dans syntheseV).
Donc apparemment, le script fait bien son travail; il collecte les images entre date_deb et (date_deb+nbjour) et les concatène dans appendfile.
Par contre j'ai vérifié dans syntheseW.c, celui-ci n'utilise pas du tout les paramètres date_deb et nbjour. D'un autre côté, le programme travaille exclusivement à partir du résultat "appendfile" de MainScript, donc normalement les bonnes images... Tout ça est assez mystérieux :)
Quels résultats devraient tu obtenir ? L'idéal serait de pouvoir comparer les résultats du programme sur un jeu d'essai au résultat connu, afin de déterminer si l'implémentation est correcte. Peut être est-ce normal d'obtenir des résultats proches pour différentes périodes de cet échantillon (données monotones) ? Les résultats sont-ils toujours similaires en faisant tourner le programme sur une série différente ?
Les mp3, les lyrics, et maintenant les tablatures... C'est injuste à la fin, seuls les droits des artistes jouant de la musique sont bien protégés.
Ils devraient aussi faire respecter le copyright des humoristes sur leurs histoires drôles (1¤ la blague à utilisation unique, pas cher !, envoie BLAGUE au 10568 !*), des artistes "modernes" (la Poste devrait vraiment payer une license à Christo)...
Bref, tout ce manque à gagner, ça me fend le porte-feuille: vivement DADVSI2 pour corriger tout ça.
* alternativement, Carambar® est un distributeur agréé.
[^] # Re: Intel GMA950 aka i945gm
Posté par JaguarWan . En réponse au journal nv? ati? intel?. Évalué à 4.
Si le driver n'arrive pas à allouer de RAM, il bloque X.
Pour plus d'info: http://www.intel.com/products/chipsets/gma950/
(d'ailleurs en forçant 256MB j'excède la spec, c'est 224 finalement).
En gros, conséquent = "consomme de la RAM comme un goret" dans mon commentaire. Pas besoin d'un jeu récent pour ça ¬¬
Vu l'utilisation que j'ai de mon PC, je préfère mille fois avoir un GPU "qui fait émuler par le CPU la moitié des fonctions habituellement câblées dans un GPU d'Ati ou nvidia" et ne pas avoir à me soucier de la compatibilité douteuses de drivers propriétaires avec mon noyau ou mon serveur X (ou les deux à la fois)... L'autonomie supplémentaire due à l'absence d'une plaque chauffante hi-tech est également appréciable.
Et non, le dernier FPS à la mode avec les effets de la morts ne me tente plus, Steam obligatoire pour jouer à HL2 ça a été la dernière goutte. Le jeu vidéo a finit sa transformation en industrie et se fout de la gueule de ses clients au moins autant que l'industrie musicale.
[^] # Re: windowmaker.info chez moi ca marche
Posté par JaguarWan . En réponse au journal WindowMaker !!! houhou !!! t'es où ???. Évalué à 10.
Note de bas de page politiquement correcte:
* premier candidat au titre qui m'est passé par la tête, remplacez par votre va-t-en-guerre préféré.
# Intel GMA950 aka i945gm
Posté par JaguarWan . En réponse au journal nv? ati? intel?. Évalué à 3.
Composite est très fluide avec, et OpenGL fonctionne sans problème avec composite activé. La seule chose qui ne me fait pas l'activer pour un usage quotidien, c'est que superkaramba utilise toujours la fausse transparence, et avec son taux de rafraichissement, ça fait des traces noires à l'emplacement des widgets quand on met une vidéo ou une appli opengl en plein écran ('fin ça dépend pas du gpu ça :) ).
Question performances, je n'ai rien testé d'extraordinaire, mais TuxRacer et Counter Strike 1.5 sous Wine tournent à pleine vitesse sans problèmes, ça me suffit :)
Pour la vidéo, j'en suis très content aussi. Xv marche très bien (on peut même configurer la couleur de fond par défaut si on n'aime pas le bleu :]), mais on peut aussi utiliser la sortie gl2 de MPlayer avec la même qualité. Sur mon ancienne nVidia, l'image en gl2 était apparemment scalée en software, donc pas terrible (surtout les sous-titres /o\), alors que là ça donne visuellement le même résultat que Xv (scaler hardware). 'fin, je peux lire des vidéo en x264 + AAC de bonne résolution (genre 704x480) à un peu moins de ~20% d'occupation CPU en Xv, c'est tout ce qui m'importe :)
Apparemment le driver gère aussi l'accélération MPEG2 hardware via XvMC (motion compensation) mais je n'utilise quasiment jamais de DVDs, je ne peux donc pas te dire si ça améliore vraiment les choses ou pas.
Par contre, si tu es un console junky, il n'y a pas de support cvidix pour les intel apparemment, donc pas de films en console comme avec une radeon R200.
Au final, j'en suis bien plus satisfait que ma GeForce 5700 ou ma Radeon 9250 - plus de driver fermé à recompiler régulièrement, et pas de bugs graphiques non plus (la Radeon 9250 en a avec TuxRacer, pas l'Intel). L'accélération 2d est aussi bien meilleure que celle de ma R200, pas besoin d'optimiser quoi que ce soit, ça marche très bien de base.
/!\ Par contre, si tu veux jouer à quelque chose de conséquent, pense à bien spécifier la mémoire réservée au GPU dans ton xorg.conf (j'ai mis 256 megs), sinon le driver peut couiner qu'il n'arrive pas à allouer de mémoire vidéo et sciemment bloquer X (oui c'est prémédité, il signale qu'il va lockup dans les logs...). 'Fin je préfère un comportement fâcheux mais bien documenté comme celui-là à l'horrible bug XID qui m'arrivait sans prévenir avec le driver nVidia (cause toujours inconnue d'ailleurs il me semble).
[^] # Re: Pour ton histoire de DMA
Posté par JaguarWan . En réponse au journal l'Avanture Acer (roman fleuve inside). Évalué à 2.
# Pour ton histoire de DMA
Posté par JaguarWan . En réponse au journal l'Avanture Acer (roman fleuve inside). Évalué à 3.
Il suffit de configurer ton noyau (de préférence un 2.6.17) comme ça:
Avec un noyau un peu moins récent on peut avoir besoin d'ajouter "libata.atapi_enabled=1" en paramètre au boot, mais c'est tout.
Tu as lu les tutoriaux ou tu as simplement utilisé le kernel par défaut de ta distro ? Typiquement le problème de DMA est du à un conflit entre la libata et le driver IDE, donc ça doit arriver systématiquement avec un kernel générique à moins de passer le paramètre magique. C'est pour ça que j'ai giclé le support IDE de mon noyau.
Sinon, personnellement je suis aussi très content de ma carte intégrée Intel :) Difficile d'avoir un chip mieux géré sous Linux (bon après, les perfs c'est autre chose, mais je ne suis pas un gamer).
[^] # Re: Et les raccourcis du tableau de bord ?
Posté par JaguarWan . En réponse au journal Kickoff. Évalué à 3.
* _finir_ son travail plus rapidement et donc avoir du temps pour mouler _après_ est une hypothèse obscène non considérée ici.
[^] # Re: Et les raccourcis du tableau de bord ?
Posté par JaguarWan . En réponse au journal Kickoff. Évalué à 2.
Le menu clic droit original du bureau (changer de fond d'écran etc...) ne sert quasiment jamais...
Je préfère *largement* cliquer droit sur un interstice entre deux fenêtres, qui laisse transparaître un bout de fond d'écran, pour appeler le menu K, que devoir lamentablement traîner le pointeur en bas à gauche (sachant que le bouton peut être couvert par une fenêtre...).
En faisant comme ça, on a en plus l'avantage d'avoir le curseur de la souris à une dizaine de pixel de l'application la plus utilisée (si bien sûr la zone "Most used applications" est activée dans les options).
Bref, c'est uniquement grâce à sa configurabilité que j'apprécie autant KDE; si j'étais contraint d'utiliser les settings par défaut, je pense que je le détesterais cordialement :)
# :/
Posté par JaguarWan . En réponse au journal Kickoff. Évalué à 7.
Les onglets "My Computer" et "Leave" entre autre prennent beaucoup de place pour rien. 'pis c'est au moment où MS arrête enfin cette mode ridicule des "My Machin" qu'ils s'y mettent, pitié /o\
Enfin vu qu'on peut toujours configurer KDE dans tous les sens, j'espère qu'on pourra au moins gicler les deux onglets idiots histoire de retrouver une largeur raisonnable, et changer les noms douteux.
Je trouve l'ergonomie de l'onglet "All programs" plutôt douteuse aussi, ce machin force à avancer dans l'arborescence, donc on ne peut pas regarder vite fait le contenu de chaque catégorie en "glissant" comme avec le menu actuel (ouais, je me trompe régulièrement entre les catégories "System", "Settings" et "Utilities" entre autres).
Bref, j'espère que tout ça sera tweakable...
[^] # Re: bcm4311 pas encore supporte
Posté par JaguarWan . En réponse au journal Le sans fil de la peur. Évalué à 2.
Merci à tous pour vos réponses :)
[^] # Re: Autre option
Posté par JaguarWan . En réponse au journal Le sans fil de la peur. Évalué à 2.
Pour le portage, je ferais ça avec plaisir si j'avais les connaissances nécessaires :) Je me dépatouille un peu en C pour des applis userland, mais bricoler des driver en mode noyau ce n'est pas le même niveau. Il ne suffira pas de remplacer des strlcat() quoi :( Il y a aussi le facteur temps, j'en aurais beaucoup moins dès la rentrée...
[^] # Re: Personnellement
Posté par JaguarWan . En réponse au journal Le sans fil de la peur. Évalué à 4.
Je ne vois donc pas en quoi c'est idiot de changer la seule pièce qui ne m'apporte pas entière satisfaction sur la machine; au niveau de la consommation, je ne pense que changer de chipset fasse une énorme différence sur batterie, mais ça fera une énorme différence pour moi :)
Et ce n'est pas (seulement) pour raisons "idéologiques", mais aussi car j'aimerais bien pouvoir bidouiller ma Nintendo DS avec (donc injection de frames), et pouvoir mettre à jour kernel et/ou driver rapidement s'il y a un trou, (sans "ah bah non si je passe en 2.6.19 ça casse le driver" ou "ah bah le fabriquant s'en fout de mon bug rare").
A priori, ces deux souhaits sont compromis avec ma carte actuelle et l'Atheros/MadWifi.
[^] # Re: Injection de trames
Posté par JaguarWan . En réponse au journal Le sans fil de la peur. Évalué à 2.
L'idéal pour ça serait du ralink, mais le code de libnifi me laisse penser que toute carte gérant l'injection proprement sous Linux et capable d'émettre à 2 Mbps en mode monitor marcherait avec.
Le gros avantage, c'est que ça permet de tester vite fait un programme raisonnable, sans avoir à le mettre sur une carte etc...
# ♥
Posté par JaguarWan . En réponse au journal Insultes à un pauvre pingouin. Évalué à 10.
Le plus amusant, c'est qu'apparemment il a pris le temps de te "googler" pour remonter jusqu'à ton site, et l'a lu (et en profondeur en plus !).
Je pense qu'il t'aime bien, au fond :)
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 1.
Et dire que si seulement il y avait un moyen de plugger du mini pci sur du mini pci-e, je pourrais lui mettre une prism54 fullmac aux fesses...
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
Actuellement, le dev en question doit d'abord choisir un framework pas forcément intégré à kde et en assimiler la doc, ensuite coder en espérant que tous les utilisateurs disposent de la lib.
L'avantage de phonon, c'est que là le dev n'a pas à se poser de question, c'est intégré à kde. Donc il utilise gentiment l'api prévue (hint: l'avantage sur utiliser xine en dur c'est l'api plus simple et l'absence de dépendance dure), et c'est kde qui se débrouille avec les moyens du bord pour que le son sorte par les enceintes, avec probablement peu de pertes de performance vu que sur le fond c'est juste un wrapper. Réutilisation (en utilisant un backend tout fait), et mutualisation du code (via le wrapper, au lieu de forcer les gens à mettre de grosses boilerplates pour utiliser une api plus complexe), c'est exactement ce que tu prône non ?
Si phonon n'utilisait pas de backends mais se débrouillait pour sortir le son tout seul tu n'aurais probablement rien contre :)
Le fait que phonon se réduise au plus petit dénominateur commun n'est pas génant vu son objectif (faire des trucs multimédia pouet pouet *simples* facilement et de manière portable). Évidemment qu'une appli de MAO n'utilisera pas phonon, mais une interface plus élaborée genre jack.
Tu trouves toujours ça aberrant ?
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 8.
C'est vraiment un excellent exemple, je suis tombé complètement par hasard sur Tracker en parcourant un troll Mono sur OSnews... :/
Beagle est une abomination à installer à partir des tarball, j'ai du prendre des binaires précompilés sur linuxpackages pour l'installer sur ma machine de test. C'est très lourd (~100 megs de RAM occupés rien que pour lui), lent à indexer et chercher. Pourtant, quelle popularité sur google... SPOTLIGHT KILLER ! mouarf.
Si on recherche Meta Tracker sur google, on ne trouve que la page du projet, et en cherchant mieux deux trois messages sur des blogs ou des ML (enfin, le nom assez générique n'aide pas non plus ;) ).
Tracker s'installe à la main très facilement à condition d'avoir dbus, trackerd consomme très peu de mémoire, et l'ensemble est considérablement plus nerveux que Beagle :) ('fin je n'ai pu joué qu'avec tracker-search et tracker-query).
J'espère que la sphère Linux n'est pas encore suffisamment intoxiquée par le marketing et la corporate-friendly attitude, et que tracker pourra s'imposer naturellement par sa supériorité technologique. Déjà, j'ai vu qu'il pouvait être intégré à Nautilus (pas testé par contre, pas de Gnome sur Slack de base :) ), c'est peut être le pied dans la porte.
Bref, tout ça pour dire que le front des "linuxiens" qui crie à la standardisation des packages manager, veulent un /etc unifié style base de registre, ABI stable dans le noyau sinon le driver nvidia est cassé, LSB sinon installer Oracle c'est compliqué, LGPL c'est mieux car on peut faire du proprio, "linux va mourir s'il gère X" où X est un buzzword à la mode, Mono C# c'est l'avenir, bref, un Windows® légalement gratuit... il me donne très très vite envie de troller :]
Je trouve d'ailleurs vraiment dommage que beaucoup de ces gens là soient du côté de Gnome (à cause de la LGPL de GTK, des grosses boîtes qui le soutiennent et d'Icaza entre autres), car ça ternis considérablement l'attrait que ce desktop - par ailleurs encore tout à fait respectable - pourrait avoir sur certains, dont moi (même si la politique de 'less is more' m'agace :þ).
J'espère simplement que GNOME, né pour contrer un KDE alors non-libre, ne se fera pas assimiler par les borgs marketing (l'inclusion de Mono est peut être un symptôme inquiétant), et surtout que KDE ne sera pas contaminé ! (comme par hasard, les devs de gstreamer travaillent à intégrer un support des DRM à leur framework (http://blogs.gnome.org/view/uraeus/2005/12/03/0 )... sayvrai, si linusque gère pas les déairem, yva creuver !!!!1!!)
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
On voit déjà les prémices, avec un gnomiste ici et sur le blog que tu cites qui couinent "ohlala pourquoi ils prennent pas le standard GST par défaut" alors que de toute façon ils n'utilisent pas KDE, et que le KDEiste moyen n'a rien à foutre de GST vu que Xine marche bien mieux.
D'ailleurs, pourquoi Xine ne pourrait pas l'être, le fameux le standard... Il me semble, que, de facto, Xine est bien plus utilisé que GST :þ
'fin tout ça c'est pas génant, ça ne fait que générer du bruit de fond sur la toile.
Phonon c'est une API multimédia basique, elle a été conçue *généreusement* de façon a proposer à l'utilisateur différents back-ends. Si le besoin se faisait sentir, ils pourraient très bien remplacer les calls vers les back-ends par une solution maison en dur, ça marcherait pareil. Ça permet simplement aux devs d'applis KDE qui ont besoin de jouer un son, par exemple, de le faire facilement sans chercher une lib adéquate et se farcir sa doc, phonon fait tout le sale boulot.
Je ne vois pas ce qu'il y a de réellement polémique dans cette démarche, m'enfin un petit troll de temps en temps ça ne se refuse pas :)
Ah, si tu trouves que les codeurs KDE sont des l33t pour réussir à faire phonon et l'interfacer avec différent backends, c'est sympa et fairplay de ta part, et je suis tout à fait de ton avis ! :)
Pour la fascination des Gnomistes pour Windows, c'est du pur troll de ma part :) M'enfin, quand on voit les décisions de Miguel de Icaza et Ximian avec Mono dans Gnome (duplication d'effort d'ailleurs, y a déjà .GNU), Evolution pour "remplacer" Outlook-Exchange, Novell-Ximian qui pousse XGL au détriment de AIGLX (supporté par les codeurs de Xorg, lui) pour "concurrencer Vista"... Y a quand même une volonté de faire comme (mieux que ?) MS.
Je trouve que ça serait plus sain, vu la qualité des trucs précités, de simplement chercher à faire de bonnes applis sans s'occuper d'MS: Evolution est vraiment une horrible usine à gaz, par contre des clients GTK comme Sylpheed sont vraiment intéressants; XGL est un hack horrible, qui utilise deux serveurs X et casse OpenGL, pourquoi le favoriser à AIGLX ? (d'ailleurs le patch glucose qui s'appuie sur AIGLX a l'air très intéressant en attendant Xegl).
Faire comme/mieux qu'MS c'est se condamner à toujours avoir un métro de retard, et ça peut même étouffer les bons projets originaux qui n'ont pas les même moyens marketing que Novell/Ximian (tout le monde connait Evolution, mais s'il n'y avait pas régulièrement des news sur Sylpheed ici...).
En bref, les KDEistes ne vont jamais couiner que Gnome n'utilise pas dcop ou les kparts, je me donc demande quelle force mystérieuse pousse les Gnomistes à râler systématiquement quand KDE n'utilisent pas leurs machins. Si ça se trouve, Gnome va se dire que finalement GST c'est pas super finalement, et sortir une lib similaire nommée Gazouilli qui fera la même chose, mais là ce sera présenté comme visionnaire :)
[^] # Re: kernel ?
Posté par JaguarWan . En réponse au journal Slackware 11.0 RC2. Évalué à 10.
Enfin, rien ne vaut le kernel qu'on a crafté soi-même en fût avec amour, donc ça n'est vraiment important que lors des premiers boots.
Que Saint Patrick (Volkerding) te bénisse :)
[^] # Re: Les Gnomistes m'emmerdent
Posté par JaguarWan . En réponse au journal Vous voulez krasher ? (KDE4 inside). Évalué à 10.
On s'en fout complètement de Windows Media Player®. En plus il me semble qu'on a largement les même fonctionnalités (sauf le bouton "Acheter" et les DRM, un manque à combler d'urgence je suppose) depuis MPlayer (MPlayer vaincra !).
Je ne comprend pas pourquoi les gnomistes sont toujours à crier à la "standardisation" et à vouloir concurrencer Windows (C#, ta référence à WMP...). En plus, la standardisation, c'est toujours dans le sens "faites comme Gnome", comme par hasard.
Pourquoi les devs KDE n'auraient pas le droit de faire leurs designs comme ils veulent sans devoir préserver l'égo des codeurs Gnomistes ? Ça ne t'ai pas venu à l'idée qu'ils n'en avaient peut être rien à foutre de GST ?
Des gars créent une API s'autoproclamant "standard pour le multimédia sous Unix" et il faudraient automatiquement les suivre car il y a le mot "standard" dedans ? Faudrait peut être qu'ils fassent leurs preuves aussi, et pour l'instant c'est loin d'être le cas.
Avec ton raisonnement, faudrait recoder KDE en GTK (duplication d'effort ! la GPL de QT c'est pas corporate friendly !* un autre toolkit, c'est préjudiciable à GTK !)
* et tout le monde sait que si Linux n'est pas corporate-friendly, il va 'se casser la gueule'®.
Ah ça oui, dès qu'on ne suit pas les standardiseurs autoproclamés, on court droit dans le mur ;)
Au lieu de chercher à unifier GNU/Linux pour le corporate desktop et devenir une alternative crédible au grand méchant Microsoft®, les gnomistes feraient mieux de simplement chercher à coder le meilleur desktop possible.
Je préfère l'ambiance "on code ce qu'on aime comme il nous plait et si on détruit MS ce sera un effet secondaire tout à fait involontaire" prônée par Linus et suivie par les devs KDE que l'élitisme hautain des Gnomistes qui passent leur temps à tout vouloir standardiser* (qui bien souvent, comme la LSB, ne serviraient qu'aux devs d'applications propriétaires) pour "concurrencer Windows".
* et couiner ensuite que personne ne suit leurs standards qu'ils sont seuls à utiliser
Bref, j'ai marché dedans, mais ça fait du bien :D
[^] # Re: Oui, mais...
Posté par JaguarWan . En réponse au journal ATI 2, nVidia 0 ? Sortie du pilote ATI 8.28.8.... Évalué à 2.
J'avais tenté de lui forcer la main, mais comme il faisait la forte tête et que je n'avais pas envie de passer une demi heure à éplucher ses scripts d'init pour simplement voir des fenêtres molles, j'ai préféré abandonner /o\
# :aloy:
Posté par JaguarWan . En réponse au journal PCI Express et informatique "de confiance". Évalué à 8.
^M c'est Carriage Return (on en croise souvent quand on ouvre avec vi un document impur qui utilise des CRLF diaboliques en fin de ligne [ :%s/^V^M//g pour un exorcisme express ]).
Si tu veux effacer un truc à la Rache®, ^H (backspace) voire ^W (giclage d'un mot) ça marche mieux.
Sinon je suis d'accord avec toi, l'avenir semble inquiétant pour l'informatique grand public, si une collusion entre hardware et software a lieu... Déjà que les périphériques Windows-only posent actuellement problème, je n'ose imaginer les conséquences sous Linux de périphériques requérant un OS signé ou ce genre d'abominations. On a apparemment mangé notre pain blanc :(
Je pense néanmoins que vu les parts de marché d'Unix (et dérivés) dans les serveurs, et le juste courroux des admins qui ne manquera pas de sanctionner ceux qui voudront mettre des mouchards dans leurs engins, on pourra toujours obtenir quelque chose de propre en y mettant le prix...
Et puis au pire, toutes les vieilles machines ne disparaitrons pas du jour au lendemain, et je ne pense pas que ce genre de matériel traître puisse un jour être requis pour accéder au net en dehors des États-Unis et de l'Europe. Le russe lingua franca des geeks d'ici vingt ans ? ;)
[^] # Re: :)
Posté par JaguarWan . En réponse au message explication d'un script. Évalué à 2.
Les paramètres date_deb et nbjour ne sont en fait utilisés que par MainScript, pour sélectionner toutes les images de la période donnée et les grouper dans le fichier "appendfile" (le programmeur original y fait référence par ce nom, c'est le fichier donné en entrée à syntheseV).
D'après ce que tu me dis sur la nature des traitements, je suppose que ces paramêtres ne devraient pas intervenir dans les calculs de syntheseV, et je peux t'assurer que c'est le cas :) Dans syntheseV, date_deb et nbjour sont lus mais ne sont jamais utilisé par la suite.
Tu fais référence aux messages comme "Image cree à partir de: 5774570 valeurs" ?
Sinon, pour utiliser syntheseV directement, il faudrait qu'il lise lui même les images traitées par MainScript, mais apparemment MainScript fait son travail correctement (donc ça serait une perte de temps). En fait, ça ressemble à un repentir du programmeur; au début, syntheseV aurait probablement du faire le travail de MainScript mais le codeur a probablement du trouver plus rapide et commode de déléguer la sélection des images à un script externe (d'où les paramètres inutilisés dans syntheseV).
[^] # Re: :)
Posté par JaguarWan . En réponse au message explication d'un script. Évalué à 2.
Par contre j'ai vérifié dans syntheseW.c, celui-ci n'utilise pas du tout les paramètres date_deb et nbjour. D'un autre côté, le programme travaille exclusivement à partir du résultat "appendfile" de MainScript, donc normalement les bonnes images... Tout ça est assez mystérieux :)
Quels résultats devraient tu obtenir ? L'idéal serait de pouvoir comparer les résultats du programme sur un jeu d'essai au résultat connu, afin de déterminer si l'implémentation est correcte. Peut être est-ce normal d'obtenir des résultats proches pour différentes périodes de cet échantillon (données monotones) ? Les résultats sont-ils toujours similaires en faisant tourner le programme sur une série différente ?
# Direct link
Posté par JaguarWan . En réponse au journal Les pieds joyeux. Évalué à 8.
Trailer1
Quicktime
56k
http://raincloud.warnerbros.com/wbol/fr/movies/happyfeet/hap(...)
500k
http://raincloud.warnerbros.com/wbol/fr/movies/happyfeet/hap(...)
Real
56k
http://raincloud.warnerbros.com/wbol/fr/movies/happyfeet/hap(...)
500k
http://raincloud.warnerbros.com/wbol/fr/movies/happyfeet/hap(...)
WMV (implémentation libre dans le dernier snapshot FFMPEG \o/)
56k
http://raincloud.warnerbros.com/wbol/fr/movies/happyfeet/hap(...)
500k
http://raincloud.warnerbros.com/wbol/fr/movies/happyfeet/hap(...)
Et le trailer 2 sur le site d'apple:
http://images.apple.com/movies/wb/happy_feet/happy_feet-tlr2(...)
En gros c'est des tas de pingouins dodus superbement animés qui se trémoussent autant que faire se peut. Bon leech.
# Injustice
Posté par JaguarWan . En réponse au journal La fin de olga.net?. Évalué à 4.
Ils devraient aussi faire respecter le copyright des humoristes sur leurs histoires drôles (1¤ la blague à utilisation unique, pas cher !, envoie BLAGUE au 10568 !*), des artistes "modernes" (la Poste devrait vraiment payer une license à Christo)...
Bref, tout ce manque à gagner, ça me fend le porte-feuille: vivement DADVSI2 pour corriger tout ça.
* alternativement, Carambar® est un distributeur agréé.