FreeDesktop permet de définir des standards de formats, d'opérations, etc. Il n'est nul besoin de réutiliser l'implémentation de KDE, il suffit d'écrire une nouvelle implémentation avec les bibliothèques que vous voulez, du moment que votre implémentation est compatible et interopérable. Considérez par exemple le standard de gestion de la corbeille, ou le standard de gestion des vignettes de fichiers.
Monter les 2 volumes TrueCrypt N-1 et N, puis faire un rsync entre les 2 points de montage ? Vous avez raison, c'est une meilleure idée, car dans le meilleur des cas (où aucune donnée n'a changé), seuls les parties contenant les métadonnées seront relues, et non pas les volumes entiers.
Existe-t-il une solution efficace pour faire des sauvegarde différentielle d'1 machine locale qu'on contrôle et en laquelle on a confiance (fichiers ou volumes chiffrés, local protégé, etc...), vers une machine hébergée chez un prestataire externe (internet) auquel on ne veut pas confier de secrets ?
Une solution que j'imagine (si il n'y a pas de postes sous Haiku/Windaube) :
Utiliser localement EncFS sur son serveur de fichier (GNU/Linux/BSD,OSX) et envoyer sur le serveur distant uniquement les fichiers modifiés depuis la dernière sauvegarde.
Tout à fait. Il existe même un mode inversé de encfs (--reverse) permettant, non pas de stocker les fichiers chiffrés, et avoir des fichiers en clairs "virtuels", mais de stocker les fichiers en clair, et d'avoir les fichiers chiffrés "virtuels" (pour ne payer le coût d'encfs qu'au moment de faire une sauvegarde distante, si l'on a confiance en la machine locale, par exemple si l'on chiffre déjà l'ensemble du disque).
Pour référence, ajoutons rdiff-backup comme alternative à rsync (car il ajoute la conservation des versions précédentes des fichiers, avec la possibilité de jeter ce qui est ancien (contrairement aux sauvegardes basées sur git))
Si il y a des postes ne gérant pas EncFS, il faut travailler sur des fichiers en clair (ou stockés en truecrypt), puis avant de faire la sauvegarde chiffrer chaque fichier individuellement...
Si l'on travaille avec des fichiers en clair (ou avec les fichiers en clair "virtuels"), on peut utiliser duplicity qui ne nécessite pas FUSE, mais je n'ai aucune idée de sa portabilité. Je ne l'ai jamais utilisé, mais voici comment il se décrit :
Duplicity backs directories by producing encrypted tar-format volumes and uploading them to a remote or local file server. Because duplicity uses librsync, the incremental archives are space efficient and only record the parts of files that have changed since the last backup. Because duplicity uses GnuPG to encrypt and/or sign these archives, they will be safe from spying and/or modification by the server.
Une autre solution (peut-être) : calculer localement les différences entre les sauvegardes N et N-1, puis ne transmettre que le patch (qui sera, éventuellement, appliqué sur la sauvegarde N-1 distante) ?
(Si vous parlez d'un seul fichier comme avec LUKS/TrueCrypt) Comme le fait rsync ? Pour référence, l'outil rdiff permet de faire manuellement les mêmes étapes que rsync (générer une signature du fichier N-1, générer un delta à partir du fichier N et de la signature N-1, puis appliquer le patch au fichier N-1, ce qui est dommage est qu'il n'a pas le --inplace de rsync).
Je ne peux qu'abonder dans ce sens, les chiffrements de type LUKS/TrueCrypt sont très mauvais s'il s'agit de les copier/synchroniser (certains utilisent ce type de chiffrement avec des logiciels comme DropBox, c'est profondément inefficace...).
À noter que EncFS ne fonctionne pas que sous Linux mais aussi FreeBSD et MacOSX (mais pas Haiku ni Windows).
rsync c'est que c'est surtout intéressant pour les transferts réseau entre 2 machines
- la machine qui envoie les données, lit son fichier, calcul une somme de contrôle sur un bloc de données
- cette somme est envoyée à l'autre machine qui va lire le même bloc de données de son côté, calculer la somme de contrôle et la comparer avec celle qui a été reçue
- si les 2 sommes de contrôle sont différentes, ce bloc du fichier est donc différent, il est donc transféré, sinon on passe au bloc de données suivant
C'est presque ça. Pour étaler ma culture : c'est la machine qui reçoit qui calcule la somme de contrôle de ses blocs ({[0;N[, [N;2*N[, [2*N;3*N[, ...}), et transmet cette liste à la machine qui envoie. Celle qui envoie cherche des endroits (à chaque octet, et non pas uniquement aux octets {0, N, 2*N, ...}, ce qui permet de gérer efficacement le cas où un octet aurait été inséré au début d'un fichier) où l'on a N octets consécutifs qui donneraient une des sommes de contrôles trouvées. Ensuite, est transmis des instructions pouvant être une suite d'octets à écrire littéralement, ou bien l'écriture d'un des blocs qui existe déjà du côté récepteur. (voir Rsync#Algorithme)
mais je crois bien qu'avec un fichier chiffré, le moindre octet modifié fait que l'ensemble du fichier est différent, ce qui rend l'option de copie différentielle encore moins intéressante qu'une copie intégrale
Pour du chiffrement de fichiers qui ne changent pas aussi souvent qu'un disque ou de petits fichiers, vous avez raison. On s'arrange (avec CBC par exemple) pour qu'un bloc chiffré ne ressemble pas à un autre même si son texte clair est identique (exemple imagé).
En revanche, pour le chiffrement d'un disque, c'est impraticable : imaginez si changer le premier octet de votre disque de 500 Go vous forçait à réécrire 500 Go ! On a par contre une technique pour au moins empêcher que 2 blocs clairs identiques ne soient aussi identiques une fois chiffrés. Pour cela, on ajoute au chiffrement une donnée qui dépend de la position (pour être précis, on réinitialise CBC (ou autre mode) à chaque secteur disque, avec un vecteur d'initialisation qui dépend de la position) (Voir également en:Disk_encryption_theory)
si tu fais un rsync entre 2 répertoires d'une même machine, tu es tout de même obligé de lire les 2 fichiers pour faire la comparaison avant d'écrire, ça n'est intéressant que si la lecture est nettement plus rapide que l'écriture (ou dans ton cas pour épargner tes cellules de flash)
Effectivement, rsync fait plus de travail qu'il n'est nécessaire (chercher à faire correspondre un bloc à une position à une autre position notamment, alors qu'il est impossible qu'un bloc chiffré se retrouve ailleurs identique). Si la lecture est vraiment plus rapide ou vraiment plus économique (sans doute pour une clef USB), alors un outil qui se contente de comparer les octets 1 à 1 (ou par secteurs) et réécrire uniquement ceux qui sont différents est ce qu'il faut. Sinon, "cp" (ou dd) est l'outil qu'il vous faut.
En théorie, c'est plus facile. Le noyau sait très bien faire cela, mais c'est moins plaisant de configurer SELinux ou d'écrire des modules pour le noyau que configurer un interpréteur Javascript.
En pratique, ce n'est pas fait, Android pourrait le faire avec son utilisation de Java, mais pourtant rien n'a été fait.
En attendant, on embarque de plus en plus de couches d'interprétation de langages (bientôt, un interpréteur écrit en Javascript d'un langage de plus haut-niveau), puis on ajoute encore plus de code pour embarquer des compilateurs dans le navigateur/environnement de bureau, puis on se demande bien comment on a pu en arriver là.
Vous n'avez pas compris. Qu'elle soit activée par défaut n'est pas ce qui est reproché. Ce qui l'est est que ce n'est même pas une option (quelle que soit sa valeur par défaut) : le seul moyen de la désactiver est d'installer quelque chose qui n'est même pas développé par l'équipe de GNOME (et qu'il est par ailleurs étrange de devoir installer plus de logiciels pour supprimer du logiciel).
Posté par BFG .
En réponse à la dépêche LLVM 3.0.
Évalué à 3.
J'aime aussi bien Scala, mais on peut vraiment écrire des choses incompréhensibles pour le commun des mortels, notamment en abusant le système de type.
On peut également faire la même chose en C++. Il vaut mieux laisser ce travail aux bibliothèques comme Loki, Boost.
Ce n'est pas forcément pour travailler sur ses projets personnels, mais par exemple si l'on n'a pas certains outils sur le lieu de travail alors qu'on les a déjà ailleurs (chez soi par exemple), et qu'on en a plus besoin plus vite que s'il fallait les installer sur le lieu de travail et ponctuellement.
Si tous les ports non-HTTP sont bloqués, comment ira-t-on trouver de l'aide sur (par exemple) IRC ou Jabber ?
Je n'utilise aucune option de complétion avancée, mais après un tour dans le manuel zshoptions, j'obtiens le comportement désiré après avoir exécuté unsetopt list_ambiguous (le nom est assez peu parlant, il faut reconnaitre).
Édition : et bien, il semblerait que quelqu'un a déjà trouvé.
Oui enfin si on a pas tout le code (et une manière de le savoir c'est de pouvoir compiler soi même) l'intérêt reste limité même pour ne faire qu'étudier le code.
On vous tend la main, vous prenez le bras ! Non seulement ce n'est qu'une supposition car vous n'avez même pas regardé quel code était accessible (vous n'avez qu'à lire les pages de leur site), mais en plus je ne vois pas en quoi cela vous empêche d'étudier ce à quoi vous avez accès.
Je ne pense pas qu'ils vont changer d'avis maintenant. Vous pensez qu'ils ont mis les sources accessibles pour ce Humble Bundle, mais ce n'est pas le cas, car cela fait des années qu'ils vendent le code source sous les mêmes conditions qu'aujourd'hui, voir la page d'Uplink en 2005 (qui n'a pas changé), et la page Darwinia+Multiwinia en 2010. La seule chose qui a changé est l'accès aux sources de DEFCON.
Avant, on lisait la notice imprimée qui était livrée avec le matériel (et l'on discutait de vive voix avec des personnes qui avaient déjà fait l'opération).
Sur la commande 'status', je suis pollué par le code html retourné par le serveur, j'aurais juste aimé n'avoir que ma trace "Freebox Wifi is XX". 'option curl --silent n'y fait rien. Des idées ?
Il faut utiliser curl -o /dev/null --silent (-o /dev/null enregistre la réponse du serveur dans /dev/null, et --silent désactive les informations comme la barre de progression).
bash est aussi une extension au shell POSIX, on a pour preuve les scripts d'initialisation écrits pour bash mais déclarés pour sh qui ne peuvent pas s'exécuter sur un autre shell POSIX (comme "dash" chez Debian).
zsh a lui aussi des extensions, la différence est qu'il a des années d'avance sur bash, et que ses utilisateurs savent qu'écrire "!#/bin/sh" signifie "ne pas tester le script uniquement avec zsh, mais avec un shell purement POSIX", contrairement à la majorité des utilisateurs de bash.
Le fait que le format des messages soit tout à fait libre et sans conventions rend le parsing impossible.
On va commencer par imposer format minimal et strict, puis on se rendra compte que ce n'est pas suffisant, alors on autorisera des extensions diverses pour chaque application, et le problème sera le même qu'avant. Je propose qu'on appelle ça... "XML" !
L'article en question est déjà une forme de publicité pour les appareils dont il parle... Enfin, personnellement, je n'aime pas beaucoup ce genre d'articles sur DLFP.
À condition qu'il y ait action en justice : si ça arrange une entreprise qu'on parle d'elle, elle laissera faire. Ce qui a changé, c'est qu'on ne pourra plus en parler si ça ne l'arrange pas.
Vous avez raison, j'ai déjà eu un problème avec ça il y a un moment, et je croyais avoir déduit que le propriétaire du dossier ne pouvait plus supprimer ses fichiers avec le sticky bit, mais il semblerait que c'est faux.
[^] # Re: GNOME
Posté par BFG . En réponse au journal Yet Another GnOme Flameware (YAGOF). Évalué à 2.
FreeDesktop permet de définir des standards de formats, d'opérations, etc. Il n'est nul besoin de réutiliser l'implémentation de KDE, il suffit d'écrire une nouvelle implémentation avec les bibliothèques que vous voulez, du moment que votre implémentation est compatible et interopérable. Considérez par exemple le standard de gestion de la corbeille, ou le standard de gestion des vignettes de fichiers.
[^] # Re: encfs
Posté par BFG . En réponse au message Logiciel de mise à jour de fichier. Évalué à 2.
Monter les 2 volumes TrueCrypt N-1 et N, puis faire un rsync entre les 2 points de montage ? Vous avez raison, c'est une meilleure idée, car dans le meilleur des cas (où aucune donnée n'a changé), seuls les parties contenant les métadonnées seront relues, et non pas les volumes entiers.
[^] # Re: diff
Posté par BFG . En réponse au message Logiciel de mise à jour de fichier. Évalué à 2.
Tout à fait. Il existe même un mode inversé de encfs (--reverse) permettant, non pas de stocker les fichiers chiffrés, et avoir des fichiers en clairs "virtuels", mais de stocker les fichiers en clair, et d'avoir les fichiers chiffrés "virtuels" (pour ne payer le coût d'encfs qu'au moment de faire une sauvegarde distante, si l'on a confiance en la machine locale, par exemple si l'on chiffre déjà l'ensemble du disque).
Pour référence, ajoutons rdiff-backup comme alternative à rsync (car il ajoute la conservation des versions précédentes des fichiers, avec la possibilité de jeter ce qui est ancien (contrairement aux sauvegardes basées sur git))
Si l'on travaille avec des fichiers en clair (ou avec les fichiers en clair "virtuels"), on peut utiliser duplicity qui ne nécessite pas FUSE, mais je n'ai aucune idée de sa portabilité. Je ne l'ai jamais utilisé, mais voici comment il se décrit :
(Si vous parlez d'un seul fichier comme avec LUKS/TrueCrypt) Comme le fait rsync ? Pour référence, l'outil rdiff permet de faire manuellement les mêmes étapes que rsync (générer une signature du fichier N-1, générer un delta à partir du fichier N et de la signature N-1, puis appliquer le patch au fichier N-1, ce qui est dommage est qu'il n'a pas le --inplace de rsync).
[^] # Re: encfs
Posté par BFG . En réponse au message Logiciel de mise à jour de fichier. Évalué à 2.
Je ne peux qu'abonder dans ce sens, les chiffrements de type LUKS/TrueCrypt sont très mauvais s'il s'agit de les copier/synchroniser (certains utilisent ce type de chiffrement avec des logiciels comme DropBox, c'est profondément inefficace...).
À noter que EncFS ne fonctionne pas que sous Linux mais aussi FreeBSD et MacOSX (mais pas Haiku ni Windows).
[^] # Re: diff
Posté par BFG . En réponse au message Logiciel de mise à jour de fichier. Évalué à 3. Dernière modification le 03 décembre 2011 à 00:31.
C'est presque ça. Pour étaler ma culture : c'est la machine qui reçoit qui calcule la somme de contrôle de ses blocs ({[0;N[, [N;2*N[, [2*N;3*N[, ...}), et transmet cette liste à la machine qui envoie. Celle qui envoie cherche des endroits (à chaque octet, et non pas uniquement aux octets {0, N, 2*N, ...}, ce qui permet de gérer efficacement le cas où un octet aurait été inséré au début d'un fichier) où l'on a N octets consécutifs qui donneraient une des sommes de contrôles trouvées. Ensuite, est transmis des instructions pouvant être une suite d'octets à écrire littéralement, ou bien l'écriture d'un des blocs qui existe déjà du côté récepteur. (voir Rsync#Algorithme)
Pour du chiffrement de fichiers qui ne changent pas aussi souvent qu'un disque ou de petits fichiers, vous avez raison. On s'arrange (avec CBC par exemple) pour qu'un bloc chiffré ne ressemble pas à un autre même si son texte clair est identique (exemple imagé).
En revanche, pour le chiffrement d'un disque, c'est impraticable : imaginez si changer le premier octet de votre disque de 500 Go vous forçait à réécrire 500 Go ! On a par contre une technique pour au moins empêcher que 2 blocs clairs identiques ne soient aussi identiques une fois chiffrés. Pour cela, on ajoute au chiffrement une donnée qui dépend de la position (pour être précis, on réinitialise CBC (ou autre mode) à chaque secteur disque, avec un vecteur d'initialisation qui dépend de la position) (Voir également en:Disk_encryption_theory)
Effectivement, rsync fait plus de travail qu'il n'est nécessaire (chercher à faire correspondre un bloc à une position à une autre position notamment, alors qu'il est impossible qu'un bloc chiffré se retrouve ailleurs identique). Si la lecture est vraiment plus rapide ou vraiment plus économique (sans doute pour une clef USB), alors un outil qui se contente de comparer les octets 1 à 1 (ou par secteurs) et réécrire uniquement ceux qui sont différents est ce qu'il faut. Sinon, "cp" (ou dd) est l'outil qu'il vous faut.
[^] # Re: Mon septicimse...
Posté par BFG . En réponse au journal Un site d'extensions pour GNOME-shell. Évalué à 5.
En théorie, c'est plus facile. Le noyau sait très bien faire cela, mais c'est moins plaisant de configurer SELinux ou d'écrire des modules pour le noyau que configurer un interpréteur Javascript.
En pratique, ce n'est pas fait, Android pourrait le faire avec son utilisation de Java, mais pourtant rien n'a été fait.
En attendant, on embarque de plus en plus de couches d'interprétation de langages (bientôt, un interpréteur écrit en Javascript d'un langage de plus haut-niveau), puis on ajoute encore plus de code pour embarquer des compilateurs dans le navigateur/environnement de bureau, puis on se demande bien comment on a pu en arriver là.
[^] # Re: Trolledi indeed
Posté par BFG . En réponse au journal Un site d'extensions pour GNOME-shell. Évalué à 7.
Vous n'avez pas compris. Qu'elle soit activée par défaut n'est pas ce qui est reproché. Ce qui l'est est que ce n'est même pas une option (quelle que soit sa valeur par défaut) : le seul moyen de la désactiver est d'installer quelque chose qui n'est même pas développé par l'équipe de GNOME (et qu'il est par ailleurs étrange de devoir installer plus de logiciels pour supprimer du logiciel).
[^] # Re: Tart
Posté par BFG . En réponse à la dépêche LLVM 3.0. Évalué à 3.
On peut également faire la même chose en C++. Il vaut mieux laisser ce travail aux bibliothèques comme Loki, Boost.
[^] # Re: réseau social libre
Posté par BFG . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 1.
OTR doit être utilisé avec attention, car des modules de serveurs XMPP savent déjà se mettre au milieu.
[^] # Re: Ouai enfin bon....
Posté par BFG . En réponse à la dépêche sslh 1.10, la bête noire des censeurs. Évalué à 9.
Ce n'est pas forcément pour travailler sur ses projets personnels, mais par exemple si l'on n'a pas certains outils sur le lieu de travail alors qu'on les a déjà ailleurs (chez soi par exemple), et qu'on en a plus besoin plus vite que s'il fallait les installer sur le lieu de travail et ponctuellement.
Si tous les ports non-HTTP sont bloqués, comment ira-t-on trouver de l'aide sur (par exemple) IRC ou Jabber ?
# Niveau de langage
Posté par BFG . En réponse à la dépêche Entretien avec Goffi, développeur de SàT client de messagerie instantanée libre. Évalué à 5.
C'est proprement ridicule d'écrire ça, même à l'oral personne n'utiliserait ce genre de formule...
[^] # Re: Madame/Mademoiselle, Mon avis...
Posté par BFG . En réponse au journal De l'utilisation contemporaine des titres honorifiques.. Évalué à 0. Dernière modification le 30 novembre 2011 à 23:20.
Il l'a dit lui-même :
... car en 2011, les hommes ne changent pas de nom quand ils se marient, contrairement aux femmes.
# zshoptions(1)
Posté par BFG . En réponse au message [Résolu] zsh: suggestion automatique dès qu'il y a ambiguïté. Évalué à 3. Dernière modification le 30 novembre 2011 à 23:02.
Je n'utilise aucune option de complétion avancée, mais après un tour dans le manuel
zshoptions, j'obtiens le comportement désiré après avoir exécutéunsetopt list_ambiguous(le nom est assez peu parlant, il faut reconnaitre).Édition : et bien, il semblerait que quelqu'un a déjà trouvé.
[^] # Re: Non libre
Posté par BFG . En réponse au journal The Humble Introversion Bundle - les niveaux bonus pour développeur.. Évalué à 0.
On vous tend la main, vous prenez le bras ! Non seulement ce n'est qu'une supposition car vous n'avez même pas regardé quel code était accessible (vous n'avez qu'à lire les pages de leur site), mais en plus je ne vois pas en quoi cela vous empêche d'étudier ce à quoi vous avez accès.
[^] # Re: Non libre
Posté par BFG . En réponse au journal The Humble Introversion Bundle - les niveaux bonus pour développeur.. Évalué à 1.
Je ne pense pas qu'ils vont changer d'avis maintenant. Vous pensez qu'ils ont mis les sources accessibles pour ce Humble Bundle, mais ce n'est pas le cas, car cela fait des années qu'ils vendent le code source sous les mêmes conditions qu'aujourd'hui, voir la page d'Uplink en 2005 (qui n'a pas changé), et la page Darwinia+Multiwinia en 2010. La seule chose qui a changé est l'accès aux sources de DEFCON.
[^] # Re: Non libre
Posté par BFG . En réponse au journal The Humble Introversion Bundle - les niveaux bonus pour développeur.. Évalué à 1.
Vous ne semblez pas comprendre, tout cela n'est pas important puisque la seule chose importante (pour certains) est la possibilité d'étudier le code.
[^] # Re: Non libre
Posté par BFG . En réponse au journal The Humble Introversion Bundle - les niveaux bonus pour développeur.. Évalué à 3.
On peut déjà accéder au code source de Windows de manière non illégale, n'est ce pas suffisant pour vous ?
[^] # Re: Mains dans le cambouis sans crainte!
Posté par BFG . En réponse au journal Obsolescence et vieux matos. Évalué à 6.
Avant, on lisait la notice imprimée qui était livrée avec le matériel (et l'on discutait de vive voix avec des personnes qui avaient déjà fait l'opération).
# curl -o
Posté par BFG . En réponse au message Activer/désactiver le Wifi d'une Freebox V6 depuis le réseau local. Évalué à 3.
Il faut utiliser
curl -o /dev/null --silent(-o /dev/null enregistre la réponse du serveur dans /dev/null, et --silent désactive les informations comme la barre de progression).[^] # Re: Et après ?
Posté par BFG . En réponse au journal Lennart casse les logs!. Évalué à 4.
bash est aussi une extension au shell POSIX, on a pour preuve les scripts d'initialisation écrits pour bash mais déclarés pour sh qui ne peuvent pas s'exécuter sur un autre shell POSIX (comme "dash" chez Debian).
zsh a lui aussi des extensions, la différence est qu'il a des années d'avance sur bash, et que ses utilisateurs savent qu'écrire "!#/bin/sh" signifie "ne pas tester le script uniquement avec zsh, mais avec un shell purement POSIX", contrairement à la majorité des utilisateurs de bash.
[^] # Re: Problèmes de Syslog
Posté par BFG . En réponse au journal Lennart casse les logs!. Évalué à 9.
On va commencer par imposer format minimal et strict, puis on se rendra compte que ce n'est pas suffisant, alors on autorisera des extensions diverses pour chaque application, et le problème sera le même qu'avant. Je propose qu'on appelle ça... "XML" !
[^] # Re: Lifestyle !
Posté par BFG . En réponse à la dépêche Android lifestyle ?. Évalué à 4.
L'article en question est déjà une forme de publicité pour les appareils dont il parle... Enfin, personnellement, je n'aime pas beaucoup ce genre d'articles sur DLFP.
[^] # Re: Ce n'est pas forcément négatif
Posté par BFG . En réponse au journal Secret défense étendu au entreprise ?. Évalué à 7.
À condition qu'il y ait action en justice : si ça arrange une entreprise qu'on parle d'elle, elle laissera faire. Ce qui a changé, c'est qu'on ne pourra plus en parler si ça ne l'arrange pas.
[^] # Re: Super merci.
Posté par BFG . En réponse au journal Barnes & Noble résiste à M$. Évalué à -1.
Bien étrange en effet, d'autant plus que personne n'a tenu ce raisonnement.
[^] # Re: Dossier `drop`
Posté par BFG . En réponse au journal De la bonne façon d'échanger ses fichiers dans un serveur.... Évalué à 1.
Vous avez raison, j'ai déjà eu un problème avec ça il y a un moment, et je croyais avoir déduit que le propriétaire du dossier ne pouvait plus supprimer ses fichiers avec le sticky bit, mais il semblerait que c'est faux.