Pour être précis, c'est une feature qui a sauté entre Kde 4 et 5.
Je n'en veux pas aux devs (même s'il faudrait qu'ils ferment ce bug "WONTFIX" pour être cohérents), je suis content avec Xfce.
Par contre, pour un besoin de niche, c'est tout de même le bug ouvert le plus commenté de tout Plasma Shell, et de loin… Mais cette métrique vaut ce qu'elle vaut, certes.
Et bien non, j'ai un grand écran, je ne mets aucune fenêtre en plein écran.
Surtout, je suis quand même assez bien placé pour déterminer ce qui me gêne ou non, je crois. Mais ce genre de réponse un tantinet surréaliste se retrouve régulièrement sur le long échange du rapport de bug de Kde correspondant.
Personnellement j'ai surtout deux arguments, qui sont peut-être devenus obsolètes:
peu de stabilité dans la configuration: au cours des mises à jour successives, ma configuration devenait de plus en plus bancale, et au bout de 2-3 ans je devais passer par un gros reset et tout refaire afin d'éviter des soucis bizarres.
pas de fond d'écran par bureau virtuel ! Cette demande, vieille de 7 ans, est toujours en standby chez KDE. C'est pour moi un repère visuel indispensable au quotidien. J'ai le même reproche pour Gnome, d'ailleurs.
Bref, Xfce est pour moi la bonne solution: stable, efficace, et j'ai mes fonds d'écran différents.
Réflexion intéressante; la dualité classement/tag n'est toujours pas résolue, malgré les années qui passent…
Pourtant les scénarios où les tags sont pertinents existent, là n'est pas le problème. Non, le problème c'est que les tags n'ont pas vraiment de standard: on peut étiqueter des fichiers sur Linux, sur certains clouds, mais il n'y a aucune synchronisation entre tout ça, contrairement aux structures de répertoires.
Et c'est même pire que ça: étiqueter un fichier dans Dolphin ne servira à rien lorsqu'on voudra retrouver ledit fichier avec le sélecteur de Gimp.
On le voit bien, il manque ici deux étapes majeures avant que les étiquettes soient vraiment un complément utile aux dossiers:
1. un standard pour stocker et retrouver l'information (niveau OS ?)
2. une synchronisation possible entre les différentes copies des fichiers (cloud, NAS, copies locales…) afin de retrouver la donnée sur différents types de support
Mais sans ça, les étiquettes restent pour moi un gadget inutilisable à grande échelle.
surtout que moderna provoque 6 fois plus de miocardite et péricardite que pfizer et là on parle de 100x plus de risque sans vaccin donc logiquement on pourrait remettre morderna
Oui… si on n'avait que Moderna sous la main. Mais en fait c'est comme avec A-Z: puisqu'il est facile d'avoir mieux, autant le proposer.
Il faut quand même avoir de sacrées oeillères pour ne pas voir l'amélioration qu'a apporté le vaccin. Par où commencer ?
regarder les vagues pré-vaccin (avant l'été, par exemple Avril) et post-vaccin (après l'été, par exemple Août-Septembre): alors qu'on n'a même pas atteint une couverture vaccinale optimale, les hospitalisations sont déjà divisées par 2 ou 3
on oublie un peu l'ampleur de la vague actuelle: on 10 voire 20 fois plus de cas quotidiens que pour les vagues précédentes ! Omicron est heureusement un peu moins virulent, mais sans le vaccin on serait en confinement depuis longtemps.
on peut envisager un avenir moins morose: le Danemark tente le retour à une vie normale par exemple, chose absolument impensable sans le vaccin. Et oui, la 3ème dose y joue un rôle important, car elle une bien meilleure protection face à Omicron.
Alors, non, personne n'a «remarqué» que la vaccination n'avait eu aucun effet sur l'épidémie dans les derniers mois, c'est juste une impression très biaisée.
Pas de haine, mais juste une très grande lassitude.
Sur la plupart des projets auxquels je contribue, il arrive assez régulièrement qu’un patch soit initialement ignoré, jusqu’à ce que son auteur envoie un second mail après une semaine ou deux pour dire un truc du genre « ping ! juste pour savoir si vous avez bien vu ce patch et le cas échéant ce que vous en pensez ? »
Et après ces nombreuses contributions passées à la trappe par erreur, personne ne se dit que le process doit être amélioré ?
C’est plus une question de disponibilités des mainteneurs qu’une question d’outil, à mon avis.
Je ne suis pas de cet avis. Tu as deux problèmes distincts:
la quantité de problèmes qu'une équipe réduite pourra régler (besoin d'une relance pour pousser la priorité)
une visibilité de l'ensemble des problèmes (risque d'un oubli complet, besoin d'une relance pour simplement ne pas rater le patch)
GitHub & co ne va pas régler le premier problème. Aucun process ne le pourra: quand il y a trop de boulot, il faut trier. Et encore, ce tri est bien facilité avec un système de tickets ! Donc même si la bande passante reste la même, elle est sûrement mieux utilisée.
Par contre, le second problème est largement amélioré. Car un email, comme tu l'as dit, ça s'oublie ou se manque facilement. Le ticket, lui il reste là, dans la liste. Si des tickets plus récents sont créés puis résolus, il va redevenir plus visible.
Pour moi il n'y a pas photo: un système de tickets est une énorme amélioration pour gérer les demandes.
Manifestement, les mainteneurs de pkexec n'ont pas lu son blog. Et cela n'a rien de bien surprenant…
C'est un peu dommage de se donner la peine de faire cette analyse, un billet de blog, un mail, et de ne pas se demander pourquoi il n'y a aucune réponse au mail. Mais c'est vrai que la mailing-list ne répond peut-être pas à tous les mails d'inconnus, à cause du spam…
Fait amusant: aujourd'hui c'est via Twitter que cette information a réussi à être repérée. Et c'est vrai qu'une PR (ou MR pour Gitlab) est un peu plus visible et plus pratique !
Lorsque tu passe de 10 à 30 alertes, et que ton voisin passe de 10 millions à 30 millions d'alertes, on peut se demander si on reste, dans l'absolu, dans un bruit de fond: les attaques augmentent en général, mais continuent de ne pas te cibler toi plus qu'avant.
La question de savoir qui cause quoi (déploiement, robustesse, intérêt financier, méthode de remontée des problèmes, autre) reste entière. Mais ne pas se mettre des oeillères lorsqu'on analyse un problème (qui reste à définir d'ailleurs) c'est toujours bénéfique.
Bel exemple ici d'un inconvénient d'utiliser des binaires statiques (chose revenue à la mode avec Go et Rust): lorsqu'un bug est découvert dans une dépendance, il est très difficile de savoir ce qu'on doit mettre à jour.
Alors pour les paquets d'une distribution Linux j'imagine que tout sera recompilé avec la nouvelle version de la bibliothèque standard, mais pour le reste (petits utilitaires compilés localement, situation hypothétique d'un binaire commercial qui n'est plus maintenu, etc) c'est un peu le flou artistique…
Je trouve que c'est une saine piqûre de rappel de l'avantage d'avoir un livrable moins monolithique. En attendant, je crois qu'il ne me reste plus qu'à recompiler tous ces fameux petits utilitaires qui veulent remplacer les outils classiques (exa, fdupe, fd, ripgrep…)
C'est la même boîte, mais ils ont (normalement…) des rôles différents. Mais ça peut expliquer en effet pourquoi ce genre de décision a été prise.
Si GitHub lui rend l'accès à son compte, je pense que ses actions suivantes seront:
1. sauvegarde de ses repos en local ou sur un Gitlab ou autre
2. git push --force qui efface ses repos et les remplace par un README.
Oui, ce serait une belle tuile. Et, oui, c'est tout à fait son droit. Il a demandé à ce qu'on forke son projet il y a déjà plus d'un an… L'écosystème NPM fait confiance à toute une pyramide de dépendances, faisant intervenir des milliers de personnes et d'entités, la plupart de parfaits inconnus. C'est extrêmement fragile par nature, on le voit régulièrement.
Sinon c'est un peu facile aussi: le code est fourni sous licence libre, gratuitement, sans aucune garantie. Tout le monde tire dessus, personne ne veut s'en occuper (pas de fork depuis un an). Mais dès que le dev veut sonner la fin de la récré, hop on lui coupe son hébergement GitHub, qui n'a rien à voir ? Google va lui couper son mail, aussi ?
Pour NPM je n'ai aucun problème avec leur réaction, qui correspond à leur rôle d'intégrateur.
Mais GitHub ? De quelle chaîne de confiance on parle ? Ils ne sont là que pour fournir un dépôt de code, pas pour choisir si tel ou tel commit leur plaît ou non.
Alors peut-être que GitHub, dans les conditions d'utilisation de 10km, ont une clause concernant du code "malicieux", mais ça reste tout à fait sujet à critique. Qu'est-ce qu'un code malicieux ??
PS: au fait, l'auteur a averti que le logiciel ne serait plus maintenu à partir de novembre 2020. La chaîne de confiance auraît dû s'arrêter à ce moment là.
Autant la façon de faire du développeur me semble maladroite (le code est libre, ou pas ?), autant la réaction de GitHub est scandaleuse et inquiétante.
En effet, si on en croit le développeur en question, GitHub s'est permis de susprendre son compte, car il aurait enfreint les termes du contrat… Alors qu'il n'a fait que modifier son propre code.
Je vous trouve bien gentils avec cette carte: elle est tout simplement inutilisable. Impossible de chercher un nom, ou d'avoir la liste, légende illisible, et la plupart des logos sans lien ne sont pas lisibles.
On n'a pas non plus accès à l'image d'origine, pourtant elle est probablement plus détaillée.
Une mise en avant ratée pour cette «presse pas pareille», je trouve. J'espère qu'ils s'en apercevront et mettront à jour la page.
Le pass sanitaire a montré son utilisé cet été: on est passé en 2 mois de derniers de la classe à premiers de la classe. Durant l'été, il a aussi servi de limiteur de foule pour certains espaces communs.
Aujourd'hui, son utilité devient plus contestable: 90% de la population éligible est vaccinée, donc l'utilité "jauge" du pass n'existe plus.
Maintenant, il est utilisé de la même manière pour pousser la 3ème dose. Est-ce que c'est une utilisation légitime ? pas sûr.
Est-ce que les Français seraient aujourd'hui aussi bien protégés par le vaccin sans l'introduction de ce pass ? Et bien c'est là le piège: impossible à prouver ! On sait juste qu'en juin/juillet, la prise de rendez-vous pour une 1ère dose chutait en flèche.
L'encryption proposée par rclone est faite fichier par fichier (le nom aussi peut être encrypté). Donc c'est mieux qu'un disque virtuel complètement crypté, et moins bien qu'une encryption bloc par bloc.
Au quotidien, seuls les fichiers modifiés sont ré-envoyés, ce qui me convient bien.
[^] # Re: Je vous conseille
Posté par Christophe . En réponse au lien KDE Plasma 5.24 modernise son thème et sa gestion des fenêtres. Évalué à 4.
Pour être précis, c'est une feature qui a sauté entre Kde 4 et 5.
Je n'en veux pas aux devs (même s'il faudrait qu'ils ferment ce bug "WONTFIX" pour être cohérents), je suis content avec Xfce.
Par contre, pour un besoin de niche, c'est tout de même le bug ouvert le plus commenté de tout Plasma Shell, et de loin… Mais cette métrique vaut ce qu'elle vaut, certes.
[^] # Re: Je vous conseille
Posté par Christophe . En réponse au lien KDE Plasma 5.24 modernise son thème et sa gestion des fenêtres. Évalué à 5.
Et bien non, j'ai un grand écran, je ne mets aucune fenêtre en plein écran.
Surtout, je suis quand même assez bien placé pour déterminer ce qui me gêne ou non, je crois. Mais ce genre de réponse un tantinet surréaliste se retrouve régulièrement sur le long échange du rapport de bug de Kde correspondant.
[^] # Re: Je vous conseille
Posté par Christophe . En réponse au lien KDE Plasma 5.24 modernise son thème et sa gestion des fenêtres. Évalué à 6.
Personnellement j'ai surtout deux arguments, qui sont peut-être devenus obsolètes:
peu de stabilité dans la configuration: au cours des mises à jour successives, ma configuration devenait de plus en plus bancale, et au bout de 2-3 ans je devais passer par un gros reset et tout refaire afin d'éviter des soucis bizarres.
pas de fond d'écran par bureau virtuel ! Cette demande, vieille de 7 ans, est toujours en standby chez KDE. C'est pour moi un repère visuel indispensable au quotidien. J'ai le même reproche pour Gnome, d'ailleurs.
Bref, Xfce est pour moi la bonne solution: stable, efficace, et j'ai mes fonds d'écran différents.
# Les tags n'ont pas de standard
Posté par Christophe . En réponse au lien Yet Another Hot Take on “Folders vs Tags”. Évalué à 10.
Réflexion intéressante; la dualité classement/tag n'est toujours pas résolue, malgré les années qui passent…
Pourtant les scénarios où les tags sont pertinents existent, là n'est pas le problème. Non, le problème c'est que les tags n'ont pas vraiment de standard: on peut étiqueter des fichiers sur Linux, sur certains clouds, mais il n'y a aucune synchronisation entre tout ça, contrairement aux structures de répertoires.
Et c'est même pire que ça: étiqueter un fichier dans Dolphin ne servira à rien lorsqu'on voudra retrouver ledit fichier avec le sélecteur de Gimp.
On le voit bien, il manque ici deux étapes majeures avant que les étiquettes soient vraiment un complément utile aux dossiers:
1. un standard pour stocker et retrouver l'information (niveau OS ?)
2. une synchronisation possible entre les différentes copies des fichiers (cloud, NAS, copies locales…) afin de retrouver la donnée sur différents types de support
Mais sans ça, les étiquettes restent pour moi un gadget inutilisable à grande échelle.
[^] # Re: mieux vaut tard que jamais
Posté par Christophe . En réponse au journal Comment je suis devenu un vacciné antivaxx.... Évalué à 3.
Oui… si on n'avait que Moderna sous la main. Mais en fait c'est comme avec A-Z: puisqu'il est facile d'avoir mieux, autant le proposer.
[^] # Re: la goutte qui fait déborder mon vase
Posté par Christophe . En réponse au journal Comment je suis devenu un vacciné antivaxx.... Évalué à 10.
Il faut quand même avoir de sacrées oeillères pour ne pas voir l'amélioration qu'a apporté le vaccin. Par où commencer ?
Alors, non, personne n'a «remarqué» que la vaccination n'avait eu aucun effet sur l'épidémie dans les derniers mois, c'est juste une impression très biaisée.
Pas de haine, mais juste une très grande lassitude.
[^] # Re: Un blog parmis tant d'autres
Posté par Christophe . En réponse au journal Quand le mainteneur de pkexec ignorait (ou pas) les failles potentielles. Évalué à 10.
Et après ces nombreuses contributions passées à la trappe par erreur, personne ne se dit que le process doit être amélioré ?
Je ne suis pas de cet avis. Tu as deux problèmes distincts:
GitHub & co ne va pas régler le premier problème. Aucun process ne le pourra: quand il y a trop de boulot, il faut trier. Et encore, ce tri est bien facilité avec un système de tickets ! Donc même si la bande passante reste la même, elle est sûrement mieux utilisée.
Par contre, le second problème est largement amélioré. Car un email, comme tu l'as dit, ça s'oublie ou se manque facilement. Le ticket, lui il reste là, dans la liste. Si des tickets plus récents sont créés puis résolus, il va redevenir plus visible.
Pour moi il n'y a pas photo: un système de tickets est une énorme amélioration pour gérer les demandes.
# Un blog parmis tant d'autres
Posté par Christophe . En réponse au journal Quand le mainteneur de pkexec ignorait (ou pas) les failles potentielles. Évalué à 10.
Manifestement, les mainteneurs de pkexec n'ont pas lu son blog. Et cela n'a rien de bien surprenant…
C'est un peu dommage de se donner la peine de faire cette analyse, un billet de blog, un mail, et de ne pas se demander pourquoi il n'y a aucune réponse au mail. Mais c'est vrai que la mailing-list ne répond peut-être pas à tous les mails d'inconnus, à cause du spam…
Fait amusant: aujourd'hui c'est via Twitter que cette information a réussi à être repérée. Et c'est vrai qu'une PR (ou MR pour Gitlab) est un peu plus visible et plus pratique !
[^] # Re: Méfions-nous des pourcentages...
Posté par Christophe . En réponse au lien Linux malware sees 35% growth during 2021 [principalement sur l'embarqué]. Évalué à 5.
En fait, peut-être que si ?
Lorsque tu passe de 10 à 30 alertes, et que ton voisin passe de 10 millions à 30 millions d'alertes, on peut se demander si on reste, dans l'absolu, dans un bruit de fond: les attaques augmentent en général, mais continuent de ne pas te cibler toi plus qu'avant.
La question de savoir qui cause quoi (déploiement, robustesse, intérêt financier, méthode de remontée des problèmes, autre) reste entière. Mais ne pas se mettre des oeillères lorsqu'on analyse un problème (qui reste à définir d'ailleurs) c'est toujours bénéfique.
[^] # Re: Binaires statiques et conséquences
Posté par Christophe . En réponse au journal Une CVE dans le compilateur rust. Évalué à 5.
oui, c'est justement une partie du problème… Comment identifier les impacts ?
# Binaires statiques et conséquences
Posté par Christophe . En réponse au journal Une CVE dans le compilateur rust. Évalué à 10.
Bel exemple ici d'un inconvénient d'utiliser des binaires statiques (chose revenue à la mode avec Go et Rust): lorsqu'un bug est découvert dans une dépendance, il est très difficile de savoir ce qu'on doit mettre à jour.
Alors pour les paquets d'une distribution Linux j'imagine que tout sera recompilé avec la nouvelle version de la bibliothèque standard, mais pour le reste (petits utilitaires compilés localement, situation hypothétique d'un binaire commercial qui n'est plus maintenu, etc) c'est un peu le flou artistique…
Je trouve que c'est une saine piqûre de rappel de l'avantage d'avoir un livrable moins monolithique. En attendant, je crois qu'il ne me reste plus qu'à recompiler tous ces fameux petits utilitaires qui veulent remplacer les outils classiques (exa, fdupe, fd, ripgrep…)
[^] # Re: Changement de licence au passage
Posté par Christophe . En réponse au lien Rewriting the GNU Coreutils in Rust. Évalué à 4.
On n'est pas dredi ? Tu es sûr ? :)
[^] # Re: Réaction de GitHub
Posté par Christophe . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 8.
C'est la même boîte, mais ils ont (normalement…) des rôles différents. Mais ça peut expliquer en effet pourquoi ce genre de décision a été prise.
Si GitHub lui rend l'accès à son compte, je pense que ses actions suivantes seront:
1. sauvegarde de ses repos en local ou sur un Gitlab ou autre
2. git push --force qui efface ses repos et les remplace par un README.
Oui, ce serait une belle tuile. Et, oui, c'est tout à fait son droit. Il a demandé à ce qu'on forke son projet il y a déjà plus d'un an… L'écosystème NPM fait confiance à toute une pyramide de dépendances, faisant intervenir des milliers de personnes et d'entités, la plupart de parfaits inconnus. C'est extrêmement fragile par nature, on le voit régulièrement.
Sinon c'est un peu facile aussi: le code est fourni sous licence libre, gratuitement, sans aucune garantie. Tout le monde tire dessus, personne ne veut s'en occuper (pas de fork depuis un an). Mais dès que le dev veut sonner la fin de la récré, hop on lui coupe son hébergement GitHub, qui n'a rien à voir ? Google va lui couper son mail, aussi ?
[^] # Re: Réaction de GitHub
Posté par Christophe . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 9. Dernière modification le 10 janvier 2022 à 13:47.
Pour NPM je n'ai aucun problème avec leur réaction, qui correspond à leur rôle d'intégrateur.
Mais GitHub ? De quelle chaîne de confiance on parle ? Ils ne sont là que pour fournir un dépôt de code, pas pour choisir si tel ou tel commit leur plaît ou non.
Alors peut-être que GitHub, dans les conditions d'utilisation de 10km, ont une clause concernant du code "malicieux", mais ça reste tout à fait sujet à critique. Qu'est-ce qu'un code malicieux ??
PS: au fait, l'auteur a averti que le logiciel ne serait plus maintenu à partir de novembre 2020. La chaîne de confiance auraît dû s'arrêter à ce moment là.
# Réaction de GitHub
Posté par Christophe . En réponse au lien Dev corrupts NPM libs 'colors' and 'faker' breaking thousands of apps. Évalué à 6.
Autant la façon de faire du développeur me semble maladroite (le code est libre, ou pas ?), autant la réaction de GitHub est scandaleuse et inquiétante.
En effet, si on en croit le développeur en question, GitHub s'est permis de susprendre son compte, car il aurait enfreint les termes du contrat… Alors qu'il n'a fait que modifier son propre code.
[^] # Re: Syntaxe du déclaratif et QML
Posté par Christophe . En réponse au lien SixtyFPS, a fresh new toolkit for graphical user interfaces. Évalué à 2. Dernière modification le 07 janvier 2022 à 20:38.
Ok, je vois, merci pour les détails !
# Syntaxe du déclaratif et QML
Posté par Christophe . En réponse au lien SixtyFPS, a fresh new toolkit for graphical user interfaces. Évalué à 5.
En voyant les exemples, je ne peux qu'être frappé par la similitude avec le language QML.
Connaît-on les raisons pour lesquelles QML (ou un sous-ensemble de QML) n'a pas été directement utilisé ?
[^] # Re: Y'a deux sortes de sysadmins...
Posté par Christophe . En réponse au lien L'université de Kyoto perd 77 To de données de recherche à la suite d'une erreur de sauvegarde. Évalué à 5.
Oui, j'ai remarqué aussi… D'ailleurs parfois on "glisse" et ça fait backspace + entrée; dans ton cas, ce serait double punition !
[^] # Re: Mediapart ?
Posté par Christophe . En réponse au lien Carte de la «presse pas pareille» (médias libres, indépendants, alternatifs…). Évalué à 8.
Je vous trouve bien gentils avec cette carte: elle est tout simplement inutilisable. Impossible de chercher un nom, ou d'avoir la liste, légende illisible, et la plupart des logos sans lien ne sont pas lisibles.
On n'a pas non plus accès à l'image d'origine, pourtant elle est probablement plus détaillée.
Une mise en avant ratée pour cette «presse pas pareille», je trouve. J'espère qu'ils s'en apercevront et mettront à jour la page.
[^] # Re: Arte
Posté par Christophe . En réponse au lien Un épisode de 28 minute sur les GAFAM avec l'excellente Aurélie Jean !. Évalué à 7. Dernière modification le 02 janvier 2022 à 23:53.
Bref, tu aides à centraliser un Internet qui l'est déjà bien trop. C'est le but des GAFAM: être l'intermédiaire par qui toute l'information passe.
Utilisez le lien Arte !
[^] # Re: des liens
Posté par Christophe . En réponse au lien Vous aviez mis à jour log4j pour corriger log4shell ? Eh bien, il faut recommencer.. Évalué à 9.
Ce n'est pas la même info: ici, c'est la correction de la faille qui introduit un nouveau problème.
Il me semble tout a fait raisonnable de faire un lien dédié pour ça.
[^] # Re: facile ;)
Posté par Christophe . En réponse au message [Achète] Raspberry pi 4. Évalué à 2.
J'avais acheté en août chez Elektor.fr, mais je viens de voir qu'ils sont en rupture de stock aussi…
[^] # Re: Le MOVE COBOL
Posté par Christophe . En réponse au journal Des concepteurs qui ont éteint trop tôt leur cerveau. Évalué à 8.
Dans le même genre, mais en moins explicite encore, tu as l'assembleur intel:
Evidemment, un dev COBOL va tout de suite se méfier: c'est effectivement une copie. Par contre, ça copie bx dans ax !
[^] # Re: Sérieux ?
Posté par Christophe . En réponse au lien La Cnil perd patience et demande des chiffres sur l’efficacité du pass sanitaire. Évalué à 6.
Le pass sanitaire a montré son utilisé cet été: on est passé en 2 mois de derniers de la classe à premiers de la classe. Durant l'été, il a aussi servi de limiteur de foule pour certains espaces communs.
Aujourd'hui, son utilité devient plus contestable: 90% de la population éligible est vaccinée, donc l'utilité "jauge" du pass n'existe plus.
Maintenant, il est utilisé de la même manière pour pousser la 3ème dose. Est-ce que c'est une utilisation légitime ? pas sûr.
Est-ce que les Français seraient aujourd'hui aussi bien protégés par le vaccin sans l'introduction de ce pass ? Et bien c'est là le piège: impossible à prouver ! On sait juste qu'en juin/juillet, la prise de rendez-vous pour une 1ère dose chutait en flèche.
[^] # Re: Offre à vie pcloud
Posté par Christophe . En réponse au journal La sauvegarde dans les nuages. Évalué à 4.
L'encryption proposée par rclone est faite fichier par fichier (le nom aussi peut être encrypté). Donc c'est mieux qu'un disque virtuel complètement crypté, et moins bien qu'une encryption bloc par bloc.
Au quotidien, seuls les fichiers modifiés sont ré-envoyés, ce qui me convient bien.