legranblon a écrit 633 commentaires

Oui il existe et marche même bien (c'est relatif, hein ça reste ie...), la preuve, avec ies4linux j'ai pu tester la page de l'auteur du journal. Sous wine, ie ne plante pas sur cette page, mais l'effet attendu n'est pas présent, les photos apparaissent normalement.

"n'hésitez pas à consulter documentation en Français sur le site officiel."
J'ai comme l'impression qu'il y a un petit "la" avant "documentation" qui manque.

Autrement rien à redire.

Heu... si en fait, merci pour les tests :)

Le poisson, non, mais le plongeur qui tient la caméra, si.

Mais selon les personnes sur place, notemment, les décideurs (ils étaient pressés en l'occurrence), on n'est pas passé loin de l'explosion. Il a été tenté d'ensevelir le réacteur et ça a réussi, mais si la couche de sables sous le réacteur avait glissé de quelques mètres de plus sous le poid du béton, on aurait eu droit à un joli feu d'aritfice. Les matières radioactives seraient rentrées en contact avec l'eau de la nappe sous la centrale et selon les études à postériori, on aurait pas eu droit à l'arrêt de la radioactivité à la frontière française(sic).

"Tu ne peux pas comparrer les bunker des centrals françaises avec les batiment "normaux" qu'il y avait à chernobyl !"

Ouais... Un "bunker" qui ne résisterait pas à la chute d'un avion plus gros qu'un avion de tourisme... :-\ Si les murs sont hyper épais et on passé des tests d'écrasement d'avions militaires, je ne pense pas que le toit ai reçu des tests aussi sévères. Pourtant, il y a bien des gros porteurs qui se crashent dans des tours...

Mouais, et les déchêts, on en fait quoi, on fait de l'eau lourde à 1 km de profondeur pendant quelques milliers d'années? Comme tout le temps en nucléaire la surface est propre, mais dès qu'on gratte le vernis, c'est pas beau à voir...

Pour ceux qui suivent pas, il me semble que la seule méthode "fiable" pour se débarrasser des résidus de fission est d'enterrer (on ne sait pas vraiment recycler ce genre de trucs, superphénix aurait pu être une voie, mais apparament ça coûte trop cher...) à très grande profondeur les déchêts en surveillant ad vitam eternam (durée de demi-vie du matériau ce qui n'est pas franchement court à l'échelle humaine) le site d'enfouissement. Quand on enterre, il y a toujours le risque de déterioration prématurée des emballages, avec les conséquences qu'entraine le ruissellement des eaux souterraines sur les nappes phréatiques, les rivières souterraines.

Juste pour alimenter ce troll presque subtil, Je n'ai jamais entendu parler de naissance de gosses atteints de leucémies, autres cancers, dysfonctionnements tyroïdiens, malformations flagrantes (et invalidantes) dans le cas de l'utilisation d'énergie tirée du pétrole (et j'en passe certainement), du charbon et autres. Je n'ai pas dit qu'il n'y a pas d'impact sur les population, il y a certainement développement de maladies des voies aériennes et d'autres, mais que les conséquences sont de plus court terme et plus locales que dans le cadre nucléaire.

résoluble : "qui peut être annulé. Un contrat résoluble" selon le larousse. Tu voulais peut-être dire résolvable?

un mars et le troll repart ... ;)
poussez pas !

Blender n'est pas diffusé en binaires 64 bits et Ton Rosendaal indique dans un mail qu'un minumum de 2Goctets de ram sont nécessaires pour que le gain de performances soit probant (après, ça date de mars, et mes compétences ne me permettent pas de juger si c'est inhérent à la structure même de blender ou à un état temporaire du code)... Il faut donc un portable généreusement fourni ou investir dans un bon gros module de mémoire ...

le mail (5 mars 2006): http://projects.blender.org/pipermail/bf-committers/2006-Mar(...)

sont sujets aussi aux contraintes mécaniques de base :
Pour un portable qui dure, éviter de poser un portable en porte à faux ou de le tenir par une seule main par un coin façon "tiens, je te passe le bouquin". La coque a beau être rigide, les torsions subies et les jeux réduits à l'intérieur peuvent entraîner des faux-contacts sur la carte mère.

"Bon on ne peu cependant pas nier le plus du rendu, qui même si il est loin de ce qu'on trouve dans des distibs concurrentes, ne donne plus envie de fuir (osons le dire curses c'est moche!)."

C'est clair que le curses sauce debian c'est plutôt moche, vas voir côté slackware, c'est beaucoups plus joli :)))

Où ça un troll ?? J'ai rien vu moi...

Depuis que les environnements multilibs existent, il n'y a plus besoins de chroot :
les librairies 32 bits dans lib et les librairies 64 bits dans lib64 (on mélange pas les torchons et les serviettes que diable).
OOo 2.0.2 32 bits tourne impeccablement sur ma slamd64 (oui, je suis lâche, la compilation de la branche 64bits de OOo n'a jamais abouti chez moi, en même temps, c'est pas vraiment une partie de plaisir)

"Et puis bon on fait tourner des live XFCE sur 128Mo alors pourquoi pas OO avec un disque dur?"

Je bosse avec openoffice sur un portable k6-2 350MHz 198Mo de ram, dd de 40Go, et je peux t'affirmer que c'est un enfer, même avec icewm ou blackbox ou e17 (j'ai une aversion pour twm). Mes activités tournant autour de copier/coller de textes d'une appli (firefox pour le citer) vers oocalc, le swap est bien occupé (oui, je lorgne du côté de gnumeric, voire kde, on ne sait jamais).

Par contre, en tant que Tx, c'est vraiment nickel (à part peut-être l'écran un tantinet trop lent à mon goût).

Tant qu'on est dans les remèdes de grand-mère, une technique qui peut paraître viable: masser l'écran. En effet, le pixel mort peut venir d'un mauvais contact interne. Masser (modérément bien entendu) l'écran pourrait (méthode non vérifiée par moi-même) rendre la vie à un pixel (c'est tout de même mieux que tenter le bouche à bouche).

Tout Hugues Aufray qu'il est, s'il est inscrit à la SACEM, il n'a aucun droit sur ses oeuvres (de ce que j'ai retenu). Il peut donner son avis, mais si ça a pour but de faire arrêter les démarches de la SACEM, autant pisser dans un violon...

Pour le son, j'ai aussitôt pensé à linphone... qui fait du sip en pair à pair, donc tout indiqué pour ce style d'utilisation. De plus, Il est dispo en ligne de commande...

cf http://www.hardware.fr/articles/603-1/hdcp-cauchemar-cartes-(...)

Seules les entrées / sorties DVI et HDMI (un DVI avec passage du son en plus via le même câble)

:)

La seule solution sera(it) de faire un screener (filmer un écran HDCP)...

La seule solution, faut le dire vite, avec une carte telle que celle décrite sur http://forum.macbidouille.com/index.php?showtopic=102465 ...

En bref, la carte fait la conversion signal DVI -> signal pour dalle d'affichage, ce qui implique qu'on peut récupérer le signal haute définition (la puce utilisée sur cette carte est HDCP ready) en clair, et le réencoder en quelquechose d'interprétable directement comme une vidéo.
Il est clair que la manip décrite dans le journal peut paraître plus simple, mais si le procédé n'est pas applicable pour une raison X ou Y, l'alternative que tu évoques n'est certainement pas la seule.

Il apparait selon le site de l'éditeur qu'un des moteurs de rendu (chercher mental ray) pouvant être utilisé est disponible en standalone pour linux 32 et 64 bits. Il est donc apparament possible de faire une render farm composée de stations de travail windows et de serveurs de calcul sous linux.

Si quelqu'un peut confirmer/infirmer?

"Résumé des 28 pages (et ui j'ai tout lu...) :"
T'es pas le seul :)

"- Pas de mise a disposition du schémas de traçage des circuits imprimés => impossible a reproduire sans reverse engeneering, mais c'est un double couche donc c'est pas infesable"

Si tu a vraiment besoins du shéma du circuit (amélioration, vérification, modification) je ne pense pas que le créateur de la carte refusera que tu participe au développement.

"- Complexité élevée, donc très difficilement réalisable a la main"
Pour le PCB, c'est impossible à moins d'être orfèvre et être à la retraite, pour les chips, ça va encore quand on a les outils adéquats (appareils à raclette, à pierrades)...

"- Circuit Intégrés difficile a trouver"
Ils font une estimation en vue d'une commande groupée, cf "Appel aux gens intéressés" dans le journal.

"(a priori ils bossent sur des échantillons gratuits)"
Pour un développement, ça parait un peu normal, non?

"Bon point :
- La doc complète de la programmation de la puce est dispo => possibilité d'avoir un driver libre facilement en GPL directement dans le noyau"

Ça n'est ni une carte graphique, ni un périphérique spécifique, l'ensemble carte plus dalle n'est qu'un écran, charger un module dans le noyau pour cette carte en tant que telle n'est AMHA pas judicieux.
De mon point de vue, un module noyau ne serait nécessaire que dans le cas d'applications spécifiques passant par le bus usb. Tu notes l'éventualité d'un touchscreen : cette application nécessite bien un module noyau, le périphérique peut être reconnu comme un HID, module déjà présent dans linux.

À noter que la puce utilisée est HDCP ready, donc tout écran construit à partir de cette carte est prêt à diffuser de la "culture sécurisée".

Désolé pour le raccourci, mais je voulais faire court ... et paff! L'erreur perverse s'immisce dans mes propos. Merci d'avoir relevé le problème.

Tu oublie certainement pcbsd, dragonflybsd, et d'autres distribs toutes prêtes pour le desktop. Mais à côté de ça, il y a solaris, le hurd, zetaos, beos, et j'en passe.

Il ne fait pas très beau dehors, à votre place, je resterais à l'intérieur.

Ça dépend de ta version de X, mais, c'est peut-être ce paquet là qui te manque : http://ftp.x.org/pub/X11R7.1/src/lib/libXxf86dga-X11R7.1-1.0(...) (que tu peux soit compiler à la mimine - good luck - soit télécharger dans la bonne version pour ta distribution).

~$ cat /etc/slackware-version
Slackware 10.2.0 (x86_64)

Valà m'sieur ;)

Ça marche nickel sur Slamd64:
~$ ./osinfo -v
1.6
~$ ./osinfo
Slackware 10.2.0(x86_64) release (x86_64) on AuthenticAMD (2.6.16.20)