M a écrit 2988 commentaires

  • # suspend to disk

    Posté par  . En réponse au journal Booter en 5 secondes !. Évalué à 5.

    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.
  • [^] # Re: h264

    Posté par  . En réponse à la dépêche Sortie du codeur vidéo Dirac en version 1.0.0. Évalué à 2.

    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 ...)
  • # ...

    Posté par  . En réponse à la dépêche OpenMoko annonce la distribution Om2008.9. Évalué à 4.

    # 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...
  • [^] # Re: Bandelettes

    Posté par  . En réponse à la dépêche Sortie du codeur vidéo Dirac en version 1.0.0. Évalué à 5.

    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.
  • [^] # Re: Support de PAFF

    Posté par  . En réponse à la dépêche Sortie de VLC Media Player 0.9.2. Évalué à 2.

    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
  • [^] # Re: Gdium

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 3.

    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.
  • [^] # Re: Gdium

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 3.

    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...
  • [^] # Re: info gdium...

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 5.

    Avec une Mandriva qui est économe en RAM grâce à KDE,
    Ce qui faut pas entendre...
    C'est vrai on est vendredi...
  • [^] # Re: Gdium

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 3.

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

    wince supporte au moins : x86, MIPS, ARM, SH
  • [^] # Re: Gdium

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 2.

    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) ?
  • [^] # Re: Et pour les gens qui veulent utiliser autre chose que tor

    Posté par  . En réponse au journal OVH: "Mais on vous répète qu'un serveur loué ne vous appartient pas !". Évalué à 2.

    sur le second lien y a une doc.

    Par contre le truc, c'est complètement isolé d'internet...
  • [^] # Re: Gdium

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 2.

    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...
  • # Gdium

    Posté par  . En réponse à la dépêche Point sur les ordinateurs ultra-portables. Évalué à 2.

    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, ...).
  • [^] # Re: Comment voir le reportage

    Posté par  . En réponse au journal Ce soir, dans capital .... Évalué à 1.

    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.
  • [^] # Re: User-Agent

    Posté par  . En réponse à la dépêche Chrome, le futur navigateur de Google. Évalué à 2.

    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.
  • [^] # Re: Drôle...

    Posté par  . En réponse au journal Chrome, les applications web et les logiciels libres en question. Évalué à 2.

    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)...
  • [^] # Re: perf

    Posté par  . En réponse au journal Chrome, les applications web et les logiciels libres en question. Évalué à 2.

    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).
  • [^] # Re: ...

    Posté par  . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 1.

    Ben logiquement le plugin close source attaque une bibliothéque du système (libc) et pas directement des appel vers le kernel...
  • [^] # Re: ...

    Posté par  . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 1.

    Je crois que c'est plutot pour s'auto premunir des fuites de memoire.

    Oui mais bon ils savent coder chez google, ils font passer plein de test.
    De plus ils peuvent utiliser des solutions de GC pour éviter les fuites mémoire.
    Là c'est quand même le marteau pillon pour ecraser une noix.
  • [^] # Re: ...

    Posté par  . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 2.

    Bof, il explique que le multithreading pose des problemes dans l'allocation memoire: fermer un onglet ne redonne pas les ressources a l'OS d'ou le browser qui devient de plus en plus lent avec le temps.
    La c'est plus un pb de GC du language qu'un pb du système.
    Si je me souviens bien les process peuvent rendre la mémoire avec munmap ou brk.
    Mais bon faut pas que la mémoire soit fragmenté, d'ou un bon allocateur mémoire et GC.

    Et puis c'est bien beau de vouloir forcement libérer à la fermeture d'un onglet si c'est pour en redemander juste après.
  • # ...

    Posté par  . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 4.

    - et les onglets étant dans différents processus, si un processus plante ou freeze, le reste du navigateur ne tombe pas.
    C'est des processus au sens unix ou des threads ?
    Par ce que bon au sens process ca alourdit quand même pas mal les choses, avec toutes les IPC, les contextes switches, les ressources qui ne sont plus partagées.

    Un thread empêche le freeze et pour le plantage il faudrait un langage/extension qui utilise des exceptions pour se récupérer et tuer seulement le thread fautif.


    - une nouvelle machine virtuelle JavaScript "from scratch" par Google, prétendument la plus performante(?) et que Google espère voir utilisée par les autres navigateurs.
    C'est marant ca me rappelle l'annonce de Squirrelfish...

    Mais oui ca a l'air interresant bien que le gros plus de firefox sont tous les plugins qui existe.
  • [^] # Re: Et bientôt ...

    Posté par  . En réponse au journal Le premier téléphone Android pour bientôt. Évalué à 7.

    L'iPhone est complètement fermé et a un énorme succès.
    Ca vient beaucoup du succès de ipod et pas mal du desing du hard.

    De même pour Windows CE.
    Il profite de leur monopole sur les PC (msn, video wmv, syncro outlook, ...)

    Je pense que tu sous-estimes la volonté de Google là dessus, ils voient dans le téléphone mobile leur "next frontier", la plate-forme de pub et de profiling révée; et quand ils veulent vraiment q
    uelque choses ils y arrivent plutôt bien. :)


    Oui mais ca va pas être évident. Si j'ai bien compris ici google fournisse que le soft. Il va donc falloir convaincre des fabriquant de téléphone d'utiliser leur solution.
    Comme google, ni le fabriquant de téléphone ne sont pas forcement spécialisé dans le kernel Linux embarqué (surtout pour un core/soc spécifique), il faut encore une troisième société (voir par exemple windriver, nec et android).


    Du coté de la communauté/développeur haut niveau la solution google reste peu attrayante. Comme il a été dit plus haut google, c'est une libc maison, une jvm maison et un framework maison.
    C'est pour le moment de la belle techno "propriétaire" qui pourrait aussi bien tourner sur wince ou iphone.
    Si leur libc maison tourne pas sur ton hard ou est buggé, tu fais comment ? Google assure le support technique ?
    Si tu voudrais innover (ben oui tu veux te différencier des autres) et utiliser des trucs qui sont pas présent dans leur framework tu fais comment ?

    En fait leur solution me fait penser a ... WinCE. Tu fais des beau copie coller pour faire marché les parties bas niveau. La partie haut niveau reste assez rigide (modulo quelques magouilles).
  • [^] # Re: Et bientôt ...

    Posté par  . En réponse au journal Le premier téléphone Android pour bientôt. Évalué à 6.

    Oui mais voila, si on est root, rien n'empêche plus de modifier les composants GSM (en gardant la même interface) et les remplacer par une version homebrew (pourquoi pas libre).
    heu ca depend. Tu as bien l'acces root sur l'openmoko et pourtant tu ne peux pas modifier les composants GSM, qui est si je me trompe pas un bete modem sur uart.

    Idem pour les cartes 3G que l'on trouve dans le commerce, elle tourne avec Linux et on a les droits root...

    Contrairement au Freerunner, il est très probable qu'Android connaisse un énorme succès et devienne une des plateformes majeures des portables, avec Windows CE, Symbian et OSX-lite. On va se retrouver dans une configuration similaire à celle des PCs mais avec une situation beaucoup moins monopolistique.
    mouais c'est pas encore dit. Ca dépend pas mal de ce qui sera libéré par google, de la liberté (license) du framework et de ce que les utilisateurs et entreprises pouront faire.
    De plus il faut que l'API proposée (JAVA) par google seduise les developpeurs.

    Pour le moment je suis moyennent convaincu.
  • [^] # Re: Erf

    Posté par  . En réponse au journal Faille de sécurité critique dans Joomla 1.5. Évalué à 2.

    Pour ma culture, il y a vraiement des applis php qui n'ont pas/peu de faille de secu ?

    Parce que bon on retrouve toujours le même genre d'erreur ; pas de validation des données entrantes...
  • [^] # Re: rss

    Posté par  . En réponse au journal La Chine aime Windows. Évalué à 6.

    Tu parles des faux feux d'artifice retransmis à la tv : http://sports.yahoo.com/olympics/beijing/blog/fourth_place_m(...)