wilk a écrit 1171 commentaires

En Java on code vite mais y a beaucoup à coder ;-)

Bon je pense qu'il faut essayer pour être convaincu de l'intérêt du typage statique.

Je pense que le problème vient du fait qu'on résume le problème aux "erreurs de type". Hors j'ai toujours remarqué qu'en Python j'avais vraiment très peu d'erreur de type à l'exécution, du coup je ne comprenais pas trop d'où venait cette phobie.

Le typage statique ça n'est pas qu'une vérification de sécurité avant exécution, c'est surtout une aide à la saisie, à la refactorisation, à la documentation etc.

Je me suis amusé à compter en Python le nombre d'erreurs que je faisais qui auraient été détectées à la saisie en Go (j'utilise vim + vim-go), c'est impressionnant ! Mais je ne m'en rendait pas compte car ce sont des erreurs qui sont très vite détectées (F5 ou test unitaire) et faciles à corriger. De même pour le temps passé à jongler avec la documentation, rien d'impossible ni bloquant, mais juste plus long.

Donc je confirme, il faut essayer !

ps: je sais qu'il existe des éditeurs Python qui aident plus ou moins, mais c'est beaucoup plus lourd, moins sûr et très limité.

Du coup plus d'interopérabilité avec d'autres technos ?

Le monsieur te dit qu'il veut quelque chose de sérieux. Sérieux ça veut dire un minimum compliqué et pénible sinon c'est pas du jeu. Donc Go est hors jeu. Où plutôt Go est un jeu.

Le bug a été corrigé avec un appel téléphonique pour me prévenir. Un bon point Claude.

Niveau confidentialité des données y a pas mieux \o/

Tu as bien compris, ça n'est pas adapté à de l'incrémental.

Ou bien avec http://mattmahoney.net/dc/zpaq.html qui permet de créer un nouveau fichier à chaque incrément et donc d'archiver ce nouveau fichier, mais ça ne serait pas très pratique pour désarchiver.

Je n'ai pas précisé mais la suppression est également payante, c'est une opération (donc coût en fonction du volume), du coup un jonglage avec les archives aurait un coût.

Ce n'est pas parce qu'il n'y a rien par défaut qu'on n'utilise rien ou qu'il faut tout refaire par soit même… Au contraire même, on choisi ce qu'on utilise donc potentiellement plus de choses si besoin.
Inversement, dans un framework ou tout est inclus, si on doit utiliser quelque chose qui n'est pas inclus, là on va devoir "tout refaire".

Puisqu'on est dans les comparaisons, j'aime bien Pyramid pour sa flexibilité impressionnante. Je dirai même que c'est plus un toolkit de fabrication de framework qu'un framework. Donc si on a envie de se faire son framework aux petits oignons c'est l'idéal.

https://trypyramid.com/

https://blogs.oracle.com/Oracle-France/entry/la_cnaf_d%C3%A9mat%C3%A9rialise_la_prime

Et encore, c'est en Java, tu réécris tout ça en Go pour diviser par 10 ;-)
Ce qui va poser un problème c'est le budget, il faudra le justifier sous peine de ne plus avoir autant la prochaine fois.

Je disais un seul s3 dans le sens seulement sur un s3…

J'ai rarement eu de problème à cause d'un matériel défaillant, la plupart du temps les problèmes de sauvegardes viennent d'une mauvaise configuration, le mauvais répertoire indiqué, un exclude trop vaste, un lien non suivi etc. Pour ça je préfère multiplier les méthodes plus que les supports. Par exemple j'ai une sauvegarde intégrale mais avec peu d'historique, une autre avec de l'historique sur les parties plus critiques etc.

Tu utilises zpaq régulièrement, depuis longtemps ? La seule chose qui m'inquiète un peu c'est le dev qui a l'air un peu de considérer que c'est son jouet pour faire des expériences (d'après ce que je vois sur le forum).

Évidement oui, je ne me contente pas d'un seul dédié, c'est juste pour le côté "cloud". Mais je n'aurai pas non plus confiance en un seul S3. Pas tant que le support ne soit pas fiable, mais du fait que ma propre config d'upload puisse avoir des failles, humaines (par exemple sauvegarder un mauvais dossier).

Du coup je préfère multiplier les méthodes de sauvegardes plutôt que les sauvegardes elles mêmes. D'où mon journal sur zpaq qui complète un rsync + cp -al etc.

Quelque part ça m'arrange que ce soit en RoR, ça me fait une excuse pour ne pas participer ;-p

Mais je remercie Bruno de l'avoir fait car c'était un challenge (à l'époque RoR n'était pas si connu non ?) qu'il a réussi à mener haut la main et sorti linuxfr du bourbier php. On en bénéficie tous et surtout du fait qu'il nous fasse régulièrement bénéficier de cette expérience. C'était également le cas de templeet. Je trouve que c'est une bonne chose que linuxfr soit le fruit d'une passion, ne serait-ce que celle d'un moment (pas sûr qu'il utilise toujours Ruby non ?), plutôt que d'un consensus mou pour bénéficier de contributions. Je n'utilise pas Ruby non plus, mais je suis sur que si on voulait vraiment on pourrait contribuer quand même sans trop de difficulté (un autre dinosaure et collectionneur de langages qui parle) et que Bruno donnera volontiers le coup de main pour ne pas rester bloqué dans les méandres de Ror.

Et sinon tout reste à faire alors. Qu'est-ce qu'on essaye d'autre comme réécriture ? Des micro-services en Go ? Je suis persuadé que Bruno ne manque pas d'idée de ce genre (mais plus de framework hein) ! Bha, finalement le dinosaure va plutôt retourner s'occuper de sa marmaille… (nouvelle excuse : si je ne contribue pas c'est à cause de mes gosses)

C'est l'heure du goutter.

Je préfère encore utiliser un nuage perso dans le coin d'un dédié (chez online pour ma part).
C'est comme ça qu'a démarré amazon s3, ils ont utilisé leur architecture existante pour louer l'espace disponible. Et finalement je crois que c'est ce qui leur rapporte le plus maintenant.
La seule contrainte que je vois c'est que la capacité est moins flexible. En revanche ça permet de faire tout un tas de vérifications et stats des données sur le serveur lui-même.

On peut même se monter son propre s3, c'est ce que je suis entrain de m'amuser à faire avec https://minio.io + https://restic.github.io/
Mis à part qu'il est clairement indiqué en rouge "Minio server is under active development. Do not deploy in production." ça marche et c'est vraiment très simple à déployer. Presque trop simple, on n'a pas du tout envie de tenir compte de cette note !

Un nouveau venu en Rust : https://github.com/dpc/rdedup

J'ai essayé restic qui a l'air plutôt bien parti et dont le développement semble un peu plus "moderne" que zpaq (ce qui n'est pas péjoratif, loin de là). Avec une création d'exécutable multiplateforme grâce au langage Go qui est bien pratique.
Il a l'air bien au fait de ce qui se fait avec un dépôt recensant les alternatives :
https://github.com/restic/others
En fait il y en a une tripotée, je ne me rendais pas compte.

https://camlistore.org/ est prometteur mais en fait peut-être un peu trop ? Je préfère un outil de sauvegarde minimaliste quitte à lui associer d'autres outils.

https://github.com/tsileo/blobsnap est intéressant aussi, il s'appuie sur https://github.com/tsileo/blobstash (du même auteur, Français, cocorico) un stockage clé/valeur avec déduplication

Vu le gain que je j'ai en terme de volume, jusqu'à diviser par 10 ! Le temps de compression devient insignifiant par rapport au temps de transfert gagné.

arrêter de jouer à l'homme orchestre

C'est relatif, de mon côté (indep qui ne travaille que très rarement en équipe) j'observe plutôt l'inverse. Ma tâche c'est le développement, mais du fait de gérer aussi le système ça me permet de bosser dans un environnement aux petits oignons et donc de ne pas perdre de temps à m'adapter à un système moins adapté ou que je ne maîtrise pas. Et quitte à être coupable, autant prendre les devants !

Je ne me souviens plus pourquoi j'ai changé par rapport à vimperator… Peut-être plus rapide ?
Pour le dev firebug, mais je me demande si ça reste indispensable vu les progrès des outils intégrés.
Pour les pubs, rien de mieux que ce qui a été mis en commentaires.

Ok, je n'avais pas réalisé que les tags fonctionnaient comme ça.
Je ne sais pas comment mais on peut fermer ma requête.

Le problème est qu'il y a les deux tags, donc finalement on met les deux à la fois ou on en oublie un… Je trouve que ce serait plus clair de n'en conserver qu'un.
Si je prend http://linuxfr.org/tags/golang/public je risque de manquer ceux qui ont mis uniquement le tag Go par exemple (et ils n'auront pas forcément tort puisque c'est le nom officiel).

Le fait d'avoir les deux tags n'enlève pas cette ambiguïté là, de fait c'est le tag Go qui est le plus utilisé pour le langage.

http://linuxfr.org/tags/go/public

Ou alors il faudrait un tag Go-lang et un tag Go-jeu mais pas de tag Go tout court.
Comme les deux sont à la fois différents à la fois relativement liés (le langage s'inspire en partie du jeu) ça ne me choque pas d'avoir les deux sous le même tag (c'est déjà le cas).

http://www.wired.com/2016/03/go-grandmaster-lee-sedol-grabs-consolation-win-googles-ai

Excellent ce passage, à voir oui ! C'est vraiment ce qui marquera ces parties, les coups vraiment surprenants.

Il me semble avoir entendu parler d'une obligation que ce soit entièrement automatisé pour pouvoir dégager la responsabilité du passager, sinon c'est trop ambigu en cas problème.
Sinon, imaginons un passager de taxi qui aurait une certaine responsabilité sur la conduite…