benoar a écrit 4229 commentaires

D'après http://www.adobe.com/products/player_census/flashplayer/ c'est même 99%, mais des Internet-enabled desktops, c'est à dire sans compter les trucs mobiles.

Flash sous linux sur arm, ça marche.

Un soft proprio fait pour une version de linux précise, avec telles libs, pour tel jeu d'instruction ARM, avec telle endianness. Mouai, je suis pas convaincu (de toutes façons je ne le serai jamais par un soft proprio, donc bon ...)

Moi ce que je n'aime pas chez ceux qui critiquent cette décision en disant "mais Apple est aussi pourri que Adobe", c'est que ça n'avance à rien : oui, bon, et alors ? Vous proposez quoi ? De continuer comme toujours avec Flash ?

Apple pousse des standards comme HTML 5 sur sa plateforme, ce qui aidera un paquet de monde à se libérer de Flash. Certes, les utilisateurs de la pomme seront toujours beaucoup enfermés, mais déjà un peu moins. Moi, ce n'est pas mon problème, mais pousser au développement d'HTML 5, ça j'aime bien.

Oui, effectivement, c'est ça, je viens de tester. Un pointeur vers des tableaux de dix double, en bon français.

Les pertes de perf pour la virtualisation se font uniquement pour ce qui est appels systèmes et tout ce qui est en relation avec la hard (en gros, d'après ce que j'ai compris). Donc, un code (en userspace) qui ne fait que de l'algo tournera exactement à la même vitesse qu'en natif.

Après, il faut voir aussi que d'autres choses peuvent se passer "dans ton dos" : comment est mappée la mémoire, les context switch, etc, et là dessus tu vas peut-être perdre un peu. Penser aussi aux malloc qui passent par un appel système : si t'en fait vraiment beaucoup, tu peux voir une petite différence. Faudra alors peut-être penser à faire ton propre allocateur (ou tweaker celui de la libc).

Bon, tout ça vient de mon analyse théorique de la chose, je n'ai pas vraiment d'expérience là-dedans. Il y a peut-être des choses à corriger.

Ah oui, sans block layer tu ne pouvais pas accéder à grand chose niveau stockage ... Il n'était pas sélectionné par défaut ? Tu as fais toute la config à la main ? Tu utilises quelle distro ?

Bon, désolé si j'ai l'air d'avoir un ton un peu péremptoire, je suis un peu comme ça quand je donne mon avis. Je comprends tout à fait que tu envisages plein de trucs différents, et que tu ne sais pas si ça va marcher.

Pour la solution "port parallèle", je ne critique pas du tout : c'est très bien si ça marche ! C'est changer vers une autre solution sans avoir toutes les connaissances "appropriées" qui me semble risqué.

Et effectivement, le FPGA peut être une bonne méthode. Mais j'y connais encore moins, alors je te laisse continuer à chercher. Bon courage !

Petit remarque : dans un initramfs, le noyau var chercher /init; pas /sbin/init. C'est l'initrd qui va, en général, une fois son boulot fait, chercher /sbin/init sur le système de fichier racine (histoire de rester "cohérent").

De mon point de vue, si tu veux leur montrer des solutions alternatives, c'est aussi en concertation avec. Ce sera plus facile de comprendre les raisons de leur choix, et de voir ce qui sera le mieux adapté à vous tous. Bon, d'un côté, si c'est dans l'aérospatiale, "rationnel" n'est peut-être pas le maître mot ...

Déjà, je te conseillerais de de concentrer sur le problème soft avant d'aller voir les histoires d'interco. Si ton bouzin marche déjà bien comme ça, garde le port parallèle, et essaye de faire un soft en python.

Si tu veux changer l'interco et passer à autre chose que le port parallèle, il te faudra de bonnes connaissances en électronique, ce dont je ne suis pas sûr que tu aies. La plupart des micro-contrôleurs dont on parle au dessus tournent eux-mêmes à une fréquence inférieure à 20MHz, et mes petites recherches sur l'Arduino (un micro-contrôleur bien connu des bidouilleurs) montrent qu'il ne peut pas vraiment dépasser les 10MHz pour les signaux en sortie. Même un port parallèle à 20MHz, c'est hallucinant (c'est pas pour rien que tes signaux sont pas très carrés). Bref, si tu veux encore plus que ça, va falloir aller voir des gens qui s'y connaissent. Ou passer à un bus standard, genre PCI, mais là va falloir changer l'interface de l'ASIC.

En plus, bit-banger à 20MHz ça me paraît déjà énorme. L'USRP en:USRP fait du 128MS/s (en analogique 14 bit, c'est vrai) et c'est du matos super haut de gamme. C'est pas pour rien que la boîte s'est fait racheter par National Instruments, d'ailleurs (qui produit ... LabView !). Bref, monter au dessus de 20MHz, pour quelqu'un qui n'a pas de connaissances en électronique, c'est quasi-impossible.

Voilà, c'est pas pour te démotivé (t'as l'air de bien aimer ça !) mais je te conseille d'aller en parler à des gens qui "savent mieux" (et je te le redis, j'en connais pas non plus des tonnes) avant de te lancer dans le truc.

Je comprends tout à fait ta motivation de passer à quelque chose de libre :-)

Par contre, en ce qui concerne le port, je pense que tu as dû mal capter quelque chose : si vous utilisez un protocole physique spécifique, ce n'est pas en te tournant vers de l'USB ou de l'ethernet que tu trouveras une solution : ils ont des protocoles physiques bien définis, incompatibles avec votre matos. Le port parallèle c'est bien pratique parce que c'est un port qu'on peu utiliser de manière "générique", à bas niveau, mais ce n'est pas le cas pour tous les protocoles modernes.

J'ai l'impression également (par la manière dont tu t'exprimes) que tu es plutôt débutant dans le domaine (je ne suis pas du tout un expert non plus). Je pense que pour l'interco avec tes ASICS, ce serait bien d'aller voir les mecs qui les développent pour voir comment eux voient l'interconnexion de leur machin avec des machines "standards" qui n'ont que des interfaces "standards".

Car oui, tu peux t'amuser à gérer en soft le protocole physique avec des GPIO (ce que fait en gros ton port parallèle, mais qui correspond aussi aux solutions proposées par les gens au dessus qui te parlent de micro-contrôleur) mais c'est pas gagné que tu puisses monter très haut en fréquence (d'ailleurs, je n'ai toujours pas compris pourquoi tu dis que le port parallèle est "trop lent" : ça marche actuellement ou pas à cette fréquence ?).

Bref, j'espère ne pas avoir l'air condescendant, mais va lire en:Bus (computing)

Je comprends que tu as deux "problèmes" que tu essayes de résoudre : remplacer LabView par quelque chose de libre, et remplacer ton port parallèle lent par quelque chose de plus rapide. Mais je vois que tu essayes de résoudre les deux en même temps, et j'ai l'impression que c'est ça qui te bloque. Selon moi, il vaudrait mieux que tu t'attaques à chaque problème séparément.

Oui ça existe, et ça s'appelle la NoBox chez FDN. D'après différentes recherches (google fdn + nobox) ça fait deux ans que des gens s'y penchent (et et pas seulement chez FDN) et d'après ce que j'ai vu, ya toujours pas de résultat. Ya quand même une liste de diffusion ici :
https://mail.fdn.fr/wws/info/nobox

Grub 2 va aller chercher le noyau et l'initrd dans l'iso pour les charger, mais après avoir fait booter ledit noyau, il faut que celui-ci aille à son tour chercher tous les fichiers nécessaires dans l'iso ... Vu que le contrôle de la machine est passé du bootloader au kernel, faut un moyen de dire au kernel de monter lui aussi l'iso en loop et de booter dessus. Ça veut sûrement dire un peu de boulot à faire à la main.

N'importe qui est libre de faire une implémentation libre d'un lecteur Flash.

Comme dit Étienne, la licence l'interdisait jusqu'à ya pas longtemps. Ça peut paraître un problème non-insurmontable, mais quand on voit qu'Adobe a menacé des développeurs de rtmpdump, et que les codecs vidéos sont pleins de brevets logiciels, je comprends les réticences de certains devs à s'engager dans un truc qui ne peut que leur apporter des problèmes.

Pilote broadcom qu’ils ont réecrits entièrement et ne sont pas autorisés à redistribuer par broadcom (pour la partie DSL).

Ce n'est pas parce qu'une boîte a écrit un contrat contraire à la GPL qu'il prévaut sur celle-ci.

Comme je disais plus haut, pour diagnostiquer, un coup de tcpdump serait pas mal.

Je dirais que c'est peut-être grâce à OSX, qui gère en général "mieux" les profils de couleur et compagnie. C'est vrai que je n'ai pas de comparaison côte à côte d'un écran mat/brillant pour voir les écarts de couleur, en référence ...

J'avoue que là je ne vois pas grand chose qui cloche .... Et quelle est ta table de routage ? Je suppose qu'elle est classique, mais je ne vois pas d'autre chose qui pourrait poser problème ... À part un classique : un truc auquel tu as touché, qui n'a "rien à voir" mais en fait si ...

Balèze, alors. Tu devais avoir de l'expérience dans un autre langage dynamique comme python, peut-être ? En tous cas, dans le genre "propre", faire des tests unitaires pour un programme comme ça ... je dirais que tu vas peut-être un peu trop loin, là :-)
Après, ce n'est qu'un programme "court" (même si je fais surtout des programmes courts en python), très algorithmique, et qui n'utilise pas d'objets : ça ne représente pas tout ce qu'on trouve en python.
Pour "référence", moi j'en fait depuis un peu moins de 10 ans, mais très irrégulièrement (genre ça fait quelques temps que je n'ai pas écrit un programme de plus de 20 lignes en python ...).

Pour la syntaxe d'exception, c'est sûr que "as" est plus clair. Je ne savais pas que l'ancienne syntaxe allait disparaître, c'est étrange vu que la nouvelle est seulement arrivée dans le 2.6, ça fait short comme transition. Mais après vérification, c'est bien le cas ... je vais me mettre à jour.

Je ne sais pas s'il est impressionnant niveau algorithmique, mais en tous cas niveau code je le trouve plutôt bien fait, au sens où tu utilises le python "bien". Genre tu utilises les méthodes "modernes" de faire les choses, et tu ne te fais pas avoir par les "corner case" (genre les arguments par défaut qui seraient des mutables ...). Ça fait longtemps que tu fais du python ?

Sinon,je viens de remarquer que python2.6 est requis au minimum à cause d'une toute petite ligne ("except Exception as e") le as étant reservé à python 2.6 m'a dit python 2.5 (impressionant quand même:2.5 dit que ce mot clef apparait dans 2.6 <- joli!)

À mon époque, on écrivait :
except Exception, e:
Mais je vois que depuis le 2.6 on peut effectivement mettre "as" (mais les deux sont acceptés). Ce simple changement te rendra compatible avec les "vieux" pythons. Mais je n'arrive pas à trouver la raison de ce changement ... Personnellement, où l'as-tu appris comme ça ?

Tout est dans le titre, c'est plutôt rapide et ça marche bien (il m'a bien dépanné une fois). Il est juste un peu vieux. J'espère que c'est juste ça et que c'est pas le disque qu'est mort ...
http://www.brzitwa.de/mb/gpart/index.html

Je n'ai pas de point de comparaison, n'ayant jamais fait de virtualisation avant d'avoir un processeur supportant l'AMD-V, mais en tous cas les tests que j'ai fait montrent que c'est très rapide, comme natif. Bon, ça ne vaut pas grand chose comme avis, mais si tu trouves que la virtualisation avec ton processeur actuel est lente, ça peut valoir le coup.

Pour le support des processeurs, moi j'ai choisi AMD parce que c'est simple : tous les Athlon supportent la virtualisation, quelque soit la gamme, point. Chez Intel, en général, le bas de gamme ne le supporte pas, mais faut toujours vérifier dans leur tableau.

Tu as dû inverser les deux. Quand tu utilises le VT-X ou AMD-V, le système invité n'a pas besoin d'être fait pour l'émulation : il n'y voit que du feu, pour lui c'est un système "classique". Par contre, si tu utilises XEN et consorts, là effectivement ton OS invité doit être fait pour.

- Les couleurs ressortent bien plus, sans commune mesure et ça, pour du traitement photo, c'est parfait.

Si tu dis ça à quelqu'un qui connaît un minimum la photo, tu vas te faire lincher. Ce n'est pas parce que les couleurs ressortent plus qu'elles sont justes : au contraire même, en général, les écran d'aujourd'hui (brillants) accentuent beaucoup trop le contraste et rendent les couleurs flashy, bien loin des couleurs naturelles. Alors oui, le flashy, c'est flateur, mais c'est très loin d'un rendu "photo".