M a écrit 2996 commentaires

Sous debian, tu peux utiliser
$debtags search game::board
$debtags search game::card
[...]
$debtags search game::*

pour en avoir certains...

Ha c'est un truc php, moi je croyais que c'était le shell http://packages.debian.org/fr/sid/posh

A noter qu'e17 est disponible dans les paquets debian experimental [1]. Sympa pour faire un test rapide sans compilation.


[1] par exemple deb http://ftp.fr.debian.org/debian ../project/experimental main contrib non-fre
e

mais ffmpeg ne permet pas de le lire sans passer par des codecs binaires
Non, le codec audio (wma9) n'est pas supporté

Ça écrase l'EEPROM, et si tu n'as pas de sauvegarde c'est très difficile à rétablir (et si le rétablissement foire, la carte n'est même plus visible sur le bus PCI d'après certaines personnes qui commentent sur le bug).
Oui, mais il y a souvent des moyen de les récuperer en by passant les stack pci des os et en utilisant des outils du constructeur.


Le problème c'est que ces données ne dépendent pas que du périphérique mais de tout le matos (le BIOS, etc), du coup Intel ne peut pas fournir une sauvegarde qui marcherait pour tout le monde (d'ailleurs leur conseil est pour les personnes possédant une carte concernée de sauvegarder tout de suite le contenu de l'EEPROM).

Bon après il suffit de prendre une copie d'une eeprom de quelqu'un qui a une config similaire a toi et eventuel de modifier un peu le contenu si le format est connu.

PS : t'es sur que l'eeprom de la carte réseau et le BIOS sont liée ?

Pareil ...

Hum, j'ai 2 Go de mémoire. Un boot en cinq secondes voudrait dire que le disque dur lit à une vitesse de 400 Mo/sec.
Oui mais tu sauve pas forcement toute la ram (par exemple du peux jetter tout les cache temporaires des disques) et puis un compression est appliquée (ce qui compresse pas mal les zones ou les données sont constantes).
On pourrait aussi imaginé une sorte de prefetch qui sauve certains bout de la ram qui sont peu modifié quand le kernel n'a rien a faire.

Suspend-to-ram est quand même plus pratique.
Oui, mais s'il y a une coupure de courant ou que tu n'as pu de batterie tu perds tes données, ca consomme, et c'est encore plus chiant a faire marcher que le suspend to disk. Le suspend to ram a besoin de acpi pour s'endormir, ce réveiller. En suspend to disk il suffit "juste" d'avoir des drivers qui sache sauver/restorer l'état des périphériques.

Non l'eeprom ne contient pas un firmware mais des paramètres de la carte (adresse MAC, constructeur, id a présenté sur le bus usb, ...)

Et du coup si certains de ces paramètres sont foireux la carte n'est plus fonctionnelle, jusqu'a qu'on ai remis dans l'eeprom des valeur correcte (souvent avec un logiciel du constructeur).

Ca met déja arriver plusieurs fois : sous windows sur une carte TV et un driver foireux (j'ai pu la réparer grace a linux qui exportait l'eeprom)
sous linux avec une carte réseau 3c905C et AIRONET (la réparation c'est fait en utilisant des logiciel du constructeur (DOS/windows)).

Pour un boot rapide le suspend to disk est quand même beaucoup plus efficace. En plus ca conserve toutes les applications en cours (modulo certains pb du a un freeze prolongé).

Pour moi l'idéal (c'est ce que je faisait quand je devais utiliser windows au boulot [1]) serait de booter de temps en temps (tout les mois par exemple) et sinon d'utiliser le suspend to disk.

Le suspend to disk a quelques limitation par rapport a un boot de zero (par exemple il faut mieux pas utiliser un système de fichier qui était monté sous un autre OS), mais il convient parfaitement dans 90 % des cas.

Faut voir aussi quel puissance est nécessaire au décodage encodage (ben oui on peut faire des algos de fou avec un super taux de compression,mais s'il sont pas décodable en temps réel c'est ennuyeux ...)

# le GSM ne fonctionne plus correctement après quelques heures
# impossible de composer des numéros commençant par * ou #
# le WiFi ne peut se connecter qu'une fois par reboot (devrait être résolu rapidement car beaucoup d'attentions sont portés à la gestion du wifi en ce moment)
# beaucoup d'écho quand une personne appelle un neo

C'est moi ou le wifi est plus prioritaire que la fonction téléphone...

L'algo de compréssion par bandelette est libre autant que tu veux : il suffit de lire les publications s'y rapportant, et d'implémenter les algos décrits.
Tu oublis les éventuels brevets : c'est pareil pour h264(voir même h26x et d'autres codec video) : il suffit de lire la spec s'y rapportant gratuitement disponible sur le site de itu, et d'implémenter les algos décrits.

Ca devrait plus ou moins marcher. Sinon soumet (ou met a jour) un bug sur https://roundup.mplayerhq.hu/roundup/ffmpeg/ avec un extrait de video qui marche pas

performances de la carte graphique ? no sé. par contre, vu que OpenArena est installé par défaut, ça doit pas être mal (mieux que le Acer One, pareil que le EEEpc, soit pour être clair de l' OpenGL 1.2 )

Ils dissent que la carte graphique est une Carte vidéo Silicon Motion SM502, 16 Mo RAM.
Apres avoir telechargé les specs http://www.siliconmotion.com.tw/en/en2/download1c.htm, et ben y a pas du tout d'opengl. C'est une carte 2D assez basique.
L'opengl est soit en soft, soit il y a un truc de louche.

PS : l'omap3 est aussi équipé un dsp à 430-MHz et d'une carte opengl qui peut l'épauler dans les traitements lourds.

Au passage sur ce cortex-A8 (avec le projet beagleboard.), ils ont réussit à décoder des video h264 : http://groups.google.com/group/beagleboard/browse_thread/thr(...)

Quand est il pour le MIPS chinois qui n'a par exemple aucune optimisation assembleur dans ffmpeg...

Avec une Mandriva qui est économe en RAM grâce à KDE,
Ce qui faut pas entendre...
C'est vrai on est vendredi...

http://msdn.microsoft.com/en-us/library/aa479379.aspx :

wince supporte au moins : x86, MIPS, ARM, SH

Bon j'aurais pas du citer openpandora (tout le monde se focalise dessus)...

Quand au autres points, quelqu'un a des infos ?
Spec ?
Performance de la carte graphique ?
importance des optimisations pour ce cpu (peut on faire du multimedia) ?

sur le second lien y a une doc.

Par contre le truc, c'est complètement isolé d'internet...

Sauf qu'OpenPandora n'existe pas encore , alors que le Gdium lui est commercialisé

Et alors ?
Compare par exemple a un zaurus (oui le cpu est moins puissant, mais depuis on a fait des progrès a la fois sur les batteries et la conso des cpu).
En parcourant rapidement la liste des ultra portable il me semble avoir vu des x86 du même poids avec la même autonomie.


PS : pour la carte graphique c'est que de la 2D avec peu de memoire (16 Mo). C'est en gros ce que l'on avait sur nos pc il y a plus de 10 ans...

tiens c'est le processeur chinois clone de mips.

4 h ca me parait pas énorme pour une archi non x86 (a comparer à http://openpandora.org/ qui est une archi arm qui affiche 10h).

D'ailleurs c'est quoi la carte graphique, elle supporte quoi comme accélération ?
On a des specs ?

Le pb avec mips, c'est que je pense que peu d'application multimédia sont optimisé pour (codec video, ...).

J'ai oui dire d'un certain wizzgo qui permettait d'enregistré les émission TNT, puis de les récuperer ensuite sur ton PC.
J'ai pas regarder en detail et je sais pas du tout ce qu'il propose veritablement.

Bref, en général on essaiera de déterminer *dynamiquement* si une fonctionnalité est supportée.
Ben ce que j'ai toujours trouvé dommage c'est que le navigateur n'ai pas un moyen d'indiquer ce qu'il supporte.

Pas d'accord pour le 'de trop': Chrome a une architecture conçue pour être robuste, si ça peut donner un coup de pied au cul aux devs de FF avec leur château de sable actuel pour faire pareil, tant mieux!
je me demande tout de même comment ils vont construire leur sandbox sous unix (la version actuel est windows only) : sous linux dès qu'on veux s'isoler un peu (chroot, changer d'user) il faut avoir des droits particulier.

Par ce que bon même si c'est des processus séparé un processus corompu (par un exploit), peu facilement prendre la main d'autres processus de même niveau avec ptrace...

PS : Les sources de chrome font au total plus 1 Go (dont 600Mo pour chrome et 400Mo pour webkit). C'est enorme (largement plus q'un os comme linux)...

En fait il convertit directement le JavaScript en langage machine (sans représentation intermédiaire, genre bytecode).
C'est pas le principe du jit de tamarin & co.

Et puis le pb du javascript c'est que la puissance de calcul brute n'est pas forcement primordiale : on calcule pas les décimale de PI en js, mais on manipule plein d'élément extérieur au langage (DOM).