Et avant openvz y avait les jails sur freebsd, les zones sur Solaris. Et si on veut remonter au début, la philosophie d isolation était déjà dans chroot en 1978. Donc la hype elle est pas là pour rien et quand tu regarde la liste des membres du projet open container initiative c'est pas près de se dégonfler.
Niveau technologie, je sais que cachefly repose sur du TCP anycast, quelqu'un sait si les autres CDN sont sur le même type de techno ? C'est plutôt standardisé (via des RFC par exemple) ou chacun à sa solution custom ?
Usine à gaz ça dépend du nombre de machine et de "vlan" que tu veux gérer, si tu veux vraiment scaler c est encore ce qui marche le mieux. Les overlays netWork c est moins performant . Si le sujet t intéresse et que l anglais te fait pas peur, regarde par la: http://docs.projectcalico.org/master/introduction/ (ils ont une doc où ils expliquent pourquoi bgp et pas ospf).
Dire que les conteneurs ça ne scale pas j ai un peu du mal avec ça, suffit de voir les démos hyperscale de mesos pour être convaincu du contraire. Je sais pas comment on fait des conteneurs chez toi mais perso je trouve ça propre et les développeurs gèrent pas le réseau, ni la collecte des logs d ailleurs (12 factor apps), après on est d accord qu il sa faut des gens compétents qui gèrent la platerforme. Docker et ipv6 c est des sujets complètement orthogonaux pour moi. La non migration d ipv4 à ipv6 n est en aucun cas lié au vm mais au fait que on a pas pensé la transition, par exemple combien de temps entre le début des normes ipv6 et les premiers tunelles 6 to 4?
Docker gère tout type de réseau, par défaut c'est un bridge, mais tu as tout les configurations possibles. T'a perdu ton boulot à cause d'un devops pour être aussi négatif ?
Oui les VM (afin les première version des outils de chez VMware) ne géré que du L2 et on a crée des énormes réseau L2 avec tout les problèmes que ça a amenés mais ce temps la est révolu. Un DevOps "compétant" il te fait du L3 avec du iBGP pour le routage maintenant (et depuis quelque temps déjà).
Après toute migration IPv4 -> IPv6 est compliquée, beaucoup de gens croit que c'est juste la taille des IP qui a grossie mais c'est quasiment tout qui change, y a beaucoup de chose a réapprendre (ARP -> NDP, les multiples configuration possible entre RA et DHCPv6 etc…).
Le client lourd n'apporte pas beaucoup plus de sécurité que l'appli webmail. Lors de ton installation de ton client lourd ou lors d'une de ses mise à jour, qui tu dit que tu as pas une backdoor dans ton client lourd ?
Tu va me dire que tu installe ton client depuis les paquets de ta distribution linux préférée et que tu fais confiance aux mainteneur pour t'avoir fournie un logiciel sans backdoor mais c'est qu'une question de confiance et à qui tu donne cette confiance.
Vérifier du code javascript via une signature c'est tout à fait techniquement possible. Bref client lourd vs client web, le problème n'est qu'une question de confiance et de vérification de code via signature.
je suis d'accord avec le début de l'histoire (cloud vs grid). Par contre sur l'avancé incroyable d'Amazon je la nuancerai. Effectivement Amazon sont les premiers à en avoir fait un business avec une offre publique. Mais par contre, Google est loin d’être en retard la dessus, leur offre commerciale est arrivé après mais google font du "cloud" et du conteneur depuis longtemps, ils ont entre 5 à 10 ans d'avance sur les autres.
Ils ont jamais vraiment aimé les VMs et font du conteneur depuis très longtemps (avant même docker, il y avait lmctfy (let me container that for you))
Leur FS distribué GoogleFS date d'avant 2003 (date de la publication de leur papier (http://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf))
Qui inspirera nutch, qui sera racheté par yahoo et qui deviendra quelque années plus tard HDFS (BigData Hadoop/HFDS public c'est vers 2007/2008 uniquement).
La technologie Map/Reduce vient aussi de chez eux (premier papier publié en 2004).
Borg (ancien Kubernete) existe aussi depuis très longtemps (j'ai pas de date précise, depuis 2005 au moins), il faudra attendra Mesos (2009/2010) pour avoir un équivalent libre. Voir a se sujet : Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon
Aujourd'hui le PAAS va très loin en terme de fonctionnalité, il y a un mouvement de fond en se moment autour du '#serverless' (pour ma part je trouve que le terme est très mal choisie, le terme 'vmless' serait plus adapté).
Avec des offres tels que Amazon lambda, Google Cloud Functions ou Azure Functions on a des offres où tu décris juste la fonctionnalité voulue (Tu te déclenche sur tels événements, tu fais tels traitement et tu sauvegarde dans tels backend) et tu t'occupe de rien d'autre et avec un payement à l’utilisation (Granularité à 100ms).
Par rapport à des serveurs qui n'ont que 15% du temps de la charge, c'est économiquement intéressant (et y a bien entendu possibilité de choisir des plafonds pour éviter de se faire ruiner face à une attaque massive).
En relisant l'offre que vous proposez, je suis surpris de constater que chaque serveur n'a qu'une interface SFP+. Sur la photo on voit un port SFP et un port RJ45 (j'image que le RJ45 est pour l'interface de management).
Vous pouvez sans doute pas nous dire de chez qui vous avez récupéré les serveurs mais je suis vraiment surpris de voir qu'il n'y a pas de redondance réseaux au niveau du serveur. La redondance ce fait qu'au niveau des racks et pas en dessous. Bon après c'est un histoire de config, doit y avoir moyen de rajouter une deuxième carte SFP+ 10Gbe.
Gérer le physique de serveurs n'est pas très reluisant mais je connais aussi pas mal de personne dans un contexte professionel qui sont un peu sensibilisé à la localisation de leur données et qui seraient prêt à s'auto-heberger si une solution simple et pérenne existait.
Avec une solution comme ça, il faut au minimum 3 machine pour fournir de la redondance, un rack, 2 switch (redondance), des batteries (vu qu'opencompute supporte le 48V DC, c'est bien moins chère que l'onduleur) et un modem 3G/4G pour avoir une connectivité de secoure. Dessus on mets du openstack et/ou mesos et on peut offir un mini-data cléfs en main pour environ 4000-5000$. Mon inconnu dans cette solution, restant le switch alim (bascule 230V vers 48VDC). Opencompute propose-t-il des solutions hardware la dessus ?
Le plus compliqué restant toujours le stockage. Le NAS pour une offre "mini-DC" peut valoir le coût, c'est pas trop chère.
Soit on fait un fs distribué (HDFS,GlusterFs,Infinit, Ceph) mais ces solutions sont assez peu performantes en I/O sur des petites fichiers (la plupart de ces solutions sont accessible en "posix" qu'à travers fuse).
J'attends de voir ce que deviendra Infinit après le rachat par Docker.
Sinon y a la solution SAN mais qui faut encore un bras. OpenCompute travail t-il aussi sur des SAN opensource ?
Gitlab-ce est limité par rapport à Gitlab-ee (entreprise edition).
Il y a une option manquante dans la version CE pour un vrai usage de développement au quotidiens et en équipe qui est la possibilité de choisir ça stratégie de merge lors d'un pull request. Dans la version communautaire seul le merge est permis (ce qui crée un historique non linéaire :/). La version payante (et donc non libre) rajoute toutes les possibilités (fast forward, rebase, squash and cherry-pick (ma méthode préfère sur gerrit, si j'ai besoin de plus de détails sur un "patchset" j'utilise le commit-id de gerrit)).
Pour une installe maison libre, je préfère un gerrit + jenkins. Le plugins gerrit de jenkins est plutôt bien fait et permet de mettre en place des intégration continue multi-git de manière assez simple (pour un coté haute disponibilités je mets jenkins avec du mesos/docker mais ça c'est une autre histoire).
Après j'avoue que le runneur de gitlab avec docker est un jeu d'enfant à mettre en place, par contre c'est du mono-git, faut tricher dans tous les sens pour faire de l'intégration continue sur des projets multi-git.
Je suis surpris que personne avant moi est fait la remarque ici, comme quoi ipv6 est toujours aussi mal connue. Il n'y a pas de taille fixe de masque réseau en /64 en ipv6, c'est juste une convention assez largement répandu.
Pour plus de détails je vous conseille cette très bonne lecture : http://www.bortzmeyer.org/7421.html
Lui, comme son entreprise, ne me semblent pas être de grandes sources d'innovation, mais davantage des entités qui ont l'intelligence de saisir les forces en puissance qui animent l'époque (aujourd'hui "l'open source", qu'on peut distinguer du "libre" peut-être ici), les assembler pour en tirer le meilleur profit.
Microsoft est énormément vaste, ok ils sont moins populaire sur le desktop c'est derniers temps (et encore, la suite office reste plus que majoritaire dans les entreprises). Mais ils ont fait pas mal d'innovation, quand ça marche, il faut avoir l’honnêteté de le reconnaître. Dans cette histoire il y a par exemple la Kinect. Ok la première génération a été faite en coopération avec la société PrimeSense (racheté par Apple depuis). Mais ils ont poussé le produit super loin et aujourd'hui ils ont la dessus une avance technologique énorme. Le modèle de reconnaissance de squelette est aujourd'hui utilisé dans une très grande majorité de laboratoire qui travail sur de la reconnaissance d'image. Aucune alternative libre la dessus. Les labos préfère travaille sur des fonctionnalité avancé en partant du SDK kinect que d'opensourcé les fonctionnalité de ce SDK.
La XBox dans son ensemble est aussi une belle réussite, ils sont arrivé tard dans le monde de la console et ils ont réussi à ce faire une place.
Azure est aussi une sacré réussite en 'on-premise', un paquet de grand groupes on du cloud Azure 'on-premise' et leur ouverture vers linux, vers docker et clairement dicté pour que Azure (leur nouvelle poule aux oeufs d'or) est une longue vie.
D'abord leur distribution linux pour les routeurs gérant leur cloud azure, puis la libération de C#, la mgiration de pas mal de chose de codeplex vers github, le support de l'api docker, leur investissement dans mesosphère …
La question a mille dollars, combien de temps avant une distribution Linux par Microsoft pour aller concurrencé red hat ?
Moins de 5 ans, ça me surprendrais pas plus que ça.
la beaglebone black de chez TI est bien mieux à ce niveau la et element 14 fournit une version "industrielle" avec des composants allant de -40 à 85°C.
J'ai d'ailleurs jamais compris l'engouement qu'il y a eu pour la raspberry pi alors qui la beagle est bien plus intéressante pour faire des POC (et antérieur à la raspberry pi). Broadcom ont joué une joli coup marketing et on ceux se refaire une virginité "opensource" grâce à ça, la raspberry c'est un cpu grevé (bizarrement) sur un GPU, ok c'est mieux qu'une beagle pour faire tourner un XBMC/Kodi sur une télé mais pour tout les autre cas d'utilisation la beagle est vraiment plus intéressante (avec un support par défaut dans yocto/poky d'ailleurs).
En plus de ne pas être libre c'est pour moi du jetable. Ce genre de carte sont des cartes fait pour faire du prototypage, pas de la production. Leur MTBF doit pas dépasser 2 ans et les composants sont dans des plages de température de fonctionnement faibles. Je vois de plus en plus ce genre de carte installé dans des armoires électriques à coté d'éléments de puissance (qui chauffe donc un max) ou sur la voie publique (armoire d'éclairage publique) où ça gèle l'hiver, brancher sur des réseaux qui sont fortement bruité avec plein d'harmonique. Résultat après 2 ou 3 ans et/ou après un hiver très très froid ou un été très très chaud, ça tombe en panne et faut les changer (et sur ce genre de carte pas de réparation possible, la seul solution c'est le remplacement). Faire de l'électronique (numérique en plus) qui dure 10 ans et qui résiste au froid et au chaud ça existe mais ça coute bien plus chère que ces cartes de prototypage.
Ansible est clairement plus simple que puppet ou chef,le coté déploiement par ssh évite d'avoir des clients installés sur les cibles. Par contre niveau syntaxe et organisation des différentes fichiers c'est pas toujours ce qu'il y a de plus simple, le yaml permet pas mal de syntaxe différentes, les playbooks sont vraiment de qualité variables (très peu on des dry-run par exemple). Et malheureusement ça nécessite d'avoir du python sur la cible, ce qui n'est pas gênant pour du x86 mais beaucoup plus si on veut l'utiliser dans l'embarqué.
Par expérience, ayant déjà travaillé en tant que prestataire chez des grosses boites du CAC40 (dont je ne dévoilerais pas ici le nom) sur des gros projets de "platforming Linux", je peux témoigner que la problématique des licences est très mal comprises de ses grosses boites (ce sont pas de boites d'informatiques) et leur service juridiques est à la ramasse la dessus. Leur réflexe est de payer des millions pour avoir du WindRiver Linux (alors qu'ils ont déjà du Vxwork et mette tous leurs oeufs dans le meme panier (alors que coté hardware ils ont des politiques très strictes de multi sources, multi fournisseurs)), dé-fois c'est un peu moins pire c'est du Mentor Graphics. M'enfin dans les deux cas, ils font ça pour se rassurer sur les problèmes juridiques, alors que Mentor Graphics ou WindRiver ne leur apport aucune garantie la dessus, il leur livre juste un yocto (afin dans le cas de WindRiver leur livraison est tellement dégueulasse que j'ai du mal à appeler ça du yocto) et donc la responsabilités de ne pas mixer des licences incompatible reste entièrement à leur charge (vu qu'il achète pas une distribution mais une meta-distribution qu'ils vont bidouiller de tout les cotés pour faire entrer dedans leur vieux code legacy porté à la rache depuis un µOS).
le pragmatisme est aussi un dogme en soit donc je trouve l'utilisation du terme pragmatique en opposition de dogmatique ne fait pas de sens. Tu aurais du utiliser "PURISTE" à la place de dogmatique.
Les russes ont obligés les acteurs du "cloud" à héberger leur données sur le sol russe si les utilisateurs sont russe. Apple avec iCloud s'y est par exemple plié l'année dernière, je pense qu'on pourrait s'inspirer de ça aussi en Europe, ça éviterai que la majeur partie du trafic européen passe par les USA et donc compliquerai les écoutes passive de la NSA et ça remplirai nos data-center plutôt que ceux des USA.
Mais bon le protectionnisme parait que c'est pas cool pour l'économie donc l’Europe fera jamais ça.
Pour rappel, dans toute techno radio, le débit est partagé entre tous les usagers de la cellule (donc oui, il y a une pertinence technique à faire de la QoS lorsque le réseau sature. ça ne veut pas dire que ton VPN ne doit plus fonctionner. Par contre ton VPN n'a peut-être pas les mêmes contraintes de latence/synchronicité qu'un flux vidéo ? De toute façon, si la capacité/spectre est limitée et que trop de monde consomme, il faut bien faire des choix donc de la QoS…).
Le choix ça peut très bien être de ne pas faire de choix. Et donc de ne privilégié personne par rapport à un autre, il n'y a aucune obligation. Appel ça de la Fair QoS si tu veux :)
la QoS / fiabilité (usages de type public-safety, opérations chirurgicales, etc.)
Pour moi ça c'est une connerie sans nom, tu fais pas de la chirurgie à distance sur internet, c'est un non sens par rapport à la topologie/architecture du réseau internet. Tu fais ça sur des réseaux dédié (ou la tu peux réserver ton tuyaux/trajet) et avoir un minimum de critère temporelle. Internet (relié des réseaux/AS entre eux) n'en a aucun. Ta QoS elle passera jamais les 42 différents AS entre le medecin et l'appareille de chirurgie, si tu as pas des réseaux dédiés, c'est mort.
Bon je sais bien que le sens de l'histoire va pas vers la mais je trouve ça vraiment dangereux de vouloir rendre "internet" par le réseau intelligent et "temps réel"/public-safety.
c'est que je voulais dire, c'est que ce qui coûte chère c'est l'enfouissement et que l'enfouissement des lignes cuivres est encore plus chère que la fibre. On se sert d'une "nouveauté technologique" la fibre, pour faire payer aux collectivité publique via des Réseaux d'Initiative Publique l’enfouissement des lignes de quelques grosse boite privé grâce à la Délégation de Service Publique et ceci souvent de manière onéreuse (c'est des nouvelles technologies, c'est normal que ça soit chère, ou pas).
C'est assez scandaleux je trouve, et à part l'Ain (qui est en régie et pas en DSP) je connais pas beaucoup d'endroit à ça se passe bien. Mais bon, vu que c'est de la technologie on arrive à enfumer beaucoup de monde, alors que déployer de la fibre c'est 95% de génie civile.
Quand à l'aérien je dis pas qu'il faut déployer de la fibre en aérien partout, je dis juste que cette possibilité n'est jamais étudié alors qu'elle peut parfois valoir le coup.
[^] # Re: Je ne comprends pas
Posté par Tangi Colin . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 6.
Et avant openvz y avait les jails sur freebsd, les zones sur Solaris. Et si on veut remonter au début, la philosophie d isolation était déjà dans chroot en 1978. Donc la hype elle est pas là pour rien et quand tu regarde la liste des membres du projet open container initiative c'est pas près de se dégonfler.
[^] # Re: cloudfl..what?
Posté par Tangi Colin . En réponse au journal Oh, la belle prise (chez CloudFlare). Évalué à 1.
Niveau technologie, je sais que cachefly repose sur du TCP anycast, quelqu'un sait si les autres CDN sont sur le même type de techno ? C'est plutôt standardisé (via des RFC par exemple) ou chacun à sa solution custom ?
[^] # Re: Quand quelqu'un l'aura codé
Posté par Tangi Colin . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 1.
Usine à gaz ça dépend du nombre de machine et de "vlan" que tu veux gérer, si tu veux vraiment scaler c est encore ce qui marche le mieux. Les overlays netWork c est moins performant . Si le sujet t intéresse et que l anglais te fait pas peur, regarde par la: http://docs.projectcalico.org/master/introduction/ (ils ont une doc où ils expliquent pourquoi bgp et pas ospf).
[^] # Re: Quand quelqu'un l'aura codé
Posté par Tangi Colin . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à 5.
Dire que les conteneurs ça ne scale pas j ai un peu du mal avec ça, suffit de voir les démos hyperscale de mesos pour être convaincu du contraire. Je sais pas comment on fait des conteneurs chez toi mais perso je trouve ça propre et les développeurs gèrent pas le réseau, ni la collecte des logs d ailleurs (12 factor apps), après on est d accord qu il sa faut des gens compétents qui gèrent la platerforme. Docker et ipv6 c est des sujets complètement orthogonaux pour moi. La non migration d ipv4 à ipv6 n est en aucun cas lié au vm mais au fait que on a pas pensé la transition, par exemple combien de temps entre le début des normes ipv6 et les premiers tunelles 6 to 4?
[^] # Re: Quand quelqu'un l'aura codé
Posté par Tangi Colin . En réponse au journal À quand l’IPv6 sur LinuxFr.org ?. Évalué à -2.
Docker gère tout type de réseau, par défaut c'est un bridge, mais tu as tout les configurations possibles. T'a perdu ton boulot à cause d'un devops pour être aussi négatif ?
Oui les VM (afin les première version des outils de chez VMware) ne géré que du L2 et on a crée des énormes réseau L2 avec tout les problèmes que ça a amenés mais ce temps la est révolu. Un DevOps "compétant" il te fait du L3 avec du iBGP pour le routage maintenant (et depuis quelque temps déjà).
Après toute migration IPv4 -> IPv6 est compliquée, beaucoup de gens croit que c'est juste la taille des IP qui a grossie mais c'est quasiment tout qui change, y a beaucoup de chose a réapprendre (ARP -> NDP, les multiples configuration possible entre RA et DHCPv6 etc…).
[^] # Re: Webmail
Posté par Tangi Colin . En réponse au journal Google chiffrement de mail end to end . Évalué à -3.
Le client lourd n'apporte pas beaucoup plus de sécurité que l'appli webmail. Lors de ton installation de ton client lourd ou lors d'une de ses mise à jour, qui tu dit que tu as pas une backdoor dans ton client lourd ?
Tu va me dire que tu installe ton client depuis les paquets de ta distribution linux préférée et que tu fais confiance aux mainteneur pour t'avoir fournie un logiciel sans backdoor mais c'est qu'une question de confiance et à qui tu donne cette confiance.
Vérifier du code javascript via une signature c'est tout à fait techniquement possible. Bref client lourd vs client web, le problème n'est qu'une question de confiance et de vérification de code via signature.
[^] # Re: Cloud et Grid
Posté par Tangi Colin . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 4. Dernière modification le 04 janvier 2017 à 09:50.
je suis d'accord avec le début de l'histoire (cloud vs grid). Par contre sur l'avancé incroyable d'Amazon je la nuancerai. Effectivement Amazon sont les premiers à en avoir fait un business avec une offre publique. Mais par contre, Google est loin d’être en retard la dessus, leur offre commerciale est arrivé après mais google font du "cloud" et du conteneur depuis longtemps, ils ont entre 5 à 10 ans d'avance sur les autres.
Ils ont jamais vraiment aimé les VMs et font du conteneur depuis très longtemps (avant même docker, il y avait lmctfy (let me container that for you))
Leur FS distribué GoogleFS date d'avant 2003 (date de la publication de leur papier (http://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf))
Qui inspirera nutch, qui sera racheté par yahoo et qui deviendra quelque années plus tard HDFS (BigData Hadoop/HFDS public c'est vers 2007/2008 uniquement).
La technologie Map/Reduce vient aussi de chez eux (premier papier publié en 2004).
Borg (ancien Kubernete) existe aussi depuis très longtemps (j'ai pas de date précise, depuis 2005 au moins), il faudra attendra Mesos (2009/2010) pour avoir un équivalent libre. Voir a se sujet : Return of the Borg: How Twitter Rebuilt Google’s Secret Weapon
# PAAS++
Posté par Tangi Colin . En réponse au journal C'est quoi le "cloud computing" ? 1/2. Évalué à 2.
Aujourd'hui le PAAS va très loin en terme de fonctionnalité, il y a un mouvement de fond en se moment autour du '#serverless' (pour ma part je trouve que le terme est très mal choisie, le terme 'vmless' serait plus adapté).
Avec des offres tels que Amazon lambda, Google Cloud Functions ou Azure Functions on a des offres où tu décris juste la fonctionnalité voulue (Tu te déclenche sur tels événements, tu fais tels traitement et tu sauvegarde dans tels backend) et tu t'occupe de rien d'autre et avec un payement à l’utilisation (Granularité à 100ms).
Par rapport à des serveurs qui n'ont que 15% du temps de la charge, c'est économiquement intéressant (et y a bien entendu possibilité de choisir des plafonds pour éviter de se faire ruiner face à une attaque massive).
# Une seul interface SFP+ 10GB par serveur ?
Posté par Tangi Colin . En réponse au journal Et si l'Open Hardware démocratisait l'usage d'ordinateurs reconditionnés ? . Évalué à 1.
En relisant l'offre que vous proposez, je suis surpris de constater que chaque serveur n'a qu'une interface SFP+. Sur la photo on voit un port SFP et un port RJ45 (j'image que le RJ45 est pour l'interface de management).
Vous pouvez sans doute pas nous dire de chez qui vous avez récupéré les serveurs mais je suis vraiment surpris de voir qu'il n'y a pas de redondance réseaux au niveau du serveur. La redondance ce fait qu'au niveau des racks et pas en dessous. Bon après c'est un histoire de config, doit y avoir moyen de rajouter une deuxième carte SFP+ 10Gbe.
[^] # Re: Créer un nouvel hébergeur
Posté par Tangi Colin . En réponse au journal Et si l'Open Hardware démocratisait l'usage d'ordinateurs reconditionnés ? . Évalué à 3.
Gérer le physique de serveurs n'est pas très reluisant mais je connais aussi pas mal de personne dans un contexte professionel qui sont un peu sensibilisé à la localisation de leur données et qui seraient prêt à s'auto-heberger si une solution simple et pérenne existait.
Ca me fait penser à Ubuntu qui avait sortir son Metal as a Service : http://3.bp.blogspot.com/-2YzvgRL6i14/U3BXULQkO1I/AAAAAAAAvjM/oCibggAGQaY/s1600/ob.png , bon depuis sur leur site maas.io j'arrive plus à trouver le hardware, ils se sont concentré sur la solution soft (openstack + juju) et s'adapte à n'importe quel architecture hardware.
Avec une solution comme ça, il faut au minimum 3 machine pour fournir de la redondance, un rack, 2 switch (redondance), des batteries (vu qu'opencompute supporte le 48V DC, c'est bien moins chère que l'onduleur) et un modem 3G/4G pour avoir une connectivité de secoure. Dessus on mets du openstack et/ou mesos et on peut offir un mini-data cléfs en main pour environ 4000-5000$. Mon inconnu dans cette solution, restant le switch alim (bascule 230V vers 48VDC). Opencompute propose-t-il des solutions hardware la dessus ?
Le plus compliqué restant toujours le stockage. Le NAS pour une offre "mini-DC" peut valoir le coût, c'est pas trop chère.
Soit on fait un fs distribué (HDFS,GlusterFs,Infinit, Ceph) mais ces solutions sont assez peu performantes en I/O sur des petites fichiers (la plupart de ces solutions sont accessible en "posix" qu'à travers fuse).
J'attends de voir ce que deviendra Infinit après le rachat par Docker.
Sinon y a la solution SAN mais qui faut encore un bras. OpenCompute travail t-il aussi sur des SAN opensource ?
[^] # Re: ce n'est pas un problème d'outillage
Posté par Tangi Colin . En réponse au journal Git : les bases et guide d'utilisation en mode centralisé (à la SVN). Évalué à 3.
Gitlab-ce est limité par rapport à Gitlab-ee (entreprise edition).
Il y a une option manquante dans la version CE pour un vrai usage de développement au quotidiens et en équipe qui est la possibilité de choisir ça stratégie de merge lors d'un pull request. Dans la version communautaire seul le merge est permis (ce qui crée un historique non linéaire :/). La version payante (et donc non libre) rajoute toutes les possibilités (fast forward, rebase, squash and cherry-pick (ma méthode préfère sur gerrit, si j'ai besoin de plus de détails sur un "patchset" j'utilise le commit-id de gerrit)).
Pour une installe maison libre, je préfère un gerrit + jenkins. Le plugins gerrit de jenkins est plutôt bien fait et permet de mettre en place des intégration continue multi-git de manière assez simple (pour un coté haute disponibilités je mets jenkins avec du mesos/docker mais ça c'est une autre histoire).
Après j'avoue que le runneur de gitlab avec docker est un jeu d'enfant à mettre en place, par contre c'est du mono-git, faut tricher dans tous les sens pour faire de l'intégration continue sur des projets multi-git.
# Erreur sur le masque de réseau fixe
Posté par Tangi Colin . En réponse au journal Jouons un peu avec les adresses IPv6…. Évalué à 8.
Je suis surpris que personne avant moi est fait la remarque ici, comme quoi ipv6 est toujours aussi mal connue. Il n'y a pas de taille fixe de masque réseau en /64 en ipv6, c'est juste une convention assez largement répandu.
Pour plus de détails je vous conseille cette très bonne lecture : http://www.bortzmeyer.org/7421.html
[^] # Re: Comme d'habitude...
Posté par Tangi Colin . En réponse au journal Linux en rémission ?. Évalué à 6.
Microsoft est énormément vaste, ok ils sont moins populaire sur le desktop c'est derniers temps (et encore, la suite office reste plus que majoritaire dans les entreprises). Mais ils ont fait pas mal d'innovation, quand ça marche, il faut avoir l’honnêteté de le reconnaître. Dans cette histoire il y a par exemple la Kinect. Ok la première génération a été faite en coopération avec la société PrimeSense (racheté par Apple depuis). Mais ils ont poussé le produit super loin et aujourd'hui ils ont la dessus une avance technologique énorme. Le modèle de reconnaissance de squelette est aujourd'hui utilisé dans une très grande majorité de laboratoire qui travail sur de la reconnaissance d'image. Aucune alternative libre la dessus. Les labos préfère travaille sur des fonctionnalité avancé en partant du SDK kinect que d'opensourcé les fonctionnalité de ce SDK.
La XBox dans son ensemble est aussi une belle réussite, ils sont arrivé tard dans le monde de la console et ils ont réussi à ce faire une place.
Azure est aussi une sacré réussite en 'on-premise', un paquet de grand groupes on du cloud Azure 'on-premise' et leur ouverture vers linux, vers docker et clairement dicté pour que Azure (leur nouvelle poule aux oeufs d'or) est une longue vie.
[^] # Bientot une distribution commercial linux par microsoft ?
Posté par Tangi Colin . En réponse au journal Linux en rémission ?. Évalué à 6.
D'abord leur distribution linux pour les routeurs gérant leur cloud azure, puis la libération de C#, la mgiration de pas mal de chose de codeplex vers github, le support de l'api docker, leur investissement dans mesosphère …
La question a mille dollars, combien de temps avant une distribution Linux par Microsoft pour aller concurrencé red hat ?
Moins de 5 ans, ça me surprendrais pas plus que ça.
[^] # Re: Raspberry Pi libre???
Posté par Tangi Colin . En réponse au journal Liberasys : visualisation des consommations électriques pour Lorient. Évalué à 1.
la beaglebone black de chez TI est bien mieux à ce niveau la et element 14 fournit une version "industrielle" avec des composants allant de -40 à 85°C.
J'ai d'ailleurs jamais compris l'engouement qu'il y a eu pour la raspberry pi alors qui la beagle est bien plus intéressante pour faire des POC (et antérieur à la raspberry pi). Broadcom ont joué une joli coup marketing et on ceux se refaire une virginité "opensource" grâce à ça, la raspberry c'est un cpu grevé (bizarrement) sur un GPU, ok c'est mieux qu'une beagle pour faire tourner un XBMC/Kodi sur une télé mais pour tout les autre cas d'utilisation la beagle est vraiment plus intéressante (avec un support par défaut dans yocto/poky d'ailleurs).
[^] # Re: Raspberry Pi libre???
Posté par Tangi Colin . En réponse au journal Liberasys : visualisation des consommations électriques pour Lorient. Évalué à 3.
En plus de ne pas être libre c'est pour moi du jetable. Ce genre de carte sont des cartes fait pour faire du prototypage, pas de la production. Leur MTBF doit pas dépasser 2 ans et les composants sont dans des plages de température de fonctionnement faibles. Je vois de plus en plus ce genre de carte installé dans des armoires électriques à coté d'éléments de puissance (qui chauffe donc un max) ou sur la voie publique (armoire d'éclairage publique) où ça gèle l'hiver, brancher sur des réseaux qui sont fortement bruité avec plein d'harmonique. Résultat après 2 ou 3 ans et/ou après un hiver très très froid ou un été très très chaud, ça tombe en panne et faut les changer (et sur ce genre de carte pas de réparation possible, la seul solution c'est le remplacement). Faire de l'électronique (numérique en plus) qui dure 10 ans et qui résiste au froid et au chaud ça existe mais ça coute bien plus chère que ces cartes de prototypage.
[^] # Re: Ansible
Posté par Tangi Colin . En réponse au journal Simple Provisioning System. Évalué à 2.
Ansible est clairement plus simple que puppet ou chef,le coté déploiement par ssh évite d'avoir des clients installés sur les cibles. Par contre niveau syntaxe et organisation des différentes fichiers c'est pas toujours ce qu'il y a de plus simple, le yaml permet pas mal de syntaxe différentes, les playbooks sont vraiment de qualité variables (très peu on des dry-run par exemple). Et malheureusement ça nécessite d'avoir du python sur la cible, ce qui n'est pas gênant pour du x86 mais beaucoup plus si on veut l'utiliser dans l'embarqué.
# Le commit de fix dans le kernel
Posté par Tangi Colin . En réponse au journal CVE-2016-5195 Dirty COW. Évalué à 6.
Le fix coté kernel peut etre trouvé ici avec une rapide explication de linus torvald :
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=19be0eaffa3ac7d8eb6784ad9bdbc7d67ed8e619
# Un service d'intégration continue en mode SaaS
Posté par Tangi Colin . En réponse au journal Le Cloud et la gestion de ses poubelles. Évalué à 2.
Avec ça, je m'installe Mesos dessus avec le plugins Jenkins et je fournis un service d’intégration continue.
[^] # Re: bof
Posté par Tangi Colin . En réponse au journal Faut-il défendre la GPL devant les tribunaux ?. Évalué à 5.
Par expérience, ayant déjà travaillé en tant que prestataire chez des grosses boites du CAC40 (dont je ne dévoilerais pas ici le nom) sur des gros projets de "platforming Linux", je peux témoigner que la problématique des licences est très mal comprises de ses grosses boites (ce sont pas de boites d'informatiques) et leur service juridiques est à la ramasse la dessus. Leur réflexe est de payer des millions pour avoir du WindRiver Linux (alors qu'ils ont déjà du Vxwork et mette tous leurs oeufs dans le meme panier (alors que coté hardware ils ont des politiques très strictes de multi sources, multi fournisseurs)), dé-fois c'est un peu moins pire c'est du Mentor Graphics. M'enfin dans les deux cas, ils font ça pour se rassurer sur les problèmes juridiques, alors que Mentor Graphics ou WindRiver ne leur apport aucune garantie la dessus, il leur livre juste un yocto (afin dans le cas de WindRiver leur livraison est tellement dégueulasse que j'ai du mal à appeler ça du yocto) et donc la responsabilités de ne pas mixer des licences incompatible reste entièrement à leur charge (vu qu'il achète pas une distribution mais une meta-distribution qu'ils vont bidouiller de tout les cotés pour faire entrer dedans leur vieux code legacy porté à la rache depuis un µOS).
# A rajouter à la liste
Posté par Tangi Colin . En réponse au journal Un peu de vert.. Évalué à 10.
En france, on a aussi Kokopelli (https://fr.wikipedia.org/wiki/Kokopelli_(association)) qui a eu quelques soucis avec la justice d'ailleurs (car commercialisant des plantes qui n'était pas référencées).
[^] # Re: chromium only
Posté par Tangi Colin . En réponse au journal 'Epeios organizer' : nouveaux types de champs (widgets jQuery) et onglets. Évalué à 2.
le pragmatisme est aussi un dogme en soit donc je trouve l'utilisation du terme pragmatique en opposition de dogmatique ne fait pas de sens. Tu aurais du utiliser "PURISTE" à la place de dogmatique.
[^] # Pendant ce temps la en Russie...
Posté par Tangi Colin . En réponse au journal Safe Harbor est mort, vive Safe Harbor !. Évalué à 10.
Les russes ont obligés les acteurs du "cloud" à héberger leur données sur le sol russe si les utilisateurs sont russe. Apple avec iCloud s'y est par exemple plié l'année dernière, je pense qu'on pourrait s'inspirer de ça aussi en Europe, ça éviterai que la majeur partie du trafic européen passe par les USA et donc compliquerai les écoutes passive de la NSA et ça remplirai nos data-center plutôt que ceux des USA.
Mais bon le protectionnisme parait que c'est pas cool pour l'économie donc l’Europe fera jamais ça.
[^] # Re: 5G vs EDGE ?
Posté par Tangi Colin . En réponse au journal Internet, 5G et chantage. Évalué à 1.
Le choix ça peut très bien être de ne pas faire de choix. Et donc de ne privilégié personne par rapport à un autre, il n'y a aucune obligation. Appel ça de la Fair QoS si tu veux :)
[^] # Re: Difficileàlire
Posté par Tangi Colin . En réponse au journal Internet, 5G et chantage. Évalué à 6.
c'est que je voulais dire, c'est que ce qui coûte chère c'est l'enfouissement et que l'enfouissement des lignes cuivres est encore plus chère que la fibre. On se sert d'une "nouveauté technologique" la fibre, pour faire payer aux collectivité publique via des Réseaux d'Initiative Publique l’enfouissement des lignes de quelques grosse boite privé grâce à la Délégation de Service Publique et ceci souvent de manière onéreuse (c'est des nouvelles technologies, c'est normal que ça soit chère, ou pas).
C'est assez scandaleux je trouve, et à part l'Ain (qui est en régie et pas en DSP) je connais pas beaucoup d'endroit à ça se passe bien. Mais bon, vu que c'est de la technologie on arrive à enfumer beaucoup de monde, alors que déployer de la fibre c'est 95% de génie civile.
Quand à l'aérien je dis pas qu'il faut déployer de la fibre en aérien partout, je dis juste que cette possibilité n'est jamais étudié alors qu'elle peut parfois valoir le coup.