Sébastien Koechlin a écrit 849 commentaires

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.

Cout de la solution :
n noeuds
n robotiques
bandes SDLT/LTO ...
logiciel de sauvegarde gérant des sauvegardes incrémentales / différencielles

Le problème, c'est qu'une bande SDLT, ça fait dans les 500 Go, imaginons un robot avec 32 slots, on a une capacité de 16 To, ce qui est loin de la capacité totale. Installer 50 robots n'est pas une solution viable, à cause du coût et de la maintenance que cela impose.

Et puis vu le budget qu'il est possible de dégager d'une boite au lettre de FAI (quelques dizaines de centime d'euros par mois), le robot est loin d'être remboursé, en plus de toute l'infrastructure pour rendre le service.

Si on considère 100 Mo de taille moyenne de boite par client, ça fait un robot pour 160.000 clients.

- la redondance ?
La redondance n'est pas une méthode de sauvegarde !!! Et bien évidement, personne ne s'amuse à faire du RAID0, sur de tels volumes, on a toujours du SAN et/ou du NAS avec du RAID 1 ou du RAID5, mais le RAID ne fait pas grand chose face à un incendie ou un formattage sauvage.

- la mutualisation ?
La mutualisation ne change rien aux volumes à sauver, ce qui est le problème ici.

Ce n'est pas la taille qui compte, bien heureusement, sinon toute entreprise avec des To et des To de données à traiter verraient des gouttes de sueur froide couler sur le front de leurs admins régulièrement.

Je ne suis pas du tout d'accord:
- Le volume de donnée à un très fort impact sur le coût de la sauvegarde.
- Les données à sauver ont aussi une valeur qui n'est pas liée au volume.

Dans un message au dessus quelqu'un proposait d'ajouter une baie de disques à la baie nominale, or une baie de disque à un coût énorme, si on veut avoir une unique sauvegarde, il faut pratiquement doubler le coût du stockage. Si on veut faire des sauvegardes incrémentales, conserver quelques snapshot, alors il faut encore augmenter la volumétrie, et donc le coût.

Si ça se justifie tout à fait pour une base de gestion commerciale, avec les clients et les commandes à traiter; informations qui ont généralement un prix énorme pour une entreprise, c'est beaucoup plus discutable pour des boites aux lettres qui ont une valeur très faible.

Il y a énormément de moyens de sauvegarde et de récupération des données adaptés aux différents types de données à stocker.

Que proposes-tu pour ce cas précis ?

Pour un petit FAI qui n'a que 700 Go de mail, c'est encore envisageable; mais lorsque ça tourne autour de 700 To de mail, je ne vois pas trop quelle solution permettrait de faire des sauvegardes.

La traduction de Firewall, litéralement "Mur à l'épreuve du feu" est généralement "Pare-feu".

L'analogie utilisée est exactement l'inverse du mur de feu. Le feu symbolise les attaques néfastes, et le pare-feu protège de ces attaques.

PS: bon et puis comme on est quand même sur linuxfr ici, petite question finale: à quand les install party "dans le noir"??? ;-)

Avec un menu surprise ? Tiens, j'ai eu une Redflag Linux en xfs (c'était la semaine asiatique).