Reprise du message précédent :

much, on t'a reconnu, arrête de hacker les comptes des autres

J'aurais bien voulu être à l'origine de cette LU, tiens

 
Quelle LU ? Ça ?

C'est pas une LU, c'est sourcé de façon claire: le responsable de l'enquête, c'est "le capitaine Jacques Hasses".

 
J'ai pas dit qu'utiliser des containers te faisait forcément faire de la merde. Je dis deux choses :
- que pour ceux qui font déjà de la merde, c'est une aubaine de pousser plus loin leur caca ;
- que les flemmards qui devaient passer par de la doc/recettes pour les admins peuvent être tentés de raccourcir certaines étapes.
 
Un outil n'est pas "mal" en soi, c'est la façon de l'utiliser qui fait que. Et pour Docker, aujourd'hui j'ai vu que des gens profiter de la techno pour y cacher leur merde ("bah je vais pas me faire chier à faire une doc d'install/dépendances, tiens télécharge mon docker et voilà" ). Et là toi, quand tu dois dépanner le machin, t'es bien emmerdé (true story)
 
Docker y est pour rien directement

http://www.docker.com/whatisdocker/
je vois pas trop comment tu peux merger ça entre développeurs

Nan c'est bon, j'avais loupé leur slogan

 
Oui ça ok, on est d'accord que ce n'est pas la faute à Docker ;D
 

 
L'idée (en tout cas la manière dont je l'utilise), c'est de versionner ton code comme habituellement, et d'avoir ton Dockfile à la racine. Dockfile que tu renseigne pour l'install et la config des softs qui vont bien, et qui attache le code dans le dossier de ton choix.

donc ça remplace les scripts de déploiement de l'appli et des serveurs ?
ça va dans le territoire de puppet du coup ?

 
j'ai déjà eu un mac tu sais...
 
 
sinon rien à voir avec les macs, mais lié à la discussion : comment changer le shell par défaut quand on se connecte en SSH à Vagrant via Idea ?
 
si je me connecte par Putty, j'ai bien fish, mais si je me connecte par Idea, j'ai bash...j'ai vu aucune config dans idea pour changer ça, et je confirme que le user vagrant a fish comme shell par défaut dans /etc/passwd
 
j'ai essayé de jouer avec la vagrantfile, mais config.ssh.shell = "fish" ne fonctionne pas...
 
 
sinon j'ai lu un peu la doc de docker et regardé ce que ça fait. Je suis surpris que les admin sys laissent faire, dans la mesure où ils perdent complètement la main sur la config serveur. C'est surement génial si t'as une team de devops et que tout ton stack tient sur un node, mais hors de ce cas, ça me parait casse gueule (ce que semble dire Plam aussi si j'ai bien compris ce qu'il a raconté)
 

au pire du pire, le docker file défini toute la merde, et normalement l'admin sys doit savoir lire couramment le shell.
a la différence du jeu des sept erreurs pour chercher les écarts entre le serveur de dev et celui de prod  
 
Contrairement à une doc jamais à jour, le code ne ment pas, et le docker file centralise tout ce code à un seul endroit.
 
Je trouve, au contraire, que ça va dans la bonne direction

@jubi : le dockerfile n'est pas forcement construit par le dev. Dans une équipe avec des devops ou des admin system on peut penser qu'ils seront  les garant d'avoir un dockerfile qui tient la route. La syntaxe et le gros usage du shell en font aussi un outil d'admin sys

Perso, je vois deux modes de fonctionnement au dockerfil:

• petits projets : le dev assume et maitrise le déploiement de bout en bout. Aujourd'hui un projet est plus souvent de l'assemblage de brique et un peu de colle que l'inverse. La prod est ainsi très proche de ce qu'a valider le dev sur sa machine.

• gros projet : le dev peut réinjecter les paramétrage de l'équipe système dans  sont environnement de développement, et bosser sur un serveur similaire à celui de la prod.

 
Il y a plusieurs approche, et je n'ai pas assez de recul pour savoir laquelle utiliser. Mais l'avantage est qu'il y a du Git derrière, et que tu peux versionner facilement ton container avec les outils intégrés.
 
Par exemple, tu peux te connecter à ton container y installer des mises à jour, tester etc. Si ça passe, tu commit/push ton container, si ça ne passe pas tu reviens en arrière.
 
Mais le container à proprement parler n'est bien entendu pas stocké dans ton appli, que tu commit indépendamment.
 
Après tu peux aussi hoster ton code directement dans le container, et uniquement commiter ce dernier, mais je n'aime pas l'approche. Pour moi un container doit être indépendant du code qu'il va héberger.
 
Mais comme je l'ai dis, je n'ai pas assez de recul pour faire les bons choix.
 

 
C'est con, y'a pas de réponse : http://stackoverflow.com/questions [...] ccessed-fr
 

Redmon, 54000 habitants, 32 000 employés de Microsoft
 
Même si tous les employés habitent pas la ville, il doit quand même un avoir un sacré appel d'air le matin.

Pour moi ce n'est pas vraiment la bonne direction, mais c'est mon passé de sysadmin qui parle

SaltStack par exemple est une meilleure solution, car tu n'es pas lié à une solution technique de virtu (bare-metal, hypervisor, container). Ce côté là (choix technique de mise en prod, très dépendant du contexte) n'est pas le problème du développeur. Mais je dis pas que Docker c'est mal : au contraire, pendant le processus de développement, c'est parfait !

Au delà, il y a tout un monde de problématiques où les conteneurs ne sont pas la panacée par rapport à un hyperviseur ou bare-metal (isolation, sécurité, choix du kernel, autre distrib voulue par le client, utilisation de lien SAN spécifiques, configuration réseau spécifique, outil de monitoring, intégration dans une infra existante, etc). N'oubliez pas que les clients ont autant de besoins qu'il existe de clients, et qu'intégrer tout ça dans un datacenter ou dans une infra existante, c'est totalement impossible sans souplesse de la techno utilisable.

Bref, Docker n'est pas la solution pour stabiliser le proche Orient, mais un outil de plus pour fluidifier le dev

http://www.reddit.com/r/programmin [...] _side_bar/
oops

edit: en fait c'est Discourse qui était buggé.

d'accord...effectivement le fait de ne plus jouer aux 7 erreurs peut avoir un intéret (je compte plus les MEP qui foirent alors que ça marchait sur l'environmment de test iso PROD )
 
par contre je sens que ça va pas venir dans les grosses COGIP tout de suite (bien qu'on ait Puppet, on est pas trop à la rue encore)
 

ouaip, technos du malin
comme c'est lié à Idea, je vais aller voir chez eux

C'est déjà une bonne chose d'avoir un Puppet (même si ça reste un peu trop compliqué à utiliser vs un Salt).

Pour avoir vu un certain nombre de boîtes tourner, celles qui allaient bien c'était avec dev -> devops -> admin. En gros le « devops » c'est l'intégrateur qui vérifie pas mal de chose avant de faire passer en prod à l'admin (recette, perfs, tests de charges, doc basique de management de l'appli), pour que l'admin en bout de chaîne, qui met en prod n'aie plus qu'à faire son boulot d'admin : gérer au mieux les ressources à disposition (serveurs, switchs, énergie) tout en rentrant dans les process sécurité/disponibilité/flexibilité. Genre machine qui explose à 4h du matin dimanche, utilisation de la recette, remonter une machine en très peu de temps. D'ailleurs on touche l'intéret de la recette « générique » : s'il n'a plus de ressources sur une des technos (mettons plus de de RAM dispo sur les hyperviseurs), il peut utiliser rapidement autre chose sans réfléchir (un serveur physique). J'aime bien cette idée de rester générique au maximum.

P.S : dans la vraie vie, l'admin et le devops c'est souvent la même personne.

edit : je pense qu'on verra de plus en plus des infras « mixtes » (hyperviseur, container, bare metal)

dans mon équipe y'avait pas d'admin, tout le monde avait les accès root
 
Comme ça, à l'heure de choisir une manière de faire les choses, ils peuvent choisir de faire un acte de développement ou de faire un acte de configuration. Y'a pas de "je fais mon truc et l'admin se démerde à déployer".
 
L'idée c'est vraiment d'essayer de contourner la loi de Conway.

 
 
mouais, j'ai 3 mots pour vous : COGIP, "segragation of duties", audit
 
@Plam : dans ma boite, et on est qu'un micro embryon du vaisseau amiral, les devs ont 0 droits en dehors des environnements de dev. Ce qu'ils font, y'a une équipe spéciale en charge de l'installer (et ça doit passer par un environnement de test avant d'aller en PROD), et une équipe en charge de le configurer, qui doit donc jouer la recette donnée par les devs
 
@nray : dev qui met en PROD, on se prend un audit, c'est non compliance direct (du genre grave, avec du sang et gens virés)
 
Note : je suis pas viscéralement attaché à ces process hyper lourdingues, mais c'est vrai que dans les grosses boites y'a une telle inertie qu'ils veulent du controle, et qu'ils ont l'impression que suivre ces procédures rajoute du controle.
 
 
mon gros problème c'est qu'il y a peu de place pour la gestion de projet / management dans une petite boite, donc des gens comme moi n'existe que dans les grosses boites

Nous on taffe sur un projet depuis bientôt 8 mois et on a 0 test unitaire/fonctionnel, tout va bien, pas d'affolement  

compliance avec quoi ? des critères d'attardés mentaux genre ISO 9000 ?

Je le comprends, tu n'as pas vraiment le choix quand tes clients sont du genre à auditer leur prestataires selon leurs critères (ex : les labos pharmaceutiques, l'industrie chimique, etc), tu te plies à leurs critères (genre pas de dev qui pousse en prod) ou tu fais faillite en perdant tes clients  

on parle de Nestlé, c'est eux qui dictent les drafts des traités internationaux à l'ONU.

Bon, j'ai finalement craqué. J'ai installé Steam sur mon portable perso.
Par contre, je ne sais pas quoi prendre.

Qu'est-ce que vous recommandez comme jeux ? (récents ou oldies goldies, mais dispo)

Pourquoi t'installes Steam si t'as pas de jeu à y acheter
"Eh les gars, je suis à Walmart, qu'est-ce que j'achète ?"

\o/ Walmart \o/
 
C'est mieux qu'eurodisney \o/
 
J'adore \o/

Parce que j'ai envie d'un petit jeu, là, comme ça
Et y'a pas de lecteur de DVD sur mon portable.

http://qrostar.skr.jp/index.cgi?page=jelly&lang=en

FTL
Bastion
Don't Starve
Papers, Please
The Wolf Among Us
Dungeons of Dredmor

Bon, j'hésite. Et sinon, Ultimate General Gettysburg est à 7€50 et a l'air sympa.

voilà...
 

 
this
 
en fait ça vient de la façon meme dont la compliance est mesurée dans les audits :
- soit tu inventes ton propre process, tu le documentes à fond, tu le fais certifier pour montrer qu'il y a pas de failles : ça prend des mois, c'est long, c'est chiant
- soit tu dis : hé, nous on suit le process XXX, qui est certifié 9001 / compliant avec la procédure interne ABC déjà auditée, etc... et hop, t'as rien besoin de faire
 
 
bon sinon petite couille d'idea, il m'avait pas mis à jour le plugin python, ça merdait velu avec Vagrant, mais là ça marche bien depuis que j'ai mis le nouveau. J'ai fait un provisionning tout simple via shell (je sais pas me servir de puppet, salt, ansible et autre) et ça roule.
Par contre c'est dans la douleur, je me plance 10 fois par lignes

Série complète pas encore sortie

Nouvelle CG commandée pour remplacer l'autre qu'est morte et pouvoir enfin recommencer à jouer

Also nouveau boitier, nouvelle alim et un peu de RAM

Et alors?

 
C'est trop ça, si ta solution est mieux mais complètement différente de ce à quoi ils sont habitués tu vas lutter comme un galérien, si tu fais le même genre de caca que les autres bien ISO-mes couilles tu évites les vagues.

Watch dogs : Critics 78/100 Users 4.7/10
 
http://www.metacritic.com/browse/g [...] /metascore
 
Hmmm hmmm

http://games.on.net/2014/06/ubisoft-game-the-review/

J'suis le seul à avoir un problème avec Gmail ? (reste bloqué sur « Loading me@gmail.com)

edit : FF KO, Chromium OK. Dunno why.

edit 2 : reviendu

Et alors y a des gens comme moi qui aiment pas se lancer dans une série pour jouer 2-3h et patienter 4 à 6 mois pour avoir la suite

Watch_Dogs c'est typiquement un jeu qui sera parfait en soldes à moins de 20 € avec le patch qui va avec. A 60 € 2 semaines après la sortie par contre, non.