BFG a écrit 897 commentaires

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.

Cela fait maintenant quelques années que Webkit est déprécié par Qt, et que Blink est bien intégré, au détriment de la portabilité et de la perte de certaines fonctionnalités.

Vous ne voulez pas avoir les yeux détruits par l'obscurité, mais vous détruisez les yeux de vos lecteurs en écrivant "sa" au lieu de "ça" à 3 reprises. Je ne parle pas des confusions "à" et "a".

Les chemins relatifs ou absolus sont-ils stockés ? Les permissions étendues (ACL) sont-elles prévues ?

Une autre remarque :
test -z $1
ne fonctionnera pas correctement si le premier argument contient des espaces.
En effet, $1 n'est pas protégé par des guillemets, il sera donc étendu en autant d'arguments que le shell peut le couper (éventuellement 0 si la chaine est vide), or test -z n'accepte au maximum qu'un argument supplémentaire :
$ foo="bar baz"; test -z $foo
bash: test: bar : opérateur binaire attendu

(Vous pouvez en lire un peu plus sur cet article)

Dans ce script, si le premier argument contient un espace, ce sera de toute façon attrapé par le case, mais cela évite que bash n'affiche une erreur que vous ne controlez pas.

Deux bots vendeurs ajustaient leur prix l'un en fonction de l'autre.

Si Let's Encrypt ne supporte les accents, comment as tu fait pour https://up.ÿ.fr/ ?

Il ne semble pas utiliser letsencrypt pour son certificat.

Un rootkit, l'OS ne sait même pas qu'il tourne.

Non, un rootkit fonctionne dans le noyau, et fonctionne au même niveau que le noyau, il peut se cacher d'outils simples, mais ne peut se cacher du système puisqu'il en fait partie.
Vous confondez avec les logiciels malicieux qui mettent le système entier dans une machine virtuelle, comme BluePill, le rendant beaucoup moins détectable qu'un simple rootkit.

Bah non, le rootkit outrepasse le kernel, il n'a pas besoin d'élèvation de privilèges.

Et comment s'installe le rootkit, à votre avis ?

Vous pouvez contribuer à LinuxFR sur son wiki.