J'aime bien les réflexions en fin d'article. Gutenberg va diviser c'est clair mais c'est surtout la question de continuer avec WordPress qu'il faut se poser. Aujourd'hui il y a pléthore de solutions en face et notamment les sites statiques.

Tcho !

2019 dernière année du net… Entre ça et l'article 13 de l'UE c'est la fin pure et simple du net tel que nous le connaissons.

Tcho !

Il me semble que le RGPD ne s'applique qu'aux entreprises et compagnies hors là c'est un blog perso…

L'article parle des sites ne respectant pas le RGPD alors qu'il ne respecte pas lui-même, c'est un peu ironique non ?

“ne pas avoir activé par défaut l’autorisation de collecte et les services tiers ce qui est très très rarement le cas !”

C'est le cas notamment sur le blog avec le tracking via Piwik/Matomo ..

C'est l'application des bonnes pratiques du DDD, fallait lui trouver un nom et voila…

C'est juste un nom classe pour réécrire un méta-framework dans les grosses applications ?

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.).

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”