Patrice Mandin a écrit 194 commentaires

Jvas m'ouvrir une bière pour fêter ça, moi...

Et après, une bonne pipe, un supo, et au lit!

... le SP2 de Windows XP, qui devrait notamment améliorer la sécurité de ce système...

[mauvaise foi="on"]
On notera l'utilisation du conditionnel, signe du marketing tout puissant. En gros, c'est même pas sûr que la sécurité soit améliorée après installation du SP2. Dans ce cas, pourquoi l'installer ?
[/mauvaise foi]

Je trouve ça plus qu'excessif. Avec une application qui télécharge, j'ai une charge d'a peu près 20% (8% user, 11% system, d'après top), avec une ligne de 128Kb/s, un taux de transfert de 6Ko/s, et un K6-2/533 sous Linux.

Je me doute que la charge CPU va augmenter avec la vitesse de la ligne et la quantité de données à transférer. Mais tu ne le précises pas...

Dans le cas des cartes graphiques, beaucoup de gens disent que c'est pour masquer le perfs réelles des cartes.

A ce propos, je pense que les cartes vidéos ne sont pas aussi puissantes que leurs constructeurs veuillent le faire croire. En effet, on utilise généralement celles-ci sur des machines avec un CPU (et la RAM) plus rapide que la génération précédente.

J'ai ressenti ça quand j'ai changé de carte vidéo (TNT2 M64, 32 Mo à Geforce 2 Ti, 64 Mo), sans changer de cpu, ajouter de RAM ou autre, ni même changer les drivers pour une version plus récente (1.0-4496). En théorie, sur le papier, le gain devrait être énorme. A l'usage, les jeux ne tournent pas plus vite, c'est tout juste si je peux les lancer dans une résolution plus élevée (qui bouffe plus de RAM vidéo, donc moins de dispo pour les textures ou les objets). L'activation de l'anti-aliasing ne semble pas non plus trop pénalisante.

Je pensais que c'était dû aux softs un peu trop vieux, n'utilisant pas les dernières techniques à la mode, mais la démo de UT2003 (qui rame sur mon système, ce qui n'est pas une surprise) me conforte dans cette idée.

Il faudrait que les benchmarks soient faits par rapport à des machines différentes (CPU, bus, RAM), pas par rapport à d'autres cartes vidéos sur la même machine. Ca permettrait aux utilisateurs de mieux juger le gain qu'ils peuvent espérer en changeant de carte.

J'ai essayé, ayant flashblock activé, je suis surpris du résultat. A part la demande de login/mot de passe, aucune autre information n'est visible. L'exemple type du site à ne pas faire. Dans le même genre, http://moto.racing-live.com/fr/(...) est mieux fait.

Monica Belucci (Perséphone, Matrix, toussa) ?

Imagine par exemple qu'on arrive à modifier génétiquement une plante de manière à ce qu'elle ne soit plus sensible à certains parasites ou maladies, et qu'en conséquence de quoi il ne serait plus nécessaire de traiter le champ avec des tonnes de pesticides et antibiotiques chaque année...

Imagine aussi qu'on arrive à produire des plantes qui pourrait pousser avec beaucoup moins d'eau, ou sur des sols plus pauvres, et qui pourrait du coup survivre dans des régions arides, et donc subvenir aux besoins de millions de personnes souffrant de la famine...

Imagine encore qu'on puisse optimiser la production d'un champ, assurer la récolte, augmenter la production, sans pour autant déverser des tonnes d'engrais dans les nappes phréatiques...

Ca, c'est la théorie, le bon coté des OGM. En pratique, ce n'est pas ca qui se passe, comme pour les brevets logiciels aux USA. Tout le monde serait très content que les choses soient telles qu'on les rêvent. Malheureusement, "bienvenue dans le monde réel" (tm).

Si les machines sont tellement puissantes aujourd'hui, c'est parce que MS a pousse a cette montee en puissance, DirectX par exemple a aide a pousser l'evolution des puces 3D, la prochaine UI de Longhorn dont les constructeurs savent qu'elle utilisera les possibilites des cartes, meme chose, la stack TCP/IP qui offload le travail sur la carte ethernet meme chose,...

C'est effectivement une bonne chose d'avoir le hardware qui décharge le CPU des tâches d'I/O (disque, réseau) ou nécessitant une grande quantité de calculs répétitifs (3D). Ca ne date pas d'aujourd'hui. Le gros problème, c'est quand les constructeurs ne permettent pas cet usage sous d'autres OS que ceux de Microsoft. Il y a pire aussi: le hardware ou le logiciel fait tout le travail (winmodem, winprinter).

Moi, j'ai ces deux là en bookmarks:

http://www.cinema.com/trailers/(...)
http://www.movie-page.com/trailers.htm(...)

Sinon, pour ceux qui s'intéressent aux erreurs dans les films:

http://www.moviemistakes.com/(...)

- Le langage C (Kernighan & Ritchie)
Beaucoup en peu de pages.

- Le livre de Tannenbaum sur le fonctionnement d'un OS Unix avec le source de Minix dedans.
Je l'ai simplement parcouru dans une bibliothèque. Je me demande encore pourquoi je l'ai pas acheté.

- Computer graphics: principes and
Idem que le précédent, il me manque aussi.

- OpenGL 1.2 redbook (en français)
Faut bien commencer quelque part.

c'était un processeur 32 bits à bus mémoire 16 bits

En réalité, c'est un peu plus vicieux. En interne (pour le programmeur), tout est en 32 bits (registres, adressage, calcul). En externe (au niveau des pattes de la puce), on a 24 bits d'adressage (16 Mo addressables), et 16 bits de données (transfert d'un mot à la fois).

La génération 68020 a apporté le full 32 bits.
Le 68030 a intégré la MMU (mais Atari pour le Falcon avait gardé le brochage du 68000 du ST: 24 bits addressables et 16 bits pour les données. Ca la fout mal pour un processeur aussi performant).
Le 68040 a intégré le FPU.
Le 68060 a intégré 2 68040 (c'est bien ça ?).

Petite pub (pour une carte accélératrice pour Falcon, à base de 060):
http://www.czuba-tech.com/CT60/french/present.htm(...)
(Note: il doit en rester une dizaine de disponibles, à l'heure actuelle, pour les intéressés). C'est vrai que ça fait jamais que 7 ans de retard sur les Amiga.

Une refonte du système de textures procédurales (textures générées automatiquement par des algorithmes) a également été faite, augmentant les possibilités et permettant ainsi de créer des textures plus réalistes.

Après avoir vu http://www.theprodukkt.com/(...) on peut se demander s'il ne serait pas utile de pouvoir exporter ces algos pour pouvoir générer soi-même les textures dans son programme. Ca éviterait de devoir utiliser une grosse quantité de données pour stocker les textures. Bien sûr, on peut toujours utiliser des textures classiques en cas de génération d'une texture très complexe. Ca permettrait aussi d'adapter très facilement la taille des textures à la machine qui fait tourner le programme. Et puis, on peut toujours utiliser un cache, une fois les textures générées.

A propos des jeux, je trouve qu'en ce moment, on les utilise plus comme benchmarks de cartes 3D que passer du temps à jouer avec. C'est un peu dommage. Quitte à faire des progs de bench, autant faire une démo. Ce sera moins lourd à télécharger.

a se demander où ils vont chercher leurs adresses

C'est simple, moi une fois, j'ai essayé de mettre mon mail dans le champ de recherche de Google pour voir si elle était disponible publiquement. On peut avoir de drôles de surprises.

Bon ben, pour moi ça marche (tm). Enfin. Après des mois d'attente et d'espérance, avec le driver 0.8.7.

Quelques remarques:

- Le Makefile dans unicorn_usb et unicorn_pci tente de trouver la version du noyau grâce à une commande un peu compliquée, qui ne fonctionnait pas chez moi. Donc j'ai forcé la valeur de PATCHLEVEL à 4 (pour un noyau 2.4), sinon ça compilait pas.

- Dans le ChangeLog, il est précisé deux choses:

> Version 0.8.6
> - Retry isoc atm reads in case of error.

Effectivement, le problème arrivait dans le traitement des interruptions isochrones sur mon contrôleur UHCI. Donc un premier problème qui fut réglé.

> Version 0.8.7:
> - Fixed a crash on low-bandwidth lines (< 320Kbits) by increasing the
> number of ISO packets in the urb's from 20 to 40.

Et là, effectivement, celui-là qui me faisait des kernel oops, car j'avais
une ligne à 128 Kbits/s.

- Ensuite j'ai remarqué que sous une forte charge CPU (pour mon K6-2/533), le driver n'arrivait pas à faire son travail d'initialisation, de synchronisation de ligne, etc... Cela était particulièrement visible au démarrage du système, ou le module était chargé au tout début (car déclaré dans /etc/modules) et tous les services divers qui étaient démarrés même temps empêchait celui-ci d'avoir suffisamment de temps CPU (modem logiciel ? Pas biieeennn). Donc j'ai placé le modprobe du module dans un service lancé en S99z* pour être bien lancé en dernier après tout le monde.

- Malgré cela, il arrive toujours que le chargement échoue quelque fois. Sur ce, je vous laisse, j'ai des porn^W isos à télécharger.

Si c'est un peu mort quand même, les patches datent de longtemps. Pour avoir les versions plus récentes, c'est là:

http://w1.894.telia.com/~u89404340/packet.html(...)
et les patches là:
http://w1.894.telia.com/~u89404340/patches/packet/(...)
et la mailing-list là:
http://lists.suse.com/archive/packet-writing/(...)

Moi, j'ai compilé le noyau et le driver avec gcc 2.95. Pour le noyau, j'ai pris le fichier de config qui est installé avec le paquet kernel_image-xxx dans /boot, comme ça j'ai quasiment la meme config du noyau (c.a.d. avec tout dedans).

Il me reste ppp à mettre à jour afin de pouvoir utiliser pppoe ou bien pppoatm (je m'interroge actuellement sur lequel utiliser). Ya un backport woody pour un ppp avec plugin pppoatm ?

Oui, pas de probleme, et sous Debian, utiliser la commande magique:

fakeroot make-kpkg kernel_headers kernel_image

Faut avoir installé fakeroot, kernel-package. On peut ajouter --initrd pour créer le initrd (fait par défaut pour les Debian).

Sinon, j'ai essayé la nouvelle nouvelle version des drivers, ici:
http://linuxfr.org/~gnurou/10668.html(...) (version 0.8.7)

[blink][size="30"]Et je n'ai plus de kernel oops ! Joie![/size][/blink]
Plus qu'a configurer la connexion maintenant.

c'est cense marcher avec le noyau par defaut (woody) ?

Le noyau 2.4 de la Woody est le 2.4.18, tu devras passer par une recompilation d'un noyau plus récent.

Puisque tu as réussi à les compiler, tu pourrais peut-être contacter l'auteur des drivers (son mail traine dans les sources) pour voir avec lui ce qu'il est possible de faire pour les 2.6.

En ce qui me concerne, pas de nouvelles pour moi, c'est toujours kernel oops :-(. J'attends une prochaine version des drivers.

Bon, je viens d'essayer avec un 2.4.25 tout frais, aucun changement (kernel oops). Ceci dit, si l'auteur du driver ne dispose pas de machine avec contrôleur UHCI, c'est normal qu'il n'est jamais rencontré ce problème. Ce qui est bizarre, c'est que normalement, tout doit être géré de la même manière que pour les contrôleurs OHCI et EHCI.

Ceci dit, je pense vraiment qu'il y a un bug dans le driver usb-uhci du noyau, car je n'ai pas de kernel oops avec le driver uhci (driver plus vieux présent aussi dans le noyau), qui n'apparait qu'avec ce driver, car il utilise une gestion particulière des interruptions.

Je crois que je vais me mettre à la programmation de drivers USB.

Moi, je suis très content de voir ça:

* Various Atari video driver improvements (thanks Patrice!)
* Added Atari CD-ROM support (thanks Patrice!)

C'est MOA qui l'ait fait! La version Atari de SDL est dispo sur mon site, pour les intéressés.

C'est vrai que vouloir porter un soft ou une lib sur une plateforme très peu représentée, ça peut paraître un effort inutile, mais si on veut des softs récents et facilement, SDL ça aide beaucoup (j'ai encore des choses à faire dedans, mais j'y travaille). Et puis on apprend des choses à vouloir programmer proprement.

Vu tes messages, je dirai que tu n'as pas les modules qui gèrent l'USB de chargés. Un modprobe usb-uhci devrait suffire. J'ai essayé les noyaux 2.4.22 à 2.4.24. Le driver est fait pour fonctionner à partir d'un noyau 2.4.21 ou plus.

Le répertoire patches/2.4.21-xxx du driver contient des patches à appliquer au noyau 2.4.21 pour les drivers ohci et uhci. Le patch pour l'ohci est présent dans les versions 2.4.22 et supérieures. Le patch pour l'uhci doit toujours être appliqué. Ceci dit, ca plante toujours avec le patch.

Enfin, je n'ai pas encore essayé le 2.4.25 (ni le 2.6 d'ailleurs) car il ne semble
pas y avoir de grosses modifs faites au niveau de l'USB, mais on ne sait jamais.

Si tu utilises le module unicorn_usb_eth au lieu de unicorn_usb_atm, tu n'as pas besoin d'ajouter le support atm du noyau, ni de la librairie linux-atm, ni du plugin pppoatm pour ppp.

Avec unicorn_usb_eth, tu te retrouves avec un périphérique Ethernet sur ta machine appelé dsl0, configurable par pppoe (donc ajouter le support de ppp over ethernet dans le noyau).

PS: quel type de contrôleur USB as-tu :ehci (usb 2.0), uhci ou ohci ?

tu ne vas tout de même pas jeter tout ces fabuleux gadgets debian ( tasses de thé, poster, t-shirt, pull, polo de rugby, horloge, boîte à lunette, assiette, petite cullière, tapis de souris, stylo plume, sous-verre [ ça c'est les cd de bêta 1 de l'installer qui sont obsolète :D ], chausson, montre, chaussette, briquet, couche, brosse à dent, tatouage, bague, écharpe, préservatif, portefeuillle, couette + taie d'oreiller, caleçon, ... et puis aussi : systeme d'exploitation !)

C'est vrai que ce serait dommage de perdre tout ce tas de réponses modulaires aux problèmes de la vie moderne (Fight club tm) :-)