L'idée est très bonne, mais je trouve dommage de faire un backup difficile à exploiter, alors que Borg permet de faire bien mieux (de mon point de vue) :
Bases de données : Je préfère une commande de la forme pg_dumpall | borg create repo::archive -, ce qui permet de restaurer avec un simple borg extract --stdout repo::archive | psql dbname
Fichiers de configuration : Pourquoi créer une archive et la sauvegarder alors que Borg est fait pour sauvegarder des fichiers ?
Je pencherais plutôt pour borg create repo::archive *.conf. L'avantage ? Pouvoir extraire aussi simplement ces fichiers avec borg extract repo::archive filename destination, voire afficher directement le contenu avec borg extract repo::archive --stdout filename
Alors oui, ce que je propose n'est peut-être pas possible avec borgmatic (ne l'utilisant pas, je le connais mal), mais quitte à faire un script, autant en profiter pour faire un backup simple à exploiter. Pour la politique de rétention, Borg fait ça très bien tout seul avec la commande borg prune. Pour vérifier la cohérence, c'est borg check. Et pas besoin de fichier de configuration supplémentaire ni de fichier de backup temporaire :)
Le point important lorsqu'on utilise un dépôt qui contient plusieurs backups différents (ici bases de données et fichiers de configuration), c'est de bien les nommer, pour pouvoir utiliser le paramètre --prefix des commandes borg prune, borg list, borg check, borg delete, etc.).
Attention sur le protocole du test : il part d'une vidéo déjà compressée, ce qui influe les résultats : le ré-encodage de vidéos dans un format continent forcément des artefacts lequels seront souvent ignorés au ré-encodage.
Des batteries de tests avaient ainsi proclamé la supériorité du h264, parce que justement la source avait été encodé une première fois dans ce format.
Idéalement, il faudrait un test à partir d'un format RAW,
Ah c'est top ca, j'ai les mêmes problemes, sauf qu'au lieu de relancer un script sur server au hasard je me connecte au site web pour telecharger la conf du “serveur recommandé”. A tester!
Le PDF est une bonne alternative, à l'exception de quelques trucs « [caractère Unicode non montré] » « car trop compliqué à faire avec LaTeX », sérieusement :‘)
C'est d'une telle clarté de lecture que cet ensemble de bonnes pratiques devrait intéresser plus d'un développeur avisé. À ajouter à votre définition du fini.
Non, je n'ai jamais visité ton site.
ça fonctionne en navigation privée. J'utilise Vivaldi.
UBLOCK Origin en Bloqueur de pub et blocage de cookies tiers
Tu fais disparaître tous les projets libre/open-source, la majorité des projets proprios font le vol aussi (j'écris ça sans source).
Les gens ne sont plus éduqués à connaître les outils qu'ils utilisent. Le marketing que les libristes peuvent détester (et j'en fais parti) conduit les gens à n'être que des consommateurs et rien de plus. On leur dit que Foo et meilleurs que Bar et ça leur suffit pour passer de Bar à Foo (sprintf Google Chrome et Firefox).
Dans ton analyse, tu échappes une partie de la population que veut reprendre les choses en main, surtout quand il s'agit des outils que leurs enfants utilisent (@see https://www.tinternet.net/ + les échanges avec les gens [très très loin des geeks] lors des rencontres).
L'idée est très bonne, mais je trouve dommage de faire un backup difficile à exploiter, alors que Borg permet de faire bien mieux (de mon point de vue) :
pg_dumpall | borg create repo::archive -, ce qui permet de restaurer avec un simpleborg extract --stdout repo::archive | psql dbnameborg create repo::archive *.conf. L'avantage ? Pouvoir extraire aussi simplement ces fichiers avecborg extract repo::archive filename destination, voire afficher directement le contenu avecborg extract repo::archive --stdout filenameAlors oui, ce que je propose n'est peut-être pas possible avec borgmatic (ne l'utilisant pas, je le connais mal), mais quitte à faire un script, autant en profiter pour faire un backup simple à exploiter. Pour la politique de rétention, Borg fait ça très bien tout seul avec la commande
borg prune. Pour vérifier la cohérence, c'estborg check. Et pas besoin de fichier de configuration supplémentaire ni de fichier de backup temporaire :)Le point important lorsqu'on utilise un dépôt qui contient plusieurs backups différents (ici bases de données et fichiers de configuration), c'est de bien les nommer, pour pouvoir utiliser le paramètre
--prefixdes commandesborg prune,borg list,borg check,borg delete, etc.).Oui, il aurait pu prendre Big Bunny en format RAW ou suite de PNG… https://media.xiph.org/BBB/
Qui plus est l'échantillon est tellement dégueu sur tous les formats que à part dire qu'à peu près rien ne se distingue…
C'est dommage ça aurait pu être très intéressant comme comparatif.
Attention sur le protocole du test : il part d'une vidéo déjà compressée, ce qui influe les résultats : le ré-encodage de vidéos dans un format continent forcément des artefacts lequels seront souvent ignorés au ré-encodage.
Des batteries de tests avaient ainsi proclamé la supériorité du h264, parce que justement la source avait été encodé une première fois dans ce format.
Idéalement, il faudrait un test à partir d'un format RAW,
Ah c'est top ca, j'ai les mêmes problemes, sauf qu'au lieu de relancer un script sur server au hasard je me connecte au site web pour telecharger la conf du “serveur recommandé”. A tester!
Tout à fait d'accord !
Si quelqu'un peut contacter l'auteur pour lui faire remonter cette correction d'erreur :
’s/Si lancez Wireshark/Si vous lancez Wireshark/'
++
J'ai vraiment bien aimé - même si je n'utiliserais pas… pour plusieurs raisons.
Édifiant. Merci ;)
Hé hé hé c'est justement parce que c'est incroyablement mauvais que c'est bon !
Tcho !
Je partage ma conf pour que ça devienne un top-modèle. (non vraiment c'est nul comme jeu de mot)
Clair, htop sur un serveur mutualisé par exemple est une mauvaise idée.
Tcho !
avec un h aspiré ? Parce que htop aspire pas mal de perfs pour un boulot simple
(retiens la porte, je te suis en courant)
Je propose un battle des jeux de mots pourris : Tip top l'article !
Tcho !
merci, je viens de corriger de nouveau.
Le lien que vous avez édité est cassé “https://githubhttps//github.com/madeindjs/api_on_rails/blob/master/fr/api_on_rails.adoc”
J'ai finalement fait pointer le lien vers les pages en français.
Le PDF est une bonne alternative, à l'exception de quelques trucs « [caractère Unicode non montré] » « car trop compliqué à faire avec LaTeX », sérieusement :‘)
C'est d'une telle clarté de lecture que cet ensemble de bonnes pratiques devrait intéresser plus d'un développeur avisé. À ajouter à votre définition du fini.
Aussi disponible en Anglais : https://www.canada.ca/en/government/publicservice/modernizing/government-canada-standards-apis.html . Mais les Canadiens sont tellement forts pour traduire les termes techniques anglophones…
Revendu à Huawei, je ne saurais dire, mais abandonné au profit d'une alliance avec l'équipementier chinois, ça semble effectivement le cas : https://www.lemagit.fr/actualites/450414065/Pour-son-cloud-public-Orange-sallie-avec-le-Chinois-Huawei
Non, je n'ai jamais visité ton site. ça fonctionne en navigation privée. J'utilise Vivaldi. UBLOCK Origin en Bloqueur de pub et blocage de cookies tiers
Tu fais disparaître tous les projets libre/open-source, la majorité des projets proprios font le vol aussi (j'écris ça sans source).
Les gens ne sont plus éduqués à connaître les outils qu'ils utilisent. Le marketing que les libristes peuvent détester (et j'en fais parti) conduit les gens à n'être que des consommateurs et rien de plus. On leur dit que Foo et meilleurs que Bar et ça leur suffit pour passer de Bar à Foo (sprintf Google Chrome et Firefox).
Dans ton analyse, tu échappes une partie de la population que veut reprendre les choses en main, surtout quand il s'agit des outils que leurs enfants utilisent (@see https://www.tinternet.net/ + les échanges avec les gens [très très loin des geeks] lors des rencontres).