Sytoka Modon a écrit 4538 commentaires

Ton apparence et ta manière de parler rentrent certainement dans les critères d'acceptabilité sociale de la police et tu n'es pas un militant politique radical

Ah ah, c'est même pas juste en plus ;-)

Si je ne suis pas fiché aux RG, c'est qu'ils sont nuls… Non, d'expérience, on n'est très peu contrôler sur les routes en France. Beaucoup de texte, beaucoup de loi mais en pratique, très peu de contrôle car très peu d'agent. Pour moi, c'est plus de la loterie. Un jour, tu tires le mauvais ticket et tu es bien emmerdé (vu le nombre de texte, impossible de ne pas franchir la ligne rouge de temps en temps).

Après, j'ai pas été lancer des pavés aux champs Élysées ces derniers temps non plus, d'abord parce que je n'aime pas cette avenue et que par ailleurs, la violence est le dernier refuge de l'incompétence (Asimov).

Quels sont vos stratégies pour sécuriser votre vie privée dans un monde qui devient totalitaire ?

Il ne faut pas exagérer non plus. En 30 ans de permis de conduire, j'ai été contrôler deux fois, une fois pour me demander si je voulais répondre à un sondage et l'autre fois je n'avais aucun papier sur moi et ils m'ont laissé repartir !

Je suis allé en Amérique du Sud plusieurs fois -> J'ai été contrôlé en moyenne une fois par mois la bas.

Nous avons la chance d'avoir la loi informatique et liberté et maintenant le RGPD Européen. D'ailleurs, l'Europe nous protège pas mal sur la question. Ma stratégie à très cours terme est d'aller voter correctement le 26 mai ;-) Chacun est libre de son choix, je conseillerais juste d'éviter les deux premiers des sondages actuels qui ne sont pas sur ce sujet les mieux placer je pense…

Plus de 90% du temps, tu relies du code d'un autre. Avec le XSLT, tu as la garantie d'avoir un XML valide mais est-ce le bon XML final ? Tu et les autres vont en ch… à maintenir et à faire évoluer ce morceau là du traitement !

XML comme YAML sont fondamentalement des langages de description. Vouloir les transformer en langage déclaratif n'est pas une bonne idée. C'est trop clairement écrit dans la structure initiale.

Le LISP qui est quasi du XML avant le XML mais basé sur une syntaxe en ( n'a pas ce problème car justement, ces concepteurs ont pris dès le début la ( afin de pouvoir mixer les deux : codes et données. Et encore, le paquet de )))) n'est pas toujours très parlant…

La syntaxe pour décrire un objet et pour du code est la même. C'est hyper simple à parser. Bref, c'est un bon langage pour faire des extensions.

Personnellement, j'aime bien le YAML pour décrire mais quand tu vois certains YAML d'aujourd'hui (Ansible…), on veut en faire un langage de script avec des boucles ! Un peu comme la catastrophe du XSLT pour le XML.

Le LISP et ses dérivés n'ont pas ce problème là. La mixité donnée / programme s'est toujours bien passée dans cette syntaxe ;-)

Merci ;-)

Tu ne pouvais pas simplement répondre sans être sur la défensive, limite méprisant ?

Moi je trouve que depuis le début il répond très calmement et du mieux qu'il peut. Bravo à lui. Par contre, moi, en tant que regard extérieur à cette conversation, je te trouve sur l'agressivité tout le temps et limite méprisant.

Voila, c'était une remarque que je voulais faire à toi mais il y a en d'autres qui sont un peu sur la même longueur d'onde que toi sur ce post.

Je crois que vous vous prenez tous la tête.

Pas du tout. Depuis le début je dis que le résultat peut être visuellement des plus réussi et agréable à l’œil. Mais DLFP ne serait pas linuxfr si on ne pouvait pas profiter d'un post pour philosopher autour de celui-ci ;-)

Ma question était effectivement surtout sur le coté technique. Quelles sont les principales différences et / ou choix techniques qui sont différents entre les deux systèmes ?

Il y a un paquet de serveur qui ne sont pas sous Windows ;-)

On m'a déjà "vendu" Nix une fois que c'était génial et tout et tout… Déjà, nix n'est pas toujours compatible avec lui même selon les versions donc l'environnement stable sur un cluster qui évolue et se renouvelle… Un peu sur-vendu.

Faire un paquet Nix n'est pas si facile que cela. Qu'en est-il d'un paquet Guix ?

On a toujours le même environnement… à condition de ne pas dépendre du noyau et de ses modules. Si vous faites du CUDA, Guix ne va pas plus être magique que Nix ou que module je pense.

On a toujours le même environnement… ce qui permet la reproductibilité. C'est un argument actuel en science. Autant je trouve GÉNIAL le projet Reproductible Build en partie porté par Debian (un même code source donne toujours le même code compilé selon l'algorithme SHA256, donc je suis sur que le code qui tourne n'a pas de porte dérobée rajoutée en cachette), autant je suis sceptique en science pour du code ou ce mot, reproductible, est utilisé pour complètement autre chose. En science, je me fou un peu (je fais exprès de prendre l'argument 100% opposé) de retrouver avec le code du voisin le même résultat que lui à la dixième décimale ! Pour moi, la reproductibilité en science est qu'une autre équipe, avec un environnement quasi-identique (mais non forcément identique) retrouve les mêmes lois de comportement, les mêmes phénomènes. Cela permet d'enrichir et de conforter un modèle. Retrouver N fois le même résultat avec le même code n'a pas un intérêt fou, sauf à vérifier que le chercheur n'a pas triché, et encore… En plus, ce coté reproductible pousse les personnes à faire du code non portable, aux API qui changent et dont le résultat est fortement dépendant des versions des modules de ceci et de cela. Telle et telle version marchent (même s'il y a un bogue et que c'est hyper dépendant des versions), hop je publie -> c'est reproductible par tout lecteur ! Bref, cette notion là éloigne au final assez fortement de la notion de reproductible au sens universel du terme.

Qu'en est-il du Python ? Car en pratique, c'est souvent les modules Python qui sont "chiants" à packager vu que cela bouge tout le temps (trop souvent) et que les API changent… Avec Nix, mes amis font du conda ou du virtualenv… Bref, c'est pas une super réussite !

Merci, c'est le lien auquel je pensais.

D'ailleurs quelqu'un connaît la principale différence entre Minix et Hurd ? Je vois que Redox suit plutôt la voie de Minix.

Oui. De mémoire, le noyau par défaut de Debian est "propre". Mais il y a toujours plus blanc que blanc ;-)

Et cela fait très longtemps que la FSF a abandonné le projet Hurd en temps qu'OS alternatif et donc ne met plus de bille dessus.

Je viens d'aller voir, le projet n'est pas mort mais tourne au ralenti depuis 2016 : http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/.

Certaines idées étaient vraiment bonne d'ailleurs, les containers que l'on voit partout de nos jours sont quasiment une brique de base de Hurd ! L'informatique distribuée n'était pas aussi courante début des années 90 que de nos jours. Peut être faudrait-il reprendre les concepts de base et repartir sur une implémentation en Rust de base plus sure ?

Si tu lis tous mes posts, c'est globalement ce que je dis ;-)

Cela étant dit, en science, s'il te manque un point et que tu l'interpoles pour le rajouter sur la courbe en disant que c'est une information sur la manip, on n'est pas loin de la supercherie…

Dans un système parlementaire représentatif, il faut une majorité de 50% pour chaque texte. S'il y a 50% de lanceur d'alerte sur un texte commun, cela devient un parti politique ;-)

C'est ce que je dis, c'est bien d'avoir quelques lanceurs d'alertes mais pas la peine d'en avoir 400 ;-)

Extrait de https://fr.m.wikipedia.org/wiki/R%C3%A9versibilit%C3%A9_thermodynamique

"
L'interprétation statistique de l'entropie et la théorie de l'information (avec notamment l'entropie de Shannon) fournissent également des interprétations à l'irréversibilité des transformations. Elle correspond :
- à une évolution spontanée de tous les systèmes vers l'uniformité ; quand toutes les grandeurs intensives décrivant le système sont uniformes, le système ne peut plus évoluer spontanément.
- à une perte d'information sur l'état du système ; toutes les évolutions s'arrêtent lorsque le désordre du système est le plus grand possible.
"

Encore une fois, il ne faut pas confondre information dans une image et effet visuel. Une image avec plus d'information peut être moins belle.

Je reprends le concept. Ton image initiale A subit un traitement et donne une image B. Si le traitement est réversible, alors B contient autant d'information que A. Si le traitement n'est pas réversible, B contient moins d'information que A sur l'état initial, c'est à dire cette prise de photon à l'instant t d'un instant de l'espace temps. La plupart des traitements sont irréversibles.

Conclusion : on sauve toujours les originaux qui ont intrinsèquement le plus d'information. On peut toujours refaire les traitements qui donnent de beaux effets visuels.

Après on est humain donc on n'est pas là pour faire de la théorie de l'information sur toutes ses photos personnelles, donc ne garder que le résultat d'un traitement parce qu'il est plus joli visuellement est tout à fait compréhensif ;-)

Il n'y a pas de majorité au parlement Européen. Il n'y a pas de sièges bonus pour celui qui gagne. Il n'y a pas de gagnant au sens strict du terme car il doit y avoir peu de liste qui dépasse les 50 % dans leur pays et aucune qui le fait au niveau de l'UE.

Donc à chaque vote, il faut qu'il y ait une majorité et des coalitions pour atteindre les 50%.

Ensuite, comme dis plus haut, les députés ne sont pas spécialistes de tous les sujets. Il est donc tout à fait normal qu'ils se regroupent par affinité et que certains affinent plus un sujet et ainsi de suite. Au moment des votes, tu votes en suivant l'affinité de ton plus proche groupe et inversement, mais sans normalement jamais franchir ta conscience. C'est ce que l'on appelle la confiance dans un groupe.

On va dire qu'ils ont a peu prêt le même poids que le sénat en France. Pas énorme mais bien mieux, beaucoup mieux qu'il y a 20 ans.

Par ailleurs, il y a tout un tas de sujet ou ils ont pas mal défendus les citoyens, mieux que les chefs d'état qui ont un discours dans leur pays et un autre lorsqu'ils sont ensemble…

Ne pas mettre de limite serait intéressant si on faisait un vote de type Condorcet à la méthode Schulze (utilisé dans les votes Debian).

L'objectif d'un député n'est pas de toucher le salaire et d'avoir l'immunité parlementaire (quoique pour certain cela semble le cas) mais d'influer sur la politique à mener. Dans ce mode de représentation, être tout seul n'a que peut d'intérêt. Donc selon les sujets, il faut former des groupes afin d’insuffler des grandes directions ici ou là.

Avoir un ou deux lanceurs d'alerte à Strasbourg, c'est bien. Pas la peine non plus qu'ils soient 50 ;-) Pas la peine non plus d'attendre après le tirage de se demander si les personnes élues sont capables de discuter a minima avec les voisins et pouvoir perdre ainsi 5 ans. Il y a suffisamment de personnes motivées pour essayer de faire en sorte que les personnes élues soient capables de travailler en groupe.

On parle d'un parlement, pas d'un spectacle avec des one man show ;-)

PS : après il y a d'autres modes de représentation du peuple mais là, on parle d'un cas précis.

Il me semble que sauf dans les communes ayant des machines à voter (très peu), ce sont aux listes de financer les impressions des bulletins de vote. Donc il est quasiment sur qu'il n'y aura pas 33 bulletins possible partout.

La règle du pognon est un peu bête mais faut être honnête, la multiplication des listes n'est pas du tout adapté à ce mode de scrutin.

PS : moi j'ai toujours été personnellement amusé de voir tous ses anti-européens chercher un poste bien payé à Strasbourg et profiter au max du système ;-)

En quoi l'apport externe d'un humain est différent de l'apport externe d'un réseau neuronal ?

Je pensais à tous les traitements basés sur l'image elle même, certains très puissants qui sont basés sur des équations différentielles. Ces traitements améliorent le contraste ou la netteté mais pas la quantité d'information.

Pour un réseau de neurone, je ne sais pas mais j'ai envie de dire contre le sens premier que cela ne change rien. L'image finale est certes plus belle mais elle n'a pas plus d'information. Cependant, le réseau de neurones stocke en partie les milliers (millions d'image) qu'on lui a fait mangé donc il est possible qu'il en injecte une partie dans l'image finale ? Dans ce cas là, l'image finale pourrait (conditionnel car j'ai quand même des doutes) avoir plus d'information globalement que l'image initiale mais pas plus d'information sur la « réalité » représentée par l'image initiale. Reprenons l'exemple de la voiture vendue en une seule couleur, par exemple rouge. Le logiciel va alors la mettre en rouge. En pratique, le propriétaire l'avait peut être repeinte en jaune. On n'en sais rien. Le réseau de neurone crée une fausse réalité, certes belle, mais n'ayant pas plus d'information sur la réalité initiale que la première image. Le traitement a crée une image composite. Ce serait intéressant d'avoir l'avis de David Tschumperlé car c'est lui le super spécialiste ici de ce genre de question ;-)

Si tu combles un trou avec une copie d'une autre image, là tu as un apport d'information extérieure. Dans le cadre du trou noir, il me semble que ce sont des millions de données mixer qui ont donné l'image finale. Le cas me semble donc très éloigné du présent sujet. On récupère des gouttes d'information à droite et à gauche pour les assembler dans une seule et même vue 2D.

Si tu fais un travail manuel, tu peux ajouter de l'information à la photographie par cet apport externe et donc améliorer l'entropie du système (sinon pas de tableau, d'artiste…). Mais si c'est un algorithme automatique, ce n'est pas possible.

Cela dit, ce n'est pas pour cela qu'il n'y a pas des algorithmes qui nous permettent d'avoir l'impression que c'est mieux. Le résultat final peut nous sembler mieux car notre vision n'est pas complète, nous n'avons qu'une vue partielle des données dans une image. Je dis juste qu'intrinsèquement, on perds de l'information.

Les deux ne sont donc pas incompatible : perte d'information mais meilleur résultat visuel.

Je ne dis pas que des algorithmes ne marchent pas pour donner l'impression d'une amélioration de la définition mais il n'y a pas d'amélioration intrinsèque. L'algorithme peut toujours être rejouer de A vers B mais on ne peut pas retourner de B vers A sans perdre des informations (si le format est par exemple le jpg).

Entièrement d'accord avec toi. C'est ainsi que je fait de plus en plus. Cela permet d'avoir des petites briques qu'on teste bien de manière indépendante et qu'on comprends. Si la vitesse n'est pas un critère, c'est vraiment intéressant.

Deux cas que j'utilise, un bien et un mauvais :

• si un script doit faire certaines commandes importante (type rm ou autre), j'ai tendance à le couper en deux. Le premier fait des écho des commandes mais ne fait rien et je l'utilise au final comme cela

 ./mon-script | bash

C'est assez pratique pour éviter les grosses conneries !

• les anciennes de bash n'avais pas les tableaux associatifs. Si on commence à utiliser les variables vectorisées (en gros la variable stockée dans la chaîne d'une autre variable, il est temps de passer à Perl ou Python ou de mettre à jour son bash ;-) Extrait partiel d'une de mes tentatives dont l'objectif était de gérer un cache des groupes des personnes dans un traitement afin de gagner du temps… À éviter !

 eval "export ${var_user}='${string}'" # "
 ...
 var_user="user_$(echo ${user} | tr '-' '_')"
 users="${users} ${!var_user}"