legranblon a écrit 599 commentaires

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)

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...