Dans l'Ain ce qui a fait que ça à marché ça provient aussi de fait que la très grande majorité du département (plus de 95%) avait son réseau électrique en régie dans le même syndicat intercommunal d'energie (http://www.siea.fr/) et c'est ce qui a gradement facilité le déploiement du réseau. C'est sur que dans un département au toutes les communes ont bradé leur infrastructure à des sociétés privés en mode délégation de service publique c'est tout de suite beaucoup plus compliqué à monter.
Un deuxième point sur la fibre qui je trouve rarement critiqué, c'est de dire que la fibre coûte chère à poser, ce qui est un gros raccourci.
Le mètre linéaire brut de fibre coûte moins chère que le mètre linéaire de cuivre. Le raccordement lui coûte plus chère que pour du cuivre (c'est plus compliqué à souder de la fibre que du cuivre).
Mais ce qui coûte vraiment chère quand on parle de "poser de la fibre", c'est l'enfouissement, or la fibre peut très bien marcher en aérien, les opérateurs telco le font d'ailleurs sur leur infra interne parfois (tels que certaines antennes sur des sommets de montagne).
Rien de nouveau sous le soleil, le partenariat microsoft/docker commence à dater.
Pour rajouté de l'information à l'information, microsoft à faillit racheter mesosphere aussi mais c'est finalement ravisé et à juste investit quelques millions lorsque que la startup mesosphere a fait son round C de levé de fonds.
Les Etats unis c'est loin d’être parfait. Ils font du "copyright-free" si tu es au Etats Unis, si c'est utilisé en dehors des Etats Unis il se réserve le droit d'appliquer leur copyright, bref du bon vieux protectionnisme. Y avait des discussions sur une liste de diffusion de debian il y a pas très longtemps : https://lists.debian.org/debian-legal/2016/01/msg00002.html
La question à sans doute déjà été répondu ailleurs mais j'ai la flemme de chercher :)
Huile et sous vide c'est cool pour les contraintes extérieur mais pour la maintenance j'ai un doute.
Pour une raison ou une autre je veux ouvrir mon boîtier pour en changer un composant, je fais comment?
Pour ça, il aurait fallu une licence correcte.
Quand on voit déjà les menaces de procès que se prend Canonical pour "oser" faire du libre avec du libre, ça ne donne pas du tout envie d'aller fouiller dans cet endroit.
Pour une fois je te trouve pas du tout objectif avec une remarque comme ça. Toi qui répète sur linuxfr qu'une licence libre ne donne que les droits qui sont écrits dans la licence et pas un de plus et la tu fait l'amalgame grossier entre deux licences libres clairement différentes dont l'une a sciemment été écrite pour ne pas être compatible avec l'autre.
Normale que Canonical se prenne des baffes pour ça.
Pourquoi avoir choisi un fork d'harmony à l'origine et pas openjdk je sais pas trop. Peut être pour marqué leur opposition franche à la GPL (bien que ici le classpath exception d'opendjk ne crée aucun soucis de licence).
Oui et non, google a jamais publié leur algo lié a leur moteur de recherche effectivement.
Mais si tu prend le cas de twitter par example, l'ensemble de leur backbone repose sur Mesos qui un projet libre et ils y contribuent énormément dessus. Ce qui a obligé Google à aussi libérer le sien (Kubernetes (ça fait bien 10 ans qu'ils ont la techno en interne et il le libère que maintenant face à la concurrence)).
Je pourrais parler de netflix aussi avec OSS (le code source de l'ensemble de leur SI basé sur Amazon).
Facebook publie aussi son matos sur opencompute.org.
Donc d'un point de vue code (je parle pas du sujet des données personnelles et des services qu'ils vendent dessus) les grosses boites font énormément de logiciel libre c'est devenue une guerre (marketing, recrutement, …) entre elles.
Je rajouterai à ça de bien pensé à ses processus de mis à jour des images.
On peut utiliser Clair pour détecter des vulnérabilité dans ses images : https://github.com/coreos/clair ou simplement régénérer souvent ses images dans un processus de Continuous Delivery avec des test de non régression de bonne qualités ça se passe tranquillement.
Avoir un SSH dans un conteneur docker est considéré comme une mauvaise pratique. Mieux vaut avoir un unique accès SSH sur le host et ensuite faire un docker exec pour entrer dans un conteneur.
Parce que sinon, avoir 150 docker déployés ça fait beaucoup de clé ssh à gérer.
Si on veux vraiment joué à qui à la plus courte faut aller plus loin, configuré yocto pour utiliser µlibc ou même musl, strippé le tout etc…
Mais honnêtement un debian (depuis un deboostrap où on vire les man, les timezones, les langues) ça tient en 40 mo seulement tout en ayant "apt-get". Je préfère largement ça et niveau politique de sécurité je rebuild et redéploie mes images toutes les semaines (donc j'ai un apt update qui s'exécute une fois par semaine).
Tout est dans le titre, je sais qu'il y a plus d'un mainteneur debian qui moule sur linuxfr, ça serait intéressant de savoir comment debian gère ce cas de figure.
2) Ils ne seraient pas les premiers à faire ça, Intel a fait pareil.
Ref needed :)
Je dis pas que c'est faux, je demande juste à que les propos soient un minimum sourcé quand il s'agit de balancer comme ça gratuitement sur certains nom de marque/société connues.
Ils n’ont pas besoin de ça. Les drivers Windows des développeurs de GPU sont bourrés de réécritures de shaders pour les gros jeux; ils détectent à la volée un jeu (AAA) et remplacent les shaders des devs(!!) par une version plus performante sur leurs GPUs.
C’est cet mascarade qui a amené la plupart des éditeurs (OS, moteurs, jeux…) et vendeurs de GPU à convaincre Khronos de faire un API bien plus complexe (Vulkan) permettant de mieux exploiter les GPUs modernes sans une connaissance ultra-poussée des paramètres de chaque GPU.
ta as des sources de ce que tu avances ? Je suis preneur d'une information plus détaillée sur le sujet.
que nvidia optimise son SDK pour ces cartes je le comprends (qu'il est pas envie de tester/optimiser leur code sur des cartes concurrentes), par contre que Nvidia fasse l'inverse, c'est a dire rajouter sciemment du code pour que le résultats soient ralenties sur les cartes concurrentes j'y crois moins, y a trop de risque de perte d'image de la marque si l'info fuite.
C'est pas un peu du FUD ça ?
Dans ton premier lien, y a rien qui parle de la licence MIT et dans le deuxième il y a rien qui dit que c'est la licence du "diable". Tu fait le même procès d'intention à jQuery ou Symfony (exemple tiré de ton deuxième lien qui utilise aussi du MIT)?
Oui, il n'y a pas de virtualisation dans docker donc le conteneur windows sur linux ou l'inverse c'est pas possible. Ce que les Windows conteneur sont c'est des API Windows (donc pas grand chose à voir avec les namespaces, capabilities, etc…) mais avec comme client "au niveau" Docker.
Je connaissais pas Xpra, si je comprend bien chaque conteneur à son serveur X à l'intérieur et Xpra sert de "proxy", j'ai bon ou je suis complètement à coté de la plaque ?
C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?
Effectivement docker et systemd sont en conflit ouvert je dirais, voir à ce sujet le dernier billet sur LWN.
Après dire que la plateforme sous jacente n'est plus importante n'est pas forcément faux, si tu passe tout dans des conteneurs tu te moque de la plateforme (modulo la version de ton kernel). Y en a qui ont appliqué ce principe à l’extrême c'est rancherOS (http://rancher.com/rancher-os/) ou tu te retrouve sur un système ou tu as juste un docker "système" et un docker "user" et rien d'autre, tous le reste tourne dans des conteneurs.
On verra qui gagne la bataille du conteneur entre systemd et docker mais je dirais que pour l'instant docker à une longueur d'avance pas sur le plan technique car effectivement l'approche daemon n'est pas la meilleur mais niveau eco-system/buzz ils sont loin devant. Le fait que les Windows conteneur utilisent l'API Docker c'est plutôt impressionnant je trouve. Et docker Inc travaille sur une approche non daemon aussi , ça s'appelle containerd (https://github.com/docker/containerd).
Historiquement Docker était une surcouche à LXC, jusqu’à la version 0.7 si mais souvenirs sont bons.
Et puis le développeur de docker ont eu pas mal d’écueils avec LXC, pas les même version suivant les distributions, des cassage d'API/ABI trop souvent et pas documenté et ils ont alors décidés d'implémenter leur propre solution en Go.
Et en dessous de libcontainer maintenant tu as runC (https://blog.docker.com/2015/06/runc/) qui est uniquement le runtime de container (sans toute la tuyauterie réseaux ). runC est du code Docker qui a était donné au projet Open Container Format de la linux fondation (dont docker est membre). C'est une réponse au "pseudo-standard" Rocket/Appc fait par CoreOS.
Y a aussi Ubuntu qui tente de vivre de son sponsoring de LXC en créant LXD.
Ceci n'est qu'une première étape puisque avec l'architecture actuelle de docker (daemon), le namespace user est le meme pour l'ensemble des conteneurs. Tu peux dire UID O du conteneur et l'UID 10049 à l'extérieur du conteneur mais ce mapping ce fera pour l'ensemble des conteneurs.
Cette fonctionnalité arrive tard dans docker par rapport à LXC par exemple qui le gère depuis longtemps. Ceci est lié au fait que docker étant basé sur du Go (golang), il a fallut attendre que les syscalls permettant d'activer les usernamespace soit implémenté dans ce langage, ce qui est arrivé avec le version 1.4 de Go. Ensuite la limitation proposé par l'architecture daemon a pas mal fait réfléchir les dévellopeurs sur la meilleur stratégie à appliquer. Voir ici un excellent résumé : http://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf
Il y a une deuxième feature de sécurité apporté par la version 1.10 qui j'attendais depuis très longtemps, c'est l'intégration par défaut de seccomp. Voir ici : https://github.com/docker/docker/blob/master/docs/security/seccomp.md
La on a vraiment une "power feature" je trouve, les users namespace c'est sympa mais ça va pas changer grand chose à ma vie (mes conteneurs ont tous un utilisateur non root et les binaires à l'intérieur de mes conteneurs n'ont pas de setuid).
L'IPV6 est pour moi un mauvais nom technique, c'est un peu comme HTML5, y a beaucoup de chose derrière.
L'IPV6 n'est pas seulement un nombre d'augmentation du nombre d’octet de l’adresse, y a des changements dans ICMP, ARP a été remplacé par NDP (Neighbor Discovery Protocol), l'autoconfiguration des addresses ip à changé aussi (Auto-configuré depuis la mac ou Route advertissement et/ou DHCPv6). Donc y a pas mal de chose à revoir et à réapprendre et malheureusement ceci est encore très mal, voir pas du tout enseigné dans les écoles.
Et le frein principale est aussi le coût. Maintenir la double stack (ipv4 et ipv6) dans son réseau à un coût. Surtout que le support de la double stack sera très certainement très très long. Même dans 20 ans je pense qu'on aura encore pas mal d'ipv4 en terminaison des réseaux (après le coeur du reseau sera peut etre passé en full ipv6 avec des tunnels).
[^] # Re: Difficile à lire
Posté par Tangi Colin . En réponse au journal Internet, 5G et chantage. Évalué à 5.
Dans l'Ain ce qui a fait que ça à marché ça provient aussi de fait que la très grande majorité du département (plus de 95%) avait son réseau électrique en régie dans le même syndicat intercommunal d'energie (http://www.siea.fr/) et c'est ce qui a gradement facilité le déploiement du réseau. C'est sur que dans un département au toutes les communes ont bradé leur infrastructure à des sociétés privés en mode délégation de service publique c'est tout de suite beaucoup plus compliqué à monter.
Un deuxième point sur la fibre qui je trouve rarement critiqué, c'est de dire que la fibre coûte chère à poser, ce qui est un gros raccourci.
Le mètre linéaire brut de fibre coûte moins chère que le mètre linéaire de cuivre. Le raccordement lui coûte plus chère que pour du cuivre (c'est plus compliqué à souder de la fibre que du cuivre).
Mais ce qui coûte vraiment chère quand on parle de "poser de la fibre", c'est l'enfouissement, or la fibre peut très bien marcher en aérien, les opérateurs telco le font d'ailleurs sur leur infra interne parfois (tels que certaines antennes sur des sommets de montagne).
# Information pas très fraiche
Posté par Tangi Colin . En réponse au journal Microsoft ♥ Docker. Évalué à 2.
Rien de nouveau sous le soleil, le partenariat microsoft/docker commence à dater.
Pour rajouté de l'information à l'information, microsoft à faillit racheter mesosphere aussi mais c'est finalement ravisé et à juste investit quelques millions lorsque que la startup mesosphere a fait son round C de levé de fonds.
[^] # Re: Morceau choisi
Posté par Tangi Colin . En réponse au journal Des vidéos qui envoient du bois. Évalué à 1.
peut etre que le kafka/Cassandra de tes collègues sont dans les 10% que PostreSQL ne traite pas.
[^] # Re: J'attends les contentieux
Posté par Tangi Colin . En réponse au journal Nouvelles Open-Source de Bulgarie. Évalué à 2.
Les Etats unis c'est loin d’être parfait. Ils font du "copyright-free" si tu es au Etats Unis, si c'est utilisé en dehors des Etats Unis il se réserve le droit d'appliquer leur copyright, bref du bon vieux protectionnisme. Y avait des discussions sur une liste de diffusion de debian il y a pas très longtemps : https://lists.debian.org/debian-legal/2016/01/msg00002.html
[^] # Re: en plus de la police, le nom si possible.
Posté par Tangi Colin . En réponse au journal Configurateur Open hardware : un (grand) merci. Évalué à 3.
La question à sans doute déjà été répondu ailleurs mais j'ai la flemme de chercher :)
Huile et sous vide c'est cool pour les contraintes extérieur mais pour la maintenance j'ai un doute.
Pour une raison ou une autre je veux ouvrir mon boîtier pour en changer un composant, je fais comment?
[^] # Re: APFS
Posté par Tangi Colin . En réponse au journal Le malaise.. Évalué à 9.
Pour une fois je te trouve pas du tout objectif avec une remarque comme ça. Toi qui répète sur linuxfr qu'une licence libre ne donne que les droits qui sont écrits dans la licence et pas un de plus et la tu fait l'amalgame grossier entre deux licences libres clairement différentes dont l'une a sciemment été écrite pour ne pas être compatible avec l'autre.
Normale que Canonical se prenne des baffes pour ça.
# Dalvik(Harmony) c'est du passé, maintenant google utilise openjdk
Posté par Tangi Colin . En réponse au journal Oracle perd son procès contre Google concernant l’utilisation de Java sur Android. Évalué à 4.
Cf : https://android.googlesource.com/platform/libcore.git/+/aab9271edee6cc8b4dd460977cad65efe52d16b0
Pourquoi avoir choisi un fork d'harmony à l'origine et pas openjdk je sais pas trop. Peut être pour marqué leur opposition franche à la GPL (bien que ici le classpath exception d'opendjk ne crée aucun soucis de licence).
# Facebook, Google, Twitter, etc gardent jalousement secret leur coeur de métier
Posté par Tangi Colin . En réponse au journal Pourquoi une petite société a intérêt à contribuer et produire du libre... mais pas que. Évalué à 4.
Oui et non, google a jamais publié leur algo lié a leur moteur de recherche effectivement.
Mais si tu prend le cas de twitter par example, l'ensemble de leur backbone repose sur Mesos qui un projet libre et ils y contribuent énormément dessus. Ce qui a obligé Google à aussi libérer le sien (Kubernetes (ça fait bien 10 ans qu'ils ont la techno en interne et il le libère que maintenant face à la concurrence)).
Je pourrais parler de netflix aussi avec OSS (le code source de l'ensemble de leur SI basé sur Amazon).
Facebook publie aussi son matos sur opencompute.org.
Donc d'un point de vue code (je parle pas du sujet des données personnelles et des services qu'ils vendent dessus) les grosses boites font énormément de logiciel libre c'est devenue une guerre (marketing, recrutement, …) entre elles.
[^] # Et les performances ?
Posté par Tangi Colin . En réponse au journal Monter un cluster mémoire avec un raspberry pi. Évalué à 2.
Gluster est basé sur fuse, donc niveau performance sur des petits fichiers ça peut vite devenir limitant.
[^] # Re: Mauvaise pratique : SSH dans un conten
Posté par Tangi Colin . En réponse au journal Yocto+Docker: Continuons l'expérience. Évalué à 1.
un bon point de départ ce trouve ici : https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/
Je rajouterai à ça de bien pensé à ses processus de mis à jour des images.
On peut utiliser Clair pour détecter des vulnérabilité dans ses images : https://github.com/coreos/clair ou simplement régénérer souvent ses images dans un processus de Continuous Delivery avec des test de non régression de bonne qualités ça se passe tranquillement.
# Mauvaise pratique : SSH dans un conten
Posté par Tangi Colin . En réponse au journal Yocto+Docker: Continuons l'expérience. Évalué à 6.
Avoir un SSH dans un conteneur docker est considéré comme une mauvaise pratique. Mieux vaut avoir un unique accès SSH sur le host et ensuite faire un docker exec pour entrer dans un conteneur.
Parce que sinon, avoir 150 docker déployés ça fait beaucoup de clé ssh à gérer.
# Pas convaincu
Posté par Tangi Colin . En réponse au journal Yocto+Docker: Les containers personnalisé. Évalué à 3.
Si on veux vraiment joué à qui à la plus courte faut aller plus loin, configuré yocto pour utiliser µlibc ou même musl, strippé le tout etc…
Mais honnêtement un debian (depuis un deboostrap où on vire les man, les timezones, les langues) ça tient en 40 mo seulement tout en ayant "apt-get". Je préfère largement ça et niveau politique de sécurité je rebuild et redéploie mes images toutes les semaines (donc j'ai un apt update qui s'exécute une fois par semaine).
# ça se serait passer comment avec une distribution linux style debian ?
Posté par Tangi Colin . En réponse au journal Comment 11 lignes de code ont provoqué un #npmgate. Évalué à 4.
Tout est dans le titre, je sais qu'il y a plus d'un mainteneur debian qui moule sur linuxfr, ça serait intéressant de savoir comment debian gère ce cas de figure.
[^] # Re: la backdoor est toujours là
Posté par Tangi Colin . En réponse au journal Nvidia ouvre son SDK GameWorks. Évalué à 3.
Ref needed :)
Je dis pas que c'est faux, je demande juste à que les propos soient un minimum sourcé quand il s'agit de balancer comme ça gratuitement sur certains nom de marque/société connues.
[^] # Re: la backdoor est toujours là
Posté par Tangi Colin . En réponse au journal Nvidia ouvre son SDK GameWorks. Évalué à 3.
ta as des sources de ce que tu avances ? Je suis preneur d'une information plus détaillée sur le sujet.
[^] # Re: la backdoor est toujours là
Posté par Tangi Colin . En réponse au journal Nvidia ouvre son SDK GameWorks. Évalué à 7.
que nvidia optimise son SDK pour ces cartes je le comprends (qu'il est pas envie de tester/optimiser leur code sur des cartes concurrentes), par contre que Nvidia fasse l'inverse, c'est a dire rajouter sciemment du code pour que le résultats soient ralenties sur les cartes concurrentes j'y crois moins, y a trop de risque de perte d'image de la marque si l'info fuite.
[^] # Re: Hôpital … charité
Posté par Tangi Colin . En réponse au journal Sale temps pour les informaticiens lanceurs d'alerte. Évalué à 7.
L'affaire va faire du bruit, j'espère que le lanceur d'alerte viré sans sortira pas trop mal au prud'homme.
# Windows utilise meme du linux en interne sur les routeurs Azure
Posté par Tangi Colin . En réponse au journal Bookmark : Microsoft vend du Linux. Évalué à 2.
En dehors du sujet mais vu que certains s'étonne que Microsoft aime linux en 2016, voici une autre info.
Les routeurs azure de microsoft tourne sur du linux et il communique dessus:
https://azure.microsoft.com/en-us/blog/microsoft-showcases-the-azure-cloud-switch-acs/
[^] # Re: Microsoft a changé... ou pas.
Posté par Tangi Colin . En réponse au journal Microsoft rejoint la Fondation Eclipse et passe en open-source certains de ses plugins. Évalué à 4.
C'est pas un peu du FUD ça ?
Dans ton premier lien, y a rien qui parle de la licence MIT et dans le deuxième il y a rien qui dit que c'est la licence du "diable". Tu fait le même procès d'intention à jQuery ou Symfony (exemple tiré de ton deuxième lien qui utilise aussi du MIT)?
[^] # Re: Facile!
Posté par Tangi Colin . En réponse au journal Microsoft va porter SQL Server sur Linux. Évalué à 1.
Oui, il n'y a pas de virtualisation dans docker donc le conteneur windows sur linux ou l'inverse c'est pas possible. Ce que les Windows conteneur sont c'est des API Windows (donc pas grand chose à voir avec les namespaces, capabilities, etc…) mais avec comme client "au niveau" Docker.
Donc sur Windows pour lancer un conteneur Windows je fait un
docker run … comme sur mon linux quoi, après entre les deux pas grand chose à voir, c'est juste une compatibilité de l'API docker pour gérer des "conteneurs".
Voir par ici : https://msdn.microsoft.com/en-us/virtualization/windowscontainers/about/about_overview
Et c'est déjà la, sur du windows server 2016, bon tout tourne pas encore avec, ça me parait assez loin d'être production ready mais c'est disponible. Un petit résumé par ici : https://msdn.microsoft.com/en-us/virtualization/windowscontainers/reference/app_compat
# Xpra
Posté par Tangi Colin . En réponse à la dépêche Subuser, une sur‐couche à Docker. Évalué à 1.
Je connaissais pas Xpra, si je comprend bien chaque conteneur à son serveur X à l'intérieur et Xpra sert de "proxy", j'ai bon ou je suis complètement à coté de la plaque ?
C'est pas un peu lourd par rapport a binder la socket X au lancement d'un conteneur ?
[^] # Re: Ce n'est qu'une première étape.
Posté par Tangi Colin . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 5.
Effectivement docker et systemd sont en conflit ouvert je dirais, voir à ce sujet le dernier billet sur LWN.
Après dire que la plateforme sous jacente n'est plus importante n'est pas forcément faux, si tu passe tout dans des conteneurs tu te moque de la plateforme (modulo la version de ton kernel). Y en a qui ont appliqué ce principe à l’extrême c'est rancherOS (http://rancher.com/rancher-os/) ou tu te retrouve sur un système ou tu as juste un docker "système" et un docker "user" et rien d'autre, tous le reste tourne dans des conteneurs.
On verra qui gagne la bataille du conteneur entre systemd et docker mais je dirais que pour l'instant docker à une longueur d'avance pas sur le plan technique car effectivement l'approche daemon n'est pas la meilleur mais niveau eco-system/buzz ils sont loin devant. Le fait que les Windows conteneur utilisent l'API Docker c'est plutôt impressionnant je trouve. Et docker Inc travaille sur une approche non daemon aussi , ça s'appelle containerd (https://github.com/docker/containerd).
[^] # Re: Ce n'est qu'une première étape.
Posté par Tangi Colin . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 5.
Historiquement Docker était une surcouche à LXC, jusqu’à la version 0.7 si mais souvenirs sont bons.
Et puis le développeur de docker ont eu pas mal d’écueils avec LXC, pas les même version suivant les distributions, des cassage d'API/ABI trop souvent et pas documenté et ils ont alors décidés d'implémenter leur propre solution en Go.
Maintenant la "full picture" est plus complète, docker c'est l'API haut niveau qui est compatible avec plusieurs "backend", par défault ça utilise "libcontainer" mais tu peux aussi explicitement spécifier d'utiliser LXC ou LMCTFY (https://blog.docker.com/2014/03/docker-0-9-introducing-execution-drivers-and-libcontainer/). Et même un backend Windows maintenant (https://msdn.microsoft.com/en-us/virtualization/windowscontainers/quick_start/manage_docker).
Et en dessous de libcontainer maintenant tu as runC (https://blog.docker.com/2015/06/runc/) qui est uniquement le runtime de container (sans toute la tuyauterie réseaux ). runC est du code Docker qui a était donné au projet Open Container Format de la linux fondation (dont docker est membre). C'est une réponse au "pseudo-standard" Rocket/Appc fait par CoreOS.
Y a aussi Ubuntu qui tente de vivre de son sponsoring de LXC en créant LXD.
La prochaine "feature" de Docker qui risque de faire du bruit c'est un meilleur support du Checkpoint/Restore (http://linuxplumbersconf.org/2015/ocw//system/presentations/2619/original/2015-08-20-CRIU_Support_in_Docker_for_Native_Checkpoint_and_Restore.pdf).
# Ce n'est qu'une première étape.
Posté par Tangi Colin . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 10.
Ceci n'est qu'une première étape puisque avec l'architecture actuelle de docker (daemon), le namespace user est le meme pour l'ensemble des conteneurs. Tu peux dire UID O du conteneur et l'UID 10049 à l'extérieur du conteneur mais ce mapping ce fera pour l'ensemble des conteneurs.
Cette fonctionnalité arrive tard dans docker par rapport à LXC par exemple qui le gère depuis longtemps. Ceci est lié au fait que docker étant basé sur du Go (golang), il a fallut attendre que les syscalls permettant d'activer les usernamespace soit implémenté dans ce langage, ce qui est arrivé avec le version 1.4 de Go. Ensuite la limitation proposé par l'architecture daemon a pas mal fait réfléchir les dévellopeurs sur la meilleur stratégie à appliquer. Voir ici un excellent résumé : http://events.linuxfoundation.org/sites/events/files/slides/User%20Namespaces%20-%20ContainerCon%202015%20-%2016-9-final_0.pdf
Il y a une deuxième feature de sécurité apporté par la version 1.10 qui j'attendais depuis très longtemps, c'est l'intégration par défaut de seccomp. Voir ici : https://github.com/docker/docker/blob/master/docs/security/seccomp.md
La on a vraiment une "power feature" je trouve, les users namespace c'est sympa mais ça va pas changer grand chose à ma vie (mes conteneurs ont tous un utilisateur non root et les binaires à l'intérieur de mes conteneurs n'ont pas de setuid).
[^] # Re: Qu'est-ce qui freine la migration à l'IPv6 ?
Posté par Tangi Colin . En réponse au journal Des abonnés Free reçoivent ¼ d’adresse IP. Évalué à 6.
L'IPV6 est pour moi un mauvais nom technique, c'est un peu comme HTML5, y a beaucoup de chose derrière.
L'IPV6 n'est pas seulement un nombre d'augmentation du nombre d’octet de l’adresse, y a des changements dans ICMP, ARP a été remplacé par NDP (Neighbor Discovery Protocol), l'autoconfiguration des addresses ip à changé aussi (Auto-configuré depuis la mac ou Route advertissement et/ou DHCPv6). Donc y a pas mal de chose à revoir et à réapprendre et malheureusement ceci est encore très mal, voir pas du tout enseigné dans les écoles.
Et le frein principale est aussi le coût. Maintenir la double stack (ipv4 et ipv6) dans son réseau à un coût. Surtout que le support de la double stack sera très certainement très très long. Même dans 20 ans je pense qu'on aura encore pas mal d'ipv4 en terminaison des réseaux (après le coeur du reseau sera peut etre passé en full ipv6 avec des tunnels).