Nicolas Boulay a écrit 15823 commentaires

on parle aussi de la période 50-80

"La première sécurité est la liberté"

Attention quand même au tableau de Pickety sur le système régressif : il ne tient pas compte des prestations socials.

C'est d'ailleurs regrettable que les sources de ses courbes ne soient pas facilement éditables pour en tenir compte.

"La première sécurité est la liberté"

senior pour moi, c'était +10 ans. Mon bon, j'ai l'impression qu'une personne qui est encore développeur à 35 ans a raté à sa vie.

"La première sécurité est la liberté"

J'aime bien la case "senior" pour 6 ans d'expérience…

"La première sécurité est la liberté"

Non, de ce que j'ai vu les salaires fixent sont sensiblement les mêmes. Sauf que les primes sur objectifs peuvent doubler le salaire.

"La première sécurité est la liberté"

La niveau de sécu n'est pas le même au US (pas de longue maladie et plafond de dépense) mais un étranger qui débute, c'est 70k€.

"La première sécurité est la liberté"

Je mets les infos sur un seul système, et j'autorise l'accès à une partie ou une autre des infos.

Sauf qu'un seul système nécessite que les 2 administrations se mettent d'accord pour dépendre d'une 3ième. Ensuite, tu prends le pari que l'administrateur de la base soit honnête et respecte les droits d'accès. Ces problèmes n'existent pas avec 2 systèmes et 2 authentifications.

Si tu veux que le citoyen ait besoin de fournir les autorisations d'accès d'une administration à des informations hors de son champ minimal, la centralisation ne l'empêche absolument pas.

Je n'ai pas compris. Une base de donné avec droit restreint n'est pas un moyen fiable pour garantir l'interdiction de recouper les données sans intervention de l'utilisateur.

"La première sécurité est la liberté"

C'est pour ça que je proposais que c'est l’outil final en fasse de l'utilisateur qui fait le recoupage de donnée et surtout pas les administrations.

"La première sécurité est la liberté"

L'idée est que c'est plus facile et plus petit un meta meta modèle. Une ontologie cela semble énorme à mettre en place.

"La première sécurité est la liberté"

-Centraliser les données

Enorme problème de gestion de la vie privé pour les particuliers, risque énorme d'usine à gaz version Louvoie pour les entreprises.

(eg: si je déménage, je ne devrais avoir à le déclarer qu'une seule et unique fois, l'info doit être automatiquement dispatchée à tous les services concernés)

Tu imagines la tronche du système qui gère cela, pour des centaines d'administration différentes ?

-Démarrer un plan d'élimination des documents papiers au profit de documents électroniques (mais il faut mettre en place un certificat électronique pour remplacer les signatures traditionnelles)

J'imaginais une pure transposition des formulaires administratifs en fichier signé. En général, un formulaire papier est amendé par une ou plusieurs administration puis suit un circuit de signatures. C'est différent d'un formulaire électronique qui remplit une base de donnée.

Est-ce qu'il existe un format de formulaire (genre doc pdf) qui inclus les signatures électroniques et le suivi de modification, avec plusieurs couches de signatures, pour avoir le même garantie que le fonctionnement papier actuel ? Le suivi serait ainsi individualisé, et l’interconnexion de base de donnée moins nécessaire, non ? Le fichier serait autoporteur.

Je rajouterais aussi la nécessité d'une propriété d'auto-remplissage par connexion à différent site web, de différentes administrations. Cela permet le remplissage rapide, sans avoir besoin que les administrations aient des données interconnectées, seul les personnes propriétaires des données feraient la connexion volontairement par le biais du formulaire.

"La première sécurité est la liberté"

Il suffirait de pouvoir le déléguer à des entreprises certifiés.

Ou encore plus simple, définir une norme de signature de document sans stockage. Le boulot de l'état se limite à un horodatage + signature cryptographique. A toi de gérer le fichier, ensuite.

"La première sécurité est la liberté"

j'ai fais 2 propositions, dont une générique sur la suppression des seuils pour en remplacement aussi générique, mais avec des exemples trop fiscal et non "entreprise". Il s'est fait refuser.

"Néanmoins, nous ne pouvons publier votre proposition "Suprimer l'utilisation de seuil " car celle‐ci ne respecte pas la charte d'utilisation du site."

Mais c'est vrai que si le boulot de recherche de doublon n'est pas fait par l’extérieur, c'est un peu idiot.

"La première sécurité est la liberté"

En gros, tu dis que si le meta modèle est présent avec les données, faut-il encore se mettre d'accord sur le meta meta modèle ?

Je partais sans doute un peu trop vite sur le fait que le meta meta modèle commun faisait parti du format de fichier.

"La première sécurité est la liberté"

Sauf que tu n'as qu'un argument d'autorité et tu ne montres en rien pourquoi c'est impossible.

Il te suffit de montrer un contre exemple, cela ne devrait pas trop compliqué.

"La première sécurité est la liberté"

"regarde les langues parlées : elles sont "bien définies","

Non, justement elles ne le sont pas.

"je bosse dans les meta-données venant de plein de format différents, j'en chie tous les jours sur ces "équivalences"."

Quel rapport avec leur définition embarqué dans le format ?

"La première sécurité est la liberté"

J'ai l'impression qu'il est complexe de se mettre d'accord sur la forme des meta-donnés pour une série de document qui implique beaucoup d'intervenant.

Est-ce qu'il n'existe pas de format de donné qui embarque leur propre description ? En gros, d'avoir un XML avec sa DTD ou équivalent dedans ?

L'open data semble avoir ce problème récurent de format. Si les meta données sont définis, faire des équivalences entre format ne devrait pas être difficile non ?

"La première sécurité est la liberté"

Ce qui, avec hashcat, est d'une très relative utilité.

"La première sécurité est la liberté"

Si les mots de passe sont partis, c'est autrement plus gênant.

"La première sécurité est la liberté"

Il n'y a pas des carte un poil plus chère qui font le boulot ?

"La première sécurité est la liberté"

Disparu avec son créateur.

"La première sécurité est la liberté"

Je n'ai pas bien compris l'usage de Box, est-ce qu'il s'agit du même système d'expand de Lisaac, qui permet d'éviter les cochonneries de type natif de Java (int != Integer) ?

Dans Lisaac, c'était hyper puissant, de faire la différence entre un layout mémoire "en dure" et un arbre de pointeur tel que se présente une arborescence d'objet. Typiquement, cela permettait à l'OS Isaac de coder les pixels de l'interface graphique comme des objets, sans perte de vitesse par rapport au C.

"La première sécurité est la liberté"

Non, même si tu n'as plus de bus SPI séparé, tu peux rajouter d'autres sur le même bus, il faut juste pouvoir générer un CS par esclave (inconvénient du SPI par rapport à des « vrais » bus série).

Pourquoi ils ne font pas de vrai bus d'extension série, avec possibilité de chainage ? Si la partie d'adresse prend trop de place, il faut un encodage type UTF-8. Ensuite, il faut trouver un moyen de démarrer pour faire de l'allocation de zone mémoire, mais cela se fait depuis le PCI.

Mais avec un système numérique, chaque port est identique, interchangeable et complet : au lieu de devoir par exemple choisir x emplacements de borniers et x fils séparés pour aller vers tel membre ou tel moteur, et y vers un autre, tu peux utiliser un connecteur et un câble uniques pour chaque module.

Tu oublis les fils qui partent de chaque module pour aller vers les capteurs ou les moteurs.

"La première sécurité est la liberté"

Là aussi, c'est encore une solution de facilité (on acquiert les entrées aussi vite qu'on peut même si elles sont dégueulasses comme des bourrins et ensuite on verra bien comment on les filtre à l'intérieur) et on bouffe des ressources et ça explique qu'on ait besoin d'un gros CPU, de RAM, et de rentrer plus de données.

Et du coup, le temps de réactivité annoncé est à moitié bidon, puisque on ne réagit qu'après avoir pris en compte les 10/20/30 derniers échantillons (et donc 10/20/30 cycles) et viré/lissé/filtré les mauvais. Il est flottant, en fait.

Tu es bon en hard, mais tu n'es pas la moindre notion de conception de système embarqué ? C'est ça ? Le fait de lisser sur 1 ou 10 cycles,est un choix de conception, qui peut arriver bien après la conception du hard.

Dans ce genre de système, tu as des taches à vitesse fixe. 1 khz a été choisi par beaucoup d'équipe e=m6, car c'est en gros la vitesse qu'il faut pour qu'un PID soit assez réactif, et tout mettre en commun permet de faire bien plus (asservissement 2D ou plus, détection de glissement, de choc,…).

Si tu veux faire complexe, tu peux toujours avoir une tache à 1kz qui dialogue avec une autre à 10Hz, si tu as besoin de plein de temps cpu.

« Bien moins de fils » avec un fil pour chaque entrée venant de chaque capteur et un fil allant à chaque commande par rapport à une liaison série à 1/2/3 fils qui transporte l'ensemble des infos de 15 capteurs et 15 sorties ???

sauf que tu oublis les fils liant ta carte fille et les capteurs. Donc tu as tout les fils d'avant, plus les fils numériques, sauf si tu mixes la carte puissance et la carte capteur.

Et le jour où tu auras besoin d'un de plus que ce que tu as prévu, ben tu refais toute une carte mère.

C'est pareil, si tu manques de lien spi.

Faut les programmer, c'est sûr, mais si on ne leur fait faire que ça (lire leurs entrées analogiques, éventuellement signaler au SoC qu'elles sont prêtes, et envoyer les données quand le SoC leur demande), ce n'est pas bien compliqué.

Il faut voir si la latence du cycle complet est assez rapide. En général, ce genre d'architecture est lente, (tu n'utilises pas de SPI à 40Mhz à travers des fils de base, si ?)

Cela existe des composants spi avec ADC + PWM en sortie ?

"La première sécurité est la liberté"

Ensuite parce que si on veut capter le peu de mouvement possible en 1/1000e de seconde2, il faut pouvoir mesurer des variations très faibles avec une très bonne précision, parce que sinon ça ne sert à rien de capter& réagir toutes les millisecondes ; et donc ça veut dire un signal très propre, sans bruit, et des ADC dont les derniers bits sont fiables.

L'avantage d'aller plus vite que la mécanique est aussi de pouvoir faire du filtrage numérique. C'est bien plus simple à modifier.

Avoir des modules est généralement une bonne idée.

Oh non. C'est une très très mauvaise idée. Je suis d'accord pour la facilité de développement. Mais au niveau de la fiabilité, cela n'est plus la même chose. Moins il y a de connections mieux on se porte.
J'ai vu des archis de robot avec plein de µP chacun sur sa carte, c'est bien plus simple d'avoir une seul carte et tout dessus. Il y a bien moins de fils et bien moins de problèmes.

De plus, tant qu'à avoir des modules, autant les déporter, ça arrangera bien les éventuels problèmes de qualité des signaux analogiques.

C'est vrai que cela a du sens pour chaque moteur ou groupe de moteur, couplé à la partie puissance, mais il faut des cartes numériques stupides, pas d'asservissement par exemple.

Tu peux préciser un exemple de composant problématique ?

J'en ai pris un au hasard http://www.ti.com/lit/ds/symlink/tlc1518.pdf . J'ai vu qu'il y a un mode "repeat" qui peut être intéressant pour 8 voies, mais j'ai l'impression que l'envoie est contrôlé par 3 bits externe (INT, CSTART, FS). C'est autant de bit pris sur le SoC. Et j'ai peur que pour gérer l'entrée, il faut commander ses bits, ce qui prend tout le cpu, pendant ce temps là.

D'ailleurs, je n'ai jamais compris que personne n'est fait encore de bus d'extention série de µP avec adressage. Électriquement, cela peut être du SPI (2 ou 3 fils), mais ensuite, qu'il n'y ai rien besoin d'autre. Cela serait une sorte de mini PCI-express. L'I2C fait un peu ça, mais c'est lent, et l'espace d'adressage est petit, rarement inclus dans l'espace d'adressage du µP, et il faudrait du DMA.

"La première sécurité est la liberté"

Tu es conscient que tu cherches la quadrature du cercle ?

Oui et non, c'est surtout que les fabricants de puce n'ont pas vu d’intérêt pour la robotique.

Je suis conscient que les procédés de SoC ne sont pas adapté au ADC, et que les procédés de µP ai du mal avec le wifi. Mais bon, 160 Mhz, cela irait. Et un BGA tient les 500 broches, si le PCB est petit cela ne devrait pas être trop couteux.

tu voudrais un boîtier sans trop de pattes ?

Je veux surtout un truc pas trop chère et si tu as 2 puces, tu as 30 pattes pour communiquer entre les 2.

En plus tu ne veux pas optimiser en hiérarchisant les entrées/sorties ni en les multiplexant, du coup toutes au max de précision et il faut toutes les caser dans un bref laps de temps. => bouffage de ressources et restriction du choix.

Tu es un vrai hardeux qui croit que le soft est magique :) Si tu gère l'équilibre d'un robot humanoïde tout bouge en même temps et tous les moteurs sont ajustés.

Sans même parler de la tronche des signaux analogiques dans ce merdier.

C'est pas faux. En même temps, 8 ou 10 bits c'est suffisant, et 1 000hz, c'est que dalle. Un adc de base à 10 bits doit pouvoir tourner à plusieurs MHz, à multiplexer sur plein de lignes. Ensuite, souvent le signal est sur la tension, un pull-up pour avoir un peu d'intensité, permet de masquer le bruit.

Au contraire il me semble qu'il faut réduire le nombre de fils an multiplexant les infos sur de simples lignes numériques.

Si tu as un robot de 50 cm, tu ne gagnes rien. Et tu as une pelleté de mini carte en plus, et de connecteurs (c'est chère les connecteurs).

Le SPI est un peu pourris, cela bouffe beaucoup de cpu. J'ai vu des CAN spi qui avait des attentes actives, c'était rédhibitoire, surtout pour une dizaine. Tu as donc besoin de truc spi qui fonctionne avec DMA, c'est pas évident. Il faudrait un CAN à ~4 entrées qui envoient en flux ses données, pour y gagner, et les pwm dans l'autre sens.

"La première sécurité est la liberté"