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.
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.
- 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.
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).
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.
Et ne parlons pas de theora qui au dernière nouvelle reste du ON2 VP3 dont les techno sont dépassé (surtout pour faire du streaming video a forte compression).
Et dire qu'a un moment chez xiph ils devaient nous pondre un codec a ondelette super performant...
Après, surtout si on a une grosse connexion comme ça, on commence peut-être par filtrer les adresses auxquelles le resolver-cache est autorisé à poser des questions et recevoir des réponses, plutôt que d'autoriser n'importe qui à lui répondre n'importe quoi.
C'est difficile :
- dans les fausses réponses que tu envoies tu peux même une adresse IP source que tu veux (donc pas filtrée).
Et je suppose que "court-circuiter" le contrôleur interne, au profit d'un FS plus performant (lesquels ? je ne suis pas très calé à ce sujet) n'est pas possible ?
Oui tu n'a pas acces à l'interface flash bas niveau.
Et/ou qu'il n'existe pas (encore ?) de modèle laissant le wear-leveling être effectué par le FS ?
Les memoires XD, mais bon on a pas non plus d'algo de wear-leveling sous Linux (a part peut etre UBI).
Donc les algos de répartition d'écritures sont dans le controlleur et il n'y a pas besoin de fs particuliers pour avoir une durée de vie correcte sur un ssd.
Faut arrêter de dire n'importe quoi.
Même s'il y a des algos de répartition d'écritures, un fs qui récrit plusieurs secteurs à chaque opération usera beaucoup plus vite la flash que celui qui récrit le strict minimun.
Moi j'ai vu le "moyen" (lien pour accéder malgré tout aux vidéos) , mais aucune vidéo ne se lance dans le cadre noir prévu à cet effet...
Ca c'est leur serveur qui ne tienne pas la charge.
Logiquement c'est des flux mms avec du wmv3/wma2. Encore faut il avoir le bon plugin qui lance mplayer, vlc & co.
Mais comme celui ci, le logiciel doit contenir des bon gros drivers proprio.
Je sais pas trop : je sais que la 3D est proprio [1] mais je crois que le reste est libre. Faudrait regarder plus en detail http://elinux.org/BeagleBoard#Code
[1]
OMAP3530 used on BeagleBoard contains a graphics accelerator (SGX) based on the SGX core from Imagination Technologies. PowerVR SGX530 is a new generation of programmable PowerVR graphics and video IP cores. Linux drivers haven't yet been released publicly. We expect the drivers to be publicly available by the end of 2008. Only the kernel portions will be open source. The PowerVR folks will provide binary user-space libraries.
Ben le machin boot sur NAND, usb, uart et sd-card.
Pour l'usb je sais pas si c'est du device ou host.
Mais ca doit etre faisable facilement par sdcard.
Et pour 149 $ (disons 100 €) on peut avoir : http://beagleboard.org/ .
Cette carte est plus puissante : arm Cortex-A8 @ 600MHz (+dsp et acceleration video), 128 MB de ddr, 256 MiB de flash.
A comparer a ce que propose cette solution
# Atmel AT91RM9200 processor (ARM9 core, includes MMU) @180 MHz
# 32MB SDRAM
# 8MB SPI flash memory
Je me souviens que dotclear gérait très mal la base de donné à une époque et que les développeurs avait eu du mal à reconaitre le problème (histoire du standblog sur apinc et ajout d'index par lucas). Mais j'arrive plus à trouvé le lien.
Et sinon au lieu de faire un truc qui n'apporte rien a part te faire perdre du temps; ceux du personnel du magasin ; et ceux des clients qui attentent que le guignol qui est devant eux à la caisse en finisse pourquoi ne pas etre plus constructif ?
Par exemple distribué des tracs pour informer les gens de leur droit (les grandes surfaces ne feront rien tant qu'une masse critique ne protestera pas).
Ou encore changer de magasin et s'orienter vers de plus petite structure (marché, petit commerce, ..).
[^] # Re: ...
Posté par M . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 1.
[^] # Re: ...
Posté par M . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 1.
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 M . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 2.
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 M . En réponse au journal Chrome, le futur navigateur de Google. Évalué à 4.
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 M . En réponse au journal Le premier téléphone Android pour bientôt. Évalué à 7.
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 M . En réponse au journal Le premier téléphone Android pour bientôt. Évalué à 6.
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 M . En réponse au journal Faille de sécurité critique dans Joomla 1.5. Évalué à 2.
Parce que bon on retrouve toujours le même genre d'erreur ; pas de validation des données entrantes...
[^] # Re: rss
Posté par M . En réponse au journal La Chine aime Windows. Évalué à 6.
[^] # Re: Ogg vorbis la seule alternative?
Posté par M . En réponse à la dépêche DRM et Tivoisation : 3 cas Apple, Yahoo Music, M6 replay. Évalué à 4.
Et dire qu'a un moment chez xiph ils devaient nous pondre un codec a ondelette super performant...
[^] # Re: Et SCTP ?
Posté par M . En réponse au journal BIND, 2ème édition. Évalué à 3.
Parce que TCP serait deja mieux que UDP, mais les serveurs ne tiendrait pas la charge...
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . En réponse au journal Linux presque entièrement en RAM. Évalué à 3.
[^] # Re: Bah oui...
Posté par M . En réponse au journal BIND, 2ème édition. Évalué à 3.
PS : c'est possible parce que c'est de l'UDP (contrairement au SMTP) et que tu n'attends pas de réponse.
PS2: une solution serait de forcer le passage à tcp, mais ça passera pas à l'echelle
[^] # Re: Bah oui...
Posté par M . En réponse au journal BIND, 2ème édition. Évalué à 2.
C'est difficile :
- dans les fausses réponses que tu envoies tu peux même une adresse IP source que tu veux (donc pas filtrée).
# ...
Posté par M . En réponse au journal BIND, 2ème édition. Évalué à 4.
Les slides du même monsieur a black hat sont très intéressante : http://www.doxpara.com/?p=1204
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . En réponse au journal Linux presque entièrement en RAM. Évalué à 3.
Oui tu n'a pas acces à l'interface flash bas niveau.
Et/ou qu'il n'existe pas (encore ?) de modèle laissant le wear-leveling être effectué par le FS ?
Les memoires XD, mais bon on a pas non plus d'algo de wear-leveling sous Linux (a part peut etre UBI).
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . En réponse au journal Linux presque entièrement en RAM. Évalué à 3.
Faut arrêter de dire n'importe quoi.
Même s'il y a des algos de répartition d'écritures, un fs qui récrit plusieurs secteurs à chaque opération usera beaucoup plus vite la flash que celui qui récrit le strict minimun.
[^] # Re: Ssd supporte un nombre d ecriture limitee?
Posté par M . En réponse au journal Linux presque entièrement en RAM. Évalué à 3.
Si c'est meme de la flash NAND.
y'a pas de wear-leveling hardware.
Bien sur que si. Apres les algos venant des clefs pas très cher ne sont pas forcement tres efficace...
Mais c'est pareil sur les disque ssd (ou sd-card).
# hum
Posté par M . En réponse au journal Linux presque entièrement en RAM. Évalué à 10.
[^] # Re: autres moyens
Posté par M . En réponse au journal france3 et Microsoft Silverlight. Évalué à 3.
Ca c'est leur serveur qui ne tienne pas la charge.
Logiquement c'est des flux mms avec du wmv3/wma2. Encore faut il avoir le bon plugin qui lance mplayer, vlc & co.
[^] # Re: mieux
Posté par M . En réponse au journal Un petit ordinateur sous linux à faire soi même. Évalué à 3.
Mais comme celui ci, le logiciel doit contenir des bon gros drivers proprio.
Je sais pas trop : je sais que la 3D est proprio [1] mais je crois que le reste est libre. Faudrait regarder plus en detail http://elinux.org/BeagleBoard#Code
[1]
OMAP3530 used on BeagleBoard contains a graphics accelerator (SGX) based on the SGX core from Imagination Technologies. PowerVR SGX530 is a new generation of programmable PowerVR graphics and video IP cores. Linux drivers haven't yet been released publicly. We expect the drivers to be publicly available by the end of 2008. Only the kernel portions will be open source. The PowerVR folks will provide binary user-space libraries.
[^] # Re: mieux
Posté par M . En réponse au journal Un petit ordinateur sous linux à faire soi même. Évalué à 2.
Pour l'usb je sais pas si c'est du device ou host.
Mais ca doit etre faisable facilement par sdcard.
Pour plus d'info lire http://elinux.org/BeagleBoard ou la datasheet.
# mieux
Posté par M . En réponse au journal Un petit ordinateur sous linux à faire soi même. Évalué à 5.
Cette carte est plus puissante : arm Cortex-A8 @ 600MHz (+dsp et acceleration video), 128 MB de ddr, 256 MiB de flash.
A comparer a ce que propose cette solution
# Atmel AT91RM9200 processor (ARM9 core, includes MMU) @180 MHz
# 32MB SDRAM
# 8MB SPI flash memory
[^] # Re: benchmark
Posté par M . En réponse au journal Dotclear 2.0 is août. Évalué à 3.
[^] # Re: benchmark
Posté par M . En réponse au journal Dotclear 2.0 is août. Évalué à 2.
# ...
Posté par M . En réponse au journal Protection de la vie privée et inspection visuelle des bagages à main dans les supermarchés. Évalué à 3.
Par exemple distribué des tracs pour informer les gens de leur droit (les grandes surfaces ne feront rien tant qu'une masse critique ne protestera pas).
Ou encore changer de magasin et s'orienter vers de plus petite structure (marché, petit commerce, ..).