benoar a écrit 4238 commentaires

Encore une autre solution : UnPlug pour firefox https://addons.mozilla.org/fr/firefox/addon/2254
Marche sur YouTube mais pas seulement, et ne passe pas par un serveur pour récupérer l'URL. Propose soit de copier l'URL dans le presse-papier pour en faire ce qu'on veut, ou propose de la télécharger.

Il parle de "millions" de téléphones avec pulseaudio ; j'en ai jamais entendu parler. C'est quoi ce truc ?

Si tu es toi aussi mécontent de ces dalles de plus en plus minces en hauteur, fais comme moi : mets ton écran à la verticale. Bon, j'en ai deux, donc j'en ai gardé un horizontal, mais je te dis qu'un terminal sur 1680 pixels de haut ça change tout ! J'hésite même à mettre le deuxième pareil ...

Ah, par contre, si t'as un TN, ça va pas le faire : les couleurs vont bouger en fonction de ton alignement droite/gauche face à l'écran. Bah oui, c'est con, comme pour le 16/9, c'est parce que ça coûte moins cher, mais c'est pourri. Perso j'ai des PVA, donc ça passe bien !

Une chose est sûre, quand tu vois un netbook comme le Samsung NC-510 dont la dalle mate était l'un des principaux arguments de vente donner naissance à un successeur en dalle brillante, pour le même prix, c'est qu'il doit y avoir une raison, probablement financière.

Un grand classique. Avant, toutes les dalles étaient mates, et quelques bécanes (c'est Sony qu'a commencé je crois) se "démarquaient" par leur dalle brillante, plus cher. À force, les constructeurs se sont rendus compte que ça se vendait mieux, et comme les clients sont cons, ils leur ont refourgué de plus en plus de brillantes. Aujourd'hui, elles sont toutes brillantes (donc ce n'est pas qu'au Japon, pour info, axioplase<) et les prix se sont donc adaptés à ces dalles.

Aujourd'hui, on voit de plus en plus de monde qui gueule contre ça (perso ça fait un paquet d'année, mais on devait pas être beaucoup à l'époque) et les constructeurs se mettent à faire une option "plus cher" pour avoir une dalle mate. Bingo pour les constructeurs.

Je parie que dans 5 ans on va ravoir du brillant "mais mieux" et que ça fera pareil (plus cher, diffusion partout obligatoire, puis retour en arrière, plus cher, etc).

C'est un peu pareil pour les dalles 16/10 ou 16/9 : pourquoi pas sur les grandes dalles, mais quand je vois des netbooks, désolé, c'est trop petit pour que le wide soit avantageux. Pour moi, à 12" et moins, c'est dalle 4/3. Donc je suis cantonné aux machines d'occasion qui ont plus de 3 ans ...

Pour les liens, oui c'est valable pour tout le monde dans /usr/bin.

Pour le make, il finit toujours par un "quitant le répertoire", mais regarde les lignes au-dessus si ya pas une erreur signalée. En tous cas, à la fin du make, tu peux toujours vérifier le status afin de voir si ça s'est bien passé (echo $?).

Enfin, pour éviter d'être un boulet, essaye de répondre aux commentaires des gens auxquels tu réponds, ce qui leur permet de savoir quand ils ont une réponse :-) Là personne ne verra que t'as écrit un nouveau message.

C'est marrant de nous sortir tout ton CV, mais pourrais-tu décrire le problème (en langage clair) et les conclusions que tu en tires ? Parce que là, avec des réponses comme ça, je ne suis pas plus avancé ...

En ce qui concerne ton problème, CSS ne mélange pas les chapitres. Ça ne vient donc à priori pas de là.
Je te conseillerais d'essayer de lire ton DVD avec mplayer, et de fournir les traces de ce qu'il fait pour qu'on voit.

C'est bien marrant 2s ton langage mais c'est incompréhensible.

Pour les protections DVD, il y a CSS et les "region codes", c'est tout. Je n'ai jamais vu de truc dont tu parles (enfin, ce que j'en comprends) et vu la manière dont tu en parles, ça me semble du FUD. T'as des sources ?

J'ai la flemme de retrouver les commentaires, mais j'avais déjà prévenu (ainsi que d'autres moules) que la gestion de la communauté par Nokia, c'était très folklorique. CF les news sur le N900, les anciennes sur le N8x0 (voire N700), les journaux, la news du dernier FOSDEM (avec une très aventureuse conférence "comment concilier l'Open Source et les DRM" par une employé de Nokia), etc.

Nokia ne sait pas gérer une communauté, est plutôt genre gestion despotique, et sa politique de support du matos c'est "démerdez vous, le prochaine version de Maemo ne tournera que sur le prochain NXXX de toutes façons".

Ça plus son lobbying pour les brevets logiciels auprès des instances dirigeantes européennes, ça fait trop pour dire que Nokia et le N900 sont "biens". Même si putain, aucun autre constructeur n'a été capable de sortir un hard aussi "bien".

Ah, remercions également Texas Instrument pour la fermeture de son DSP, et ImgTech pour l'archi fermeture de la carte graphique.

Oui, certains sont enthousiastes à propos de linux sur l'embarqué ; moi je préciserai "linux, oui, le libre, non". Les constructeurs sont trop contents d'avoir une plateforme où ils peuvent avoir des utilisateurs captifs (en plus, ça attire les geeks quand on écrit "linux" dessus) pour leur laisser les libertés basiques du LL.

Je m'étais fait "avoir" en achetant un N800, bien que des possesseurs du N700 m'aient prévenu. Depuis je fais comme eux : j'essaye de prévenir ceux qui veulent bien entendre. Mais d'un côté je vous comprend : il est bien joli ce petit N900 ...

PS: bon tenez, j'ai retrouvé mon commentaire sur le N900 : https://linuxfr.org//comments/1062046.html#1062046

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.