Et donc c’est tout sauf gratuit en terme de perfs… Et certainement pas l’outil magique.
Surtout que du bit rot, en pratique, je ne suis pas sûr d’en avoir rencontrer une seule fois dans ma vie…
Les disques du commerce grand public sont garanti à 1014 octets pour 1 erreur de bit, soit 12To avant de voir la moindre erreur. Les disques professionnelles sont à 1015 (120To). Et d’ailleurs ce chiffre concerne les HDD, les SDD ont une durée de vie plus faible.
J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.
Oui, et aucun article n’explique comment fait btrfs pour corriger une erreur de bit rot, sachant qu’il n’y a pas de sur-redondance de données (seulement 2 strips) et uniquement 1 bloc de parité (donc indécidable si c’est le bloc de parité qui s’est pris le bitrot ou un strip de data).
Tout le monde est d’accord pour dire que ça détecte le bitrot (comme tout système raid). Nul part je ne vois que ça le corrige (sauf raid5 minimum où un consensensus est possible), sinon via un retour arrière via l’historique COW (qui risque alors soit de corrompre le fichier si le rollback est au niveau bloc, soit avec pertes de données s’il est au niveau fichier).
Si j'ai une donnée corrompue, je peux récupérer la donnée avec l'autre disque du RAID1.
Sauf que comme je l’ai dis, on ne sait PAS corriger une erreur avec RAID1. on ne peut que détecter une erreur, on ne sait pas quelle donnée est la bonne. Ça ne protège donc pas d’un bitrot, ça permet uniquement de le détecter et de dégager une des grappes au pif pour pouvoir laisser la prod continuer à tourner en attendant une resynchro.
Il faut du RAID5 pour savoir corriger l’erreur une fois détecter, via la comparaison avec les 2 disques fonctionnels qui disent la même chose alors que le disque défectueux dit une connerie.
Un snapshot read-only, il faut quand même se lever de bonne heure pour arriver à l'effacer par erreur ou via un logiciel. Même avec un "rm *" en root tu n'y arrives pas. Le seul cas que l'on peut envisager c'est une erreur dans le kernel.
Je ne sais pas ce que tu entends par corruption de données/disques ?
Un secteur défectueux. Un dd à la con qui te ruine ta table des partitions.
Parce que j'ai plusieurs fois répété que pour les corruptions type « bit rot », j'étais protégé par Btrfs RAID1.
Et bien reli bien les docs, ce n’est pas le cas. Pas en RAID1.
Cela ne signifie pas du tout que j'utilise mon RAID1 comme backup ! Cela signifie juste que cela me protège contre les données corrompues (bit rot par exemple).
Un RAID1 cela ne protège certainement pas contre les "rm -rf" ou "dd /dev/sd0" (i.e. les erreurs utilisateurs).
La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Ça ne protège pas plus d’un bitrot justement.
Le controlleur RAID détectera une incohérence, ne sera pas capable de déterminer qui des 2 strips a raison et éjectera un des 2 côtés sans aucune semonce.
C’est RAID5 minimum qui permet de corriger le bitrot en regardant le consensus des grappes. RAID1 ne permet que de le détecter et ne permet aucune action corrective (sinon à la hache en dégageant une grappe).
Et ça ne fait pas ce que tu dis.
C’est effectivement COW, ce qui veut dire qu’en cas de corruption, les données PRÉCÉDENTES vont être dispos.
Si ton fichier est dans sa 1ère version et que tu te prends un bitrot, t’es cramé, il n’y a pas plus d’historique.
Et même dans le cas où tu as des données plus ancienne, tu ne sais pas revenir à l’état intègre de la version « bitrotée ». Ça continuera à te donner un fichier final corrompu d’ailleurs si le FS ne rollback qu’un bloc et non tous les blocs de ton fichier (et dans ce cas tu perds encore plus de données).
Faut pas croire que c’est magique les FS hein. Même ceux « next-gen ».
Tu n'as pas cherché à comprendre mon explication qui démontre qu'un fichier corrompu (sur ton disque dur d'origine) n'est pas forcément détecté par ton système et peut par la suite remplacer tes sauvegardes.
Je ne vois pas ce que ça vient faire là.
Et tu as le même problème sur ton truc local hein.
Un fichier corrompu non détecté merdera ad vitam éternam partout. En local, online, offline, offloadé. C’est pour ça qu’il est important de tester régulièrement ses backups.
gestion de versions et sauvegarde de données me semble très similaire
Similaires techniquement peut-être, mais dans leurs usages pas du tout.
Comme déjà dis, un backup ne suppose pas que ton système soit opérationnel pour pouvoir faire une restauration. Ta copie locale si.
C'est ta propre définition de la notion de sauvegarde, Wikipedia (en particulier la définition anglaise) donne une autre vision (que je partage, mais c'est mon avis).
« Backups have two distinct purposes. The primary purpose is to recover data after its loss, be it by data deletion or corruption. »
La page anglaise dit la même chose que moi : un backup suppose la perte complète du système principal. its loss, ce n’est pas its corruption. Tes données ne sont plus là, et considérées comme non réparables depuis le système principal.
« The secondary purpose of backups is to recover data from an earlier time »
La possibilité de restauration d’un backup après la perte de données implique un retour en arrière. Ton système local ne couvre que le 2nd usage (« retourner en arrière »), pas le 1er (« récupérer une perte de données »).
J’aurais tendance à dire que ta solution locale est de l’archivage, et non de la sauvegarde.
D’ailleurs, je trouve le dernier article assez clair au niveau des définitions :
« Je veux pouvoir récupérer mes données en cas d’évènements majeurs altérant leur accessibilité » ⇒ sauvegarde (côté « everything is doomed »)
« Je veux m’assurer de pouvoir récupérer mes données sur le long terme à tout instant » ⇒ archivage (côté « something fucked »)
« Je veux pouvoir accéder à mes fichiers où que je sois, et les partager avec mes collègues » ⇒ stockage (côté « the world is cool »)
| Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
C’est là que je ne te suis absolument pas…
Tu fous quoi en RAID1 si tu n’as pas confiance en tes disques ? :s
C’est du RAID5 minimum qu’il te faudrait du coup, puisque qu’un disque qui pète sur du RAID1 peut entraîner la perte de la grappe complète si c’est le mauvais disque qui est sorti de la grappe en 1er (déjà vécu plusieurs fois)…
| La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi.
N’appelle pas ça sauvegarde alors.
| Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Et c’est typiquement ces cas-là où une sauvegarde (donc offline ou a minima sur disque physique séparé) est utile.
Tes trucs locaux ont une probabilité plus que non nulle d’être AUSSI impacté en cas d’erreur humaine ou logicielle ou d’une corruption de données/disques.
Elles sont physiquement trop proches des données « live » pour pouvoir dire l’inverse.
| ZFS & Btrfs checksum les données, en cas d'utilisation d'un RAID (1/5/6), la version corrompue est automatiquement réparer.
Je veux bien un papier sur le sujet, parce que je ne vois pas comment c’est possible, en tout cas sur RAID1.
Si ZFS|Btrfs se rend compte d’une incohérence de données entre le checksum et les données remontées par le disque, ils n’ont aucun moyen de corriger l’erreur puisqu’ils ne peuvent pas savoir quelle erreur a réellement été commise entre
la data D1 du disque 1 est corrompue
la data D2 du disque 2 est corrompue
le checksum C1 du disque 1 est corrompu
le checksum C2 du disque 2 est corrompu
Après tu peux faire des heuristiques à la con pour chercher à corriger (si D1≠D2 on vérifie si D1 ou D2 match C1=C2, ou encore si C1≠C2, on garde le C qui matche D1=D2), mais il reste plein de trous dans la raquête (D1≠D2 et aucun C qui match, C1≠C2 et pas de D qui match, C1≠C2 & D1≠D2, etc) et tu peux empirer encore plus la situation en choisissant une mauvaise heuristique.
C’est tout le problème du RAID1 : dès qu’un truc pète (hors erreurs matos), il est préférable de dégager un disque au pif que de chercher à corriger les erreurs.
Et c’est aussi pour ça que RAID1, c’est pour moi uniquement une question de résilience et certainement pas de robustesse. Ça permet de conserver une infra physique fonctionnelle en cas de corruption, à quelques glitches près sur les zones éventuellement erronées qu’on restorera depuis les backups si nécessaires une fois le matos changé.
Si tu veux de la résilience (pas de down) et de la robustesse (pas de perte), tu passes sur du RAID5.
Je disais que dire qu'une sauvegarde « locale » est complètement inutile par rapport à une sauvegarde « distante » c'est comme dire qu'un dépôt « local » est complètement inutile par rapport à un dépôt « distant ». C'est ton avis extrême que je critiquais.
Avoir une copie locale a effectivement de l’intérêt (c’est même pour ça qu’a été inventé DSCM). Mais ce n’est pas une sauvegarde (en tout cas pas du point de vue « admin sys »). Faudrait trouver un autre terme.
Encore un homme de paille ? Où ai-je dit que j'utilisais le RAID1 comme backup ?
Ben c’est toi qui mentionne RAID1 comme la solution qui te protège hein…
La RAID1 est là pour lutter contre la corruption de données ou bit rot, c'est tout.
Faux. Il ne lutte pas contre la corruption de données/bit rot. À la moindre erreur, c’est toute ta grappe qui peut partir (et partira en dans le cas du RAID1) en sucette. Et pour le cas du RAID1, tu peux même ne pas savoir du tout quel disque contient la donnée incorrecte et lequel la données correcte (problème indécidable avec seulement 2 disques).
RAID n’apporte que de la résilience, et rien d’autre. Ça permet éventuellement d’éviter un arrêt de prod le temps de remplacer le disque.
Si justement. Tu peux avoir un disque dur qui rend l'âme silencieusement sans rien montrer dans le SMART ou dans le syslog.
Ça n’est pas génant dans le cas des backups offline/offloadés.
Tu le détecteras lors de la synchronisation que le disque est fucked. Et du coup tu pourras changer de disque pour tes nouvelles rotations et basta.
La probabilité qu’un disque OK au moment de la synchro (et donc d’un test de restauration :P) devient KO 1 semaine/1 mois après alors qu’il n’a même pas été utilisé entre les 2 est quand même vachement faible… (Et d’abord on n’a jamais dis non plus qu’un backup est infaillible, et que c’est facilement gérable avec du multi-disk.)
J'ai un peu l'impression que tu te braques sur certains mots-clés après avoir lu en diagonal sans chercher à comprendre ce que je cherchais à exprimer ?
Quelqu'un d'autre peut confirmer si je me suis bien exprimé ou bien c'est à moi de m'exprimer plus clairement ?
Tu viens ici en disant que copie online/DSCM/cow/btrfs/raid/whatever est un système de backup. C’est même le sujet de ton journal : « Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ? ».
La réponse est non et sera invariable.
Une sauvegarde doit permettre de revenir à un état cohérent et utilisable passé, en faisant un minimum d’hypothèses sur la procédure à suivre et sur l’état courant du système (en particulier, on doit supposer le système d’origine inutilisable au moment de la restauration).
En particulier, un backup est un système qui devrait te permettre une restauration de service même si l’ensemble de ton système d’origine a disparu de la surface de la planète.
Ou dit encore autrement, la seule hypothèse de restauration doit être la possession d’un backup (sachant que ton système lui, doit être considéré 100% KO).
Une copie online/DSCM/cow/btrfs/raid/whatever ne répond qu’à peu voire aucune des propriétés de ce que doit être une sauvegarde (en particulier nécessite un système disponible et l’outil de backup fonctionnel au moment de la restauration).
Appelle ça comme tu veux (« cache », « snapshot », « dumb-user-proof », « fast-rewind »…) mais pas « sauvegarde ».
Là c'est un point de vue extrême que je ne partage pas du tout.
Ce serait comme dire qu'un dépôt local ne sert à rien dans le cas de la gestion de version distribuée.
Tu ne protèges pas du tout de la même chose avec un DSCM et avec une sauvegarde.
Un DSCM ne protège ne protège que d’une corruption (à prendre au sens générale, ça peut être le matos, le système de fichiers, un dev qui a fuck…) interne du dépôt (un dev a fait un rm -rf des fichiers du dépôt). Ça ne protège pas des corruptions externes (un dev a fait un rm -rf du .git, un secteur défectueux empêche la lecture de méta-données…).
Tu peux par exemple te retrouver avec un dépôt git fucké avec plus aucune commande qui ne fonctionne à cause d’une corruption des données du dépôt.
Un backup va te protéger de ces corruptions externes justement.
Dit autrement, un DSCM permet de remonter à un instant T-X, un backup permet de garantir que si ça marchait à l’instant T, cet instant T refonctionnera à l’instant T+X une fois restauré (alors qu’un dépôt qui fonctionne à l’instant T peut être impossible à remettre dans l’état de l’instant T s’il est corrompu).
Mon approche va même plus loin, car comme je l'expliquais, les données et les sauvegardes pointent sur le même espace disque (snapshot/CoW) !
Ce qui est pire que tout.
Tu as le moindre problème externe, tu as tout perdu.
Pour la corruption des données, je pense justement que mon approche est peut-être plus saine car je suis en RAID1 avec Btrfs, donc les corruptions de données peuvent être détectées et corrigées.
Un backup ne suppose rien de l’état de ton système justement.
Je ne connais que trop de gens qui se croyaient à l’abris avec du RAID1. Faire du RAID, c’est très compliqué à faire proprement.
Par exemple si tu mets 2 disques issus du même fabriquant avec des numéros de série relativement proche, il y a de très grandes chances que lors qu’un des disques sautera, la reconstruction achèvera le 2nd disque, qui aura grosso modo la même durée de vie.
Faire du RAID1 proprement, c’est acheter 2 disques de constructeurs différents, à 2 dates relativement éloignées (plusieurs mois, les composants physiques étant presque tous fabriqués au même endroit, quelque soit le fabriquant).
Sans parler que btrfs et RAID ne te protègeront pas d’un « rm -rf / » ou d’un dd foireux.
Le RAID, c’est comme les DCSM, ça n’est pas une solution de backup.
Ce qui ne serait pas le cas dans le cas d'une approche traditionnelle où j'ai simplement un disque contenant les données et un disque externe pour contenir la sauvegarde des données (parce que dans ce cas là les corruptions de données sont silencieuses).
Les corruptions de données ne sont pas silencieuses avec des backups.
Des backups, ça se teste régulièrement. L’état SMART des disques est à vérifier régulièrement. fsck à passer régulièrement.
Le fait de les avoir unmount/offline/offload protège aussi le matériel. Étant moins sollicités, la durée de vie des supports physiques est plus longue. Un disque qui passe 1 mois dans un coffre à la banque ne s’use pas, pas plus que celui posé sur mon étagère.
Et encore une fois, btrfs/raid ne te protège pas des « corruptions » logicielles (rm -rf, dd…)
| Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
C’est tout sauf dépasser.
Le problème de la « sauvegarde » locale, c’est qu’elle ne protège que de peu de choses. En fait de rien du tout généralement.
Si tes données sont au même endroit que tes « sauvegardes » (en tout cas sur le même disque physique), alors il y a un risque plus que non négligeable qu’en cas de corruption des données, ta « sauvegarde » le soit aussi. Sauf cas très particulier (backup sur un disque séparé, non monté ou en read-only seulement) ou erreur très ponctuelle et légère (un fichier supprimé par mégarde, un truc modifié qui n’aurait pas du l’être), en bref ce pour quoi existe la gestion de configuration (qui n’est donc pas une sauvegarde).
Un rm foireux, un disque qui claque sans crier gare, une mauvaise manip pour flasher une clef USB (que celui qui n’a jamais confondu deux /dev/sdx lors d’un dd lève la main) ou un cryptolocker qui passe, et c’est le drame à la fois pour les données et la « sauvegarde » locale. Ce n’est donc pas (en tout cas pour ma part) une sauvegarde viable, tout au plus un cache temporaire.
Une sauvegarde, c’est pour moi une copie des données dont la probabilité d’être impactée en cas de soucis sur les données d’origine est plus que très faible voire si possible nulle.
C’est donc a minima une copie sur un disque physiquement différent de celui des données. Non monté ou en read-only sauf période de backup s’il reste online.
Et même plutôt physiquement déconnecté de la machine des données sauf durant les phases de sauvegarde (disque USB par exemple).
Personnellement, je vais jusqu’à faire tourner chaque mois un des 2 disques de backups offline dans un coffre à la banque pour mes données très sensibles. En plus du disque de backup online présent dans la machine (démonté après chaque synchronisation et qui me sert d’image de base pour la synchro sur les disques offline).
Ça donne donc :
- backup quotidien sur disque online (purgé selon le motif 7 quotidiens, 4 hebdos, 12 mensuels, 10 annuels)
- backup hebdo du disque online sur le disque offline présent chez moi
- échange mensuel du disque offline chez moi avec celui offloadé
Je peux te dire que chaque morceau de ce pattern m’a sauvé les miches, et plus d’une fois.
- backup online : grosse merde sur le disque principal (rm -rf, dd foireux…)
- backup offline : HDD HS data + online (oui je suis un chat noir, mais c’est un scénario classique comme pour le cas du RAID, la resynchro risque de finir d’achever ton disque de backup qui était usé mais pas HS)
- backup offloadé : protection contre perqui ou saisie, cambriolage, incendie
pourquoi ne généralisent-elles pas l'authentification en 2 étapes, soit avec un token physique, ou via l'envoi d'un SMS ? Là où tous les webmails ou sites "sérieux" le proposent, elles accusent un temps de retard je trouve à ce niveau là.
Le Crédit Coopératif, en tout cas pour les clients pro, fournit une carte à puce et un lecteur de carte délivrant un OTP nécessaire à chaque connexion et pour les opérations sensibles.
Donc ils ont calculé presque 264 hashes. C'est dingue, je pensais qu'il était matériellement impossible de calculer n'importe quelle fonction pour toutes les valeurs possibles d'une variable de 64 bits.
C’est pour ça que l’état de l’art de la crypto est plutôt de tabler sur 128 bits minimum pour être à l’abri des attaques modernes.
64 bits, ça puait déjà un peu depuis quelques temps, sweet32 avait fini de semer le doute partout, mais là c’est carrément une preuve que Google nous a sortie !
À ce sujet, je tiens à rappeler que toutes les versions de GnuPG publiées depuis 2010 utilisent par défaut, pour les signatures, SHA-256 et non plus SHA-1. Vous n’avez donc pas besoin, contrairement à ce qu’on peut lire sur des tutos obsolètes, d’ajouter d’options du style cert-digest-algo ou personal-digest-preferences à votre fichier ~/.gnupg/gpg.conf.
Il y a une différence entre « GnuPG a fixé le problème depuis 2010 » et « les distributions et OS ont propagé la modification ».
Actuellement, sous Debian stable, on a toujours le problème :
$ cat /etc/debian_version
8.7
$ apt-get dist-upgrade
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Calcul de la mise à jour... Fait
0 mis à jour, 0 nouvellement installés, 0 à enlever et 0 non mis à jour.
$ apt-cache policy gnupg{,2}
gnupg:
Installé : 1.4.18-7+deb8u3
Candidat : 1.4.18-7+deb8u3
Table de version :
*** 1.4.18-7+deb8u3 0
500 http://http.debian.net/debian/ jessie/main amd64 Packages
100 /var/lib/dpkg/status
1.4.18-7+deb8u2 0
500 http://security.debian.org/ jessie/updates/main amd64 Packages
gnupg2:
Installé : 2.0.26-6+deb8u1
Candidat : 2.0.26-6+deb8u1
Table de version :
*** 2.0.26-6+deb8u1 0
500 http://http.debian.net/debian/ jessie/main amd64 Packages
100 /var/lib/dpkg/status
$ gpg --gen-key
pub 2048R/22152665 2017-02-23
Empreinte de la clef = 2696 3ECE B2DD BD1D B015 0C27 A26E 442A 2215 2665
uid test-key <test@example.org>
sub 2048R/58A0BAC2 2017-02-23
$ gpg --edit-key 22152665
gpg> showpref
[ ultime ] (1). test-key <test@example.org>
Hachage : SHA256, SHA1, SHA384, SHA512, SHA224
$ gpg2 --gen-key
pub 2048R/E71DC86E 2017-02-23
Empreinte de la clef = 61F5 082A 93D9 491B CAAD C6A5 E055 E54D E71D C86E
uid [ ultime ] test-key <test@example.org>
sub 2048R/360B7F49 2017-02-23
$ gpg2 --edit-key E71DC86E
gpg> showpref
[ ultime ] (1). test-key <test@example.org>
Hachage : SHA256, SHA1, SHA384, SHA512, SHA224
Et donc actuellement, sur une Debian stable, SHA1 est encore devant les SHA-2 à l’exception de SHA256…
Il faut attendre la version 2.1 de GnuPG pour réellement avoir ce changement. Version actuellement disponible nul part ou presque (Debian testing uniquement, ni Debian stable, ni Ubuntu, ni Windows, ni Mac).
Donc si, on a toujours besoin de faire ces modifications de fichiers !
SHA-1 est actuellement utilisé au « cœur » de OpenPGP, pour le calcul des empreintes des clefs en version v4. Ce dont on a besoin pour ce type d’utilisation est la résistance aux attaques sur la seconde pré-image (étant donné le condensat d’une clef, trouver une autre clef donnant un condensat identique). La résistance aux collisions n’est pas critique ici et vos clefs OpenPGP ne sont donc pas menacées par le résultat rapporté ci-dessus.
Du coup, j’ai VRAIMENT du mal à comprendre ton billet…
« Je ne parle que des projets qui ont décidé de se lancer sur le grand public ». Déjà ça concerne très peu de projet au final.
Et généralement ceux qui se sont lancé là-dedans font DÉJÀ appel à de la communication et du marketing, y compris professionnellement. Que ça soit Mozilla, Firefox, LibreOffice, VLC, Cozy, j’en passe et des meilleurs.
Et donc on en revient au point de départ : ça n’est pas qu’ils n’ont pas de stratégie sur le sujet, c’est qu’ils n’ont pas celle que toi tu souhaites.
C’est juste que tu considères que, parce que ça n’est pas ce que TOI tu aurais fais, c’est du « caca sur une paroi rocheuse inégale avec le soleil dans les yeux ».
Tu as même été jusqu’à dire que Cozy n’avait pas de designer ni de marketing, alors que c’est même là-dessus qu’on passe le plus gros de notre temps… Avec un designer recruté à plein temps, des tonnes de dev fronts plus que compétents en terme d’UX ou de design, une personne en charge du marketing, l’appel à des boîtes de com’ et de design pour nos communications externes, des méthodes agiles de feedback rapides de la part des utilisateurs et même des meetups complets dédiés au sujet.
C’est très révélateur de la véritable nature de ton billet : cracher sur le travail des autres au motif où tu considères que leur boulot est de la merde. Soit exactement ce que tu reproches dans ton billet.
tu justifies un non-design avec des arguments fallacieux plutôt que d’écouter des designers, confondant pèle-mêle beau, accessible, et communication en général
Et toi tu continues à parler de communication générale et de marketing pour des projets répondant aux besoins de 3 personnes et maintenue par 1 personne avec un budget de 0 voire négatif, qui n’ont jamais demandé à devenir le prochain écran publicitaire de TF1 ou ne cherche pas à concurrencer Google.
Parce que la réalité de l’éco-système des projets libres dont tu parles au début, c’est ça. Même GnuPG, c’est un gus dans un garage ou presque.
Pas les Mozilla, VLC ou autre LibreOffice. Qui eux ont déjà recours à du design et du marketing. En fait depuis qu’ils se sont mis comme objectif de devenir grand public.
Loin de moi l’idée d’avoir dit ça. Juste que c’est un design simple à réaliser et lisible par tous. Mais qui peut être perçu comme moche ou peu agréable.
Et qu’un designer risque d’avoir des difficultés à trouver un design adapté à la fois à une vision normale et à une vision daltoniste.
Surtout en ayant dans l’idée de faire un truc génialissime révolutionnaire. La mode et autres tendances actuelles étant plutôt à l’opposé des préoccupations d’accessibilité.
Et c'est la seule manière que le site soit accessible à cette personne daltonienne ? Ou c'est juste une excuse un peu ridicule pour justifier ce design ?
Il faut des contrastes très forts et beaucoup de couleurs ne sont pas distinguables par un daltonien.
En gros, un daltonien ne perçoit que du bleu et jaune ou du bleu et rouge. Ça rend très difficile la conception d’un design qui ne va arracher la vue de personne. Dans tous les cas, dès que tu dépasses 4 couleurs, il va être totalement perdu et les nuances ne sont pas perçues.
Je vais d’ailleurs donner un exemple tout con des problématiques qu’on peut aussi avoir avec une réflexion pur designer only : https://nos-oignons.net/wiki-admin/
On est d’accord, c’est très moche non ? Tu voudrais bien changer ça hein ?
Pas de bol, il y a une personne daltonienne dans l’équipe. Ces couleurs permettent d’avoir un site accessible y compris pour elle.
Ton futur méga design de la mort qui tue qui ramènera whatmilles bouzillions de personnes et l’être aimé·e sur ce projet ? On le mettra bien gentiment à poubelle, parce qu’on devra perdre au moins UNE personne actuellement contributrice en échange.
Idem pour tes designs de folies type Office, GMail ou autre. Combien sont réellement accessibles à un lecteur d’écran et donc compatible avec les personnes déficientes visuelles ? Idem, ça finira donc à la poubelle d’un projet libre qui tient à rester accessible à tout un chacun.
Certes, certains projets sont moches. Mais ô combien plus accessibles pour les personnes handicapées que certains designs qu’on voit fleurir partout dans les logiciels privateurs…
Bref, on ne veut pas de traitement de faveur, on veut juste être traité comme les autres contributeurs : que les contributions soient jugées, acceptées ou refusées par des gens au même niveau au moins que ceux qui les soumettent.
C’est là que tu te méprends à mon avis.
Dans une interface CLI ou moche, un patch sera effectivement jugé par de purs développeurs.
Pour la conception d’une affiche, un design sera effectivement jugé par de purs designers. Et encore, tu risques de te faire envoyer bouler par ton imprimeur parce que tu auras utilisé une couleur qu’il est incapable de reproduire correctement (au pif, certains jaunes).
Pour l’intégration par un intégrateur d’un design fait par un designer dans un code fait par un développeur, c’est l’ensemble de l’équipe qui va avoir son mot à dire. Et que ton patch pourra du coup être refusé parce que les intégrateurs vont juger qu’il est in-intégrable au projet alors que tous les designers vont être unanimes pour vouloir l’intégrer.
Comme déjà mentionné sur Twitter, le fait d’avoir une collaboration fait naître aussi certaines obligations. Mon exemple donné est qu’il ne sera pas illégitime pour un projet libre de rejeter une contribution d’un designer livrée sous forme de PSD, même si professionnellement le boulot réalisé est l’équivalent graphisme de la solution à la faim dans le monde.
Il ne suffira pas de faire du plus que très bon boulot au niveau design pour voir ta contribution acceptée par le projet. Il faudra faire tes preuves sur l’ensemble de ta contribution, et en particulier sur toutes les parties qui ne sont justement pas ton dada, tout comme un développeur sera sanctionné pour un manque de doc ou de test, alors qu’il n’est ni documentaliste ni testeur mais que des compétences sur ces sujets sont AUSSI attendues que son code lui-même.
À la réflexion, j’ai vraiment l’impression que tu te méprends plus que fortement sur ce qu’est réellement la conception d’un projet et en particulier sur ce qu’est être un développeur…
Hum, juste au pif comme ça, est-ce que tu n’aurais pas tout simplement sélectionné plusieurs feuilles à la fois (avec ctrl ou shift) ?
Ça ressemble en tout cas fortement au comportement que tu observes…
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à -1.
Et donc c’est tout sauf gratuit en terme de perfs… Et certainement pas l’outil magique.
Surtout que du bit rot, en pratique, je ne suis pas sûr d’en avoir rencontrer une seule fois dans ma vie…
Les disques du commerce grand public sont garanti à 1014 octets pour 1 erreur de bit, soit 12To avant de voir la moindre erreur. Les disques professionnelles sont à 1015 (120To). Et d’ailleurs ce chiffre concerne les HDD, les SDD ont une durée de vie plus faible.
C’est d’ailleurs confirmé par des études empiriques chez Microsoft : https://www.microsoft.com/en-us/research/publication/empirical-measurements-of-disk-failure-rates-and-error-rates/?from=http://research.microsoft.com/pubs/64599/tr-2005-166.pdf
Et enfin, ils préviennent aussi que quand un truc disjoncte, d’autres trucs disjonctent en même temps pas très loin :
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 2. Dernière modification le 18 juin 2017 à 02:41.
J’attend ta doc de comment tu fais pour corriger un problème de bitrot à partir de 2 strips de data RAID1 hein. C’est mathématiquement impossible.
Tu avais 0110110110111000101 | 0110110110111000101 avant
Tu as dorénavant 0110110110*0*11000101 | 0110110110111000101
Tu ne peux pas savoir lequel des 2 strips est l’original, tu peux seulement constater que tu as un écart. Et au mieux décider au pifomètre une grappe à sacrifier.
Ou au mieux restaurer l’état précédent via le COW, qui va te corrompre ton fichier si tu travailles au niveau bloc, et te faire perdre des données si tu travailles au niveau fichier.
Pour corriger l’erreur, il faudrait que btrfs stocke en plus un 3ème strip (de parité par exemple, donc RAID5) ou un checksum au niveau FS (mais bonjour les perfs et la conso d’espace supplémentaire) pour permettre de déclencher un consensus et de trouver le strip fautif.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
Oui, et aucun article n’explique comment fait btrfs pour corriger une erreur de bit rot, sachant qu’il n’y a pas de sur-redondance de données (seulement 2 strips) et uniquement 1 bloc de parité (donc indécidable si c’est le bloc de parité qui s’est pris le bitrot ou un strip de data).
Tout le monde est d’accord pour dire que ça détecte le bitrot (comme tout système raid). Nul part je ne vois que ça le corrige (sauf raid5 minimum où un consensensus est possible), sinon via un retour arrière via l’historique COW (qui risque alors soit de corrompre le fichier si le rollback est au niveau bloc, soit avec pertes de données s’il est au niveau fichier).
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à -2.
Sauf que comme je l’ai dis, on ne sait PAS corriger une erreur avec RAID1. on ne peut que détecter une erreur, on ne sait pas quelle donnée est la bonne. Ça ne protège donc pas d’un bitrot, ça permet uniquement de le détecter et de dégager une des grappes au pif pour pouvoir laisser la prod continuer à tourner en attendant une resynchro.
Il faut du RAID5 pour savoir corriger l’erreur une fois détecter, via la comparaison avec les 2 disques fonctionnels qui disent la même chose alors que le disque défectueux dit une connerie.
Un secteur défectueux. Un dd à la con qui te ruine ta table des partitions.
Et bien reli bien les docs, ce n’est pas le cas. Pas en RAID1.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0. Dernière modification le 18 juin 2017 à 02:06.
Ça ne protège pas plus d’un bitrot justement.
Le controlleur RAID détectera une incohérence, ne sera pas capable de déterminer qui des 2 strips a raison et éjectera un des 2 côtés sans aucune semonce.
C’est RAID5 minimum qui permet de corriger le bitrot en regardant le consensus des grappes. RAID1 ne permet que de le détecter et ne permet aucune action corrective (sinon à la hache en dégageant une grappe).
Et ça ne fait pas ce que tu dis.
C’est effectivement COW, ce qui veut dire qu’en cas de corruption, les données PRÉCÉDENTES vont être dispos.
Si ton fichier est dans sa 1ère version et que tu te prends un bitrot, t’es cramé, il n’y a pas plus d’historique.
Et même dans le cas où tu as des données plus ancienne, tu ne sais pas revenir à l’état intègre de la version « bitrotée ». Ça continuera à te donner un fichier final corrompu d’ailleurs si le FS ne rollback qu’un bloc et non tous les blocs de ton fichier (et dans ce cas tu perds encore plus de données).
Faut pas croire que c’est magique les FS hein. Même ceux « next-gen ».
Je ne vois pas ce que ça vient faire là.
Et tu as le même problème sur ton truc local hein.
Un fichier corrompu non détecté merdera ad vitam éternam partout. En local, online, offline, offloadé. C’est pour ça qu’il est important de tester régulièrement ses backups.
Similaires techniquement peut-être, mais dans leurs usages pas du tout.
Comme déjà dis, un backup ne suppose pas que ton système soit opérationnel pour pouvoir faire une restauration. Ta copie locale si.
« Backups have two distinct purposes. The primary purpose is to recover data after its loss, be it by data deletion or corruption. »
La page anglaise dit la même chose que moi : un backup suppose la perte complète du système principal. its loss, ce n’est pas its corruption. Tes données ne sont plus là, et considérées comme non réparables depuis le système principal.
« The secondary purpose of backups is to recover data from an earlier time »
La possibilité de restauration d’un backup après la perte de données implique un retour en arrière. Ton système local ne couvre que le 2nd usage (« retourner en arrière »), pas le 1er (« récupérer une perte de données »).
https://www.appvizer.fr/magazine/services-informatiques/sauvegarde/sauvegarde-archivage-stockage-quelles-differences-1443109474
http://blog.watsoft.net/actualite-watsoft/difference-entre-larchivage-et-la-sauvegarde-dun-serveur-de-messagerie/
http://www.gestion-documents.fr/archivage-vs-sauvegarde/
https://blog.netexplorer.fr/stocker-archiver-sauvegarder-differences/
J’aurais tendance à dire que ta solution locale est de l’archivage, et non de la sauvegarde.
D’ailleurs, je trouve le dernier article assez clair au niveau des définitions :
« Je veux pouvoir récupérer mes données en cas d’évènements majeurs altérant leur accessibilité » ⇒ sauvegarde (côté « everything is doomed »)
« Je veux m’assurer de pouvoir récupérer mes données sur le long terme à tout instant » ⇒ archivage (côté « something fucked »)
« Je veux pouvoir accéder à mes fichiers où que je sois, et les partager avec mes collègues » ⇒ stockage (côté « the world is cool »)
[^] # Re: Rhétorique
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
| Je n'ai surtout pas confiance dans mon disque, raison pour laquelle je suis en Btrfs/RAID1. J'ai souvent eu le cas de corruption de données (mauvais câble, mauvais disque).
C’est là que je ne te suis absolument pas…
Tu fous quoi en RAID1 si tu n’as pas confiance en tes disques ? :s
C’est du RAID5 minimum qu’il te faudrait du coup, puisque qu’un disque qui pète sur du RAID1 peut entraîner la perte de la grappe complète si c’est le mauvais disque qui est sorti de la grappe en 1er (déjà vécu plusieurs fois)…
| La sauvegarde locale, même si ce n'est pas du tout en soi suffisant, c'est un gros bonus pour moi.
N’appelle pas ça sauvegarde alors.
| Car très très souvent, quand je fouille dans mes sauvegardes pour récupérer quelque chose, ce n'est pas à cause d'un cambriolage, d'un feu ou d'un piratage, mais à cause d'une erreur humaine/logicielle ou d'une corruption de données/disque.
Et c’est typiquement ces cas-là où une sauvegarde (donc offline ou a minima sur disque physique séparé) est utile.
Tes trucs locaux ont une probabilité plus que non nulle d’être AUSSI impacté en cas d’erreur humaine ou logicielle ou d’une corruption de données/disques.
Elles sont physiquement trop proches des données « live » pour pouvoir dire l’inverse.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à -1.
| ZFS & Btrfs checksum les données, en cas d'utilisation d'un RAID (1/5/6), la version corrompue est automatiquement réparer.
Je veux bien un papier sur le sujet, parce que je ne vois pas comment c’est possible, en tout cas sur RAID1.
Si ZFS|Btrfs se rend compte d’une incohérence de données entre le checksum et les données remontées par le disque, ils n’ont aucun moyen de corriger l’erreur puisqu’ils ne peuvent pas savoir quelle erreur a réellement été commise entre
Après tu peux faire des heuristiques à la con pour chercher à corriger (si D1≠D2 on vérifie si D1 ou D2 match C1=C2, ou encore si C1≠C2, on garde le C qui matche D1=D2), mais il reste plein de trous dans la raquête (D1≠D2 et aucun C qui match, C1≠C2 et pas de D qui match, C1≠C2 & D1≠D2, etc) et tu peux empirer encore plus la situation en choisissant une mauvaise heuristique.
C’est tout le problème du RAID1 : dès qu’un truc pète (hors erreurs matos), il est préférable de dégager un disque au pif que de chercher à corriger les erreurs.
Et c’est aussi pour ça que RAID1, c’est pour moi uniquement une question de résilience et certainement pas de robustesse. Ça permet de conserver une infra physique fonctionnelle en cas de corruption, à quelques glitches près sur les zones éventuellement erronées qu’on restorera depuis les backups si nécessaires une fois le matos changé.
Si tu veux de la résilience (pas de down) et de la robustesse (pas de perte), tu passes sur du RAID5.
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
Avoir une copie locale a effectivement de l’intérêt (c’est même pour ça qu’a été inventé DSCM). Mais ce n’est pas une sauvegarde (en tout cas pas du point de vue « admin sys »). Faudrait trouver un autre terme.
Ben c’est toi qui mentionne RAID1 comme la solution qui te protège hein…
Faux. Il ne lutte pas contre la corruption de données/bit rot. À la moindre erreur, c’est toute ta grappe qui peut partir (et partira en dans le cas du RAID1) en sucette. Et pour le cas du RAID1, tu peux même ne pas savoir du tout quel disque contient la donnée incorrecte et lequel la données correcte (problème indécidable avec seulement 2 disques).
RAID n’apporte que de la résilience, et rien d’autre. Ça permet éventuellement d’éviter un arrêt de prod le temps de remplacer le disque.
Ça n’est pas génant dans le cas des backups offline/offloadés.
Tu le détecteras lors de la synchronisation que le disque est fucked. Et du coup tu pourras changer de disque pour tes nouvelles rotations et basta.
La probabilité qu’un disque OK au moment de la synchro (et donc d’un test de restauration :P) devient KO 1 semaine/1 mois après alors qu’il n’a même pas été utilisé entre les 2 est quand même vachement faible… (Et d’abord on n’a jamais dis non plus qu’un backup est infaillible, et que c’est facilement gérable avec du multi-disk.)
Tu viens ici en disant que copie online/DSCM/cow/btrfs/raid/whatever est un système de backup. C’est même le sujet de ton journal : « Est-ce que la gestion de versions peut être considérée comme de la sauvegarde de données et inversement ? ».
La réponse est non et sera invariable.
Une sauvegarde doit permettre de revenir à un état cohérent et utilisable passé, en faisant un minimum d’hypothèses sur la procédure à suivre et sur l’état courant du système (en particulier, on doit supposer le système d’origine inutilisable au moment de la restauration).
En particulier, un backup est un système qui devrait te permettre une restauration de service même si l’ensemble de ton système d’origine a disparu de la surface de la planète.
Ou dit encore autrement, la seule hypothèse de restauration doit être la possession d’un backup (sachant que ton système lui, doit être considéré 100% KO).
Une copie online/DSCM/cow/btrfs/raid/whatever ne répond qu’à peu voire aucune des propriétés de ce que doit être une sauvegarde (en particulier nécessite un système disponible et l’outil de backup fonctionnel au moment de la restauration).
Appelle ça comme tu veux (« cache », « snapshot », « dumb-user-proof », « fast-rewind »…) mais pas « sauvegarde ».
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 0.
J’ajouterai même mieux :
Un DSCM permet de remonter à tout instant T sous réserve que le dépôt soit encore opérationnel à l’instant T+X
Un backup assure que s’il était opérationnel à l’instant T, il est restaurable et fonctionnel à l’instant T+X
Un DSCM est un « rewind-backup », alors qu’un backup est un « forward-backup ».
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 3. Dernière modification le 17 juin 2017 à 20:34.
Tu ne protèges pas du tout de la même chose avec un DSCM et avec une sauvegarde.
Un DSCM ne protège ne protège que d’une corruption (à prendre au sens générale, ça peut être le matos, le système de fichiers, un dev qui a fuck…) interne du dépôt (un dev a fait un rm -rf des fichiers du dépôt). Ça ne protège pas des corruptions externes (un dev a fait un rm -rf du .git, un secteur défectueux empêche la lecture de méta-données…).
Tu peux par exemple te retrouver avec un dépôt git fucké avec plus aucune commande qui ne fonctionne à cause d’une corruption des données du dépôt.
Un backup va te protéger de ces corruptions externes justement.
Dit autrement, un DSCM permet de remonter à un instant T-X, un backup permet de garantir que si ça marchait à l’instant T, cet instant T refonctionnera à l’instant T+X une fois restauré (alors qu’un dépôt qui fonctionne à l’instant T peut être impossible à remettre dans l’état de l’instant T s’il est corrompu).
Ce qui est pire que tout.
Tu as le moindre problème externe, tu as tout perdu.
Un backup ne suppose rien de l’état de ton système justement.
Je ne connais que trop de gens qui se croyaient à l’abris avec du RAID1. Faire du RAID, c’est très compliqué à faire proprement.
Par exemple si tu mets 2 disques issus du même fabriquant avec des numéros de série relativement proche, il y a de très grandes chances que lors qu’un des disques sautera, la reconstruction achèvera le 2nd disque, qui aura grosso modo la même durée de vie.
Faire du RAID1 proprement, c’est acheter 2 disques de constructeurs différents, à 2 dates relativement éloignées (plusieurs mois, les composants physiques étant presque tous fabriqués au même endroit, quelque soit le fabriquant).
Sans parler que btrfs et RAID ne te protègeront pas d’un « rm -rf / » ou d’un dd foireux.
Le RAID, c’est comme les DCSM, ça n’est pas une solution de backup.
Les corruptions de données ne sont pas silencieuses avec des backups.
Des backups, ça se teste régulièrement. L’état SMART des disques est à vérifier régulièrement. fsck à passer régulièrement.
Le fait de les avoir unmount/offline/offload protège aussi le matériel. Étant moins sollicités, la durée de vie des supports physiques est plus longue. Un disque qui passe 1 mois dans un coffre à la banque ne s’use pas, pas plus que celui posé sur mon étagère.
Et encore une fois, btrfs/raid ne te protège pas des « corruptions » logicielles (rm -rf, dd…)
[^] # Re: On en est encore là ?
Posté par Aeris (site web personnel) . En réponse au journal Gestion de versions et sauvegarde de données. Évalué à 1.
| Il me semble que ce point de vue, cette vision très tranchée (il faut une sauvegarde distante) est une approche qui est dépassée aujourd'hui.
C’est tout sauf dépasser.
Le problème de la « sauvegarde » locale, c’est qu’elle ne protège que de peu de choses. En fait de rien du tout généralement.
Si tes données sont au même endroit que tes « sauvegardes » (en tout cas sur le même disque physique), alors il y a un risque plus que non négligeable qu’en cas de corruption des données, ta « sauvegarde » le soit aussi. Sauf cas très particulier (backup sur un disque séparé, non monté ou en read-only seulement) ou erreur très ponctuelle et légère (un fichier supprimé par mégarde, un truc modifié qui n’aurait pas du l’être), en bref ce pour quoi existe la gestion de configuration (qui n’est donc pas une sauvegarde).
Un rm foireux, un disque qui claque sans crier gare, une mauvaise manip pour flasher une clef USB (que celui qui n’a jamais confondu deux /dev/sdx lors d’un dd lève la main) ou un cryptolocker qui passe, et c’est le drame à la fois pour les données et la « sauvegarde » locale. Ce n’est donc pas (en tout cas pour ma part) une sauvegarde viable, tout au plus un cache temporaire.
Une sauvegarde, c’est pour moi une copie des données dont la probabilité d’être impactée en cas de soucis sur les données d’origine est plus que très faible voire si possible nulle.
C’est donc a minima une copie sur un disque physiquement différent de celui des données. Non monté ou en read-only sauf période de backup s’il reste online.
Et même plutôt physiquement déconnecté de la machine des données sauf durant les phases de sauvegarde (disque USB par exemple).
Personnellement, je vais jusqu’à faire tourner chaque mois un des 2 disques de backups offline dans un coffre à la banque pour mes données très sensibles. En plus du disque de backup online présent dans la machine (démonté après chaque synchronisation et qui me sert d’image de base pour la synchro sur les disques offline).
Ça donne donc :
- backup quotidien sur disque online (purgé selon le motif 7 quotidiens, 4 hebdos, 12 mensuels, 10 annuels)
- backup hebdo du disque online sur le disque offline présent chez moi
- échange mensuel du disque offline chez moi avec celui offloadé
Je peux te dire que chaque morceau de ce pattern m’a sauvé les miches, et plus d’une fois.
- backup online : grosse merde sur le disque principal (rm -rf, dd foireux…)
- backup offline : HDD HS data + online (oui je suis un chat noir, mais c’est un scénario classique comme pour le cas du RAID, la resynchro risque de finir d’achever ton disque de backup qui était usé mais pas HS)
- backup offloadé : protection contre perqui ou saisie, cambriolage, incendie
# Docker en prod
Posté par Aeris (site web personnel) . En réponse au message Docker en prod. Évalué à 2.
J’avais aussi rédigé ça il fût un temps
https://blog.imirhil.fr/2016/10/09/docker-container-hell.html
# 2FA
Posté par Aeris (site web personnel) . En réponse au journal Sécurité et authentification des sites bancaires.. Évalué à 5. Dernière modification le 20 mars 2017 à 13:38.
Le Crédit Coopératif, en tout cas pour les clients pro, fournit une carte à puce et un lecteur de carte délivrant un OTP nécessaire à chaque connexion et pour les opérations sensibles.
[^] # Re: Every single 64 bits possible value…
Posté par Aeris (site web personnel) . En réponse au journal Et paf, le SHA-1 !. Évalué à 8.
Autant ne laisser que le SHA256 du coup…
[^] # Re: Every single 64 bits possible value…
Posté par Aeris (site web personnel) . En réponse au journal Et paf, le SHA-1 !. Évalué à 5.
C’est pour ça que l’état de l’art de la crypto est plutôt de tabler sur 128 bits minimum pour être à l’abri des attaques modernes.
64 bits, ça puait déjà un peu depuis quelques temps, sweet32 avait fini de semer le doute partout, mais là c’est carrément une preuve que Google nous a sortie !
[^] # Re: Un 2nd Oupa
Posté par Aeris (site web personnel) . En réponse au journal Et paf, le SHA-1 !. Évalué à 0.
Si je ne dis pas de connerie (donc à vérifier), ça nécessite la version 2.1.14 minimum.
[^] # Un 2nd Oupa
Posté par Aeris (site web personnel) . En réponse au journal Et paf, le SHA-1 !. Évalué à 3.
Il y a une différence entre « GnuPG a fixé le problème depuis 2010 » et « les distributions et OS ont propagé la modification ».
Actuellement, sous Debian stable, on a toujours le problème :
Et donc actuellement, sur une Debian stable, SHA1 est encore devant les SHA-2 à l’exception de SHA256…
Il faut attendre la version 2.1 de GnuPG pour réellement avoir ce changement. Version actuellement disponible nul part ou presque (Debian testing uniquement, ni Debian stable, ni Ubuntu, ni Windows, ni Mac).
Donc si, on a toujours besoin de faire ces modifications de fichiers !
# Oupa
Posté par Aeris (site web personnel) . En réponse au journal Et paf, le SHA-1 !. Évalué à 0.
Gaffe, tu es dans la 3ème colonne là :P
http://valerieaurora.org/hash.html
[^] # Re: Mon commentaire sur le blog…
Posté par Aeris (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 8.
Du coup, j’ai VRAIMENT du mal à comprendre ton billet…
« Je ne parle que des projets qui ont décidé de se lancer sur le grand public ». Déjà ça concerne très peu de projet au final.
Et généralement ceux qui se sont lancé là-dedans font DÉJÀ appel à de la communication et du marketing, y compris professionnellement. Que ça soit Mozilla, Firefox, LibreOffice, VLC, Cozy, j’en passe et des meilleurs.
Et donc on en revient au point de départ : ça n’est pas qu’ils n’ont pas de stratégie sur le sujet, c’est qu’ils n’ont pas celle que toi tu souhaites.
Ils ont DÉJÀ une stratégie, du marketing et du design.
Au pif, https://fr.libreoffice.org/community/design/, https://blog.mozilla.org/opendesign/, https://www.videolan.org/vlc/skins.php, etc (histoire de couvrir à la fois du marketing, du design et de l’UX)…
C’est juste que tu considères que, parce que ça n’est pas ce que TOI tu aurais fais, c’est du « caca sur une paroi rocheuse inégale avec le soleil dans les yeux ».
Tu as même été jusqu’à dire que Cozy n’avait pas de designer ni de marketing, alors que c’est même là-dessus qu’on passe le plus gros de notre temps… Avec un designer recruté à plein temps, des tonnes de dev fronts plus que compétents en terme d’UX ou de design, une personne en charge du marketing, l’appel à des boîtes de com’ et de design pour nos communications externes, des méthodes agiles de feedback rapides de la part des utilisateurs et même des meetups complets dédiés au sujet.
C’est très révélateur de la véritable nature de ton billet : cracher sur le travail des autres au motif où tu considères que leur boulot est de la merde. Soit exactement ce que tu reproches dans ton billet.
[^] # Re: Mon commentaire sur le blog…
Posté par Aeris (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 4.
Et toi tu continues à parler de communication générale et de marketing pour des projets répondant aux besoins de 3 personnes et maintenue par 1 personne avec un budget de 0 voire négatif, qui n’ont jamais demandé à devenir le prochain écran publicitaire de TF1 ou ne cherche pas à concurrencer Google.
Parce que la réalité de l’éco-système des projets libres dont tu parles au début, c’est ça. Même GnuPG, c’est un gus dans un garage ou presque.
Pas les Mozilla, VLC ou autre LibreOffice. Qui eux ont déjà recours à du design et du marketing. En fait depuis qu’ils se sont mis comme objectif de devenir grand public.
C’est rigolo aussi.
[^] # Re: Mon commentaire sur le blog…
Posté par Aeris (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 1.
Loin de moi l’idée d’avoir dit ça. Juste que c’est un design simple à réaliser et lisible par tous. Mais qui peut être perçu comme moche ou peu agréable.
Et qu’un designer risque d’avoir des difficultés à trouver un design adapté à la fois à une vision normale et à une vision daltoniste.
Surtout en ayant dans l’idée de faire un truc génialissime révolutionnaire. La mode et autres tendances actuelles étant plutôt à l’opposé des préoccupations d’accessibilité.
[^] # Re: Mon commentaire sur le blog…
Posté par Aeris (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 0.
Il faut des contrastes très forts et beaucoup de couleurs ne sont pas distinguables par un daltonien.
Voir ici par exemple pour un exemple flagrant de la restriction du spectre des couleurs http://blog.octo.com/pattern-ui-vision-des-couleurs-et-daltonisme/
En gros, un daltonien ne perçoit que du bleu et jaune ou du bleu et rouge. Ça rend très difficile la conception d’un design qui ne va arracher la vue de personne. Dans tous les cas, dès que tu dépasses 4 couleurs, il va être totalement perdu et les nuances ne sont pas perçues.
[^] # Re: Mon commentaire sur le blog…
Posté par Aeris (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 2. Dernière modification le 11 février 2017 à 17:12.
Je vais d’ailleurs donner un exemple tout con des problématiques qu’on peut aussi avoir avec une réflexion pur designer only : https://nos-oignons.net/wiki-admin/
On est d’accord, c’est très moche non ? Tu voudrais bien changer ça hein ?
Pas de bol, il y a une personne daltonienne dans l’équipe. Ces couleurs permettent d’avoir un site accessible y compris pour elle.
Ton futur méga design de la mort qui tue qui ramènera whatmilles bouzillions de personnes et l’être aimé·e sur ce projet ? On le mettra bien gentiment à poubelle, parce qu’on devra perdre au moins UNE personne actuellement contributrice en échange.
Idem pour tes designs de folies type Office, GMail ou autre. Combien sont réellement accessibles à un lecteur d’écran et donc compatible avec les personnes déficientes visuelles ? Idem, ça finira donc à la poubelle d’un projet libre qui tient à rester accessible à tout un chacun.
Certes, certains projets sont moches. Mais ô combien plus accessibles pour les personnes handicapées que certains designs qu’on voit fleurir partout dans les logiciels privateurs…
[^] # Re: Mon commentaire sur le blog…
Posté par Aeris (site web personnel) . En réponse au journal Le libre et l'expérience utilisateur. Évalué à 5. Dernière modification le 11 février 2017 à 16:59.
C’est là que tu te méprends à mon avis.
Dans une interface CLI ou moche, un patch sera effectivement jugé par de purs développeurs.
Pour la conception d’une affiche, un design sera effectivement jugé par de purs designers. Et encore, tu risques de te faire envoyer bouler par ton imprimeur parce que tu auras utilisé une couleur qu’il est incapable de reproduire correctement (au pif, certains jaunes).
Pour l’intégration par un intégrateur d’un design fait par un designer dans un code fait par un développeur, c’est l’ensemble de l’équipe qui va avoir son mot à dire. Et que ton patch pourra du coup être refusé parce que les intégrateurs vont juger qu’il est in-intégrable au projet alors que tous les designers vont être unanimes pour vouloir l’intégrer.
Comme déjà mentionné sur Twitter, le fait d’avoir une collaboration fait naître aussi certaines obligations. Mon exemple donné est qu’il ne sera pas illégitime pour un projet libre de rejeter une contribution d’un designer livrée sous forme de PSD, même si professionnellement le boulot réalisé est l’équivalent graphisme de la solution à la faim dans le monde.
Il ne suffira pas de faire du plus que très bon boulot au niveau design pour voir ta contribution acceptée par le projet. Il faudra faire tes preuves sur l’ensemble de ta contribution, et en particulier sur toutes les parties qui ne sont justement pas ton dada, tout comme un développeur sera sanctionné pour un manque de doc ou de test, alors qu’il n’est ni documentaliste ni testeur mais que des compétences sur ces sujets sont AUSSI attendues que son code lui-même.
À la réflexion, j’ai vraiment l’impression que tu te méprends plus que fortement sur ce qu’est réellement la conception d’un projet et en particulier sur ce qu’est être un développeur…
[^] # Re: Exemple
Posté par Aeris (site web personnel) . En réponse au journal Potentiel gros bug sous LibreOffice @ Debian testing. Évalué à 7.
Hum, juste au pif comme ça, est-ce que tu n’aurais pas tout simplement sélectionné plusieurs feuilles à la fois (avec ctrl ou shift) ?
Ça ressemble en tout cas fortement au comportement que tu observes…