BFG a écrit 904 commentaires

(et encore heureux, sinon on perd une partie de l'interêt du chiffrement par fichier)

Entièrement d'accord. Et justement, ZFS implémente-t-il la déduplication malgré son chiffrement par fichiers ? (je ne parle pas d'encfs ici)

En effet, c'est impossible.

Oui, encfs se place après le système de fichiers. Il stocke les fichiers chiffrés sur le système sous-jacent (ZFS, extfs, etc.) et les chiffre/déchiffre à la volée (sans jamais stocker la version déchiffrée). C'est une surcouche avec FUSE.
Le problème qui se pose alors est sa performance, FUSE n'étant, il me semble, pas réputé pour sa grande vitesse.

En effet, je n'avais pas compris qu'avec ZFS il était possible de n'avoir pas le systèmes de fichiers chiffré mais uniquement le contenu des fichiers. LUKS se place en effet avant le système de fichiers.

LUKS ne fonctionne pas que sur les disques, il fonctionne même sur les fichiers.

Il suffit de colle et chemise. Maintenant il m'ajoute même "collection" automatiquement…

Oui, il y avait d'autres mots, et alors ? "Induit en erreur" ? Si je demande à rechercher quelque chose, ce n'est pas pour qu'il l'ignore et n'en fasse qu'à sa tête !

Je n'ai plus d'exemple en tête. Par contre, il se permet de corriger des soi-disant fautes qui n'en sont pas. Je cherchais "colle", et il m'a annoncé fièrement avoir trouvé des résultats contenant "col".

Cette assistance de google est bien souvent contre-productive pour ma part. Google remplace automatiquement les mots que j'utilise par des synonymes, mais les synonymes qu'il choisit ont un double-sens, donc les résultats sont pollués par des pages qui n'ont plus rien à voir avec ce que je cherchais.

Alors c'est un bug que vous devez signaler, car ça ne suit pas la norme des shells POSIX comme j'ai posté plus haut. Par ailleurs, mon bash 4.2.45 n'a pas ce comportement.

Dans zsh, ls grep ne donne pas du tout la même chose, puisque le grep n'est pas remplacé par son alias à l'exécution.

C'est la même chose dans bash (et tous les autres).

Un alias n'est évalué que si la commande commence par cet alias, pas s'il est au milieu :

% alias foo=bar
% ls foo
ls: impossible d'accéder à foo: Aucun fichier ou dossier de ce type

En revanche, zsh permet d'évaluer certains alias n'importe où dans une commande, en les déclarant avec alias -g (pour global).

C'est très désagréable avec Google notamment, ils doivent générer des certificats à la volée, et l'on a des alertes en permanence. J'ai fini par désactiver l'extension.

La page du wiki attend vos contributions.

La description donnée du livre donne l'impression qu'il cherche à placer le plus de sujets provocants possible, et à paraître le plus moderne possible (avec ses hashtags par exemple), la description ne parlant de rien d'autre. Si quelqu'un l'a lu, y a-t-il quelque chose d'intéressant à part ça ?

Pour les jeux rapides en ligne, la latence est tellement importante que l'on peut se permettre de perdre des paquets : un paquet arrivant trop tard est un paquet de toute manière sans intérêt, le renvoi de paquets (que font TCP et QUIC) n'est donc pas souhaité.
Voir ces deux articles.

pourquoi trackable?

Parce que Javascript peut servir à tester la présence de fonctionnalités comme WebRTC (installé par défaut, donc son absence est rare), ou bien la liste des polices installées. Ces caractéristiques en apparence anodine peuvent donner une combinaison relativement unique, donc facile à surveiller. Le User-Agent est déjà particulièrement fourni en détails qui n'apportent rien à part de la traçabilité.

Attention, dans votre premier collage de code, vous écrivez 4096 fois le même caractère.
Voici à quoi ça aurait ressemblé avec islice :

import itertools

iter_gen = gen()
while True:
    block = ''.join(itertools.islice(iter_gen, 4096))
    if not block:
        break
    f.write(block)

Si votre générateur retourne un seul caractère à la fois, alors chaque caractère sera écrit, ce qui est lent. À l'inverse, la seconde méthode lit tous les caractères à la fois, comme si le générateur avait retourné tous les caractères à la fois, et écrit en une seule passe.

Vous pouvez avoir les avantages des deux méthodes en faisant une solution intermédiaire (entre "écrire 1 caractère" et "écrire tous les caractères") des 2 méthodes.
Vous pouvez modifier le générateur pour qu'il retourne plusieurs caractères à la fois, par exemple 2 caractères, ou 10, ou encore 4096 (n'hésitez pas à utiliser un bloc de plusieurs kilos, les systèmes de fichiers fonctionnent de toute manière par blocs, à plus forte raison sur les SSD).
Si vous ne pouvez pas modifier le générateur, vous pouvez quand même utiliser une variable "out" qui va accumuler 4096 caractères du générateur, et les écrire par paquets de 4096. Aussi, cette fonction pourra vous être utile.

Non. D'abord, incrémental et différentiel sont deux choses indépendantes. La sauvegarde incrémentale permet de conserver l'historique des sauvegardes. La sauvegarde différentielle permet de ne transférer que ce qui a été modifié depuis la précédente sauvegarde.
Partons du principe où l'on ne fait pas confiance à la destination (qui était la première partie de mon message précédent).

Si l'on utilise LUKS, la partition est un énorme fichier chiffré. Mais modifier un seul fichier à l'intérieur de la partition ne modifie qu'une petite partie du fichier partition chiffré, ce qui permet de profiter du différentiel (nul besoin de re-transférer la partition totale à chaque fois). Le différentiel est même un prérequis, vu la taille probable de la partition. L'incrémental est possible, si l'outil gère ses versions grâce à des deltas, là encore à cause de la taille de la partitions.

Si l'on utilise encfs, chaque fichier est chiffré séparément. On peut faire de l'incrémental sans avoir besoin du différentiel ici, même si l'on peut en profiter. Le différentiel est également possible car modifier une partie d'un fichier en clair ne modifie qu'une partie du fichier chiffré (si le fichier était chiffré avec gpg, ce ne serait pas vrai). L'article encfs explique le fonctionnement et ce qu'il faut sauvegarder.

Notez que pour LUKS, si l'historique est conservé, ce sera un historique des "images disques", et non un historique "par fichier".

Si votre partition est chiffrée avec LUKS, TrueCrypt ou autre méthode qui chiffre au niveau de la partition, vous pouvez simplement sauvegarder l'imposant fichier représentant la partition. Il vous faut absolument utiliser un outil de sauvegarde qui peut n'envoyer qu'un delta pour un gros fichier.
Si vos données sont chiffrées avec un outil tel qu'encfs, donc au niveau des fichiers, alors la structure de dossiers et fichiers est conservée, mais leurs noms et contenus sont chiffrés. Dans ce cas, vous devriez utiliser un outil qui sauvegarde tout un arbre de fichiers, et la sauvegarde peut aussi n'envoyer que des deltas pour chaque fichier, mais ce point n'est pas essentiel ici, à moins que vous n’ayez de gros fichiers.
À noter qu'il est aussi possible de chiffrer à la volée avec encfs, pour utiliser un outil de sauvegarde qui convient mieux avec encfs, même si votre partition est chiffrée avec un outil tel que LUKS.

Pour ce que j'utilise personnellement : partitions sources et destinations chiffrées avec LUKS, toutes les deux montées au moment de la sauvegarde (car je fais confiance à la destination), et rdiff-backup pour effectuer la sauvegarde (incrémentale).

Le verbe existe et n'est pas un anglicisme, même s'il en a tout l'air.

EncFS possède un mode "inverse" (option -r), où au lieu d'avoir un montage déchiffrant un dossier chiffré, on a un montage chiffrant un dossier en clair.

Il faut donc avoir lu tous les journaux précédents quand on arrive sur LinuxFR avant d'avoir le droit de poser une question ?

En fait, quand j'avais besoin de ce genre de chose c'était pour faire du rsync, et là ça ne marche plus (il faut tout rapatrier en local et on perd l'intérêt de l'incrémental)

Que voulez-vous dire exactement ? rsync n'est pas incrémental. Si un fichier est chiffré, la modification d'un seul octet modifie tout le fichier, ce qui empêche de n'envoyer qu'un "diff".