Sébastien Koechlin a écrit 854 commentaires

Un critère très important est la focale. Regarde à quelle distance tu peux installer ton projecteur du mur ou de l'écran.

Si tu n'as pas beaucoup de recul, un appareil mal adapté va te donner une toute petite image.

Ensuite si c'est destiné à être déplacé souvent, la facilité d'utilisation peut aussi entrer en compte. Quoi de plus pénible que de passer à chaque fois 15 minutes à chercher dans tous les sens pourquoi est-ce qu'il n'y a pas d'image.

J'ai acheté il y a un moment un NEC VT-47 ( http://www.nec-pj.com/products/vt/index47.html ) et je suis franchement très content. Il ne fait pas trop de bruit; il me donne une image qui prends tout le mur avec le recul dont je dispose, il corrige automatiquement la déformation trapézoïdale en fonction de l'inclinaison du projecteur, et il a un bouton correspondant à chacune des entrées pour ne pas passer 15 minutes à configurer.

La résolution n'est pas terrible, mais c'est un ancien modèle, et pour un film, ce n'est pas très génant.

S'il est prévu de pouvoir le désactiver, il ne doit pas être possible de contourner cela simplement de manière logiciel.

Il faut probablement désassembler le BIOS et écraser le code qui désactive le VT. Il doit y avoir une séquence caractéristique d'une dizaine d'octets qui permet de retrouver l'endroit où cela est fait.

Flasher ensuite le BIOS avec une version modifiée n'est peut-être pas trivial non plus.

Comme beaucoup de monde, je n'ai plus de montre, finalement ça ne sert à rien sinon à se stresser.

Bon, j'ai fais une légère approximation.

Les normes actuelles d'Unicode et par conséquent d'UTF-8, UTF-16 et UTF-32 ne définissent pas de code supérieur à U+10FFFF. Mais l'algo qui permet de représenter des caractères de valeur supérieur à U+007F utilisé en UTF-8 peut être étendu pour aller jusqu'à U+7FFFFFFF sans soucis (la limitation est artificielle), ce qui fait 2^31.

Absolument pas.

UTF-8 et UTF-32 sont tous les deux capables de contenir les mêmes caractères, à savoir environ les 2^32 premiers de la table unicode.

La seule différence entre UTF-8 et UTF-32, c'est que les caractères des pages basses consomment moins d'octets en UTF-8.

Premièrement, Adobe n'a pas sorti de mise à jour de flash, il a sortie une beta. Comme son nom l'indique, elle n'est pas encore de qualité à être installé partout.

Ensuite flash implémente un décodeur vidéo (format FLV), chose utilisé par Google, Youtube et Dailymotion par exemple, mais ce n'est pas pour autant du vectoriel, Wikipedia a plus de détail sur ce codec: http://en.wikipedia.org/wiki/FLV

Je suis désolé, mais ton argument est stupide.

Tu as fais une fausse manip et tu as écris un nouveau fichier sur le serveur web, c'est de ta faute.

Appeler explicitement index.php est contraite à l'architecture du Web qui veut que:

- Une URL ne change pas même si la techno change derrière.
- Les adresses ne doivent pas contenir des informations d'implémentation, ici PHP.
- Le client n'a pas à réclamer explicitement l'index d'un répertoire. Il doit demander une ressource sans se préocuper d'une distinction fichier/répertoire ou autre. Dans ce cadre, index n'apporte rien, au contraire.
- Le fait d'associer l'espace des URLs à une arborescence disque réelle contribue à la confusion entre les deux.

Cela n'a rien à voir avec une URL plus jolie qu'une autre..

A moins d'avoir une alimentation très complexe, ce dont je doute, tu peux probablement trouver un transformateur compatible pour pas très cher.

Dans une boutique comme Selectronic place de la Nation, ils te trouveront un transformateur suffisement puissant dont on peut régler la tension, la polarité et le connecteur.

Si le connecteur n'est pas courant, il est toujours possible de re-souder celui de ton ancien transfo sur le nouveau.

J'ai un pack de 5 CD Infomagic rouge. Ceux qui contenait les images de Sunsite & Co, avec les sources des kernel 1.1 et 1.0. et quelques distributions, en particulier la première Slackware que j'ai installé.

On s'organisait à l'école pour envoyer quelqu'un au monde en tique en acheter un lot dès qu'ils les recevaient.

Cette question est abordée dans les commentaires du blog:
http://blogs.adobe.com/penguin.swf/2006/10/beta_is_live.html(...)

Jim wrote:
When there is a JavaScript menu roll-over or any object that is supposed to display over everything else, it is still pushed behind any flash objects.(...)

That sounds like a WMODE issue. (Plugins usually write direct-to-screen, but some browsers offer to pipe plugin rectangles to the browser's own compositing buffer for layering, through use of a WMODE attribute in the OBJECT/EMBED tags to compliant plugins.)

I don't see this mentioned in the release notes, but it's both a plugin dependency and a browser dependency, and I'd be a little surprised if it could get into an early release, and it might not even be possible in some browsers in the final release.

Je regrette aussi qu'il n'y ait pas de version PPC, mais d'après les blogs des gens qui bosse sur la version Linux; c'est loin d'être aussi simple qu'une recompilation. Ils ont aussi dit qu'ils ne comptaient pas sortir une version 64bits (en tout cas pas tout de suite) pour les mêmes raisons.

Il y a pas mal de routines optimisées en assembleur qui sont difficiles à porter. Lorsqu'ils recrutaient des développeurs Linux, l'assembleur 386 était au programme (686 plutôt, MMX, SSE & compagnie).

Il existe une version PPC pour MacOSX, je l'utilise de temps en temps, mais vu les performances qu'elle a, j'imagine qu'elle est nettement moins optimisée et très dépendante de l'OS

Le site RedHat maintenait, (je ne sais pas si c'est toujours le cas), une matrice de compatibilité hardware, permettant de savoir quel était le matériel supporté, et dans quel version de leur distribution.

Je pense que le bus AGP n'est pas pertinent. A moins d'avoir une pénurie de RAM sur la carte vidéo, ou une carte vidéo sans RAM, beaucoup de jeux en 3D et en particulier les anciens sont capables de stocker l'intégralité des textures nécessaires dans la RAM vidéo.

Si on part de l'hypothèse que toutes les textures sont déjà dans la carte vidéo, le fait de travailler en 16 bits joue:

- Sur la RAM vidéo occupée par les textures
- Sur la RAM occupée par le buffer de rendu
- Sur la bande passante occupée par les lectures de texture
- Sur la bande passante occupée par les écritures dans le buffer
- Sur la bande passante occupée par les lectures du RAMDAC

A moins que les cartes, pour une raison de simplification, fasse une conversion transparente 16bits -> 32bits, on peut donc effectivement s'attendre à une grosse amélioration de vitesse de rendu pour les scènes ayant un lourd rendu en textures.

Pour ce qui est de la complexité, en particulier le nombre de polygones, je pense que ça ne change pas grand chose aux calculs qui doivent être fait, et donc à la vitesse de rendu.

Un petit mot pour nous dire de quoi il s'agit ?

Java2 correspond en grande partie à ton besoin:

Se connecter à une base de donnée: Java viens avec une API simple nommée JDBC qui est très largement supporté par pleins de bases; cela te permettra d'adapter très facilement le logiciel le jour ou tu voudras changer de base de donnée.

Afficher des résultats: si tu penses à une interface graphique, Java vient avec une API un peu complexe je pense, nommée SWIG qui fait tout cela sur toutes les plateformes.

Fonctionnel sans installation: il est possible de distribuer les applications sous forme d'un fichier JAR qui est un fichier au format zip contenant le code, les ressources et un fichier texte décrivant quelle classe doit être lancée lorsque le JAR est exécuté. Il est nécessaire d'avoir Java2 (la version Runtime) installé sur l'OS. Sous windows, il suffit de double-cliquer sur le fichier JAR.

Multiplateforme: il faut voir si Java2 est disponible sur toutes les plateformes que tu veux utiliser. Il est peut-être possible de réduire l'application pour qu'elle tourne sur la version mobile, ou d'avoir deux interfaces de sortie selon les disponibilités.

Assez standard pour vite trouver les compétences: Java est extrèmement répandu en ce moment.

Si l'intérêt d'un jeu est conditionné par le fait qu'il est en 3D, j'ai bien peur que ça ne vole pas haut. Si seuls les graphiques en 3D sont beaux, ça n'a pas de sens.

Ce qu'il manque, à mon avis, à ce jeu, c'est un graphiste qui retravaille les images pour en faire un tout cohérent. On peut aussi faire des choses très moches en 3D. Le fait que le rendu final soit sous la forme d'une image en 2D n'empèche pas le graphiste de travailler les modèles en 3D.

Les jeux commerciaux comme Civilisation, Sim-City 2000, Settlers et pleins d'autres ont fonctionnés en 2D sans vraiment de critique du graphisme.

Pratiquement tous les jeux qui sortent en ce moment sous Linux sont des jeux en 3D qui posent beaucoup de problèmes à énormément de personnes. Personnellement, je n'installe jamais les jeux qui sont en 3D parce que le support est beaucoup trop variable; d'une machine à une autre, d'une révision de X à une autre, d'une configuration ou d'une distribution à une autre.

Tu crées un fichier .screenrc qui contient:

caption always "%{=b wK}%-w%{=b rY}%n %t%{-}%+w %=%{= wB}%c%{-} "


Screen affiche entre autre l'heure en bas, mis à jour toutes les minutes; comme ça ça génère du traffic.

La lecture du manuel ne fait pas de mal; pour changer les couleurs en particulier.

Illiad faisant un procès à tous les sites d'annuaires ayant annu dans le nom, je pense que l'on pourra reposter une news dans quelques temps avec le nouveau nom de cet annuaire.

http://fabienma.club.fr/free/

Est-ce que des personnes du site peuvent nous expliquer quels sont les différences avec les autres sites existants sur ce sujet ? En quoi cet annuaire se distingue ?

Pareil ici. Les EJBs, c'est peut-être bien; mais on ne trouve pas de développeurs suffisement compétents pour les utiliser. Ca fini toujours en chaleur et lumière tellement les codeurs PHP promus experts J2EE nous produisent des cochonneries. En prime dans les 2.0, les pièges sont un peu nombreux.

Pour l'instant Spring a bien la cote, et Struts est toujours dans les cartons parce qu'il est bien maitrisé et qu'on n'a pas trouvé un truc dont le coût d'apprentissage justifie la migration.

Hum, l'informatique ne vit pas par l'informatique. Elle s'applique dans de très nombreux domaines; finance, industrie, télécoms, infographie, gestion clients, jeux...

Il se trouve que la téléphonie est un gros consommateur d'informatique, et cela augmente encore avec la migration vers la VoIP.

Ta vie doit être triste s'il n'y a aucune application de ce que tu fais. :-)

Et puis je suis peut-être frustré et aigri mais pas anonyme.

C'est bête parce que ça veut aussi dire (entre autre) Calling Line Identification. Dont dérive le CLIP (Calling Line Identification Presentation) qui est la présentation du numéro de l'appelant.

Pour une liste francophone, ce n'est pas terrible d'utiliser une abréviation en anglais.

Il faudrait peut-être s'inscrire à l'a.a.a.a.a.a.

Concernant les systèmes de fichiers adaptés aux mémoires non volatiles; la réponse n'est pas simple.

Tous les supports ne sont pas égaux. La mémoire Flash doit être effacé et écrite par blocs, il vaut éviter de fatiguer prématurément certaines cellules en les modifiant en permanence. Comme pratiquement tous les appareils travaillent en FAT qui demande une ré-écriture continuelle de ces secteurs, les fabriquants ont carrément intégré dans les controleurs un mécanisme d'indirection pour faire une rotation des cellules.

Pour la MRAM, on ne connait pas encore très bien ses limites, ou en tout cas elles ne sont pas publiques. Il y a des FS adaptés à la Flash, qui ont été cité. Si la MRAM ne souffre pas de ces limitations, alors ils ne seront probablement pas adaptés. Un autre facteur a prendre en compte est la garantie d'atomicité des écritures; que se passe-t'il lorsqu'il y a une coupure au milieu d'une écriture ? Si l'écriture est faite octet par octet, ça va compliquer les choses, on va avoir beaucoup de mal à retrouver où est-ce que l'on s'est arreté, si c'est par secteur de 512 octets, c'est comme un disque ordinaire...

Les FS classiques ne sont plus vraiment optimisés pour la géométrie des disques. Aujourd'hui je ne pense pas que l'on fabrique encore de disques qui publient leur géométrie réelle; on tombe toujours sur une géométrie logique qui permet de booter, ensuite le FS se base sur une couche d'abstraction qui fonctionne en blocs logiques.Les FS n'ont donc pas spécialement de contre indication pour leur usage sur de la MRAM.

A la base, ce n'est pas LVM le problème, c'est que tu utilises un système de fichier moderne et performant, capable de grossir.

Si tu avais choisi un truc lent et obsolète comme le FAT qui est lisible partout, tu n'aurais pas pu étendre tes partitions, monter à 350 Go.

Je ne suis pas certain que ce soit ce que tu cherches.

Mais non, ici il fait déjà un peu moins chaud.

A non pardon, on me dit dans mon oreillette que c'est Richard qui a mis la clim plus fort.

Pareil, j'ai vendu un objet, en mettant une photo, et je n'ai eu aucun problème sous Linux.