wilk a écrit 1110 commentaires

É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…

Une voiture qui roule à 37km/h et qui ne monte pas sur les trottoirs, c'est plutôt une feature qu'un problème. Ca obligerait à un peu plus de responsabilité du côté des aménagements ce qui ne serait pas plus mal.

C'est ce que je trouve vraiment intéressant. On n'est pas dans une reproduction des meilleurs coups mais bien dans une sorte d'apprentissage.

D'après l'ingénieur, AlphaGo serait censé privilégier 1 demi point à 99 chances sur cent que 20 points à 80 chances sur cent. Quelque part je me demande si on va continuer à pouvoir parler d'agressif et défensif quand il s'agit d'un robot qui se contente de juste gagner !

Par contre tu as sûrement raison car sur la deuxième partie il parait plus clair que les coups sont considérés comme agressifs, d'autant plus que Lee jouait blanc et avait quand même décidé d'être plus défensif…

En tout cas là où il n'y a pas d'ambiguïté c'est que les coups sont surprenants ! Lee dit qu'il est choqué et sans voix ! (alors qu'il était plutôt confiant au départ)
Ke Jie lui reste encore confiant mais voudrait jouer vite avant que le robot ne progresse !
http://www.shanghaidaily.com/national/AlphaGo-cant-beat-me-says-Chinese-Go-grandmaster-Ke-Jie/shdaily.shtml

C'est vraiment paradoxal pour un programme qui est censé jouer par observation des parties déjà jouées de sortir des coups imprévisibles…
Ce soir on pourra revoir la partie commenté par Motoki sur kgs, à 20h30
Attention il faut java, hier je me suis fais avoir j'avais pas prévu le 1/4 d'heure pour installer java, rajouter une barrette mémoire, modifier /etc/java-7-openjdk/sound.properties pour avoir le son…

Y a plus qu'à essayer soit-même !
https://www.tensorflow.org/

J'ai regardé la partie commenté par Motoki hier soir (on peut le revoir sur KGS), ça n'est pas ce que j'ai retenu. Des coups surprenants mais pas agressifs pour autant. Après à ce niveau c'est difficile de faire la différence, je serai curieux de savoir s'il est possible d'analyser les logs d'AlphaGo pour voir s'il s'est "senti" en difficulté ou pas et si ça l'aurait obligé à être agressif ou s'il s'est senti en avance et que ses coups consolidaient sans qu'on ne s'en rende compte. Est-ce que le robot a cette notion ?
Motoki a montré quelques coups considérés comme surprenants en début de partie qui se sont avérés solides en fin de partie.

Mais bon, tu as raison dans le sens où ça ne semble pas être une partie juste sans erreur comme ça peut être le cas aux échecs.

Et même solution : les microservices :-)

Tu as raison il faut préciser le contexte sinon on ne sait pas de quoi on parle.
Mon créneau c'est beaucoup de petites et moyennes (1 à 15K lignes de code très concis) applications web très spécifiques, dont certaines vont durer très longtemps et évoluer dans des sens non définis au départ et que je gère quasiment seul. Genre des gestion de chantiers qui commencent gérées au siege, puis par des agences, puis par des chefs d'équipe sur leur smartphone etc… Après ça sera une gestion de résidents d'une maison de retraite qui pointent leur repas, leur ménage etc. Ou bien un site de vente de livres, où les éditeurs se regroupent puis se séparent puis se regroupent à nouveau, un jeu en ligne, un service de calcul d'itinéraire… Je suis également admin sys de tout ça, cad quelque dizaines d'apps en cours. Et c'est chouette de rentabiliser sa passion :-)

Donc mon casse tête c'est de pouvoir réutiliser le maximum de composants pour ne pas réinventer et réapprendre la roue. A court terme un bon framework c'est royal pour moi, j'essaye souvent.
Mais sachant que les composants et frameworks vont avoir une durée de vie plus courte que certaines applis et qu'ils seront utilisés dans des contextes parfois très différents, il faut impérativement que j'évite les effets de bords, dans l'instant et sur la durée, qu'en faisant évoluer un composant ça n'impacte pas les autres mais qu'une ancienne appli puisse quand même en bénéficier facilement un jour.

Si j'avais utilisé des gros frameworks, j'aurai du en utiliser plusieurs en même temps dont certains qui n'existeraient plus. Imagine si j'avais à maintenir des applis Zope et Django en même temps avec une demande d'évolution vers les websockets ou une contrainte de perf…
En revanche, avec un micro framework comme Pyramid je trouve un outil qui me permet de remplacer progressivement des composants de mon framework perso sans avoir à changer une ligne de code de mon appli. Donc j'achète, au pire je revend plus tard, le coût de la manoeuvre reste faible. Je prend Pyramid comme exemple car la doc explique de manière très détaillée cette philosophie, qui plus est par un ancien de Zope qui connaît bien le domaine, ça vaut le coup d'être lu même si on ne l'utilise pas.

Je faisais l'analogie avec la philosophie Go dans le sens où les auteurs ont décidés d'accepter une fonctionnalité du langage que s'ils étaient tous d'accord. J'applique la même règle avec mes composants perso, pour en faire une lib que je vais partager il faut que toutes mes applis soient d'accord, même la plus ancienne. En attendant : "une petite copie vaut mieux qu'une grosse dépendance" (Rob Pike).

C'est sûrement pas universel mais c'est assez marrant de partager certains points de vue entre Google et un indep ! J'ai vraiment été surpris. De la même manière quand je me suis aperçu que je pouvais utiliser Python pour le boulot, un langage qui semblait fait pour les enfants !

Je ne dis pas que je n'utilise pas d'orm, je dis juste que si je veux changer d'orm je ne veux pas avoir à changer de template pour autant.

Je ne cherche pas à être hors de toute dépendance, mes projets dépendent souvent de postgresql et reportlab par exemple mais aucun d'eux ne m'oblige à utiliser un orm quelconque ou à mettre mes fichiers de conf à tel endroit par exemple.
On n'utilise pas les mêmes frameworks du coup j'ai l'impression que ça commence à devenir difficile de savoir de quoi on parle…

J'ai des applis qui durent depuis plus de dix ans donc ça m'arrive assez souvent de changer un composant principal. Je préfère changer composant par composant que tout d'un coup. Si je dois démarrer une nouvelle app avec un autre moteur de template, je n'ai pas envie d'avoir à réaprendre un nouveau méga-framework et changer d'orm pour autant.
Mais bon, je ne cherche pas à convaincre, c'est juste mon expérience après avoir étudié et essayé les deux.