La centralisation n'est qu'un des 4 algos de distribution de données.
Les 3 autres nécessitent un stockage local et une adresse ou un moyen de l'obtenir. Il y a la migration, une donné se balade sur les différents stockages avec un système de pointeur pour s'y retrouver.
Et puis il y a la réplication en lecture, qui ressemble au système de cache. Il y a 2 façon de faire pour garder à jour les données : soit par invalidation des copies "autres", soit par propagation des écritures.
Selon les patterns d'usage, l'efficacité change avec le nombre d'écriture par rapport au nombre de lecture, et la taille des données par rapport à la taille des messages de gestion.
Cela serait bien si le numéro n'était pas unique (par exemple faire des cartes lié à la CI, mais pas forcément unique). Cela évite que le croisement de base de donné puisse donner un tas d'information sur la personne.
Ils ne prennent jamais le temps de copier tes papiers, juste prendre un numéro au mieux. Là, ils peuvent tout copier et te tracer comme les porteurs de leur carte de fidélité sans rien demander.
Je n'ai pas le courage de me lancer dans ce genre de projet. Je voulais juste signaler qu'une telle carte pourrait intéresser beaucoup de monde: Tout ceux qui veulent faire de la robotique un peu costaux (nao, c'est un pc via connecté à un µp pour contrôler les servo-moteur).
Pour que le soft soit aussi gros, il faut que toutes les library soit en 12 000 exemplaires. 3.5Go de binaires, cela représente des milliards de lignes de code.
Dans ce genre de projet, tu as toujours 2 facettes. Le coté joli, marketing qui doit être très policé et bien fini, souvent avec une grosse organisation derrière (gcombust,k3b de kde) et de l'autre, il y a le petit programme en ligne de commande écrit par un expert qui fait le vrai boulot (cdrecord/wodim).
Autant la jolie façade doit s'adapter au reste de l'environnement (windows, gnome, kde, androïd), autant le moteur reste le même.
Dans le cas de la freedom box, cela serait étonnant qu'il n'y ai pas de besoin d'outils en ligne de commande que tous le monde utilise (sshd ?).
je crois qu'il existe des CAN à bus parralèles avec plein d'entrés, cela serait plus simple pour les lires. Je ne suis pas sur qu'une sorte de DMA pour SPI soit si simple et suffisamment petit pour en mettre plein.
Disons qu'une tel carte n'est pas aussi simple que ça du tout. Je voulais signaler aux auteurs du potentiel d'une tel carte fille, en plus si il y a des drivers linux, c'est encore mieux :)
Je me doute bien qu'il y a des cartes filles, je me demandais si il y avait une carte fille avec ce genre d'IOs, car faire ce genre de carte avec des pas fin n'est pas facile du tout.
Les CAN ne s'ajoutent pas à un FPGA, bien qu'il soit possible d'en faire un avec un comparateur externe en plus, ce n'est pas si précis.
C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.
non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.
La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.
là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.
A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.
En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
# GPU
Posté par Nicolas Boulay (site web personnel) . En réponse au journal La solidité des mots de passe. Évalué à 3.
Voici un article sur le cassage de code pour les fichiers d'archives
http://www.presence-pc.com/tests/password-recovery-gpu-23381/
C'est instructif. ( http://www.presence-pc.com/tests/password-recovery-gpu-23381/4/ )
"La première sécurité est la liberté"
# partage de ressource
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Pourquoi la décentralisation fonctionne mal mais est inévitable dans les réseaux sociaux. Évalué à 4.
La centralisation n'est qu'un des 4 algos de distribution de données.
Les 3 autres nécessitent un stockage local et une adresse ou un moyen de l'obtenir. Il y a la migration, une donné se balade sur les différents stockages avec un système de pointeur pour s'y retrouver.
Et puis il y a la réplication en lecture, qui ressemble au système de cache. Il y a 2 façon de faire pour garder à jour les données : soit par invalidation des copies "autres", soit par propagation des écritures.
Selon les patterns d'usage, l'efficacité change avec le nombre d'écriture par rapport au nombre de lecture, et la taille des données par rapport à la taille des messages de gestion.
"La première sécurité est la liberté"
[^] # Re: Pas d'accord...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 3.
pour avoir les lib mix, il faut une distrib qui le supporte. Mandriva semble le faire depuis longtemps.
"La première sécurité est la liberté"
[^] # Re: Carted'identitébelge
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HS - carte d'identité et empreinte de l'index gauche . Évalué à 3.
Cela serait bien si le numéro n'était pas unique (par exemple faire des cartes lié à la CI, mais pas forcément unique). Cela évite que le croisement de base de donné puisse donner un tas d'information sur la personne.
"La première sécurité est la liberté"
[^] # Re: Carted'identitébelge
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HS - carte d'identité et empreinte de l'index gauche . Évalué à 2.
Ils ne prennent jamais le temps de copier tes papiers, juste prendre un numéro au mieux. Là, ils peuvent tout copier et te tracer comme les porteurs de leur carte de fidélité sans rien demander.
"La première sécurité est la liberté"
[^] # Re: Pas d'accord...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal FatELF : binaires universels pour Linux. Évalué à 5.
Tu parles de l'option "-m32" de gcc ?
"La première sécurité est la liberté"
[^] # Re: Carte d'identité belge
Posté par Nicolas Boulay (site web personnel) . En réponse au journal HS - carte d'identité et empreinte de l'index gauche . Évalué à 4.
Donc maintenant il suffit qu'un commerçant demande ta carte pour avoir plus d'info que tu lui donnais avant ?
"La première sécurité est la liberté"
[^] # Re: Java sur le web ???
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 3.
et le html 5, ça reste encore une blague
Même en comptant les applications google ?
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 1.
Je n'ai pas le courage de me lancer dans ce genre de projet. Je voulais juste signaler qu'une telle carte pourrait intéresser beaucoup de monde: Tout ceux qui veulent faire de la robotique un peu costaux (nao, c'est un pc via connecté à un µp pour contrôler les servo-moteur).
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 0.
Pour que le soft soit aussi gros, il faut que toutes les library soit en 12 000 exemplaires. 3.5Go de binaires, cela représente des milliards de lignes de code.
"La première sécurité est la liberté"
[^] # Re: Pas payé
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Réflexions sur la session Centralised Internet... aux RMLL. Évalué à 5.
Dans ce genre de projet, tu as toujours 2 facettes. Le coté joli, marketing qui doit être très policé et bien fini, souvent avec une grosse organisation derrière (gcombust,k3b de kde) et de l'autre, il y a le petit programme en ligne de commande écrit par un expert qui fait le vrai boulot (cdrecord/wodim).
Autant la jolie façade doit s'adapter au reste de l'environnement (windows, gnome, kde, androïd), autant le moteur reste le même.
Dans le cas de la freedom box, cela serait étonnant qu'il n'y ai pas de besoin d'outils en ligne de commande que tous le monde utilise (sshd ?).
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
je crois qu'il existe des CAN à bus parralèles avec plein d'entrés, cela serait plus simple pour les lires. Je ne suis pas sur qu'une sorte de DMA pour SPI soit si simple et suffisamment petit pour en mettre plein.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Disons qu'une tel carte n'est pas aussi simple que ça du tout. Je voulais signaler aux auteurs du potentiel d'une tel carte fille, en plus si il y a des drivers linux, c'est encore mieux :)
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Le problème c'est fabriquer la carte fille qui va avec, la fabriquer soi-même n'est pas simple.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 1.
Je me doute bien qu'il y a des cartes filles, je me demandais si il y avait une carte fille avec ce genre d'IOs, car faire ce genre de carte avec des pas fin n'est pas facile du tout.
Les CAN ne s'ajoutent pas à un FPGA, bien qu'il soit possible d'en faire un avec un comparateur externe en plus, ce n'est pas si précis.
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Tu sais combien ça coute un FPGA avec 1000 ios ? Et le prix de la carte pour le poser dessus ?
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
Si tu divises par 2 ton salaire en suisse combien tu dois gagner aux US ! :)
"La première sécurité est la liberté"
[^] # Re: Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 3.
C'est vrai uniquement pour la partie numérique mais pour les convertisseurs analogiques numériques ?
Je ne crois plus du tout à l'architecture des robot amateurs classiques : une sorte de PC relié à un microcontoleur qui fait les IOs: il y a trop de latences, si le µp fait des traitements, cela veut dire ne pas tenir compte de tous les capteurs et cela complexifie les ordres données par le gros cpu. si le Pc ne devient qu'un auxiliaire de traitement pour la camera, on se retrouve vite à l'étroit dans un microcontrolleur (trop peu de mémoire pour faire des cartes ou ou trop peu de cpu pour faire des calculs complexes)
A un moment, j'ai cherché le sain graal de la robotique : un cpu rapide(>100Mhz), une fpu (plein d'algo sont infiniment plus simple en flottant), des CAN et des pwm. Et bien, cela n'existe pas ! Il manque toujours un truc. Les arduinos n'ont pas de fpu et sont assez lent. Les petit arm (arm7 ou les petit cortex)n'ont pas de fpu et sont limités souvent à 70Mhz. Les gros arm ou dsp n'ont pas de CAN et/ou pas de pwm.
Et pour ceux qui ont des IOs, on est loin de ce qu'il faudrait pour un robot marcheur (nao a 50 moteurs de mémoire, contre 16 pwm présent en général, pour un moteur synchrone, il faut 3 pwm).
"La première sécurité est la liberté"
# Robotique ?
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Sortie de la version 4.0 du "Projet Armadeus". Évalué à 2.
Je voulais savoir si vous aviez une carte additionnel pour faire des IOs pour la robotique qui passe par un bus système.
Pour un robot humanoïde vous avez besoin de gérer 1 à 3 pwm par moteur, et le double de convertisseur analogique/numérique (mesure sur le moteur et sur le mouvement lui-même). Les CAN permettent de lire un potentiomètre qui sert de mesure d'angle absolue (servo moteur), de mesurer la position d'un actionneur et faire le debounce en numérique au lieu de mettre un AO en trigger de Schmitt pour chaque fil, cela remplace souvent beaucoup d'électroniques analogiques.
Il n'y a guère que les roues codeuses qui ont besoin uniquement d'entrés purement numérique (c'est un moyen pour avoir l'information de vitesse d'un axe qui tourne roue fait maison). Le problème des roues codeuses est en général leur prix délirant(~100€), souvent, c'est remplacé par une petite génératrice dont il suffit de mesurer la tension pour connaitre la vitesse de rotation (c'est moins précis).
Bref, l'électronique de robot ressemble beaucoup à celle d'un téléphone portable : grosse patate, grosse autonomie, une camera (seul capteur un peu évolué pas trop chère) mais tout plein d'IOs à basse latence.
Attention, il faut des IOs intelligentes, les CAN sur spi ne sont d'aucune utilité: trop lent. La plus part des CAN demandes un protocole pour être interrogé, c'est souvent impossible d'avoir un flux sauf pour les spécialisés en audio, mais il vont seulement par 2. La mise en place du protocole introduit des latences de lecture et utilise beaucoup de cpu, il faudrait que tous les CAN soit disponible à chaque cycle de calcul du robot (~1ms). Les PWM doivent être gérés par des compteurs internes, tous les machins purement logiciel prennent beaucoup trop de temps machines.
Ces IOs ne peuvent être sur microcontroleur externe : c'est trop lent 90% du temps ou alors cela complexifie le problème qui est la latence. Les bus de communication entre microcontoleur sont trop lent. Les bus can, I2C, etc... tournent autour de 1mbits/s, si on a 50 valeurs de CAN 10 bits (soit 16 bits, 20 bauds), on est déjà saturé à tout juste 1000 transmissions /second.
Un robot réactif a besoin d'une boucle de 1ms entre le moment où il lit les capteurs, fait son traitement et agit sur ses effecteurs. Cela correspond à la vitesse de réaction mécanique de ses moteurs. Sachant qu'il y a toujours un asservissement, le temps réel de réaction tombera autour de 10ms. C'est la différence entre un robot réactif et un chewing-gum.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Oui bien sûr, mais ça suppose que ta mercedes est la fonction de changement de pneu. Donc si c'est une bibliothèque qui n'a pas prévu le coup, t'es mort, tu retournes voir le constructeur.
non, tu encapsules, ou au pire, tu hérites, voir tu hérites juste de la bonne interface avec l'encapsulation.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 4.
La loi a raison. Pour ton deuxième exemple bien complexe, tu as 2 cas de figures : soit il y a très peu de ce genre de pattern, et il est simple d'en faire des méthodes circonscrites à une seul classe, soit tu en as plein et tu est vraiment dans la m... par ce que ce truc va vite devenir complètement in-maintenable.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
obj.getVoiture().getFirstRoue()
là, c'est facile, c'est des getter, mais imagines que ta roue se "balade" dans ton code. Si tu appelles un seul setter, tu va modifier la roue mais aussi la voiture par la même occasion. C'est rarement ce que tu veux faire.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ensuite, l'inline par le compilo devrait régler les problèmes de perf.
C'est le "devrait" le problème : le jit de sun ne le fait pas.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 5.
A court terme, c'est parfaitement inutile.
A long terme, si tu te rend compte de l'inadéquation de ton modèle de donnée dans la classe, c'est facile de le changer et de garder les getter/setter précédent.
En gros, cela permet d'avoir une liaison moins forte entre la classe et son usage.
"La première sécurité est la liberté"
[^] # Re: Chacun son style
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Naissance d'un géant : Java. Évalué à 2.
Ce genre d'optimisation de "delayed initialisation", se fait aussi à coup de pointeur nul que l'on teste avant utilisation.
"La première sécurité est la liberté"