est-ce que la reprogrammation du timer est coûteuse en nombre de cycles CPU ? Si oui, ça veut dire qu'on risque de perdre un peu en performances non ?
Ca consiste juste à écrire une valeur (le nombre de coups d'horloge à compter jusqu'à la prochaine interruption) dans un registre du timer. C'est un seul accès sur le bus, a mon avis c'est négligeable.
Sur le principe, je pense que dans les cas où on a beaucoup d'entrées-sorties (donc des attentes d'interruption) et/ou plein de process qui se synchronisent (sémaphores et mutexes), ce système est positif car il évite d'appeler le séquenceur pour rien (de toute façon il est appelé assez souvent).
Je ne sais pas si c'est lié avec les formats ouverts, mais en France comme ailleurs on devrait prendre modèle sur le ministère belge de la Simplification Administrative.
C'est un concept qui doit être inconnu de nos énarques ...
J'adore le logo, le Brasil-mètre installé sur la facade du ministère, et l'url du site annonce la couleur : http://www.kafka.be
[X]La liberté d'améliorer le programme et de publier vos améliorations
car il me semble qu'elle inclut implicitement les 3 autres.
En effet, la liberté d'améliorer implique que j'ai précédemment eu la liberté d'étudier le fonctionnement, donc que j'ai les sources. Celle-ci implique à son tour que j'ai pu exécuter librement le binaire qui en résulte.
Et la liberté de distribuer les versions améliorées, c'est aussi la liberté de redistribuer les copies (on ne précise pas de degré d'amélioration minimum ...)
Donc selon le principe du "qui peut le plus peut le moins", si il fallait n'en garder qu'une ce serait la dernière.
Techniquement, les fondeurs ne distribue pas Linux, ils te vendent un chip avec un firmware et il se trouve que le firmware contient Linux
Euh, je ne suis pas tout à fait d'accord : ca dépend bcp du fournisseur.
Si on prend l'exemple de Texas Instruments, dont les puces OMAP (contenant entre autres un processeur ARM, et souvent un DSP, très utilisés dans les téléphones et es PDA), le fondeur fournit sa puce, les docs de sa puce, les outils pour compiler du logiciel pour cette puce, et éventuellement des drivers. Pour ce qui est du Linux, soit tu fais ta petite LFS-pour-l'embarqué et tu te débrouilles, soit tu vas voir un des "partenaires" du fondeur, souvent MontaVista, qui se fera un plaisir de te vendre une distrib'. Je ne vois pas de "firmware contenant Linux" tout fait, de toute façon ca dépend tellement du reste de la carte ... http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?tem(...) http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?(...)
Chez d'autres fondeurs, c'est peut-être le cas, mais c'est aussi ceux qui jouent à fond la discrétion (et les specs sous Non-Disclosure Agreement), je pense notamment à Broadcom (qui équipe bcp de modems/routeurs/wifi, comme les Linksys et la Freebox). Effectivement, dans ce cas le respect de la GPL est très théorique, et le reverse engineering compliqué.
En tout cas, firmware ou pas, il n'y a pas d'exception à la GPL. Il faut que l'utilisateur ait accès au code source. Ensuite, ca dépend de la définition du mot "utilisateur". Je comprends qu'il y ait interprétation quand l'appareil est loué comme terminal faisant partie intégrante d'un réseau spécifique, mais pas quand le bidule est vendu à un utilisateur final.
sinon microsoft va nous expliquer que windows est un firmware...
Avec WinCE ils ne sont pas loin de le dire ... D'ailleurs, ils vont changer de nom, et s'appeler MicroFirm ;o)
Je confirme.
Il y a sans doute plusieurs puces sur la chaîne JTAG, le Broadcom (modem ADSL), le ST (décodeur MPEG), le FPGA, la flash du FPGA ...
Généralement les Flash programme ne sont pas JTAG, il faut donc piloter correctement les IO du/des chips qui y sont connectés pour y accéder. Ca implique de connaître (partiellement) le schéma de la carte, et de gérer correctement la sérialisation des bits sur la chaîne JTAG en fonction du modèle de Flash. Bref, pas un boulot de débutant, surtout en reverse-engineering : bravo à ceux qui ont réussi cette manip !
La dernière fois que j'ai regardé dans la fente PCMCIA d'une Freeboîte V3, j'y avais trouvé les même pastilles pour connecteur JTAG que dans la V4.
Attention, je n'affirme rien avec certitude, mais je pense que ca doit se ressembler pas mal* et qu'il peut être intéressant de vérifier.
Un autre point très important, c'est le FPGA (un Xilinx Spartan 2E je crois), qui est certainement dans la chaîne JTAG, et qui pourrait également bénéficier d'un firmware amélioré ... ou pâtir d'une manp foireuse ! Par contre un bitstream de FPGA c'est un peu plus compliqué à désassembler que du code MIPS ...
* C'est de toute façon le même chip Broadcom dans les deux, non ?
Ca me rappelle le déguisement d'un des "chefs de guerre" du PLF lors d'une conférence à Solution Linux il y a qq années : treillis kaki, t-shirt des Brigades Rouges et cagoule pendant toute la présentation ... Ca avait vraiment fait de l'effet, juste en face du stand IBM ;-)
Je l'ai revu cette année, il m'a confié qu'il a arrêté le style "canal historique", car outre la chaleur là-dessous, les gens venaient juste voir "le pirate avec une cagoule" sans vraiment écouter son message.
Je pense que faire un peu de provoc' reste une bonne façon de lutter contre la criminalisation médiatique actuelle de la société de l'information, avec le terme disproportionné de "pirate", l'emploi erroné de "hacker", l'assimilation de la copie à du vol, la réduction des libertés de communiquer, etc.
J'avais lu par ici l'adage : "Un logiciel libre est gratuit quand il a été payé une fois".
Contrairement aux "entreprises peu scrupuleuses (sic)", ce concept permet de vivre (tout juste) du développement, et de mettre du beurre dans les épinards en vendant du service. Mais ca implique aussi que c'est le premier "couillon" qui a besoin d'un truc, qui le paye pour le reste du monde (y compris ses propres concurrents !). Ca refroidit certaines entreprises/clients potentiels ... (1)
Des modèles économiques de type "souscription" pour une fonctionnalité donnée est peut-être mieux adaptée au développement libre-pas-gratuit. C'est finalement ce que Mandrak^H^H^Hiva a mis en place avec le Club, et ca me semblait assez efficace ces derniers temps. Mais après les déboires financiers que l'on sait, la phase d'expansion et de rachats n'aurait-elle pas été un peu hâtive ?
Je pense que Mandriva ne profite pas assez de ses implantations géographiques et des éventuels soutiens politiques associés : contrairement à SuSE qui est vraiment répandue en Allemagne, et peut-être ex-Connectiva au Brésil, je n'ai pas l'impression que les administrations et les entreprises françaises fassent spécialement appel au seul grand éditeur le logiciel du pays (oops, j'oubliais le fossile de Bull) pour le déploiement de logiciels libres. Pour les grands comptes qui s'intéressent à GNU/Linux, hors Red Hat point de salut, et on est en train de refaire un monopole.
Ce qui me surprend aussi, c'est que les professionnels de la sécurité, les militaires et leurs fournisseurs ne soient pas plus intéressés par l'indépendance technologique (envers qui-vous-savez-de-l'autre-côté-de-l'Atlantique) la robustesse et la sécurité apportées par les logiciels libres.
(1) Oui, je sais, la GPL n'impose de distribuer les sources _que_ aux utilisateurs (éventuellement payants) et pas gratuitement au monde entier. Mais le client frileux est déjà surgelé avant d'avoir compris ca.
je ne pige pas pourquoi tu inverses les bits au sein d'un même octet, je n'ai jamais vu ça.
Justement, c'est bien là la principale différence entre Big Endian et Little Endian. C'est l'ordre des bits du bus de données (physiquement, sur les broches de la puce) qui est inversé :
- en little endian, le bit 0 du bus est le bit de poids faible, le bit 31 est le bit le plus significatif (1),
- en big endian, c'est le bit 0 qui est le bit de poids fort.
Ainsi, on représente généralement les bus big-endian [0..31] et les bus little endian [31..0], en notant toujours le bit de poids fort à gauche, dans le sens naturel de lecture.
Mais du coup, l'ordre des octets dans la mémoire est également inversé, car on parcourt toujours les adresses dans le sens croissant : l'octet qui contient le bit 0 sera toujours placé à une adresse plus basse que celui qui contient le bit 31.
Peut-être, mais il n'y a pas une sanction aggravée en cas de récidive ?
Si ce n'est pas le cas, imaginons que la loi soit passée (snif), on peut comparer pour l'album-lambda de 15 titres :
- ~15¤ + DRM en téléchargement "légal",
- ~20¤ + rootkit en galette chez le marchand,
- 38¤ d'amende en téléchargement "peer-rate".
Seul le dernier permet la copie privée et l'interopérabilité, et seul le deuxième n'est pas soumis à la redevance sur les supports vierges.
La question est : est-ce que les amendes rémunèrent les artistes, ou bien juste l'Etat comme celles du code de la route ?
les processeurs actuels sont capables de se câbler comme on le désire
Oui, c'est bien ce que je disais : les Mips, les PowerPC, les DSP TI, et sans doute bien d'autres. N'empêche que ces modes ne sont pas compatibles entre eux, et qu'il faut bien choisir lequel on utilise sur une carte donnée. Par exemple, il y a deux branches Mips dans Debian, l'une pour les stations Digital et l'autre pour SGI. http://www.debian.org/ports/mips/
Le standard PC est toujours little-endian, et les standards réseaux sont presque tous big-endian.
d'un point de vue d'électronicien, faire du Big-Endian était plus simple, mais que d'un point de vue d'informaticien, le "penser" était plus difficile (ce qui se conçoit aisément)
Je code quotidiennement pour des cibles embarquées qui utilisent les deux modes. La difficulté, c'est justement qu'on a une chance sur deux, quand on définit un champ de bits pour un registre, de se tromper de sens ... et que pour faire un code portable il faut tout faire en double, avec le risque d'erreur qui en découle.
Est-ce que tu te souviens de ce qui rend plus simple l'un ou l'autre sens selon le point de vue de l'utilisateur ? Parce que comme je suis à mi-chemin entre l'informaticien et l'électronicien, je n'ai pas un avis aussi tranché ;-)
Au sujet de ASIC / FPGA, il faut comprendre que l'on cherche a faire un micro-processeur.
J'avais bien compris. Mais tu sais sans doute qu'on peut mettre des microprocesseurs dans les FPGA ... soit en dur dans le silicium (comme les Virtex4FX de Xilinx équipés d'un ou deux PowerPC 405), soit sous la forme de netlist (Nios chez Altera, MicroBlaze chez Xilinx, et puis le LEON dont on parlait plus haut).
Tu sais aussi que Linux (ou µClinux) a été porté sur tous ces processeurs.
Evidemment, les fréquences de fonctionnement n'ont rien à voir avec les processeurs PC haut-de-gamme, on est aujourd'hui dans la gamme 100 à 200 MHz pour un soft-core, et le double pour un hard-core (le tout sans radiateur ni ventilo !). Mais le but est bien différent de celui d'un CPU généraliste, ca on est dans une puce programmable ! On peut donc implémenter plein de périphériques sur mesure, parallèliser des coprocesseurs hardware pour des applications particulières, profiter de la reconfigurabilité de la puce (même en cours de fonctionnement), explorer des topologies multiprocesseurs ... les performances (vitesse de calcul ET consommation) ne sont pas du tout ridicules pour une application embarquée spécifique.
Et la possibilité de modifier le design une fois le produit fini, pour corriger un bug ou ajouter une fonctionnalité, vaut de l'or !
Un FPGA coute plus cher a l'unite mais si tu as besoin de grandes quantites les couts fixes lies a la fabrication d'un ASIC (dont les 1 a 2 annees de developpement) sont finalement ammortis.
Effectivement, c'est valable sur une grande quantité. Plus performant, moins cher à l'unité, mais il faut être sûr de son marché.
Le point où il devient plus rentable d'engager des gros coûts fixes pour produire un ASIC pas cher, que de payer un FPGA tout fait, recule de plus en plus. Par exemple, il y a un FPGA (un Spartan2, je crois) dans la Freebox, et ce n'est plus un produit de petite série ...
On s'en sert souvent pour prototyper un micro-controlleur genre ARM par exemple.
Pour certaines applications de traitement d'image en temps réel, où les débits de données sont importants, il n'est pas question d'utiliser un processeur généraliste (soit il consomme trop, soit il n'est pas assez performant), les délais de mise sur le marché et les volumes ne sont pas compatibles avec un développement ASIC, alors le FPGA est la seule solution !
Il y a 4 ou 5 ans, les FPGA étaient sans doute principalement utilisés pour faire du prototypage, mais plus maintenant.
Pour revenir aux outils de CAO (électronique et autres), il y a des solutions propriétaires qui tournent sous Linux [*], certaines ont même des versions démo gratuites, mais malheureursement rien de libre. Dans le domaine mécanique, il y a des codes de calcul, comme CodeAster, mais pas d'outil de design comme Catia. Pour l'électronique analogique, il y a Spice. Pour l'électronique numérique, je crois qu'on les a presque tous cités. Et l'optique, l'acoustique, la thermique, l'aérodynamique, l'énergétique ?
Il est vraiment temps que les outils libres sortent du domaine quasi-exclusif de la programmation logicielle, et déferlent sur tous les domaines techniques !
[*] La migration station->PC a réduit les coûts, mais la migration UNIX->Windows associée n'a pas que des avantages quand on développe ... Alors le couple PC+Linux est un bon compromis pour la CAO, et de + en + d'entreprises vont dans cette direction. Les éditeurs commencent (timidement) à suivre.
Il faut un outil de synthese (tres cher), d'analyse statique de timing (cher aussi) et de simulation (il y en a des gratos) pour synthetiser et valider ton processeur.
C'est à mon avis un domaine où les logiciels libres sont très peu présents, même si il y a des initiatives en cours, c'est encore un domaine où les softs propriétaires aux prix exorbitants sont incontournbles.
Par exemple, moins un simulateur VHDL est cher (version démo gratuite), plus il contient de boucles d'attente vides ... (les simulations durent des heures).
Sans aller jusqu'au développement d'ASIC, avec les coûts de production astronomiques des masques, déjà avoir des outils libres pour FPGA permettrait de faire plein de choses. On a beau dire que c'est moins performant et plus cher, ces puces reconfigurables évoluent très vite : les prix baissent et les perfos augmentent à un rythme soutenu. http://www.trenz-electronic.de/prod/proden21.htm
J'avais eu l'occasion, il y a 3 ou 4 ans, d'aborder le sujet avec RMS. Il avait tout de suite soulevé le pb des coûts de production, mais quand j'ai parlé de FPGA, il a dit "si ca se télécharge dans la puce, alors c'est du logiciel, et la FSF encourage le logiciel libre"
peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien)
En tout cas, il n'est pas rare de voir un Solaris 32 bits tourner sur un UltraSparc ... cherchez l'erreur.
UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé
C'est clair que le portage peut s'avérer pénible si le code n'est pas bien propre au départ. D'un autre côté, le Sparc a des caractéristiques assez sympa, comme la banque de registres "à glissière" qui permet des changements de contexte très rapides.
J'avais aussi entendu dire qu'un processeur grand-boutiste était un petit peu plus rapide, et que c'est pour ca que tous les CPU RISC utilisent cette orientation (ou sont configurables, comme le MIPS et le PowerPC). Quelqu'un en sait plus ?
Cela dit, la libération du Sparc (même si c'était déjà un design assez ouvert, cf. LEON) est une excellente nouvelle, car on pourrait voir apparaître des fondeurs-intégrateurs comme il y a des assembleurs de PC taiwanais, produisant à bas coût le design développé par la communauté des électroniciens-libres. Ca pourrait se concerner surtout des mini-PC, du style MacMini ou Mini-ITX, très prisés des geeks que nous sommes ! http://damnsmalllinux.org/store/
De son côté, IBM et Freescale ont également ouvert le design du PowerPC 405 pour les universités, mais apparemment n'importe qui peut devenir membre du consortium de spécification du standard PowerPC. La licence n'a quand même pas l'air libre ... http://www.power.org/home
"Le fait de distribuer un logiciel de contournement de MTP sur une
plateforme pour laquelle le fournisseur de la MTP n'a pas fourni de
solution de lecture n'est pas concerné par cette loi"
Est-ce que c'est plus clair en le formulant comme ca ? "En l'absence de moyen de lecture de MTP officiel compatible avec une plateforme informatique, la conception et la distribution d'un moyen de contournement de MTP sont autorisées pour cette plateforme."
Il faudrait définir "plateforme informatique", et d'ailleurs ca peut être autre que purement informatique : autoradio, chaîne hifi, téléphone ... chanté sous la douche ...
J'ai aussi remplacé "logiciel" et "solution" par "moyen", et indiqué expressément l'autorisation : si c'est pas concerné par cette loi, ca pourrait l'être par une autre !
L'expression "moyen de lecture de MTP" est encore perfectible, mais si on détaille ca fait une loooongue périphrase : "moyen de lecture légalement proposé par un fournisseur de contenu audiovisuel protégé par des mesures techniques de protection". MLLPFCAPMTP. Ouf !
Et non, une grande entreprise ne peut pas se permettre de dire « vaguement testé » ou « ça devrait marcher » ou « ouais on y a fait gaffe mais rien n'est sûr »
Il y a quand même une grosse marge entre ne rien tester (hormis la config la plus répandue) et vérifier un minimum de compatibilité avec les alternatives qui se développent fortement.
Voici une nouvelle illustration de l'intérêt du respect des normes !
Même si ce n'est pas le cas ici, bloquer un site pour les navigateurs autres que IE c'est nier le but inital d'internet : communiquer.
On peut déjà enregistrer les codes PS/2 du clavier ou de la souris avec un keylogger matériel.
Ceux-ci ne sont pas très miniaturisés : http://www.thinkgeek.com/gadgets/electronic/5a05/ http://www.insecure.org/stc/ (photo au milieu de la page)
mais avec un petit PIC10F200 et une Flash I²C on doit pouvoir en bricoler un assez compact.
[^] # Re: Nouveau?? Comment çà marche?
Posté par Jimmy . En réponse à la dépêche Timers haute résolution et horloge dynamique.. Évalué à 4.
Ca consiste juste à écrire une valeur (le nombre de coups d'horloge à compter jusqu'à la prochaine interruption) dans un registre du timer. C'est un seul accès sur le bus, a mon avis c'est négligeable.
Sur le principe, je pense que dans les cas où on a beaucoup d'entrées-sorties (donc des attentes d'interruption) et/ou plein de process qui se synchronisent (sémaphores et mutexes), ce système est positif car il évite d'appeler le séquenceur pour rien (de toute façon il est appelé assez souvent).
[^] # Re: phénomène récent, ... ou pas
Posté par Jimmy . En réponse à la dépêche Timers haute résolution et horloge dynamique.. Évalué à 1.
http://www.linuxdevices.com/articles/AT3239582376.html
ou à ca :
http://www.erikyyy.de/tempest/
sauf que le signal n'était pas émis par l'écran ...
[^] # Re: Vivement la Suisse
Posté par Jimmy . En réponse à la dépêche Format Open Document adopté dans l'administration belge. Évalué à 0.
C'est un concept qui doit être inconnu de nos énarques ...
J'adore le logo, le Brasil-mètre installé sur la facade du ministère, et l'url du site annonce la couleur : http://www.kafka.be
Vous avez votre formulaure 27B/6 ?
[^] # Re: mais heuu
Posté par Jimmy . En réponse au sondage La liberté la plus importante garantie par la GPL est. Évalué à 5.
car il me semble qu'elle inclut implicitement les 3 autres.
En effet, la liberté d'améliorer implique que j'ai précédemment eu la liberté d'étudier le fonctionnement, donc que j'ai les sources. Celle-ci implique à son tour que j'ai pu exécuter librement le binaire qui en résulte.
Et la liberté de distribuer les versions améliorées, c'est aussi la liberté de redistribuer les copies (on ne précise pas de degré d'amélioration minimum ...)
Donc selon le principe du "qui peut le plus peut le moins", si il fallait n'en garder qu'une ce serait la dernière.
[^] # Re: Pas si simple que ça...
Posté par Jimmy . En réponse à la dépêche Un téléphone mobile de conception française sous Linux. Évalué à 2.
Euh, je ne suis pas tout à fait d'accord : ca dépend bcp du fournisseur.
Si on prend l'exemple de Texas Instruments, dont les puces OMAP (contenant entre autres un processeur ARM, et souvent un DSP, très utilisés dans les téléphones et es PDA), le fondeur fournit sa puce, les docs de sa puce, les outils pour compiler du logiciel pour cette puce, et éventuellement des drivers. Pour ce qui est du Linux, soit tu fais ta petite LFS-pour-l'embarqué et tu te débrouilles, soit tu vas voir un des "partenaires" du fondeur, souvent MontaVista, qui se fera un plaisir de te vendre une distrib'. Je ne vois pas de "firmware contenant Linux" tout fait, de toute façon ca dépend tellement du reste de la carte ...
http://focus.ti.com/general/docs/wtbu/wtbugencontent.tsp?tem(...)
http://focus.ti.com/general/docs/wtbu/wtbusplashcontent.tsp?(...)
Chez d'autres fondeurs, c'est peut-être le cas, mais c'est aussi ceux qui jouent à fond la discrétion (et les specs sous Non-Disclosure Agreement), je pense notamment à Broadcom (qui équipe bcp de modems/routeurs/wifi, comme les Linksys et la Freebox). Effectivement, dans ce cas le respect de la GPL est très théorique, et le reverse engineering compliqué.
< HS > Au passage, quelqu'un a aussi un modem câble Thomson ? Il y a sûrement moyen de les recycler une fois désabonné ... http://wiki.openwrt.org/OpenWrtDocs/Hardware/Thomson/TCM390
< /HS >
En tout cas, firmware ou pas, il n'y a pas d'exception à la GPL. Il faut que l'utilisateur ait accès au code source. Ensuite, ca dépend de la définition du mot "utilisateur". Je comprends qu'il y ait interprétation quand l'appareil est loué comme terminal faisant partie intégrante d'un réseau spécifique, mais pas quand le bidule est vendu à un utilisateur final.
sinon microsoft va nous expliquer que windows est un firmware...
Avec WinCE ils ne sont pas loin de le dire ... D'ailleurs, ils vont changer de nom, et s'appeler MicroFirm ;o)
[^] # Re: euh ?
Posté par Jimmy . En réponse à la dépêche Modifier le firmware d'une Freebox grâce à OpenFreeBox. Évalué à 4.
Il y a sans doute plusieurs puces sur la chaîne JTAG, le Broadcom (modem ADSL), le ST (décodeur MPEG), le FPGA, la flash du FPGA ...
Généralement les Flash programme ne sont pas JTAG, il faut donc piloter correctement les IO du/des chips qui y sont connectés pour y accéder. Ca implique de connaître (partiellement) le schéma de la carte, et de gérer correctement la sérialisation des bits sur la chaîne JTAG en fonction du modèle de Flash. Bref, pas un boulot de débutant, surtout en reverse-engineering : bravo à ceux qui ont réussi cette manip !
Quelques infos sur le JTAG pour ceux que ca intéresse :
http://www.chez.com/jtag/description.htm
http://en.wikipedia.org/wiki/JTAG
http://www-s.ti.com/sc/psheets/ssya002c/ssya002c.pdf
[^] # Re: quelle version de freebox ?
Posté par Jimmy . En réponse à la dépêche Modifier le firmware d'une Freebox grâce à OpenFreeBox. Évalué à 3.
Attention, je n'affirme rien avec certitude, mais je pense que ca doit se ressembler pas mal* et qu'il peut être intéressant de vérifier.
Un autre point très important, c'est le FPGA (un Xilinx Spartan 2E je crois), qui est certainement dans la chaîne JTAG, et qui pourrait également bénéficier d'un firmware amélioré ... ou pâtir d'une manp foireuse ! Par contre un bitstream de FPGA c'est un peu plus compliqué à désassembler que du code MIPS ...
* C'est de toute façon le même chip Broadcom dans les deux, non ?
[^] # Re: Comme d'habitude...
Posté par Jimmy . En réponse au sondage Pour développer un site web, je préfère utiliser. Évalué à 2.
http://www.fortranstatement.com
# Penguin Liberation Front
Posté par Jimmy . En réponse au journal [Humour] Nouveaux terroristes. Évalué à 5.
Comme Google image est mon ami, voici des preuves :
http://www.aldil.org/photos/SL/SL_autre/31.html
http://plf.zarb.org/rmll9.jpg
Je l'ai revu cette année, il m'a confié qu'il a arrêté le style "canal historique", car outre la chaleur là-dessous, les gens venaient juste voir "le pirate avec une cagoule" sans vraiment écouter son message.
Je pense que faire un peu de provoc' reste une bonne façon de lutter contre la criminalisation médiatique actuelle de la société de l'information, avec le terme disproportionné de "pirate", l'emploi erroné de "hacker", l'assimilation de la copie à du vol, la réduction des libertés de communiquer, etc.
[^] # Re: Avenir du métier d'éditeur
Posté par Jimmy . En réponse au sondage Mandrake^H^H^Hiva. Évalué à 8.
Contrairement aux "entreprises peu scrupuleuses (sic)", ce concept permet de vivre (tout juste) du développement, et de mettre du beurre dans les épinards en vendant du service. Mais ca implique aussi que c'est le premier "couillon" qui a besoin d'un truc, qui le paye pour le reste du monde (y compris ses propres concurrents !). Ca refroidit certaines entreprises/clients potentiels ... (1)
Des modèles économiques de type "souscription" pour une fonctionnalité donnée est peut-être mieux adaptée au développement libre-pas-gratuit. C'est finalement ce que Mandrak^H^H^Hiva a mis en place avec le Club, et ca me semblait assez efficace ces derniers temps. Mais après les déboires financiers que l'on sait, la phase d'expansion et de rachats n'aurait-elle pas été un peu hâtive ?
Je pense que Mandriva ne profite pas assez de ses implantations géographiques et des éventuels soutiens politiques associés : contrairement à SuSE qui est vraiment répandue en Allemagne, et peut-être ex-Connectiva au Brésil, je n'ai pas l'impression que les administrations et les entreprises françaises fassent spécialement appel au seul grand éditeur le logiciel du pays (oops, j'oubliais le fossile de Bull) pour le déploiement de logiciels libres. Pour les grands comptes qui s'intéressent à GNU/Linux, hors Red Hat point de salut, et on est en train de refaire un monopole.
Ce qui me surprend aussi, c'est que les professionnels de la sécurité, les militaires et leurs fournisseurs ne soient pas plus intéressés par l'indépendance technologique (envers qui-vous-savez-de-l'autre-côté-de-l'Atlantique) la robustesse et la sécurité apportées par les logiciels libres.
(1) Oui, je sais, la GPL n'impose de distribuer les sources _que_ aux utilisateurs (éventuellement payants) et pas gratuitement au monde entier. Mais le client frileux est déjà surgelé avant d'avoir compris ca.
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Jimmy . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 1.
Justement, c'est bien là la principale différence entre Big Endian et Little Endian. C'est l'ordre des bits du bus de données (physiquement, sur les broches de la puce) qui est inversé :
- en little endian, le bit 0 du bus est le bit de poids faible, le bit 31 est le bit le plus significatif (1),
- en big endian, c'est le bit 0 qui est le bit de poids fort.
Ainsi, on représente généralement les bus big-endian [0..31] et les bus little endian [31..0], en notant toujours le bit de poids fort à gauche, dans le sens naturel de lecture.
Mais du coup, l'ordre des octets dans la mémoire est également inversé, car on parcourt toujours les adresses dans le sens croissant : l'octet qui contient le bit 0 sera toujours placé à une adresse plus basse que celui qui contient le bit 31.
Voici une explication assez claire :
http://membres.lycos.fr/cgiguere/vdn/vdn71/vdn71.htm
notamment le passage sur UNIX, XINU et NUXI ...
(1) on utilise souvent les notations MSB (Most Significant Bit) et LSB (Least Significant Bit).
[^] # Re: Le logiciel libre pris en compte par le gouvernement ?
Posté par Jimmy . En réponse à la dépêche DADVSI : suite.... Évalué à 8.
Dans ce domaine, je crois que c'est celui-ci le meilleur (même si il n'a pas concouru pour l'IOCCC) : http://www.mail-archive.com/cryptography@c2.net/msg04508.htm(...)
Plein d'autres exemples ici : http://www.cs.cmu.edu/~dst/DeCSS/Gallery/index.html
/* efdtt.c Author: Charles M. Hannum <root@ihack.net> */ /* */ /* Thanks to Phil Carmody <fatphil@asdf.org> for additional tweaks. */ /* */ /* DVD-logo shaped version by Alex Bowley <alex@hyperspeed.org> */ /* */ /* Usage is: cat title-key scrambled.vob | efdtt >clear.vob */ #define m(i)(x[i]^s[i+84])<< unsigned char x[5] ,y,s[2048];main( n){for( read(0,x,5 );read(0,s ,n=2048 ); write(1 ,s,n) )if(s [y=s [13]%8+20] /16%4 ==1 ){int i=m( 1)17 ^256 +m(0) 8,k =m(2) 0,j= m(4) 17^ m(3) 9^k* 2-k%8 ^8,a =0,c =26;for (s[y] -=16; --c;j *=2)a= a*2^i& 1,i=i /2^j&1 <<24;for(j= 127; ++j<n;c=c> y) c +=y=i^i/8^i>>4^i>>12, i=i>>8^y<<17,a^=a>>14,y=a^a*8^a<<6,a=a >>8^y<<9,k=s[j],k ="7Wo~'G_\216"[k &7]+2^"cr3sfw6v;*k+>/n."[k>>4]*2^k*257/ 8,s[j]=k^(k&k*2&34)*6^c+~y ;}}[^] # Re: Génération MacTel
Posté par Jimmy . En réponse au sondage Pour accéder à linuxfr.org, j'utilise principalement le protocole. Évalué à 2.
Pourquoi pas un bon vieux gros connecteur Token Ring hermaphrodite, tant que tu y es ?
http://www.mycableshop.com/300x300/CTRC5-BA.large.jpg
(à peu près taille réelle)
--->[]
[^] # Re: Les amendes
Posté par Jimmy . En réponse à la dépêche DADVSI : retour le 7 mars 2006 à l'Assemblée Nationale. Évalué à 2.
Si ce n'est pas le cas, imaginons que la loi soit passée (snif), on peut comparer pour l'album-lambda de 15 titres :
- ~15¤ + DRM en téléchargement "légal",
- ~20¤ + rootkit en galette chez le marchand,
- 38¤ d'amende en téléchargement "peer-rate".
Seul le dernier permet la copie privée et l'interopérabilité, et seul le deuxième n'est pas soumis à la redevance sur les supports vierges.
La question est : est-ce que les amendes rémunèrent les artistes, ou bien juste l'Etat comme celles du code de la route ?
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Jimmy . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 3.
Oui, c'est bien ce que je disais : les Mips, les PowerPC, les DSP TI, et sans doute bien d'autres. N'empêche que ces modes ne sont pas compatibles entre eux, et qu'il faut bien choisir lequel on utilise sur une carte donnée. Par exemple, il y a deux branches Mips dans Debian, l'une pour les stations Digital et l'autre pour SGI. http://www.debian.org/ports/mips/
Le standard PC est toujours little-endian, et les standards réseaux sont presque tous big-endian.
d'un point de vue d'électronicien, faire du Big-Endian était plus simple, mais que d'un point de vue d'informaticien, le "penser" était plus difficile (ce qui se conçoit aisément)
Je code quotidiennement pour des cibles embarquées qui utilisent les deux modes. La difficulté, c'est justement qu'on a une chance sur deux, quand on définit un champ de bits pour un registre, de se tromper de sens ... et que pour faire un code portable il faut tout faire en double, avec le risque d'erreur qui en découle.
Est-ce que tu te souviens de ce qui rend plus simple l'un ou l'autre sens selon le point de vue de l'utilisateur ? Parce que comme je suis à mi-chemin entre l'informaticien et l'électronicien, je n'ai pas un avis aussi tranché ;-)
[^] # Re: Spec != RTL
Posté par Jimmy . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 3.
J'avais bien compris. Mais tu sais sans doute qu'on peut mettre des microprocesseurs dans les FPGA ... soit en dur dans le silicium (comme les Virtex4FX de Xilinx équipés d'un ou deux PowerPC 405), soit sous la forme de netlist (Nios chez Altera, MicroBlaze chez Xilinx, et puis le LEON dont on parlait plus haut).
Tu sais aussi que Linux (ou µClinux) a été porté sur tous ces processeurs.
Evidemment, les fréquences de fonctionnement n'ont rien à voir avec les processeurs PC haut-de-gamme, on est aujourd'hui dans la gamme 100 à 200 MHz pour un soft-core, et le double pour un hard-core (le tout sans radiateur ni ventilo !). Mais le but est bien différent de celui d'un CPU généraliste, ca on est dans une puce programmable ! On peut donc implémenter plein de périphériques sur mesure, parallèliser des coprocesseurs hardware pour des applications particulières, profiter de la reconfigurabilité de la puce (même en cours de fonctionnement), explorer des topologies multiprocesseurs ... les performances (vitesse de calcul ET consommation) ne sont pas du tout ridicules pour une application embarquée spécifique.
Et la possibilité de modifier le design une fois le produit fini, pour corriger un bug ou ajouter une fonctionnalité, vaut de l'or !
Un FPGA coute plus cher a l'unite mais si tu as besoin de grandes quantites les couts fixes lies a la fabrication d'un ASIC (dont les 1 a 2 annees de developpement) sont finalement ammortis.
Effectivement, c'est valable sur une grande quantité. Plus performant, moins cher à l'unité, mais il faut être sûr de son marché.
Le point où il devient plus rentable d'engager des gros coûts fixes pour produire un ASIC pas cher, que de payer un FPGA tout fait, recule de plus en plus. Par exemple, il y a un FPGA (un Spartan2, je crois) dans la Freebox, et ce n'est plus un produit de petite série ...
On s'en sert souvent pour prototyper un micro-controlleur genre ARM par exemple.
Pour certaines applications de traitement d'image en temps réel, où les débits de données sont importants, il n'est pas question d'utiliser un processeur généraliste (soit il consomme trop, soit il n'est pas assez performant), les délais de mise sur le marché et les volumes ne sont pas compatibles avec un développement ASIC, alors le FPGA est la seule solution !
Il y a 4 ou 5 ans, les FPGA étaient sans doute principalement utilisés pour faire du prototypage, mais plus maintenant.
Pour revenir aux outils de CAO (électronique et autres), il y a des solutions propriétaires qui tournent sous Linux [*], certaines ont même des versions démo gratuites, mais malheureursement rien de libre. Dans le domaine mécanique, il y a des codes de calcul, comme CodeAster, mais pas d'outil de design comme Catia. Pour l'électronique analogique, il y a Spice. Pour l'électronique numérique, je crois qu'on les a presque tous cités. Et l'optique, l'acoustique, la thermique, l'aérodynamique, l'énergétique ?
Il est vraiment temps que les outils libres sortent du domaine quasi-exclusif de la programmation logicielle, et déferlent sur tous les domaines techniques !
[*] La migration station->PC a réduit les coûts, mais la migration UNIX->Windows associée n'a pas que des avantages quand on développe ... Alors le couple PC+Linux est un bon compromis pour la CAO, et de + en + d'entreprises vont dans cette direction. Les éditeurs commencent (timidement) à suivre.
[^] # Re: Spec != RTL
Posté par Jimmy . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 3.
C'est à mon avis un domaine où les logiciels libres sont très peu présents, même si il y a des initiatives en cours, c'est encore un domaine où les softs propriétaires aux prix exorbitants sont incontournbles.
Par exemple, moins un simulateur VHDL est cher (version démo gratuite), plus il contient de boucles d'attente vides ... (les simulations durent des heures).
Sans aller jusqu'au développement d'ASIC, avec les coûts de production astronomiques des masques, déjà avoir des outils libres pour FPGA permettrait de faire plein de choses. On a beau dire que c'est moins performant et plus cher, ces puces reconfigurables évoluent très vite : les prix baissent et les perfos augmentent à un rythme soutenu. http://www.trenz-electronic.de/prod/proden21.htm
J'avais eu l'occasion, il y a 3 ou 4 ans, d'aborder le sujet avec RMS. Il avait tout de suite soulevé le pb des coûts de production, mais quand j'ai parlé de FPGA, il a dit "si ca se télécharge dans la puce, alors c'est du logiciel, et la FSF encourage le logiciel libre"
http://www.freehdl.seul.org/
http://www.opencores
http://www.geda.seul.org/index.html.org
http://qucs.sourceforge.net/index.html
[^] # Re: Tanenbaum était un visionnaire ...
Posté par Jimmy . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 3.
En tout cas, il n'est pas rare de voir un Solaris 32 bits tourner sur un UltraSparc ... cherchez l'erreur.
UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé
C'est clair que le portage peut s'avérer pénible si le code n'est pas bien propre au départ. D'un autre côté, le Sparc a des caractéristiques assez sympa, comme la banque de registres "à glissière" qui permet des changements de contexte très rapides.
J'avais aussi entendu dire qu'un processeur grand-boutiste était un petit peu plus rapide, et que c'est pour ca que tous les CPU RISC utilisent cette orientation (ou sont configurables, comme le MIPS et le PowerPC). Quelqu'un en sait plus ?
[^] # Re: C'est bien mais
Posté par Jimmy . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 5.
Par exemple, des DSP Texas Instruments C5xxx, utilisés dans des téléphones portables, consomment environ 0.33mA/MHz, soit 80mW à 200MHz sous une tension de coeur de 1.2V.
http://focus.ti.com/dsp/docs/dspplatformscontenttp.tsp?secti(...)
Un DSP C6416 à 1GHz consomme moins d'1W, et il a aussi 8 unités de calcul en parallèle (ca compte quand même pour un seul coeur)
http://focus.ti.com/docs/prod/folders/print/tms320c6416t.htm(...)
Un ARM926 consomme environ 0.45 mW/MHz, soit 120mW à 266 MHz. Sans compter les modes d'économie d'énergie.
http://arm.com/products/CPUs/ARM926EJ-S.html
Cela dit, la libération du Sparc (même si c'était déjà un design assez ouvert, cf. LEON) est une excellente nouvelle, car on pourrait voir apparaître des fondeurs-intégrateurs comme il y a des assembleurs de PC taiwanais, produisant à bas coût le design développé par la communauté des électroniciens-libres. Ca pourrait se concerner surtout des mini-PC, du style MacMini ou Mini-ITX, très prisés des geeks que nous sommes ! http://damnsmalllinux.org/store/
De son côté, IBM et Freescale ont également ouvert le design du PowerPC 405 pour les universités, mais apparemment n'importe qui peut devenir membre du consortium de spécification du standard PowerPC. La licence n'a quand même pas l'air libre ... http://www.power.org/home
[^] # Re: Quelles solutions proposer pour préserver le LL?
Posté par Jimmy . En réponse à la dépêche Débat ouvert autour de DADVSI. Évalué à 4.
plateforme pour laquelle le fournisseur de la MTP n'a pas fourni de
solution de lecture n'est pas concerné par cette loi"
Est-ce que c'est plus clair en le formulant comme ca ?
"En l'absence de moyen de lecture de MTP officiel compatible avec une plateforme informatique, la conception et la distribution d'un moyen de contournement de MTP sont autorisées pour cette plateforme."
Il faudrait définir "plateforme informatique", et d'ailleurs ca peut être autre que purement informatique : autoradio, chaîne hifi, téléphone ... chanté sous la douche ...
J'ai aussi remplacé "logiciel" et "solution" par "moyen", et indiqué expressément l'autorisation : si c'est pas concerné par cette loi, ca pourrait l'être par une autre !
L'expression "moyen de lecture de MTP" est encore perfectible, mais si on détaille ca fait une loooongue périphrase : "moyen de lecture légalement proposé par un fournisseur de contenu audiovisuel protégé par des mesures techniques de protection". MLLPFCAPMTP. Ouf !
[^] # Re: Ok avec firefox, KO avec les browsers texte
Posté par Jimmy . En réponse au journal Credit Agricole en ligne refusera bientôt l'accès aux navigateurs alternatifs. Évalué à 2.
Pense à un non-voyant avec un outil de synthèse vocale ou un terminal braille.
http://oralux.org/
Et puis on peut afficher des graphiques avec lynx ... en ascii-art !
http://aa-project.sourceforge.net/aview/
[^] # Re: En effet
Posté par Jimmy . En réponse au journal Credit Agricole en ligne refusera bientôt l'accès aux navigateurs alternatifs. Évalué à 2.
Il y a quand même une grosse marge entre ne rien tester (hormis la config la plus répandue) et vérifier un minimum de compatibilité avec les alternatives qui se développent fortement.
Voici une nouvelle illustration de l'intérêt du respect des normes !
Même si ce n'est pas le cas ici, bloquer un site pour les navigateurs autres que IE c'est nier le but inital d'internet : communiquer.
[^] # Re: excuse bidon
Posté par Jimmy . En réponse au journal Credit Agricole en ligne refusera bientôt l'accès aux navigateurs alternatifs. Évalué à 1.
[^] # Re: Et l'intêret d'un clavier virtuel
Posté par Jimmy . En réponse au journal Credit Agricole en ligne refusera bientôt l'accès aux navigateurs alternatifs. Évalué à 2.
Ceux-ci ne sont pas très miniaturisés :
http://www.thinkgeek.com/gadgets/electronic/5a05/
http://www.insecure.org/stc/ (photo au milieu de la page)
mais avec un petit PIC10F200 et une Flash I²C on doit pouvoir en bricoler un assez compact.
[^] # Re: IE for Mac
Posté par Jimmy . En réponse au journal Credit Agricole en ligne refusera bientôt l'accès aux navigateurs alternatifs. Évalué à 2.
Et en plus, ce sera sans doute possible même sur un Mac ... maintenant qu'Apple fait des PC.