BFG a écrit 901 commentaires

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).

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.

OTR doit être utilisé avec attention, car des modules de serveurs XMPP savent déjà se mettre au milieu.

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 ?

LinuxFR.org : T'es qui toi ?

LinuxFR.org : C'est quoi SàT ?

C'est proprement ridicule d'écrire ça, même à l'oral personne n'utiliserait ce genre de formule...

Il l'a dit lui-même :

et donc savoir que le nom n'est probablement pas le nom de jeune fille.

... car en 2011, les hommes ne changent pas de nom quand ils se marient, contrairement aux femmes.

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.

Est-ce que l'on peut prendre les sources, les compiler soi-même et arriver à un OS complet ?

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.

On peut déjà accéder au code source de Windows de manière non illégale, n'est ce pas suffisant pour vous ?

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" !

La pub ? Beurk...

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.

Bien étrange en effet, d'autant plus que personne n'a tenu ce raisonnement.

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.

À condition de mettre le "sticky bit" sur le dossier, sinon les autres utilisateurs peuvent écraser les fichiers que Alice aura déposé.

Avec cette solution, Ève pourra remplir le dossier ~bob/drop que Bob ne pourra plus supprimer !

Et bien le mien (Samsung Galaxy premier du nom) a Android 1.5 et pas de mise à jour disponible.