legranblon a écrit 593 commentaires

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)

Bon, heu les gars, la news sur Nexuiz, c'est par là :
http://linuxfr.org/2006/06/16/20964.html

J'avais fait un truc de build/création de paquets pour slamd64, c'est (un peu) gorret en l'état actuel des choses, mais ça ne demande qu'à être amélioré (mais j'ai pas trop de temps ces temps-ci, néanmoins, j'accepte volontiers toute critique ;) .

le "script" :
http://legranblon.dyndns.org/slamd64/e17.slambuild

la liste ordonnée de compilation:
http://legranblon.dyndns.org/slamd64/compile-order

Sinon, des vieux paquets de mars sont dispos sur http://www.intuxication.org/~legranblon/slamd64/e17/ (pour slamd64)

Trop gros...

Passera pas :)))

Puisque tes parti à pleurer sur les standards, demande à ms de mettre ie en conformité avec les standards, ça fera avancer les choses

D'ailleur, il a pas à y aller avec un butineur tout pourri, s'il était sioux, il aurait demandé au cache de google.

"Debian, l'abandon du support apres si peu d'annees force les entreprises a migrer"

<humour style="troll:1;">
bah! T'façon, on peut pas comparer debian et windows, il est tout à fait normal que windows ai besoin d'être supporté plus longtemps au vu des trous à boucher plus conséquents et nombreux ;)
</humour>

Bein ouais, BAH!
Le descriptif fournit sur http://www.microsoft.com/whdc/xps/wmphoto.mspx fait au mieux 100 % commercial (aka 100 % pipo) au pire 100 % vaporware, c'est pas la première fois que ms promet monts et merveilles.
Si les algoritmes utilisés sont potables, y'a fort à parier qu'il faudra au moins windows vista pour voir les belles images wmp d'un site IIS/ws2003 sous peine de se voir dire que l'os utilisé (win<vista, le reste ne faisant pas partie de la définition d'os) est trop ancien pour pouvoir les afficher.
Pour les conditions d'utilisation du format, on va pas se faire trop d'illusion, hein ...

Tout et dans le titre.

Note aux esprits mal tournés : aucune pensée ambigüe n'y est évoquée.

Un intermittent de l'informatique quoi...

Il existe OpenCascade ( opencascade.org ), c'est reliativement libre (lgpl like), il apparaît que des développements fleurissent dessus : http://projects.opencascade.org/projects/ , http://www.opencascade.org/org/community/projects ,
http://free-cad.sourceforge.net/

"C'est le nouveau truc de RMS pour forcer ATI a rendre leur pilotes opensource ?"

Non, c'est un truc qui tue et qui marche au GPL.

POUSSEZ PAS! Je sais par où il faut aller...

Contrairement à certains constructeurs, celui-ci semble être réglo avec les licences : http://www.samsungpc.com/top_faq/58_faqanswer_%20avsnow_info(...)

"est-ce que quelqu'un sait en quoi le fait de mettre une carte mère au frigo fait sauter le mot de passe ?"

Bein, je sais pas, mais je vais essayer de raisonner avec mon peu de souvenirs :)

disclamer : je tente une supposition abracadabrantesque, merci de me corriger si vous voyez une ânerie. Merci aussi de compléter (si besoin :)

Prêt ?

Dixit wikipedia, "On voit immédiatement que la concentration en porteurs dépend fortement de la température. Augmenter celle-ci conduit à augmenter le nombre de porteurs et accroît donc la conductivité" ( 1 ), on est heureux, on sait donc qu'un semi-conducteur conduit moins quand la température décroît. On sait en plus que la ram est composée (en partie) de transistors composés eux-mêmes de matériaux semi-conducteurs ( 2 ). Ces transistors fonctionnent normalement à température ambiante, faire baisser la température revient à faire baisser le nombre de porteurs de courant, ce qui revient à diminuer la conductivité des transistors qui contribuent au rafraichissement des condensateurs ( 3 )( les transistors manquant de porteurs ne peuvent plus propager assez d'énergie jusqu'aux condensateurs ) . Le transistor ayant un comportement différent lorsque la température est basse, la mémoire réagit différement et a de grandes chances de se retrouver réinitialisée (condensateurs tous vides de charges électriques)

Donc, l'information peut être perdue dans une mémoire volatile simplement en abaissant la température du composant, et ce, même si l'énergie nécessaire à la conservation des données est fournie en entrée du composant. Comme les pc de bureau n'on jamais été construits pour fonctionner à 6°C (vous vous voyez dans un bureau à 6°C vous? ;) il ne me parait pas improbable que le simple fait de mettre la carte mère au réfrigérateur réinitialise le bios.

Désolé si j'ai été trop brouillon.

1 : paragraphe niveaux de Fermi de http://fr.wikipedia.org/wiki/Semi-conducteur
2 : http://fr.wikipedia.org/wiki/MOSFET
3 : http://fr.wikipedia.org/wiki/M%C3%A9moire_informatique , "condensateur"

en sus, pour les curieux : http://fr.wikipedia.org/wiki/Transistor#Effet_de_champ


"je ne sais pas si ça fonctionne réellement"
Il me semble que c'est cette technique qui est utilisée par les constructeurs lorsqu'ils implantent un cavalier sur la carte mère : c'est la manière la plus simple: on court-circuite les condos et imanquablement, la mémoire est vide :) . C'est clair que ça fait plus propre quand il y a un cavalier, mais àmha les constructeurs n'ont pas dû s'encombrer avec des principes plus hasar^évolués.

"En tout cas, ce n'est pas une solution que j'essaierais :)" : je ne suis pas aussi catégorique que toi ;)

dans ce cas, court-circuiter le condensateur chargé d'alimenter la ram du bios réduit très fortement la durée d'attente : comme dit sur http://www.projectnews.fr/sections.php?op=viewarticle&ar(...) , une résistance de 10 ohms suffit à éviter d'être patient (10 ohms~queudalle, perso, j'aurais juste pris un bout de fil, les résistances de contact se situant dans les environs du 0.2 ohms, on obtient une résistance de 0.4 ohms, quand on est bourrin, on se refait pas ;).

Bon, bein yapuka faire un chien de garde mécanique qui va appuyer tout seul sur le bouton...

Bon, je vais aller réviser mes devises shadock moi...