M a écrit 2988 commentaires

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...

Et en perf ca donne quoi ?
Parce que TCP serait deja mieux que UDP, mais les serveurs ne tiendrait pas la charge...

Et voir mon commentaire à ce sujet : https://linuxfr.org//comments/920002.html#920002

s/même/mettre/

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

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

http://www.doxpara.com/?p=1215 (de la personne qui a decouvert la faille) est aussi à lire.

Les slides du même monsieur a black hat sont très intéressante : http://www.doxpara.com/?p=1204

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.

Une clé USB c'est pas un disque flash,
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).

Linux ne "cache" pas deja les systèmes de fichiers avec toute la RAM qu'il peut prendre ?

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.

Oui ca a l'air d'etre le meme SOC OMAP.


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.

Pour plus d'info lire http://elinux.org/BeagleBoard ou la datasheet.

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

Y a pas que les bench qui compte, un comparatif sur les trous de secu serait aussi interessant ...

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, ..).

Sinon au passage www.voyages-sncf.com est telement bien foutu que suivant comment tu demandes un billet (promo ou pas/direct ou pas/...) tu peux avoir des tarifs différents pour le même train/classe/cgv/...

A une époque ils avaient aussi fait un truc sympa qui permettait de voir les prix les plus bas dans un calendrier sur la semaine/moi, mais faut croire que ca marchais trop bien...

Pour cela les sémaphores embarquent un compteur mais pourtant dans la pratique la limite est presque toujours fixée à 1 (un seul processus doit avoir accès à la ressource à un moment donné). Pourquoi alors s'embêter avec des sémaphores complexes et leur compteur quand dans la plupart des cas on ne doit autoriser qu'un seul processus à la fois ?
Parce que dans un mutex c'est le même thread qui fait le lock/unlock alors que ce n'est pas le cas avec les sémaphore.

Le système de fichiers UBIFS qui est spécialisé pour les disques SSD fait l'objet d'une revue de code à la demande des ingénieurs de Nokia pour une future inclusion dans le noyau. Comme le résultat semble positif il est presque certain qu'UBIFS va intégrer le 2.6.27.
UBIFS est pour les flash accéder via mtd, pas pour les disques SSD qui émule en hard une interface de type disque dur standard.

On peut maintenant attacher des périphériques IDE à chaud. Selon l'exemple donné dans la documentation pour changer le périphérique du port idex il suffit de faire un echo -n "1" > /sys/class/ide_port/idex/delete_devices puis d'enlever l'ancien périphérique et de brancher le nouveau en faisant un echo -n "1" > /sys/class/ide_port/idex/scan.
C'était pas déjà le cas en utilisant la nouvelle stack pata s'appuyant sur libata ?

La batterie n'est pas trop juste ?
2-3 H ca me semble assez peu.

D'apres http://www.aspireoneuser.com/, on peut remplacer la batterie par une plus puissante, mais bon ca devient un ordinateur en kit (faut plus de ram, plus de batterie, ...)

Par rapport à ALSA :
-Mal documenté .

C'est pas faut...


-Nécessite des bibiliothèques redondantes augmentant la consommation mémoire . Cela augmente la charge pour les systèmes embarqués .

Pour la conso mémoire tu utilise la bibliothèque salsa. Pour la charge, la bibliothèque ne fait pas grand chose

-Peu d'abstraction du matériel
-Conçu pour une latence 0 dont peu d'applications ont besoin, ce qui rend difficile l'utilisation normale .
-Méthodes de transfert multiples .
-Certains pilotes utilisent des canaux entrelacés, d'autres pas .

Et ben tu choisis celle qui te plait ou tu utilises un code qui te l'abstrait. Au point précédent tu étais à cheval sur la conso cpu et memoire et maintenant, tu voudrais qu'ALSA fasse des choses dans ton dos...

-L'API est basée sur des callbacks qui nécessitent une compétence de haut niveau de la part des programmeurs . Les gotos sont considérés comme mauvais depuis des décennies . Les callbacks sont encore pires .
Heu tu connais pas tres bien alsa. L'API callback d'alsa est malheureusement très limité...
Sinon je te conseil de regardé comment fonctionne asio, portaudio, jack ... c'est que des callbacks...


PS : la prochaine fois avant de troller documente toi un peu

Ben c'est ce qu'il ont fait dans android depuis longtemps...

Pourtant telnet est bien pratique pour se connecter sur des systèmes à ressource limité : genrer bootloader, telephone portable, routeur (IRRC les freboox on un serveur telnet accessible seulement par les techniciens de free), ...

Donc telnet n'est peut etre pas adapter au réseaux publique, mais s'il est limité au réseau privé il peut etre tres pratique...

C'est pareil avec FTP...

D'un autre coté dans le test, ca a l'air le serveur dns suivant qui a l'air fautif (chez moi ceux de free). dnsmasq fait juste proxy dns.

va sur http://www.doxpara.com/ pour tester. Chez moi ca n'a pas l'air bon...