BAKfr a écrit 76 commentaires

En fait, il y a plusieurs niveau de découpage.

• Les pages sont la plus petite unité de donnée, entre 2Ko et 32Ko. On peut écrire ou lire une page, mais pas la modifier ou l'effacer.
• Les pages sont groupées en erase blocks (généralement entre 128Ko et 2Mo). Si on veut réécrire des données, il faut remplacer un erase block d'un coup.
• Le contrôleur du SSD travaille avec des structures encore plus grandes, les segments. Un segment fait généralement 4Mo (parfois 2Mo ou 8Mo). Il me semble que le wear leveling se fait segment par segment.

Note que ces infos datent d'il y a quelques années maintenant et concernent les mémoires de type NAND. Je ne suis pas sûr que les autres technologies utilisent le même principe, et les tailles ont peut-être changés.

Je sais que j'avais lancé des benchmarks sur une carte SD "rapide", et lire 1024 octets prenait 20 fois plus de temps si les données étaient sur deux segments, par rapport à si elles étaient alignées.

J'ai regardé un peu, et j'avoue que je ne vois pas d’où peut venir le problème.
Tu es sûr que tu as remplacé toutes les occurrences à chaque fois, sait-on jamais ? D'ailleurs, le code gagnerait fortement à être fortement à être refactorisé, on doit pouvoir le réduire de 3/4 facilement, mais je suppose que tu le sais.

Ta meilleure chance est d'afficher toutes les valeurs (et leurs types) dans un try: ... except ... pour voir ce qu'il se passe.

Il est possible que les données en entrée ne soient pas en UTF-8, ou bien qu'il y ait un bug ailleurs qui ne soit pas apparu avant. Sinon, je ne voit pas.
L'un des gros inconvénients de l'unicode en Python, c'est que les exceptions n'apparaissent que quand on commence à utiliser des caractères non-ascii, c'est peut-être le 1er produit à avoir un nom avec des symboles non-ascii ?

Est-ce que tu as un moyen d'afficher une valeur quelque part ? tu peux faire un print(type(res.product_id.name)) pour afficher le type réel.

Si tu as un lien vers le code en question, je peux y jeter un coup d’œil.

Si les variables sont de type str contenant de l'UTF-8, c'est bien decode('utf-8') qu'il faut utiliser. Tu peux essayer:

values.update({'name': res.product_id.name.decode('utf-8') + " - " + xpak.pack_pro_id.name.decode('utf-8')})

# ou plus simple à écrire (code équivalent):
values['name'] = res.product_id.name.decode('utf-8') + " - " + xpak.pack_pro_id.name.decode('utf-8')

Mais au vu de l'erreur, je pense qu'elles sont déjà en unicode (et le cast en str() n'aime pas les caractères unicodes). Dans ce cas, si values['name'] attend bien de l'unicode, il ne devrait pas y avoir besoin de transformation.

values['name'] = res.product_id.name + " - " + xpak.pack_pro_id.name

Si les variables d'entrées sont en unicode mais values['name'] doit être en str, je te proposes ça:

values['name'] = (res.product_id.name + " - " + xpak.pack_pro_id.name).encode('utf-8')

Note que tout ces exemples ne fonctionneront qu'en Python 2.

---

Tu peux admirer ici l'enfer de la gestion de l'encoding en Python. Certaines libs prennent uniquement des str en paramètre de leurs fonctions, d'autres uniquement des unicode. Pareil pour les valeurs de retour, le type varie suivant les libs, et parfois même les deux types peuvent être retournés. Dans 80% des cas, ça n'est pas documenté.

Il y a 2 types de données pour du texte en Python, str et unicode.
encode('utf-8') va transformer un str en unicode (en assumant que la source est bien au format unicode), et decode('utf-8') va faire le contraire.

Est-ce que tu sais de quel type sont res.product_id.name et xpak.pack_pro_id.name ? Et quel type tu attend dans ton objet values ?

Est-ce que tu peux nous fournir l'erreur précise que tu reçoit ?

Le problème venait des données OpenStreetMap: les barrières levantes du canal n'avait pas de tag "access", et donc étaient considérées infranchissable.

Je viens de fixer ça.

Les problèmes de tearing de XFCE sont résolus dans la dernière version de dev de xfwm (4.13). Pour ceux qui sont pressés, il est possible d'installer xfwm 4.13 tout en restant sous XFCE 4.12. Ça fait un mois que je suis dessus, ça fonctionne nickel.

Dans l'intention peut-être, dans la pratique, un des deux candidats restants va devenir président quel que soit le niveau d'abstention. Donc si c'est Lepen, ça ne te dérange pas plus que si c'est Macron.

Donc, si je vote Blanc / je m'abstiens, je mets Macron et Le Pen au même niveau.
Si je vote Macron, je le soutiens.

Et si je veux exprimer le fait que je ne soutiens absolument pas Macron, mais que je considère Le Pen encore pire, je vote quoi ?
C'est le problème des questions où toutes les réponses sont fausses: quoi que je réponde, j'aurais tort.

J'irais voter Macron ce week-end, mais je comprends ceux qui ne le feront pas. Les discours du type "Si tu n'es pas pour, tu es contre" sont fatigants à la longue.

Dans le cas d'un accès payant payant aux données, c'est le prix des données qui est bloquant: ceux qui ont le plus d'argent peuvent obtenir et profiter de ces données des centaines, voir milliers de fois plus.

L'argument de l'article est que lorsque le cout des données est nul, ce qui va bloquer est la capacité à traiter ces données. Hors, Google est capable de traiter des milliards de fois plus vite / efficacement ces données que n'importe qui d'autre, et donc d'en sortir des bénéfices en proportion.

Je suis aussi pour le libre accès à la culture et aux données. Mais l'argument, qui est que Google y gagne plus que nous, est pertinent.

Cette illustration montre seulement que Mélenchon soutient l'intervention de la Russie en Syrie.
Rien à voir avec le fait de soutenir la politique de Poutine dans sa globalité.

La mémoire n'est pas utilisée si la partition est vide. La taille du tmpfs correspond en fait à la valeur max de RAM qu'il est autorisé à consommer.

Donc sauf à stocker des Go de données dans /tmp, cela ne pose aucun problème.

C'est vrai que ce n'est pas utile pour produire du code ou le tester.
En revanche, si tu penses que c'est inutile pour déverminer, c'est que tu ne connais pas git bisect.

Pour pip, ça marche bien avec des programmes simples, mais dès qu'on sort du cas basique d'une lib ou un logiciel en cli, c'est plus compliqué. Par exemple la génération des fichiers Desktop, l'association de fichier au programme, et tout ces petits trucs qui font partie de l’intégration avec le système sont compliqué.
Un autre point qui est difficile à traiter, c'est la location des ressources: Mettre les fichiers de données au bon endroit dans /usr/share de façon propre n'est pas simple, et y accéder depuis le code python non plus.

Et puis aussi, l'histoire du packaging python est compliqué, avec plein de réécriture de techno plus ou moins compatibles entre-elles (setuptools, distutils, …), donc on a une grande diversité de format et de méthode d'installation.

Ou bien s'ils détectent un esprit critique ils font exprès de vous mettre des pubs idiotes pour vous faire croire qu'ils sont incapables de tout savoir sur vous.

J'avais lu un article qui disait que lorsque les pubs étaient trop pertinentes, notamment sur les sujets sensibles tels que les grossesses, le taux de rendement de ces pubs baissait, probablement parce que l'intrusion dans la vie privée apparaissait plus visiblement.
En réaction, les publicitaires réduisaient volontairement la pertinence des pubs.

Dans le même genre que agar.io, tu peux rajouter slither.io

Je vois pas tellement de problème pour la duplication de code: il suffit de faire une lib.

Certes, ce ne sera pas dans Wayland, mais je ne voit pas ça comme un problème: la fonctionnalité copié-collé par click du milieu n'a rien à voir avec le serveur graphique, et un environnement de bureau pourrait très bien décider que cette fonctionnalité n'apporte rien et ne pas l'implémenter.

Le seul problème semble être que le code pour gérer ça n'est pas encore là / pas encore intégré dans tous les DE. Et là, bah c'est comme tout: ça viendra mais ça prends du temps.

Je viens de faire le test.

En résumé, ça modifie la référence du dossier de travail (HEAD), mais ça ne modifie pas les fichiers physiques.

Il faut savoir que HEAD peut pointer vers un commit précis (git status nous indique qu'on est dans l'état "HEAD détachée"), ou pointer vers une branche, qui elle-même pointe vers un commit (le fonctionnement normal).
Une opération push va modifier la branche, et si HEAD suit la branche, HEAD sera indirectement impactée. Mais les fichiers locaux ne vont pas changer.

En pratique, si coté client on ajoute un fichier F dans un commit C, du coté serveur, git status va nous dire qu'on est bien sur le commit C, mais que le fichier F a été supprimé.

Avant le push (sur le serveur):

Sur la branche master
Modifications qui seront validées :
  (utilisez "git reset HEAD <fichier>..." pour désindexer)

    nouveau fichier : fichier1-coté-serveur

Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)

    fichier2-coté-serveur

Après le push:

Sur la branche master
Modifications qui seront validées :
  (utilisez "git reset HEAD <fichier>..." pour désindexer)

    supprimé :        fichier-commité-coté-client
    nouveau fichier : fichier1-coté-serveur

Fichiers non suivis:
  (utilisez "git add <fichier>..." pour inclure dans ce qui sera validé)

    fichier2-coté-serveur

Le risque, c'est que si on a des fichiers modifiés et que quelqu'un push sur notre dépôt, ça va tout mélanger et il va falloir faire du tri à la main, donc potentiellement grosse galère pour s'y retrouver.

Pour les autres opérations de pull et clone, ça ne devrait pas avoir d'impact.

Curieusement, je n'étais jamais tombé sur ce cas.

Apparemment, on ne peut pas agir sur la branche pointée par "HEAD", pour ne pas laisser le dépôt distant perdu sans savoir sur quel branche il est.
Par contre, ça ne pose pas de problème de pousser une autre branche.

Non, c'est bien git s'en charge tout seul:

# version rapide
git push user@host:/path/to/repo master

# avec sauvegarde du dépôt distant
git remote add my-other-pc user@host:/path/to/repo
git push my-other-pc master

Il me semble que pour travailler avec Git il est nécessaire d’avoir un dépôt de référence (un bare…) car il n’est pas possible de pousser vers un dépôt de travail

Il est possible très facilement de pousser vers un dépôt de travail. Si le dépôt distant a un accès SSH, il n'y a rien à configurer. Ça peut être très utile, par exemple pour tester rapidement des commits sur une VM de test.

et il n’est pas possible non plus de travailler dans un dépôt de référence…

Il n’est pas possible de travailler dans un dépôt "bare", mais rien n'empêche de prendre un dépôt normal comme référence. Accessoirement, on peut convertir un dépôt bare en dépôt normal, et vice-versa, en 4-5 lignes de commande.

Pour réapprendre proprement le langage, j'étais tombé sur un tuto interactif avec uniquement des code à modifier: http://ejohn.org/apps/learn/

Ça ne concerne ni NodeJs, ni les nouveautés apportées par ES6, mais c'est excellent pour comprendre les spécificités de Javascript, notamment le fonctionnement des closures, le comportement de this et l'orienté objet par prototype.
Apparemment, ce serait une partie et/ou les exemples du livre Secrets of the JavaScript Ninja de John Resig, le créateur de jQuery.

Je n'ai pas de lien global pour apprendre le js "moderne", mais pour donner quelques orientations:

• La norme ECMAScript 6, aussi appelée ES6 ou ECMAScript 2015, est finalisée depuis juin 2015. Tout les navigateurs ne supportent pas encore toutes les nouveautés, loin de là, mais ça arrive vite, et il existe des outils pour pour utiliser ES6 en gardant la compatibilité avec tout le monde.
  Il y a de la doc très détaillée sur le site de doc de mozilla, et on peut avoir un aperçu avec exemple de code de chaque nouveauté sur cette page github.
  En résumé, beaucoup de nouvelles fonctions/méthodes dans la lib standard qui auraient dues être là depuis des années, pas mal de sucre syntaxique, et quelques fonctionnalités qui permettent de gérer beaucoup plus facilement le code asynchrone.
  Avec ca, je trouve que le langage ressemble de plus en plus à Python (mais ne le dites surtout pas à un dev Python, il le prendrait très mal ;) ).
  Je suis également le blog ②ality (en) qui propose des articles vraiment détaillés sur chaque point d'ES6 et explore tout les cas tordus. Une mine d'or.

• Ensuite, on a NodeJs.
  C'est "juste" un interpréteur javascript, avec une lib pour communiquer avec l'OS (filesystem, réseau). En pratique, l'API de NodeJS est clairement orientée serveur, et repose beaucoup sur l'asynchrone. Sa doc est assez lisible pour trouver ce que l'on veut, et on monter un serveur HTTP ou faire un petit exécutable CLI en quelques lignes. Le cas d'utilisateur le plus courant de NodeJs, c'est un site web basé sur un framework web minimaliste tel que ExpressJS.
  C'est très, très simple de monter un site web et d'avoir un visuel en 5 minutes, mais on peut facilement s'y perdre si on ne maîtrise pas la notion de scope en Javascript.
  Le code asynchrone est énormément utilisé par NodeJs et son écosystème. Comme en js, il est très facile de créer des fonctions lambda, les callbacks sont énormément utilisées.
  Sauf que l'asynchrone apporte forcément une dose de complexité, et qu'il est très facile de s'y perdre et de produire du code dégueulasse (callback-hell). Face à ça, des conventions et des design patterns ont émergés. On trouve énormément d'articles sur le sujet en cherchant les notions d'error-first callback, de thunk et de Promise.

En Javascript moderne (Ecmascript 2015 pour être précis), on peut faire bien plus court avec les fat arrows:

f = (a, b) => a + b

J'ai une config à peu prêt similaire, et j'ai galéré pour avoir mes trois écrans, mais j'ai réussi.

Voilà ma conf:

# One screen section per graphic card
Section "ServerLayout"
           Identifier  "Layout 1"
           Screen      "Screen0"
           Screen      "Screen1" LeftOf "Screen0"
EndSection


# NVIDIA graphic card.
Section "Device"
        Identifier      "nvidia0"
        Driver          "nvidia"
        Option          "NoLogo"                "1"  # Remove nvidia branding at startup
        BusId           "PCI:1:0:0"
        Option          "ProbeAllGpus"          "false"  # Only required for nvidia
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce GT 610"
EndSection


# Internal graphic card.
Section "Device"
        Identifier      "intel0"
        Driver          "intel"
        BusId           "PCI:0:2:0"
EndSection


# NVIDIA (uses two monitors)
Section "Screen"
    Identifier     "Screen0"
    Device         "nvidia0"
    DefaultDepth    24
    Option         "Stereo" "0"
    Option         "nvidiaXineramaInfoOrder" "DFP-0"
    Option         "metamodes" "DVI-I-1: nvidia-auto-select +0+0, HDMI-0: nvidia-auto-select +1920+0"
    Option         "SLI" "Off"
    Option         "MultiGPU" "Off"
    Option         "BaseMosaic" "off"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

# Intel
Section "Screen"
    identifier     "Screen1"
    Device         "intel0"
EndSection

Le truc à savoir, c'est que Xorg est obligé de créer un "Screen" par carte graphique, et qu'un Screen n'est pas un écran physique.
Dans ma config, le Screen NVIDIA est en fait 2 écrans (listés dans l'option "metamodes")
Bon, ça utilise le driver proprio.

Par contre, il faut bien comprendre que les 2 Screens sont indépendants, presque comme 2 serveurs graphiques. Les environnements de bureau gèrent ça plus ou moins bien. Sous Xubuntu (donc XFCE), c'est loin d'être parfait: on ne peut pas faire passer de fenêtre entre les 2 Screens, et il y a parfois des bugs graphiques bizarres.

Ce que me fait me demander, comment sont propagées les mises à jour des clés ?

Par exemple (corriges moi si je me trompe), Alice révoque sa clé, et upload sa clé révoquée sur son serveur de clé pour "publier" l'information.
Comment Bob fait-il pour être informé des modifications ? C'est automatique, ou manuel ?

Il n'y a pas de risque d'avoir des clés obsolètes et de les utiliser quand même ?

GMail permet de créer des alias avec le caractère + à la fin de l'adresse. mon.adresse+label@gmail.com redirigera les mails vers mon.adresse@gmail.com. C'est très pratique pour créer une adresse par site, par exemple mon.adresse+ulule.com@gmail.com.
Seul inconvénient, parfois les formulaires d'inscription refusent (à tort) le caractère + dans les adresses mails.