mahikeulbody a écrit 1671 commentaires

Très franchement, je doute de l'efficience énergétique* de cette solution par rapport à celle, centralisée, des data-centers pour les services que tu évoques.

* sans parler de l'efficience en matière de consommation de matières premières (métaux rares, etc…).

Le chauffage collectif urbain tel qu'il existe déjà dans ma ville mais "alimenté" par des data-centers est une solution qui me paraît plus convaincante.

Après l'idée d'un internet décentralisée / auto-hébergé est séduisante pour beaucoup d'entre nous mais c'est un autre sujet qui à mon avis à besoin d'autres arguments pour se justifier.

Ou, en posant la question autrement, dans combien de temps peut-on espérer que les nouveaux processeurs à venir ne soient plus vulnérables à ces deux failles (hors palliatifs logiciel) ? Est-ce une remise en cause profonde de l'architecture ou bien un correctif, certes matériel, mais "facile" à effectuer sur les prochaines versions de processeurs ?

@patrick_g : Ton argument tient (un peu) si Google produit une mise à jour pour un truc un peu plus ancien comme la Nexus 7 par exemple. Est-ce que cela sera le cas ?

C'est sûr que si le user a un Windows pirate qui ne reçoit aucune maj et un vieux android qui ne reçoit aucune maj ben il est dans la merde : mais c'est la faute du user !

Il est fort probable que beaucoup de smartphones avec un Android pas vieux (moins de deux ans) ne recevront pas de mises à jour pour corriger ce problème. Ce sera aussi la faute du user parce qu'il n'avait qu'à acheter un Nexus ?

Disons que le post de aurelienpierre un peu plus bas qui qualifie mon discours de complètement faux en brandissant darktable-chart alors que je parlais de tous les traitements qui font qu'un raw devient un jpeg (et donc pas seulement la colorimétrie) m'a rendu un peu sensible sur ce point. Mais j'admets que c'est une réponse au mauvais endroit, désolé…

Ceci dit, tu dis "comportant entre autre" : quels autres presets génère daktable-chart ?

Je me retrouve dans cet objectif et après avoir traité l'exposition, les niveaux, le recadrage, etc… j'étais en général satisfait du résultat sans avoir eu à faire de la colorimétrie (hormis parfois via la balance des blancs), heureusement d'ailleurs car ce n'est pas très simple. Sauf que quand je comparais au jpeg du boîtier, oh horreur le vert du gazon n'était pas tout à fait le même, etc… et j'essayais alors de me lancer dans les modules de colorimétrie. Jusqu'au jour où on m'a fait comprendre qu'il n'y avait aucune raison de faire ça si le résultat initial était satisfaisant et pas moins "vrai" que le soi-disant "original" boîtier.

Dans mon histoire à moi, comprendre ça m'a fait gagner du temps, bien au contraire.

En revanche, si pour un boîtier donné Darktable ne produit pas une bonne colorimétrie alors que celle du boîtier est ok (et sans se laisser abuser par "jpeg boîtier = original" !), darktable-chart est une solution et tu as bien fait de la citer.

Un problème de balance des couleurs peut-être (même si par défaut darktable est censé prendre celle du boîtier) ?

La solution pour avoir un jpeg proche de la version boîtier […]

Il serait plus exact de dire "pour avoir un jpeg avec une colorimétrie proche de la version boîtier".

Les corrections locales par empilement de modules sont certes puissantes, mais il manque un module permettant la sélection d'une zone et l'application de plusieurs corrections (exposition, teinte, contraste, détail, récupération des hautes lumières, récupération des ombres, etc.) en une seule fois.

On peut réutiliser un même masque dans différents modules. Ça ne suffit pas ?

Appliquer les algorithmes et les paramètres utilisés par le boîtier pour élaborer le jpeg nécessite de connaître ces algorithmes et ces paramètres. Les paramètres sont certes décrits dans le fichier raw mais de façon non documentée, et les algorithmes ne sont pas décrits du tout. Le seul moyen d'obtenir les mêmes jpeg que le boîtier consiste à utiliser le logiciel de développement du fabricant (Olympus Viewer 3 dans ton cas) qui, malheureusement, n'est pas toujours au même niveau d'ergonomie et de fonctionnalités que ses confrères généralistes (Lightroom, Darktable, etc…).

Par ailleurs, il n'est pas pertinent de comparer l'affichage par défaut de Darktable avec le jpeg du boîtier. En effet, Darktable fait le choix d'appliquer le moins de traitements possibles par défaut : dé-rawtisation, balance des blancs et - optionnellement - un réglage émulant la courbe de base du boîtier. Il reste donc par définition du travail à faire. On peut cependant automatiser en partie ce travail via les styles (voir la documentation).

Mon dernier point est pour dire qu'il est très difficile au début de se mettre dans la tête que le jpeg du boîtier n'est pas la référence : des boîtiers de marque différentes équipés du même capteur (cas assez courant) produiront des jpeg différents de la même scène. Est-il crédible de penser que seul l'un d'entre eux a toujours "raison" ?

Le développement doit donc s'effectuer en pensant à l'image qu'on veut obtenir (par rapport à sa mémoire visuelle par exemple) en oubliant l'interprétation qui en a été faite à partir de choix arbitraires du fabricant, choix parfois heureux, parfois moins pertinents selon la scène. Facile à dire mais il m'a fallu beaucoup de temps pour passer cette étape…

utilisateurices

Je n'ai pas suivi tout le débat sur l'écriture inclusive(1) mais j'ai peut-être bien fait car ça sera sans moi, sans façon.

(1) on me rétorquera peut-être que ce n'est pas de l'écriture inclusive à la lettre, mais j'imagine que c'est dans le même esprit.

J'utilise Darktable (sous Linux) depuis deux ou trois ans maintenant (après avoir utilisé un peu Lightroom et DxO) et je n'envisage pas un instant de changer. On a l'impression que ce logiciel a changé de dimension depuis quelque temps (nb de contributeurs, version Windows, apparition/annonce de modules très sophistiqués, citations plus nombreuses dans les medias spécialisés, de plus en plus de tutos, etc…). Mais si cela a été possible c'est sans doute aussi parce que les fondations étaient saines grâce à ses premiers développeurs. Bravo à eux.

Dans le libre, il y a de la place pour tout le monde mais je me pose quand même la question de celle que peut encore avoir Raw Therapee…

J'allais oublier : merci pour cette superbe dépêche !

Aucune différence, je voulais juste montrer que l'hébergement chez-soi n'est pas forcément un problème pour transmettre les données à sa famille.

Ce n'est pas de transmission d'un mot de passe dont je parlais mais de la prise en charge du serveur de mail lui-même (même si on peut espérer qu'il va marcher sans maintenance un certain temps). C'est quand même plus compliqué de trouver quelqu'un pour reprendre ça en main que d'ouvrir une enveloppe et de retrouver l'accès aux mails. De plus, il ne s'agit pas seulement de mes mails mais aussi ceux de chaque membre de ma famille (pour lesquels le problème du mot de passe ne se pose pas).

Après, chacun fait comme il veut.

Pour ce qui est de ton histoire Facebook, je ne vois pas où est le problème si chacun laisse la clé de son keepass (ou équivalent) dans une enveloppe scellée. Comme tu peux accéder à tous les contenus même après un décès.

je peux toujours donner à ma famille une carte / un document scellé avec la clé.

Tout comme je peux aussi indiquer à ma famille où se trouve une enveloppe scellée avec la clé d'accès à mon keepass qui contient les mots de passe de gmail, facebook (ça j'ai pas), etc… Quelle est la différence ?

De plus, avoir gmail ne m'empêche pas d'avoir une copie de mes mails chez moi (via Thunderbird connecté à mon compte gmail de temps en temps). Tout le reste (photos, etc…) est chez moi (mais ce n'est pas vraiment ce que j'appelle de l'auto-hébergement).

Je ne pense pas que le notaire qui assurera la succession s'amuse à prévenir les GAFA de mon décès afin qu'ils bloquent mes comptes.

Je l'ai moi-même fait il y a quelques années. Puis je me suis rendu compte que ça n'augmentait pas la privacité de mon courrier puisque tous mes correspondants étaient sur gmail, hotmail, etc… Puis je me suis aussi rendu compte que s'il m'arrivait quelque chose, ma famille perdrait l'accès à sa messagerie ne sachant pas maintenir le truc (même si je me doute que ça sera pas sa première préoccupation). Et ce n'est sans doute pas optimal en terme de consommation énergétique.

Bref est-ce que ça sert à autre chose qu'à se faire plaisir (ce qui n'est évidemment pas critiquable) ?

(c'est une vraie question)

Après on s'étonne que les gens achètent de moins en moins de PC… :D

Heu… j'ai un (sérieux) doute sur la raison que tu invoques à la baisse du marché PC.

Il y a quand même aussi un problème sur Ubuntu 17.10 car ce serait la seule distribution concernée.

Je me corrige : il semble que ce soit un bug de driver Intel que l'on peut donc retrouver sur d'autres distributions qui ont le kernel concerné.

Il boote toujours mais plus sur une clé USB.

1) Ça ne touche pas que Lenovo, d'autres modèles/marques de laptops sont cités (à tort ?).

2) Il y a quand même aussi un problème sur Ubuntu 17.10 car ce serait la seule distribution concernée.

J'avoue ne pas avoir creusé le sujet mais j'ai lu certains commentaires indiquant que c'est aussi un peu la faute de certains fabricants (apparemment toujours les mêmes) qui ne respecteraient pas l'implémentation standard de UEFI dans leur firmware pour y ajouter je ne sais quels goodies.

Bref, c'est quand même bien embêtant pour ceux qui ont été touchés car pour le moment il n'y aurait aucun correctif pour réparer le firmware (autre que celui préconisé par Lenovo : changer la carte mère !).

Au Brésil, pour la plupart des paiements par carte on te demande "débit ou crédit ?". Si je me souviens bien*, il faut répondre "crédit" car "débit" signifie là-bas "débit immédiat" (cad connexion à la banque pour vérifier si solde suffisant ce qui a des chances de moins bien marcher si on est à l'étranger).

Ceci pour dire que les mots "débit" "crédit" n'ont pas forcément le même sens selon les pays (et leur système bancaire).

*
J'ai toujours un doute parce que des fois (rares) on ne te demande rien et que d'autres fois il faut essayer les deux pour trouver celui qui marche…

L'idée n'était pas qu'on puisse réparer et faire évoluer cette imprimante en imprimant les nouvelles pièces ? Quel intérêt d'en prendre une autre ?

J'imagine qu'imprimer une pièce pour réparer une imprimante en panne peut difficilement se faire sur l'imprimante en panne elle-même ! Après, ce n'est sans doute pas la seule raison de son nouvel achat car on peut aussi utiliser ponctuellement une imprimante dans un fablab pour faire la pièce nécessaire à cette réparation.

Merci pour cette suggestion mais je préfère rester sur le FS par défaut (ext4).

Bup et Restic ne sont pas forcément loin derrière BorgBackup mais j'ai finalement choisi ce dernier qui m'a vraiment convaincu (fonctionnalités, nombreux retours d’expérience sur le net, très bonne documentation, projet actif, etc…).

Je vais mettre en place la solution suivante :

• repos Borg sur un DD dédié dans un des PC locaux avec les archives Borg chiffrés (automatiquement par Borg). Au lieu d'un DD sur un des PC locaux, ça pourrait être un NAS ou un PC local dédié à ce rôle pour éviter d'avoir dans le même boîtier DD "données utilisateur" et DD "archives Borg" mais ce n'est pas obligatoire du fait de l'étape ci-dessous.

• rclone du repos sur un archivage cloud type Glacier (Amazon), C14 (Online)[1] ou PCA (OVH), beaucoup moins coûteux que du stockage cloud classique (avec quand même l'avantage sur un PC familial off-site d'être toujours en ligne). Je n'aurai à l'utiliser - en restitution - que si je perds les données source et le repos Borg. Le temps de restitution plus long d'un archivage cloud (vs. stockage cloud) n'est donc pas un problème dans mon cas d'utilisateur non professionnel.

Et au final, ça me paraît assez simple à mettre en œuvre.

Merci pour vos suggestions !

[1] C14 ne laisse que 7 jours pour ajouter ou modifier une archive => avec mon pauvre ADSL, le premier envoi (plus de 500 Go) ne passera jamais dans ce délai.

Après quelques essais (en local), borgbackup semble effectivement un très bon candidat !
Je vais focaliser mes essais en non-local sur cette solution.

Sinon, il y aussi restic (voir une comparaison avec borg et la réponse apportée par un des dev de borg). Je ne l'ai pas encore essayé.

bup (développé par l'auteur de rsync) est très séduisant mais le fait que la fonctionnalité prune soit encore expérimentale et complexe à implémenter (car bup est basé sur git) ne m'incite pas à utiliser pour le moment. Par ailleurs il semble moins activement développé et utilisé que borg ou restic.

mais le volume stocké n'étant dédupliqué que fichier à fichier sera stocké deux fois.

C'est rédhibitoire pour moi. En effet, quand je vide la carte mémoire de mon appareil photo, je lance un backup (en réalité, avec Crashplan, c'est automatique et au fil de l'eau mais peu importe ici). Puis, plus tard, quand j'ai le temps, je taggue mes photos. D'après ton explication, quand je vais refaire un backup, le transfert sera optimisé mais pas le stockage : à l'arrivée, je vais avoir deux fois la taille de mes photos.