pepie34 a écrit 226 commentaires

Il y a un téléphone sonne ce soir sur le sujet:

La réforme européenne sur le droit d'auteur a franchi une étape décisive et doit confirmer sa courte majorité cet été. >Quel cadre juridique imposer à Internet ? Ce soir, le téléphone sonne Europe fait le point sur le projet !

Invités:
* Virginie Rozière, Députée européenne (Les Radicaux de Gauche), groupe de l'Alliance Progressiste des Socialistes et Démocrates.
* Pascal Durand, Vice-président du groupe Verts-ALE au Parlement européen. Ancien avocat.

Peut-être l'occasion de se faire entendre. #telsonne sur le réseau de microbloging avien.

Lien vers le site de l'émission

En complément,

Ce que je décris là-haut est un gros trucage pour feinter l'allocateur de chunks de btrfs. L'allocateur décide toujours de réserver un chunk sur le disque qui contient le plus d'espace libre. En appelant, btrfs balance avec le filtre devid on indique uniquement que l'on veut ré-allouer les chunks présents sur le disque source. Par contre il n'y a aucun moyen de préciser explicitement où on veut qu'ils aillent. En ayant fait le btrfs fi resize (attention ! avec l'option devid précisant qu'on réduit la taille du disque source), on ne laisse plus de place sur le disque source. L'allocateur va donc déplacer les chunks du disque source au disque cible.

Pour revenir à BTRFS, il y a quand même plusieurs manquements soit dans l'implémentation actuelle soit dans le système en lui même. Citons par exemple:

• le pmove comme simuler ici
• une politique configurable de l'allocateur (pour par exemple prendre en compte une configuration hybride hdd/ssd)
• des profils RAID par sous-volume

A priori, les manquements ci-dessus sont réalisables sans modifier le format disque, mais juste les outils et le driver tout en étant retro-compatible. Certains sont dans les tuyaux.

Par contre, les profils RAID sont codés assez simplement dans le format du fs (DUP/RAID0/RAID1) ce qui à mon avis limitera l'évolution du système. On pourrait par exemple imaginer des profils du type, je veux au moins 3 copies réparties sur au moins 2 disques physiques. Aujourd'hui sans changer le format disque ce n'est pas possible.

J'ai effectué plusieurs fois le même type d'opérations dans des conditions légèrement différentes.

Notamment sur un ordinateur portable et un DD externe, condition qui ne me permettait pas de faire l'opération btrfs device delete simplement. En effet, device delete doit être effectué d'une traite sans arrêt possible et dans mon cas j'avais trop de données pour que cela puisse se faire en une nuit.

Solution: réduire la taille du disque source via un btrfs fi resize d'une taille juste supérieure à la taille utilisée puis à coup de btrfs balance avec un filtre devid on peut bouger les chunks d'une disque à l'autre par une opération interruptible. C'est équivalent à un pvmove de LVM.
Quand tout est transféré, on passe au btrfs device delete final.

git over nntp… çà se tente.

Surtout que par dessous git il y a un fs immutable (les dossiers en code hexa) et que nntp en fait c'est juste un protocole de synchro de fichiers aussi de façon immutable (cf l'orgine dans UUCP).

Pourquoi ne simplement pas se remettre au NNTP Usenet ?
Avec un site web qui ne serait qu'un client web.

Ça couvrirait quasiment tous les besoins du site et pour le restant ben on étend le protocole ce qui lui ferait du bien car la dernière RFC date de 2006.

Trêve de plaisanterie, mais je me dis quand même que 90% des utilisations des forums/listes de diffusion/réseaux sociaux sont possibles en NNTP et çà serait beaucoup plus efficient.

PS Qui connait une app Android digne de ce nom pour faire du NNTP (et pas pour le téléchargement) ?

rech proj pour proj priv self dem brut poss s'adrr a l'hot mart

Apprentissage Automatique

Pour être plus précis ce type de machine est dédié à l’apprentissage automatique Apprentissage_automatique ou machine learning.
Plutôt que de décrire un ensemble de règle à l’ordinateur puis de lui demander de résoudre un problème dans le cadre de ces règles, il s’agit de lui présenter un (grand) nombre de cas et l’ordinateur déduira de lui même ses propres règles de décision à partir de ces cas.

Il s’agit par exemple de lui donner des millions d’images avec une liste des entités se trouvant sur chaque image (phase d’apprentissage), puis on lui présente une nouvelle image qui lui est inconnue et l’ordinateur doit donner les entités qui se trouvent sur l’image (phase de décision). Typiquement ce genre de problèmes est formulé comme un problème d’optimisation continue où on cherche à trouver un minimum (ou plus récemment des point-selles) sur des fonctions très compliquées, par exemple des réseaux de neurones artificiels. La machine de NVIDIA est dédiée à cela, les GPUs étant très performant à faire des multiplications matricielles. Pour info, certains labos français possèdent déjà cette machine.

On est donc très loin de ce qu’on entend dans le grand public comme étant de l’IA ou des concepts qui ont été discutés précédemment dans ce journal. On ne cherche pas à reproduire des capacités cognitives de haut niveau mais des fonctions de perceptions de bas niveau.

Depuis NIPS une des très grandes conférences sur le sujet.

Est-ce que vous savez s'il existe un convertisseur ADC (vers 25MHz) 12/16 bits à prix abordable ? et si un décodeur purement logiciel de signaux TV noir et blanc / PAL / SECAM / NTSC existe ?

Avant 1983, la première chaîne émettait dans une résolution 819 lignes entrelacées pour le noir et blanc; ce qui est meilleur que du 720i. Un de mes rêves est de tomber sur un de ces enregistrements 819 lignes originaux et de les numériser. Je crois bien qu'à l'INA la numérisation s'est faîte à partir des supports 625 lignes analogiques et non pas 819 lignes, fautes de décodeurs numériques adaptés.

Pour ma part je fais un cp -a suivi d'un rsync -aHAXS .
Les options de rsync A et X permettent de sauvegarder les ACL et les attributs étendus. C'est par exemple utilisé par shotwell pour les étiquettes de photos.

Sinon, j'utilise depuis deux mois btrfs et çà a changé ma vie.

Voilà donc le diable, on est donc bien dans le registre de la religion !

Pour le coup ce sont les designers du SIP qu il faut pendre ! Le niveau 7 ne devrait jamais s'échanger de manière autonome des informations des niveaux 3/4. La séparation des couches n est pas respectée.

Pour être propre, si tu me contactes et que je veux ouvrir une connexion dans l autre sens je dois récupérer ton IP sur le socket ouvert en local via l os et pas en me fiant aux informations que tu me donnes dans ton contenu applicatif.
(NB en tcp je comprends mal l utilité de la nécessité de connaître l ip de son correspondant comme il y a de base une connexion dans les deux sens ouverte. Peut être en cas de rupture pour que l appelé réinitialise à son initiative la communication ?)

Transmettre deux fois la même information dans deux niveaux différents (l entête IP et le contenu en soit) c est ca le vrai diable. C est comme avoir deux fois la même info dans deux tables différentes d une même BD, on sait qu'un jour tôt ou tard ca va foirer…

Jamais la table de correspondance est publique !

De toute façon, si tu souhaites "cacher" ton réseau derrière un NAT autant garder une structure réseau IPv4, puisque les avantages de l'IPv6 seront perdues (plusieurs adresses IP atteignables de l'extérieur du réseau par machine).

Cette phrase est la preuve que tu n as pas compris la proposition. Le principe du end to end de l ipv6 est bien maintenu.

Je vais reformuler de deux nouvelles façons:
1. Il s'agit de faire du Network prefix translation avec en plus de l obfuscation du suffixe.
2. Dans du nat44 il y a 1 ip publique avec n ip locales. Dans la proposition ici c est l inverse, il y a m ip publiques pour n ip locales avec m très grand devant n.

Pour reproduire un comportement similaire avec les adresses temporaires telles que proposées par la RFC, il faudrait que la machine tire une nouvelle adresse temporaire très fréquemment et avec plusieurs ip temporaires en parallèles par exemple pour chaque connexion en cours. Cependant, je ne pense pas que les mécanismes proposés puissent tenir un tel rythme.

1) Je crois qu'il y a quiproquo

Dans la proposition le routeur ne s'occupe jamais de la façon dont les machines internes s'attribuent les adresses IP. Cela n'a rien n'a voir avec du DHCPv6.

Le routeur voit passer un paquet qui va de "A vers B" où A est sur son interface interne et B est sur son interface externe, il change l'entête pour "X vers B" où X est dans sa plage de dispo. Il garde en mémoire la correspondance (A,X) et quand un paquet arrive de "C vers X" où C est sur son interface externe alors il change l'entête pour "C vers A". Noter que B et C ne sont pas forcément supposés identiques.

Le routeur n'a rien à faire de comment A est devenu a eu l'IP A.

2) Je crois qu'il y a encore plus quiproquo

Comme indiqué plus haut X ne correspond qu'à une seule machine interne donc çà pète pas les protocoles même le P2P. Tant qu'il y a suffisamment de place dans la table de correspondance, le routeur peut toujours retrouver qui est X même trois jours plus tard.

3) Ce qu'on cherche à cacher: le profil d'activité des machines !

En utilisation stationnaire, une machine est facilement reconnaissable à son profile statistique d'activités, peu importe son IP à l'instant t. Je n'ai pas besoin de savoir de façon déterministe comment elle passe de l'IP X à l'IP Y pour savoir que X et Y sont la même machine. Çà n'a rien à voir donc avec la RFC et comment les IP sont attribuées (aléa ou pas aléa).

Répartir les activités (à la connexion) sur toutes les IPs dispos, çà rend une attaque statistique difficile.

Dans la proposition chaque IP externe est reliée à une unique IP interne. En quoi çà peut péter le moindre protocole ? On respecte bien une IP pointe vers une seule machine.

L'inverse n'est pas vrai, une IP interne peut est reliée à plusieurs IP externe. Comme on peut tirer 72057594037927936 * 256 IPs on va pas se gêner on peut le faire à chaque nouvelle connexion…, si çà c'est pas de l'obfuscation !

Pour le traçage avec les adresses temporaires cf ma réponse plus bas.

Avec les adresses temporaires il est toujours possible de récupérer de l'information qui était plus difficile à extraire avec du NAT44 comme par exemple le nombre de machines internes. Et à partir du nombre de machines internes, il sera facile de trouver des profiles statistiques de chaque machine et donc de relier une adresse temporaire à une machine précise rien que par son activité. (Pour ceux qui connaissent le clustering, une fois le nombre de clusters connu, le boulot de profilage est quasiment fait)

Pour brouiller cela il faudrait un changement très fréquent des adresses temporaires pour que quelqu'un qui observe la sortie de ton routeur ne puissent pas dire en moyenne je vois x IPs sortir, fréquence de l'ordre de chaque nouvelle connexion TCP/UDP. Hors je ne pense pas que la RFC ait été prévue pour une telle fréquence. Rien que la gestion des collisions d'adresses n'est pas compatible avec cela.

L'idée proposée est bien d'utiliser la TOTALITÉ de la plage disponible en attribuant aléatoirement une IP non-utilisée pour empêcher justement la connaissance du nombre de machines. Cela peut se faire sans trop de ressource par le routeur, un générateur de nombre aléatoire suffit (la probabilité que le générateur sorte 2 fois la même IP sur deux connexions sortantes en cours est extrêmement faible ), pas de gestion de collisions à se soucier car seul le routeur attribue les IPs externe. En outre, la mascarade en elle même est bien plus simple que du NAT44, une simple table où chaque ligne contient 2 IPs suffit (l'IP externe et l'IP interne), le nombre de ligne est à fixer en fonction du nombre de connexions simultanées max acceptables par le routeur. Pas besoin de regarder les ports, pas besoin de suivre les connexions…c'est peanuts par rapport au travail d'un NAT44.

Peut être est-ce la peur du 666 mais je ne comprends pas le conflit religieux qui empêche de faire du NAT66 ou du moins une masquarade 66?

En effet, admettons qu'une routeur serve de passerelle entre les internets et un réseau local et qu'il dispose d'un préfixe sur les internets donnant une grande plage d'ipv6 (par exemple si le nombre ipv6 disponible est très grand devant le nombre de machines réelles). Alors quel dogme l'empêche à chaque connexion sortante de la machine X du réseau local vers les nets de tirer au hasard une IP Y dans sa plage et faire une masquarade de Y vers X le temps de la connexion ? C'est beaucoup plus simple que du NAT44.

Est-ce que quelqu'un connaîtrait le nom de la voix off sur l'extrait de l'émission d'Arte ? J'ai l'impression que ce comédien à illustrer de sa voix beaucoup de reportages et documentaires scientifiques de ma jeunesse (petite larme).

L'apport du "deep" c'est justement le contraire: réduire le plus possible le "features engineering" effectué par des humains pour aller vers du "features learning" …

C++ et langage X avec Qt çà va encore mais c'est quand il y a ménage à trois que le statut change pour "C'est compliqué"…

Et avec la volonté de Qt de pousser à ce que la vue soit codé en JS çà va arriver vite.

Merci de passer sous silence l’existence de gtkmm pour gobject ou de swift pour libobjc…

Clairement Qt est mieux foutu (aussi bien pour l'utilisateur que pour le dev) que GTK. Par contre, c'est vraiment la misère pour s'interfacer avec un autre modèle objet.

Premièrement attention gtk ≠ gtkmm ≠ gobject ≠ glib .

Le problème de Qt c'est qu'ils se veulent multi plates-formes et multi langages…

Le modèle QObject est une surcouche du modèle de C++ et donc cela impose que les autres langages puissent se contorsionner pour rentrer dans ce modèle.

En revanche, les modèles d'objets de GTK et de Cocoa (OpenStep),respectivement GObject et libobjc, sont écrits indépendamment d'un langage. Dans les deux cas tu peux écrire un programme en C pure si tu as envie (avec tout le glue code que cela implique) mais aussi contrairement à ce que tu indiques en langage de haut niveau type C++ ou objective-C ou SWIFT ou vala ou c# …
A ce moment là, la classe objet de base court-circuite le modèle objet propre au langage pour utiliser celui externe (ce qui relativement facile à faire). Ainsi tu codes en gtkmm (le binding c++ de gtk) comme si tu codais en c++ sans le glue code. Idem pour Cocoa en c++.

Comme effet de bord, ça permet de s'échanger des classes entre langages différents ce qui pour rappel n'est pas standard même entre deux compilos de c++.

Essayes d'utiliser une classe héritant de QObject écrite en Java dans un programme en python…tu vas pleurer.

Le truc qui me peine vraiment avec Qt est que son modèle objet est fortement lié à celui du C++ .

Ca rend le binding difficile pour certains langages et en plus ca le prive de technos innovantes comme Core Data ou son équivalent libre Core Object.

Mon idéal serait donc un Qt reposant sur un modèle objet indépendant du langage. Et oui: gobject + Qt !

Là je crois qu'il y a quiproquo.

L'utilisateur se fout de savoir à quel niveau d’abstraction se fait la persistance des données. Ce qu'il veut s'est juste retrouvé ses petits la prochaine fois qu'il ouvre le même logiciel.

Par contre, je pense 90% des développeur ont entendu parler sinon pratiqué la programmation orienté objet. Alors pourquoi en tant que programmeur on doit toujours se taper à la main:
*L'annulation des actions de l'utilisateur
*Le branchage, la fusion d'un graphe d'objets
*La gestion de version en générale
et choisir avec ses propres a priori entre:
*La sérialisation/désérialisation d'un graphe d'objets vers un fichier
*La persistance d'un graphe d'objets vers une BD (via ORM ou pas).
Ainsi pour moi, c'est pas à l'application mais bien à l'environnement desktop de l'utilisateur de décider comment se fait cette persistance.

Quelques pointeurs supplémentaires sur des projets qui vont dans le même sens:
* Gobject un gestionnaire d'objets agnostique du langage de programmation
* MMtk le gestionnaire de mémoire de llvm
* VMkit et VMkit2 ou comment factoriser le travail de différentes VM

Sauf erreur de ma part, le paradigme de fichier et de dossier est antérieur à la métaphore du bureau. Il même antérieur à l'informatique ! Il provient de la mécanographie et du traitement automatique des cartes perforées Source .

Mais encore une fois, on reste sur le troll hiérarchie vs tags, alors que le vrai débat c'était: Est-ce que le prog, il doit penser fichier ou objet pour faire la persistance de ces données ?
Si la réponse est objet, alors que tous les environnements possède un accès aux fichiers standardisé (cf stdio), rien de tel n'existe côté objet. Plein de petits bouts ici et là … mais c'est pas pensé et construit de façon cohérente.

Mettez un diamant Core Object au cou d'un vieux troll tout poilu, hiérarchie vs tags, vous êtes sûr que personne ne verra la pierre précieuse.

Trêve de plaisanterie, le dit Core Object permet d'intégrer très simplement les mécanismes d'un DVCS au sein de son application Desktop. La granularité de ce DVCS étant un objet et non pas un document, l'application gagne automatiquement un mécanisme undo/redo et un mécanisme d'édition collaborative.
En contrepartie, il faut déléguer la partie Modèle de son MVC à une bibliothèque externe.

C'est une réelle avancée pour le développement et la maintenance des applications. Imaginer donc, pour un traitement de texte par exemple, une fois écrit proprement l'UML de mon modèle de document et instancié ce modèle par ce mécanisme, le développement pourra se concentrer sur le contrôleur et la vue.

Problème, Core Object s’appuie sur la gestion des objets d'un langage / d'une VM précis en l’occurrence Objective C. Afin de pouvoir généraliser ces mécanismes, il faudra penser une plate-forme de gestion des objets commune aux différents VM, langages, et frameworks.

Il me semble inefficient (voir dangereux) que cette plate-forme commune soit uniquement disponible sous forme de SAS via Drive, iCloud, Dropbox…
Par contre, le niveau OS ou Desktop me semble tout à fait adéquat.
Il y a déjà des expérimentations en ce sens. Par exemple, l'interface graphique rio de Plan 9 s'appuie sur le VFS unique à chaque processus pour fournir un mécanisme équivalent. Chaque objet de l'UI d'un processus est représenté par un fichier dans son propre VFS.