mahikeulbody a écrit 1500 commentaires

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.

Merci, je vais regarder ces deux propositions.

J'étais en train d'essayer BUP qui semble aussi répondre au problème.

C'est couvert par l'article 700 en cas de "victoire" ou bien ce dernier est-il notoirement insuffisant ?

Une assignation abusive n'est pas "une erreur dans le système judiciaire" mais juste l'action d'un citoyen lambda (ou d'une entité) que l'assigné peut éventuellement considérer abusive mais ce n'est, bien sûr, pas à lui d'en juger.

Par ailleurs, il existe la notion de "procédure abusive" en droit français (j'ignore cependant quel est son champ d'application). Il y aussi les frais de justice à la charge du perdant.

En fait je ne comprends pas trop le "mouhahahahaha" final dans le contexte de cette discussion.

C'est une fonctionnalité non standardisée pour l'instant.

Tu veux dire qu'il faut nécessairement que les autres membres du "groupe" auquel est destiné le billet utilisent aussi SaT ?

Par ailleurs, pour revenir à Movim, à quoi sert un billet non publié publiquement ? C'est une sorte de brouillon pour une éventuelle publication publique ultérieure ?

Quelque chose m'échappe (peut-être un manque d'habitude des réseaux sociaux) : je ne vois pas comment restreindre la publication d'un billet à certains contacts (ou un groupe de contacts). Du coup, je me pose aussi la question suivante : a contrario, qui peut voir un billet privé (i.e. non publié publiquement) ?

L'idée serait d'avoir un espace où mes proches pourraient "publier" de façon privée sans pour autant faire du chat.

Je ne suis pas encore utilisateur (hormis quelques essais à chaque version) mais je viens de faire un (petit) don. Au delà de l'aspect technique (pour ou contre XMPP, voir les nombreuses discussions sur Linuxfr), je suis admiratif de la constance dans l'avancement de ce projet. Bravo !

Je n'ai rien trouvé sur 18.10, tu es sûr qu'elle existe cette version ?

Elle n'existera qu'en octobre 2018.

Ah ok, ce n'est pas rsync mais un prog/script utilisant rsync. Comme Back in Time, par exemple.

pour les sauvegardes, c'est rsnapshot ou rsync.

Des sauvegardes avec rsync ? Comment tu fais ?

(je parle de vraies sauvegardes, c'est-a-dire historisées, pas juste de copies sur un autre DD)

En l'occurrence, il ne se préoccupait pas tant de OVH que de

ni mon FAI, ni l'administrateur du MC Donald ou ses clients, ni l’hôtel qui m'héberge, n'ont à connaître mon mot de passe.

Comment prendre au sérieux une commission qui dépense des millions juste pour vérifier que les sites préviennent les gentils internautes des grands méchant cookies en imposant des bandeaux hideux et inutiles ?

Je pense que ça ne se limite pas à ça, loin de là.

mais je crois que ce sera un Unity simplifié.

Ce n'est pas ce que j'ai lu à ce sujet : Unity dégagerait complètement (y compris Mir).

En revanche, essayer aujourd'hui Gnome sur Ubuntu ne donnera pas forcément une idée exacte de ce que sera Ubuntu 17.10. En effet, il y aura sans doute une configuration de Gnome (et probablement des patchs) avec par exemple un lanceur "à la Unity" afin de ne pas "déstabiliser" l'utilisateur lambda.

ce qui est probablement le cas car l'OS est un Android stock sans ajout supplémentaire … à priori.

Si le simple fait d'activer ce service fait rebooter Android, ça se saurait, non ? J'imagine plutôt un problème matériel lié à la puce GPS.

En attendant, la campagne Ulule progresse mais pas très vite, je trouve…

A part en parler autour de soi (et faire un don, bien sûr), que peut-on faire d'autre ?

Comment ça se situe par rapport à Vorbis, lui aussi développé/soutenu par Xiph.org ?

Ça le remplace ?

Edit : Apparemment ça remplace Vorbis et Speex.

Il y a d'autres buts possibles : lieu d'échanges au sein de la sphère familiale ou au sein d'un groupe d'amis, par exemple.

Dans ce cas-là, peu importe que le réseau ne soit pas hyper-fréquenté. L'important est qu'il soit facile d'utilisation et multi-plateforme pour arriver à convaincre les gens concernés de l'utiliser (ça n'implique pas qu'ils abandonnent FB s'ils l'utilisent déjà).

Pour ma part, j'attends que Movim arrive à maturité.

Atos c'est des dizaines de milliers de personnes et, surtout, des tas sites/branches d'activité différentes. Dans celle où j'ai travaillé (l'énergie), non, cette définition ne s'appliquait pas du tout (ça a peut-être changé depuis mon départ il y 5 ans).

En revanche, il est vrai qu'il y a dix, vingt ou trente ans, il y avait (dans ma branche, du moins) un management avec une vision industrielle qui cherchait plus à faire de grands projets qu'à fourguer des "consultants".

Il y aussi le fait que les principaux clients de ces grandes SSII sont de grandes entreprises avec une direction des achats puissante qui choisit souvent le "soit-disant" mieux-disant sans tenir trop compte de l'avis des services concernés par le projet => pour avoir l'affaire, les commerciaux bradent l'offre quitte à ce que les équipes de réalisation bâclent pour finir dans les coûts.

C'est bien sûr une vision à court terme.

Le Defy est plus épais de 5mm, ceci expliquant peut-être cela.

En ce qui concerne les Xperia, c'est sans doute dû au fait qu'ils sont étanches. J'imagine que faire une batterie facilement amovible en ne perdant pas l'étanchéité à chaque ouverture/fermeture du capot doit être plus compliqué. Bien sûr, il me paraît complètement invraisemblable que, outre cette difficulté indéniable, le marketing en ait rajouté une couche pour accélérer l'obsolescence du produit…

Pour en revenir au sujet, comment ça se passe concrètement si on n'est pas expert en build AOSP ? Il y a des firmwares prêts à télécharger et installer basés sur les sources mis à disposition par Sony ?

Donc je pense que la question du contrôle a été aussi abordé et élucidé.

C'était un peu ça, ma question : quelles solutions peuvent être mise en œuvre pour assurer qu'un logiciel libre certifié installé quelque part n'a pas été modifié ?

(Certes, la même question se pose aussi en théorie pour un logiciel non libre certifié qu'on peut toujours patcher mais c'est quand même beaucoup moins simple quand on n'a pas les sources).

Si un logiciel de facturation libre est certifié, les fraudeurs vont se précipiter pour l'utiliser puisqu'il sera bien plus facile à modifier qu'un logiciel propriétaire certifié.

Finalement, quel est l'intérêt de cette loi sans un processus de certification qui s'intéresse aussi à l'inaltérabilité du code ?

D'où mon doute sur le fait que des logiciels libres arrivent à avoir cette certification.

Ceci dit, des lois qui ne servent à rien (ou qui existent déjà sous une autre forme) sont monnaie courante chez nous, alors ce ne sera peut-être qu'une usine à gaz de plus.