damaki a écrit 389 commentaires

J'ai du louper un peu l'explication. Les disques offline sont en btrfs, mais une partition qui n'est pas une copie de la sauvegarde current, c'est juste fait avec un rsync après effacement

Oups, c'est pas clair non plus. Ce que je voulais dire c'est que je ne copie que les fichiers de la sauvegarde courante, pas la structure de la partition btrfs avec les subvolumes des précédentes.

est-ce que ton NAS ne te sert que de support de sauvegarde ? Autrement il te faudra aussi sauvegarder les données qui ne sont que sur ton NAS (c'était la principale difficulté de mon journal).

Non, mais les autres données présentes dessus sont considérées comme sacrifiables. Et en plus elles sont sur des disques différents de ceux dédiés aux sauvegardes.
Je sauvegarde le /etc du NAS, mais je saurais honnêtement le reconstruire, ça prendrait quelques heures.

si tu chiffres tes disques externes, je suppose que tu chiffres aussi ton NAS (autrement quelqu'un volant ton NAS aurait accès à toutes les données de toutes tes machines) ? Si oui il y a pas mal de problèmes associés

Non, mais j'en suis conscient et c'est prévu comme évolution imminente. Le NAS étant un PC de récup moche et vieux de 10 ans (+ d'autres facteurs), ça n'est encore pas une inquiétude majeure.

tu sauvegardes une partition Btrfs sur une partition NTFS, du coup si je comprends bien tu perds tout le bénéfice de la déduplication des données (2 snapshots incrémentaux seront sauvegardés comme 2 ensembles indépendants).

J'ai du louper un peu l'explication. Les disques offline sont en btrfs, mais une partition qui n'est pas une copie de la sauvegarde current, c'est juste fait avec un rsync après effacement. Je ne sauvegarde pas les snapshots pour des raisons de budget disque, mais ça va sans doute changer sous peu, dès que j'aurais le budget. Tout comme le nombre de disques de sauvegarde offline que je vais augmenter progressivement.
Je considère aussi comme acceptable de perdre un mois de données en cas de désastre combiné "source de données cassée"/"raid 1 du NAS cassé".

tu fais énormément confiance à ton RAID1 si je comprends bien ? Si jamais il y a un problème qui n'est pas détecté/corrigé par ton RAID1, le problème sera recopié sur ton disque externe ?

C'est un gros point faible, en effet. Il manque un système pour valider que le contenu du current du NAS est identique aux sources de données des sauvegardes. Ça résoudrait en partie le problème, même si rien ne garantit que la source n'a pas été corrompue entre temps (déjà subi :( ).
Pour les sauvegardes faites avec du rsync, je pourrais forcer une fois par mois (voire à chaque fois) le mode --checksum. Pour les autres sources de données, c'est du cas par cas.

L'autre point qui manque, c'est régulièrement de faire des tests de scénarios de désastre pour découvrir des faiblesses et documenter les restaurations, ça reste le meilleur moyen.
J'ai récemment écrasé partiellement (involontairement, c'était génial) le début d'un des disques du raid et ça a été très formateur.

Tous les process de sauvegarde du monde ne valent rien tant qu'on a pas validé rigoureusement que toutes les pièces du mécanisme fonctionnent avec des tests.

Comme tout désastre possible, il faut analyser la probabilité que ça se produise, et l'impact si ça se produit. Dans mon cas, c'est hautement improbable (je ne détaillerai pas pourquoi ici) qu'on soit cambriolés et qu'on vole un PC moche vieux de 10 ans/NAS
L'analyse de l'impact, je ne détaillerai pas non plus ici, mais c'est fait aussi.

Malgré tout, oui, chiffrer la sauvegarde locale online est en cours de réflexion malgré tout. J'ai surtout mis la priorité à court terme sur le chiffrement des PC portables, les mobiles, les sauvegardes offline hors site, les clés USB et puis les rares données sur mon nextcloud.

J'améliore graduellement la sécurité de mes données ; ça prend du temps.

Ok, merci !

J'ai un dossier current qui contient un sous-dossier pour chaque appareil et chaque groupement de fichiers à sauvegarder. Les fichiers y sont déposés, suivant les dossiers par des scripts avec rsync ou des applications mobiles ou à la main, bref tout moyen capable de déposer un fichier dans un dossier.
C'est sur ce dossier current que les snapshots de subvolume sont effectués, sachant que cette partition en RAID 1 ne sert qu'à ça.

Mon système est à peu près similaire, sauf que les sauvegardes distantes en question sont hors ligne. Ce sont des disques durs chiffrés qui sont ailleurs que chez moi, non branchés. Quand je veux mettre à jour les sauvegardes distantes, je ramène le disque, et je lance mon script qui fait:
- mountage du disque, luksOpen et tout le toutim
- effacement complet du contenu du disque
- copie des fichiers avec un rsync tout simple (c'est pour la reprise en cas de pépin)
- scrub de toute la partition ntfs
- si le scrub est ok, la sauvegarde est supposée bonne, luksClose et umount, puis je débranche.
- si je souhaitais valider une sauvegarde, suffit de brancher le disque et de faire un scrub

Mon système a deux failles:
- les snapshots ne sont pas en lecture seule. Faut faire hyper gaffe. Mais en relisant de la doc, je viens de découvrir que ça existe en btrfs et que je ne le savais pas, btrfs subvolume snapshot -r
- la sauvegarde distante ne marche que si ma sauvegarde courante est bonne. si j'avais un soucis avec la sauvegarde locale, ça foire tout.

Ça part aussi du principe que la clé de chiffrement est sur un autre média que tout ce que j'ai cité. Je l'ai en 3 copies, une sur le serveur local de sauvegarde, deux sur des clés usb chiffrées avec veracrypt.

Ouais, enfin pas fait pour le desktop, un humain normal avec des besoins normaux en termes de perf (pas un serveur, quoi) ne verra pas la différence. La compression est très appréciable sur un laptop avec peu de disque, quand on veut grater de l'espace disque. J'imagine que l'utilisateur lambda va pas être spécialement intéressé par les snapshots et les checksums, mais ça reste pratique.

Franchement, en deux ans d'utilisation régulière de btrfs sur desktop, même pour du dev et de la compilation, je n'ai pas ressenti de souci de perf notable empiriquement. Avec des benchmarks assassins, je dis pas, mais ma vraie vie voit pas le soucis.

Je me sers des snapshots BTRFS pour faire des sauvegardes incrémentales avec un coût ultra faible et des scripts hyper simples, sur mon NAS (PC de récup). Combiné avec les scrub hebdomadaires ça a un coût de stockage faible et une fiabilité raisonnable une fois combiné avec un RAID 1 (mirroring) et des sauvegardes offline mensuelles.
Mais ça n'est clairement pas le genre d'installation que je ferais en entreprise, par contre…

Quel est exactement le problème avec la compression sur btrfs ?
J'ai juste rencontré des soucis d'usage de CPU avec l'algo zlib, sur des machines faiblardes, mais pas de soucis en lzo au bout de 1 an et demi sur mon modeste serveur de backup en ligne.

Pour les remarques précédentes, le BTRFS n'a pas comme cible la haute performance, tout comme le ZFS. Le cas d'utilisation actuel théorique est plutôt la fiabilité et la possibilité de valider l'état des fichiers (bitrot et tout ça, surtout quand on a de mauvais contrôleurs et disques), ou les snapshots.

Au sujet de Red Hat, ça reste l'une des distro les plus conservatrices qui soient. Le fait que BTRFS ne soit pas juste une nouvelle version d'un système de fichier existant ne doit pas trop aider à son acceptation, d'autant plus que j'entends fréquemment des histoires de scénarios catastrophes à son sujet (jamais rencontrés personnellement sur mes mini prods). Et la compression ou les snapshots, ça reste des problèmes qu'on peut résoudre en balançant bêtement plus d'espace disque. Ça ne laisse donc pas beaucoup d'avantages sur les autres fs malgré cette liste de features.

J'ai l'impression que vous n'avez jamais tenté de soumettre un nouvel article ou une modification sur la Wikipedia. Je suis désolé, mais j'ai bien du mal à mettre en phase votre vision de Wikipedia et la mienne.
Wikipedia n'a clairement jamais été démocratique et ses modérateurs (humains et robots) ont toujours le dernier mot.

La Wikipedia, déjà, si vous n'avez pas un sujet de page qui plaise à un des modérateurs, le robot vous la supprimera automatiquement (testé et déprimé plusieurs fois). Les modérateurs ont un temps limité pour accepter les nouveaux articles ; passé ce délai ils sont automatiquement refusés et effacés. Oui, par défaut, votre savoir donné à la communauté sera par défaut supprimé. C'est donc le premier souci : la sélection oligarchique de l'article, selon les priorités des modérateurs. La Wikipedia n'est pas le savoir universel, c'est le savoir considéré important par les modérateurs. Le savoir universel a sa place ailleurs sur le web, grâce à sa décentralisation.
Le deuxième sujet est donc les citations. Si votre sujet a été considéré comme intéressant, vous avez déjà passé la première étape. Maintenant, il vous faut des sources qui sont référencées sur le web ou des ISBN, ou numéro de référence équivalent (qui ne sera de toute façon pas forcément vérifié). Votre source est une obscure publication ? A moins que vous ne la mettiez sur le web, sans nécessairement avoir le droit d'ailleurs, ce qui est cocasse, aucune garantie que votre article soit conservé. Le syndrome du citation needed et des articles qui risquent d'être effacés faute de source. Oui, vous avez remarqué que j'en revient encore à l'effacement. Sans source, votre article ne vaut rien, oui car la Wikipedia n'est pas une source de savoir original mais un agrégat, un résumé. On peut y voir làune qualité ou un défaut. Mais vu le nombre de wikis parallèles qui pullulent partout sur le web, on peut discerner que le savoir spécialisé, original et libre n'a sa place qu'ailleurs.
Imaginez maintenant que votre article est sur le web, et que vous avez des sources. Pensez-vous vraiment que vos sites de sources vont survivre disons 5 ans ? 10 ans ? 20 ans ? Vous voyez donc le problème final émerger : le savoir qu'on accumule sur la Wikipedia, s'il ne se base pas sur des livres trouvables est périssable. Votre article devra donc avoir des références maintenues à jour sous peine de suppression possible, ou de fiabilité contestable de l'information sur le long terme. On en revient à l'idée que ça n'est pas une source de savoir de référence et que ça ne le sera jamais.

Tout ça pour dire que Wikipedia est un excellent outil, mais en aucun cas un outil de référence. Avant d'y voir une source de liberté, de débat, il faudrait déjà voir Wikipedia pour ce que c'est : un outil qui a strictement les mêmes travers que les encyclopédies privées. Ça n'est pas un vrai lieu de débat, car ses fondements mêmes sont biaisés par sa modération. Wikipedia est donc la vision du monde par ses modérateurs.
Ne mettez pas dans Wikipedia des valeurs et des qualités qui n'y sont pas.

Tout n'est pas noir au sujet de la migration systemd. systemd-sysv-generator aide pas mal pour la migration des scripts /etc/init.d ; les scripts fonctionnent par défaut. Ce qui n'est pas le cas sous Arch, versions 2017. Et avec la commande "service" et les logs syslog activés par défaut à l'ancienne, la migration s'est vraiment faite sans accroc sous Debian.
Autant, je ne vois pas le bénéfice de ma petite lorgnette, autant, c'est clairement pas pire qu'avant.

Ce n'est pas le rôle de git de gérer les pull requests, tout comme montrer les commits sur un site web n'est pas non plus son travail.
Une pull request, c'est un message servant à prévenir qu'il faut valider un ensemble de commits pour l'intégrer à une branche de travail. Donc c'est plutôt un outil de messagerie qu'il faut utiliser. Les modifs attachées au message peuvent être hébergées sur un autre repo git, ou être fournies dans le message lui même. Ca n'a aucune importance, il n'y a même pas de dépendances à une techno particulière, que ce soit un VCS (système de contrôle de version) ou à une méthode d'envoi du message (forum, github, e-mail, message IRC, etc…). Pour des raisons de traçabilité et de simplicité, Linux utilise des emails pour gérer ça, mais ça n'a pas vraiment de couplage avec git.

Et si vous cherchez un truc sans dépendances pénibles, pas trop gourmand et ultra facile à installer sur n'importe quoi, vous avez aussi Gitbucket. C'est le point faible de tous les autres que j'ai eu l'occasion de tester, le côté overkill et complexité à administrer quand on a moins de 10 utilisateurs.
Ca n'est évidemment pas le même cas d'utilisation que Gitlab, outil excellent, avec plein de fonctionnalités intégrées (et débilement gourmand sur une petite install).

En plus de tous les arguments énoncés, les bitrates fixes ne sont plus trop utilisés quand on règle l'encodage. On utilise plutôt un niveau de qualité qui vise à peu près un bitrate (VBR), mais si l'encodeur juge qu'il a besoin de beaucoup de données pour stocker une frame audio, il en prendra un peu plus. Inversement, s'il juge qu'il peut économiser du bitrate, il le fera.
L'encodage à bitrate constant n'est plus utilisé que pour le streaming et même Apple utilise du VBR pour ses fichiers encodés en AAC.

En résumé, même un bitrate moyen ne suffit pas pour juger la qualité, avec un codec moderne. Ca permet juste d'avoir une vague idée de si c'est écoutable ou pas suivant une échelle de références, mais ça reste une indication et pas un fait. Et l'encodeur utilisé joue beaucoup aussi. Les MP3s encodés vers 2001 ou 2002 sont désormais à peine écoutable, par exemple.

Il faut différencier les différents types de test, qui n'ont pas la même valeur scientifique :
- AB, test en sachant quel est l'échantillon a et quel et le B. Aucune valeur scientifique, le royaume de l'idiophile, des enceintes chaudes et du vinyl chaleureux. Si vous testez casque dans le magasin, vous le faites.
- ABX. Test en aveugle, sans savoir si on écoute l'échantillon A ou B. Valide scientifiquement si on fait suffisamment d'essais en aveugle.
- ABC/HR, assez proche de l'ABX où en plus on note la qualité de l'échantillon. Souvent utilisé avec des samples de sons problématiques sur les encodeurs. C'est valide scientifiquement également, et la qualité du test dépend du nombre de tentatives.
Il existe donc de vraies méthodologies, pas spécifiques à l'audio qui permettent de connaître avec certitude la qualité d'un codec, pour peu qu'on ait assez de participants avec une bonne oreille. A noter que la qualité du matos utilisé pour faire le test ne joue pas plus que ça. Du mauvais matos peut permettre de mieux percevoir certains défauts et du meilleur matos peut aider à en percevoir d'autres.

wikipedia: AB
Hydrogenaudio: ABX
Hydrogenaudio: ABC/HR

Juste pour rappel, une substance bien plus addictive est dans notre consommation courante, donc une affection préliminaire (pré-diabète) affecte environ 30% de la population américaine, et à peu près autant de la population française, et représente un aussi au moins gros problème de santé publique. Oui, je parle du sucre. Essayez juste une semaine sans, et vous verrez, les envies de sucre n'ont rien à envier à l'alcool.

Maintenant, est-ce qu'on devrait conseiller au gens de boire des boissons sucrées plutôt que de l'alcool ? Ah cette morale, quand on parle de drogue, en ignorant que beaucoup de ce qu'on mange provoque des addictions. Et si on parlait aussi de la caféine, donc l'arrêt brutal provoque quand on en consomme beaucoup de violent maux de tête, pendant des semaines. Et tant d'autres substances. Est-il vraiment nécessaire de continuer ?

Maintenant qu'on est dans le domaine de la science et plus de la morale, peut-on commencer à réfléchir raisonnablement et à accepter notre culture et ses travers ?

N'oubliez pas d'indiquer le type de levures dans les ingrédients. Juste levure, c'est extrêmement vague.

Ou des sous-marins sous Windows…

Je ne connaissais pas Raptor Engineering, mais j'avoue être perplexe sur le papier de cette boîte. C'est juste un papier corporate qui glorifie cette entreprise, non ? Alors autant, je suis tout à faire convaincu de l'importance de coreboot et c'est bien qu'une entreprise mais était-ce bien nécessaire de récupérer cette publicité pour Raptor Engineering ? D'autant plus qu'aucune solution concrète, achetable réellement n'est évoquée dans cette dépêche.

Je ne trouve pas cette publi-information pertinente.

Et 35 requêtes sont bloquées sur le simple affichage de la page d'accueil. Je n'ai jamais vu un truc pareil.
Le site a probablement été infecté récemment et/ou alors affiche du malvertising.

Votre besoin ressemble à ce soft sur framalibre . Mais sinon, un pauvre classeur sur framacalc (site officiel d'inventaire) ou sur une instance perso peut faire l'affaire aussi.

J'utilise au taf un model M qui a à peu près cette tronche, mais en version azerty et tous les marquages en français :)
Trouvé dans la rue à Paris. Magique.

En précommande (expédition en mars 2017) depuis l'Europe, et testé par personne à par ses créateurs. Un peu difficile à recommander.
J'avoue que je l'ai quand même précommandé depuis un an avec des Cherry MX clear, l'accessoire trackball et le groupe de trois touches en plus :D

Faut pas que je poste quand je suis malade. 75% de hors-sujet. Je sors…

Je pense que le principal souci est que cette techno recrée le même problème qui a provoqué la naissance du pagerank de Google : les sites qui trichaient avec leurs keywords et leur contenu. Ça part du principe que les sites sont sincères. Et ça part aussi du principe, clairement obsolète, que les métadonnées fournies par le site sont suffisantes pour mesurer la pertinence et la qualité d'un site.
Le principe même de la SEO, quelle que soit l'époque, c'est soit de mentir (dans le pire des cas) soit de customiser le site pour plus ressortir que les autres. Et même regarder le contenu même des pages est à peine suffisant pour en déduire la qualité, d'où l'ancien système pagerank avec le compte du nombre de liens hypertextes existants vers la page. Et inversement dans un cas de non optimisation des métadonnées, un site excellent pourrait aussi être ignoré par l'index d'un tel moteur de recherche.

Alors non, la main-mise de Google n'est pas une bonne chose, mais cette techno n'est en aucun cas une solution.