La version communautaire est pour ma part limité, il y a une fonctionnalité qui n'existe que dans la version commerciale et qui est pour moi déterminante qui est celle de la stratégie de merge sur un pull request. Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.
Coté CI de gitlab, c'est assez simple à faire marcher par contre c'est beaucoup trop lié à GIT donc dès que tu veux faire des choses qui sont périodique avec tu te retrouve à bidouiller de faux événements git via cron, la dessus Jenkins est bien plus puissant. Pareille pour ce qui est tableau de reporting (avoir de joli graphique qui parle au chef de projet sur le nombre de tests qui passe etc…), coté gitlab on est très très limité.
Tout dépend à quel point tes données sont "Big" ou "Fast" pour avoir vraiment besoin de se genre d'écosystème. Quoiqu'il en soit, mesos me semble en tout cas un très bon choix pour gérer la charge multi-machine (que ça soit pour y mettre du bigdata dessus ou un simple "container management system" via marathon).
Dans le cas d'Android, il s'agit de java (enfin de dalvik) donc quand sa touche au bas niveau c'est via du C (par JNI). Dans ton cas si j'ai bien compris il y a ses propres syscall, comme on peut trouver en Go.
je m'insurge sur le fait de dire que la carte la plus ""Open-source" c'est la Raspberry PI, ce SOC est une infamie, c'est un gpu sur lequel ils ont collé un bout de cpu, le système d'init est complètement custom, y a pas de Global interrupt controller mais un truc custom qui passe par le gpu. Il a fallut super longtemps avant d'avoir un bootloader libre pour ce SOC.
Y a juste eu une énorme buzz autour de cette carte et donc une grosse traction de la communauté derrière mais je préfère mille fois le boulot fait par TI avec ses beagleboards si on veut comparer ceux qu'y ont l'approche la plus "Open-source".
J'ai pas trouvé l'info dans la documentation d'android pour savoir quels tests sont executés pour détecter la présence d'un téléphone root ou non mais si tu es pas allergique en anglais voici un lien qui montre quelqu'une des techniques possibles :
En résumé, tu as la recherche d'APK installé servant à rooter un téléphone (superuser.apk etc…), image signé ou non, présence de "su" et binaire busybox, modification de certaines propriétés systèmes.
Je vois pas où est le problème.L application Netflix repose sur des DRM et veux donc être sur que tu as pas bidouillé le système. Libre à toi de pas utiliser Netflix, ils ont jamais prétendu faire du libre.
Pour information la dernière version de kubernetes n'utilise plus l api de docker mais directement runC (l engine de docker qui est maintenant maintenu par OCI). Kubernetes comme mesos utilisent CNI pour le réseau, standard malheureusement non suivi par docker pour l'instant.
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).
# pluriel optionnel
Posté par Tangi Colin . En réponse au journal Écriture inclusive, comment la France a encore perdu une belle occasion de devenir leade(r|use).. Évalué à 10.
Le pluriel étant optionnel, agricult(eur|rice)s devrait plutôt être agricult(eur|rice)s{0,1}$ non ?
[^] # Re: git-repo ?
Posté par Tangi Colin . En réponse à la dépêche tsrc — un gestionnaire de dépôts git. Évalué à 3.
Git-repo existe sur Windows via un fork : https://github.com/esrlabs/git-repo , mise à jour récemment sur la dernière version de Google.
# Version communautaire limité
Posté par Tangi Colin . En réponse au journal GNOME va passer à GitLab. Évalué à 8. Dernière modification le 18 juillet 2017 à 09:54.
La version communautaire est pour ma part limité, il y a une fonctionnalité qui n'existe que dans la version commerciale et qui est pour moi déterminante qui est celle de la stratégie de merge sur un pull request. Avec la version communautaire seulement le merge request est permis, adieu les possibilités de rebase/squash+cherry-pick qui permettent d'avoir un historique linéaire.
Coté CI de gitlab, c'est assez simple à faire marcher par contre c'est beaucoup trop lié à GIT donc dès que tu veux faire des choses qui sont périodique avec tu te retrouve à bidouiller de faux événements git via cron, la dessus Jenkins est bien plus puissant. Pareille pour ce qui est tableau de reporting (avoir de joli graphique qui parle au chef de projet sur le nombre de tests qui passe etc…), coté gitlab on est très très limité.
[^] # Re: Hadoop ?
Posté par Tangi Colin . En réponse au journal Data Warehouse. Évalué à 3.
Puisque tu pars d'une feuille blanche, je te conseille de jeter un coup d’œil à l'architecture SMACK (pour Spark, Mesos, Akka, Cassandra, Kafka):
https://mesosphere.com/blog/2017/06/21/smack-stack-new-lamp-stack/
Tout dépend à quel point tes données sont "Big" ou "Fast" pour avoir vraiment besoin de se genre d'écosystème. Quoiqu'il en soit, mesos me semble en tout cas un très bon choix pour gérer la charge multi-machine (que ça soit pour y mettre du bigdata dessus ou un simple "container management system" via marathon).
[^] # Re: sans libc?
Posté par Tangi Colin . En réponse au journal Sortie de haskus-system 0.7. Évalué à 3.
Dans le cas d'Android, il s'agit de java (enfin de dalvik) donc quand sa touche au bas niveau c'est via du C (par JNI). Dans ton cas si j'ai bien compris il y a ses propres syscall, comme on peut trouver en Go.
[^] # Re: Pourquoi X86 (Intel)
Posté par Tangi Colin . En réponse à la dépêche Un pas en avant pour les serveurs libres : le projet NERF. Évalué à 7.
je m'insurge sur le fait de dire que la carte la plus ""Open-source" c'est la Raspberry PI, ce SOC est une infamie, c'est un gpu sur lequel ils ont collé un bout de cpu, le système d'init est complètement custom, y a pas de Global interrupt controller mais un truc custom qui passe par le gpu. Il a fallut super longtemps avant d'avoir un bootloader libre pour ce SOC.
Y a juste eu une énorme buzz autour de cette carte et donc une grosse traction de la communauté derrière mais je préfère mille fois le boulot fait par TI avec ses beagleboards si on veut comparer ceux qu'y ont l'approche la plus "Open-source".
[^] # Re: Comment l'application sait que l'appareil est rooté ?
Posté par Tangi Colin . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 4.
J'ai pas trouvé l'info dans la documentation d'android pour savoir quels tests sont executés pour détecter la présence d'un téléphone root ou non mais si tu es pas allergique en anglais voici un lien qui montre quelqu'une des techniques possibles :
https://medium.com/@scottyab/detecting-root-on-android-97803474f694
En résumé, tu as la recherche d'APK installé servant à rooter un téléphone (superuser.apk etc…), image signé ou non, présence de "su" et binaire busybox, modification de certaines propriétés systèmes.
[^] # Re: l'interet d'etre root
Posté par Tangi Colin . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 3.
Sur un téléphone android récent, la partition système est protégé par dm-verity (https://source.android.com/security/verifiedboot/dm-verity), donc modifier la partie système est le meilleur moyen de bloquer son téléphone.
# Titre racoleur et où est le problème ?
Posté par Tangi Colin . En réponse au journal Être root sur votre appareil Android va vous causer des soucis. Évalué à 7.
Je vois pas où est le problème.L application Netflix repose sur des DRM et veux donc être sur que tu as pas bidouillé le système. Libre à toi de pas utiliser Netflix, ils ont jamais prétendu faire du libre.
[^] # Re: Je ne comprends pas
Posté par Tangi Colin . En réponse au journal Mark Shuttleworth annonce l’abandon d’Unity. Évalué à 2.
Pour information la dernière version de kubernetes n'utilise plus l api de docker mais directement runC (l engine de docker qui est maintenant maintenu par OCI). Kubernetes comme mesos utilisent CNI pour le réseau, standard malheureusement non suivi par docker pour l'instant.
[^] # 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).