BFG a écrit 904 commentaires

Pour s'en convaincre, on peut comparer les différentes sorties :

echo "konqueror --profiles" | xxd

Je vais faire un peu de publicité non-dissimulée, l'outil en ligne de commande univisible affiche quels points de code constituent une chaine :

% univisible -i << EOF
еріс
epic
EOF
е (U+0435): CYRILLIC SMALL LETTER IE
р (U+0440): CYRILLIC SMALL LETTER ER
і (U+0456): CYRILLIC SMALL LETTER BYELORUSSIAN-UKRAINIAN I
с (U+0441): CYRILLIC SMALL LETTER ES

 (U+000A)
e (U+0065): LATIN SMALL LETTER E
p (U+0070): LATIN SMALL LETTER P
i (U+0069): LATIN SMALL LETTER I
c (U+0063): LATIN SMALL LETTER C

 (U+000A)

Doom III, c'est id Tech 4.

heu, ouais, je sais pas, 6 frames d'écart entre une action et le feedback visuel, perso je le remarque direct.

Personnellement, je ne compte pas le nombre d'images qui suivent chacun de mes clics !

100ms de lag perso je trouve ca énorme.

Tout dépend du contexte. Sur ma configuration, dans firefox, quand je clique sur "fichier > ouvrir", la boite de dialogue met, très très approximativement, une demie-seconde à afficher quelque chose d'exploitable. C'est très certainement lent, mais je ne le remarque même pas consciemment, pour de multiples raisons (liste non exhaustive) :

• je n'ai pas besoin de faire cette action à toute vitesse
• je pense (subjectif) qu'il peut y avoir beaucoup de fichiers, donc je tolère la lenteur
• je ne fais pas cette opération très souvent
• la fenêtre est très loin du menu, le temps d'y déplacer mon curseur, la fenêtre sera probablement chargée

Si c'était un lecteur vidéo, et que la vidéo ne se mettait en pause que 100 ms après que j'ai cliqué sur le bouton pause, je le remarquerai peut-être, mais ça ne me dérangerait pas outre mesure, mais ça serait la limite.
Si en revanche, le lecteur vidéo ralentissait pendant 100 ms ne serait-ce qu'une fois au milieu d'une vidéo, oui, ça serait dérangeant.

J'ai le temps de faire une requête réseau et récupérer la réponse dans ce délai, c'est pas exactement ce que j'appelle rapide.

Il n'est pas question de vitesse, mais de sensation de vitesse pour l'utilisateur.

Tout dépend s'il parle d'un lecteur vidéo, d'un délai pendant la lecture de la vidéo (ça se remarquera probablement), ou bien d'un traitement de texte, d'un délai entre le clic sur le bouton "ouvrir" et l'apparition de la fenêtre de sélection de fichiers (probablement invisible).

Il est impossible de sélectionner du texte sur le site car un javascript désélectionne tout dès qu'on arrête le clic, c'est fort dommage.

Comment garantir que la clé de X que le service m'a donné est bien la bonne?

Je ne sais pas quelle est la solution choisie par google, mais le plus simple me semblerait que quand on demande à l'annuaire d'ajouter une clef dans un premier temps, l'annuaire envoie un courrier chiffré à l'adresse donnée avec la clef publique associée dans un second temps.
L'insertion de la clef dans l'annuaire ne serait validée que si l'on est capable de recevoir le courrier et le déchiffrer. On le prouve en restituant ce contenu déchiffré à l'annuaire dans un troisième temps.

En regardant les captures d'écrans, cela ressemble beaucoup à Inkscape. Concrètement, qu'est ce qui le démarque de ce dernier ?

Je n'ai aucune idée de l'utilisation réelle qui en est faite, mais à première vue j'imagine que ça peut servir par exemple pour stocker la vignette d'une image/vidéo/autre document (si la vignette est perdue, ce n'est pas un problème, elle peut être re-générée).
Cela peut également faire office d'attributs étendus, par exemple pour des applications ayant besoin de suivre les mouvements de fichiers, comme des logiciels de sauvegarde.

le filesystem ne voyait que les quelques octets du fichier texte et le disque etait saturée à cause de la video qui n'apparaissait pas

Vous devez probablement parler des "Alternate Data Streams" d'NTFS.
Ces métadonnées sont des attributs du fichier, au niveau du système de fichiers, pas dans le fichier, elles ne sont donc pas transmises pendant un simple téléchargement.

Avec zsh, on peut tout simplement faire "tab" pour évaluer les expressions "!", ce qui est bien plus pratique qu'avec bash.

Notez aussi que tous les outils utilisant la libreadline bénéficient des mêmes raccourcis claviers, et que le fichier pour les configurer est ~/.inputrc.

Notez que cette fonctionnalité n'est en rien spécifique à bash puisqu'elle est standardisée POSIX, mais la façon standard de l'activer sur tous les interprètes est set -C

cédérom

"Cédérom" est très mauvais, je suis d'accord. Que j'ai donné ce lien ne signifie pas que c'est moi qui aie créé le site, ni que j'approuve tout ce qu'il dit, néanmoins je trouve le site intéressant et souvent pertinent, c'est tout.

bogue pour bug, ça vient d'où ?

"Bug" ("insecte") signifie "erreur" en anglais ?
Les traductions ne sont pas parfaites mais aucune langue n'est parfaite, la langue source des mots traduits sur ce site (l'anglais) n'y fait pas exception. Ce n'est pas une raison pour ne pas traduire les mots, et si besoin, en inventer.

"Bug" a plusieurs sens, le sens principal étant "insecte". En mettant de côté la raison phonétique, pourquoi "bogue" ne pourrait-il pas lui aussi avoir plusieurs sens ?

Comme pour tous les homonymes ?

Et bien c'est pareil en français, la personne fera la différence entre "cerveau" et "cerveau". Un français n'est pas plus idiot qu'un étasunien.

Un mot a de multiples définitions. La documentation du logiciel donne une définition de "neurone" car c'est un concept important dans le logiciel, et que, toujours dans le logiciel, le mot ne désigne pas une cellule vivante. Pour autant, cela reste un nom commun, pas une marque déposée. Même un mot nouveau peut être traduit.

Ce sont des mots clef du logiciels suffisamment importants pour avoir leur propre entrée dans la documentation du logiciel.

Qu'est ce que cela change ?
Avec ce raisonnement, on justifie d'utiliser le mot "thread" alors que "fil/fil d'exécution" convient parfaitement, car les fonctions permettant de les manipuler s'appellent "pthread_create", "CreateThread", "QThread", etc.

De la même façon, on justifie les mots "log", "merger" [sic], "liker" [sic].
Vous les prenez comme des noms propres car ils ne sont pas dans votre langue et vous ne vous les appropriez pas.

Parlez-vous de "logarithmorum", terme employé par Napier pour introduire ce que la plupart des français appellent communément "logarithme" ? Pourquoi traduire "logarithme", mais pas "thread" ou "neurone" ?

Une langue emprunte des mots à de nombreuses autres langues, mais dans l'informatique, la proportion est bien différente, et les mots viennent presque exclusivement de l'anglais.
C'est à mon avis un effet de mode, où les marques déposées sont adulées, et où les mots du domaine technologique font tendance.

Pour moi il ne s'agit pas de cerveau ou de neurone, mais de concepts qui sont appelés brain et neuron. Je ne traduit pas main ou include quand on parle de C.

Et pour un natif de la langue anglaise, comment fait-il la différence entre un "brain" qui a le sens de "cerveau", et un "brain" qui a un sens d'autre chose ?
Cette distinction que vous faites est arbitraire, et c'est la même qui sert à justifier tous les anglicismes. Elle n'a pas lieu d'être, il vaut mieux utiliser les traductions, qui au moins donnent une indication de ce que l'on veut dire.

que je ne croule pas exactement sous les billets.

Oui, je pense que cela doit être réparti, mais cela n'est pas à votre charge. Peut-être suggérez aux auteurs de solliciter un financement participatif sur une plateforme bien en vue ?
L'information pourrait ensuite être relayée sur LinuxFR, avec un journal ou simplement en suggérant une dépêche.

deux outils libres troués qui, en plus, ne me convenaient pas (inutilisables sous Windows).

D'autres ont été proposés, comme Cryfs, et qui semble avoir une bonne sécurité, et n'est donc pas "troué". J'ai bien noté qu'il ne fonctionnait pas Windows.
Puisque vous êtes prêt à payer, une solution potentielle serait de reporter l'argent que vous versez à Crashplan vers Cryfs, pour qu'ils fassent le portage sur Windows. Évidemment, le portage ne sera pas instantané, et cela ne vous convient donc probablement pas, mais sur le long terme ça pourrait être intéressant.

Moi, j'ai choisi de faire confiance à cette entreprise pour designer correctement leur système, parce qu'ils font un service à destination des professionnels, et probablement des gens qui savent ce qu'ils font en matière de sécurité.

Qu'en savez-vous ? Des entreprises embauchent des incompétents tous les jours, ou font des erreurs, comme tout un chacun, et comme les projets libres, il n'y a aucune différence là dessus.
La seule différence est que le projet libre a l’honnêteté d'être ouvert, ainsi on peut trier les bons projets libres des mauvais.

Vous choisissez de vous reposer sur un critère complètement orthogonal à la sécurité : la structure légale de l'équipe développeurs.
C'est votre choix, comme vous le dites, mais ne prétendez pas qu'il y a une quelconque corrélation entre ce critère et le critère de la sécurité.

Sauf que quand toutes les alternatives libres qui répondent à mes besoins ont des failles, j'ai pas d'autre choix que de me rabattre sur autre chose. Et si on exclut la paranoïa, je vois pas pourquoi faire confiance à une boîte qui a l'air sérieuse et a une bonne réputation serait forcément une erreur.

Je ne ferais pas confiance en un logiciel qui me cache ouvertement (oxymore amusant) des choses.
Certains projets libres ne vous conviennent pas du point de vue sécurité, peut-être, mais vous ignorez totalement si crashplan est bon de ce point de vue là, et si vous vouliez le savoir, vous ne le pourriez pas, parce qu'ils ont décidé de vous le cacher.

Moi, j'ai choisi de faire confiance à cette entreprise pour designer correctement leur système, parce qu'ils font un service à destination des professionnels, et probablement des gens qui savent ce qu'ils font en matière de sécurité. Entre un système revu en interne par un cryptographe et un système open source revu en externe et considéré comme troué, je vais faire confiance au premier, merci bien.

L'histoire regorge d'exemples d'entreprises peu scrupuleuses ou tout bonnement ignorantes, que ce soit à destination des particuliers ou des professionnels.
Vous faites confiance au costume qu'ils portent, pas à ce qu'ils sont réellement.

C'est la même chose avec les navigateurs. Regarde les deux seuls à peu près utilisables sur le marché sous Linux : Firefox et Chrome. Le premier n'a toujours pas de sandbox après des années, n'est même plus accepté à la Pwn2Own parce qu'ils le trouvent trop facile à attaquer, et rien ne va changer avant un bon paquet de mois/années encore de ce côté là. Donc je fais confiance à Chrome. C'est la même chose ici.

Il existe le projet Chromium qui repose sur la même base que Chrome, mais est libre et n'incorpore pas de composants non-libres.

Je sais bien qu'on est sur un site sur le libre, mais c'est pas une raison pour le considérer comme la réponse à tout.

Un logiciel libre peut être vérifié/audité par tous.

À l'inverse, un logiciel propriétaire ne repose que sur la confiance. Même si le logiciel propriétaire est audité, personne ne peut vérifier les dires de l'audit. Personne ne peut non plus vérifier que la version téléchargée est la même que la version auditée, puisqu'il est impossible de la recompiler. Personne ne peut vérifier ce que font les mises à jour du logiciel propriétaire, et dans quelle mesure les éventuels audits précédents sont toujours d'actualité.

Faut pas inverser l'argument en faisant du libre une preuve de sécurité supérieure.

Je ne dis pas cela, je dis que le critère "libre" est un critère minimum, obligatoire surtout quand on parle de logiciel concernant la sécurité.
Une fois qu'on l'a, on peut commencer à juger le niveau de qualité du logiciel et sa cryptographie. Si l'on ne l'a pas, le logiciel n'est même pas bon à prendre en considération, car ses auteurs vous demandent de leur faire confiance, mais vous interdisent de vérifier leurs dires.

Rejeter encfs (ainsi que tous les autres) parce qu'il a un "design pas très sérieux" pour choisir un logiciel non-libre, donc dont on ne peut rien savoir sur la conception, c'est quand même osé…

Duplicity est incrémental, et utilise GPG pour la cryptographie.

Si je te diffuse un signal continu à 18kHz et que j’ajoute un autre signal, par intermittence à disons à 20030Hz, tu vas « entendre » ce second signal, car la pression acoustique changera, tu n’entendras pas le premier signal de la même manière…

Ça ne contredit pas ce que je dis, car cette différence sera aussi "capturée" dans le fichier échantillonné à 2 * 20kHz.

« sur le plan théorique, un CD dispose d’une fréquence d’échantillonnage de 44,1 kHz qui, de fait, bride les fréquences élevée à 22 kHz (théorème de Shannon), alors que le son d’une trompette grimpe au-delà de cette limite. Cela engendre une perte de notes sur le spectre audio, souci absent de l’écoute sur vinyle grâce à son "image spatiale plus précise" »

Donc pour moi, lorsque l'on rippe un CD, quel que soit le format même sans compression on aura toujours cette perte, je ne vois pas comment le flac pourrait retrouver ces sons …

Ces sons dont la fréquence est supérieure à 20kHz sont de toute manière inaudibles par une humain (pour les meilleures oreilles, car en pratique, la fréquence maximale audible diminue beaucoup avec l'âge).
En les perdant, il y a une différence, mais il vous sera biologiquement impossible de la remarquer.

tu peux utiliser un format avec perte qui restera encore de meilleure qualité (auditive) que le format CD

Si c'est pour écouter, et non pour travailler sur le son, ça n'a aucun intérêt.