Et du coup, c'est quoi la motivation pour ne pas trouver un taf qui soit moins relou ?
Parce que bon, le taf, on y passe pas mal de temps, donc ça me parait important que le truc soit pas trop chiant. Est ce que ça paye tellement bien, le travail en lui même est intéressant, ou d'autres raisons ?
Les fondations comme Apache ne vont aller que dans des cas précis. Comme tu dis, il y a des règles, notamment d'avoir assez de contributeurs (de boites différentes aussi), ce qui rends ça impropre pour la majorité des projets (mais pas forcément pour la majorité des projets qui ont un impact).
Et oui, y a des alternatives, mais pour le moment, si les gens n'utilisent pas, ça ne va pas influer vraiment sur la décentralisation.
On parle d'une présentation Apple. Le but est pas d'être précis mais de tracer des grands traits qui sont repris par les fans.
C'est aussi à cause de ce genre de présentation que les maceux se font vanner à longueur de temps, mais comme Apple fait bien les choses, ça renforce le message principal (à savoir qu'utiliser un mac permet d'être différent).
Tu pars du principe qu'un service va emerger. Mais ça, c'est si github fait tellement de la merde que quelqu'un décide de refaire des trucs.
Par exemple, si demain, y a soit github, soit trois fois rien, et que github décide de bannir tout ce qui a trait à la crypto, parce que raison stupide (remplace "la crypto" par "popcorn time" par exemple). Il se passe quoi ?
Si demain, tel gouvernement contraint de fermer un compte à GH, genre la chine qui demande à fermer un miroir d'un soft libre qui contourne son firewall, il se passe quoi ?
Si demain, une entreprise fait fermer un soft qui démontre l'insécurité d'une de ses solutions, il se passe quoi ?
Si on concentre tout l'infra chez 1 fournisseur, alors, ce fournisseur deviens critique, et tu as beau parler d'autres services, ça va causer des soucis.
Si le projet Lua dont on parle se fait bannir de GH pour une raison quelconque, il va être moins vivace si j'en crois l'article. Alors ouais, le code est encore la, mais c'est une piètre consolation.
Donc oui, c'est une raison suffisante pour au moins donner du souffle à des alternatives, et peut être à rendre github moins centrale d'une maniére ou d'une autre.
Par exemple, gitlab.com permet d'avoir un projet qui est un miroir tenu à jour depuis github, ce qui est déjà un bon début.
Oracle a aussi du code en GPL dans Linux (btrfs, oc2fs), donc ils sont globalement à pied d'égalité avec les autres personnes ayant la capacité de porter plainte (modulo le fait que eux, ils sont mieux équipés).
Ensuite, Oracle peut aussi avoir décidé pour le moment de pas utiliser ça et faire comme Microsoft et Android. À aucun moment Microsoft n'a été en frontal avec Google sur la question des brevets, car c'est bien plus rentable d'aller demander de l'argent à chaque OEM.
Attaquer Ubuntu, ça va juste rien apporter, la boite va pas être rentable. Aller voir Amazon ou Azure le jour ou ils respectent pas la license, ça, ça va être bien mieux (avec point bonus qu'Oracle va pouvoir dire "notre OS n'a pas de risque juridique").
Si c'est contre la licence de mélanger du code GPL avec du code CDDL, on peut supposer que les devs kernels vont raler, mais aussi les détenteurs des droits du coté de ZFS. Et c'est la ou ça deviens amusant, car c'est Oracle. Les mêmes à avoir tenter de faire un procès à Google sur Android.
Bien sur, Canonical ne va pas avoir de souci directement. Les gens qui proposent Ubuntu et qui se font du blé, genre Amazon ou Microsoft, ç'est déjà autre chose, car ils ont un chouia plus de quoi payer les amendes.
Oui, le jour de l'ansiblefest, après avoir discuté en réunion que c'était relou de pas avoir le support. A la fin de la réunion, l'idée était de faire une surcouche à github pour les bugs.
Mais même si un template est une addition intéressante, je pense que ça ne remplace pas vraiment une UI. Déjà, tu va rentrer les informations, mais tu peux pas être que que les gens ont mis l'information, tu es obligé de parser le markdown si tu veux agir dessus, ce qui est fragile et risqué. Et bien sur, chacun va devoir faire sa propre solution, et tu ne peux pas vraiment agir sur l'UI de github pour diriger les gens vers la ou tu veux.
Il faut voir aussi que dans le cas de youtube, c'est parfois pas tant du profilage que de la pur recommendation commercial payé.
Exemple, chaque fois que j'écoute "passenger, let her go", ça bascule toujours sur la même exact chanson après. Chanson que je coupe toujours au bout de 5 secondes pour mettre autre chose, car l'ambiance est pas la même ni rien. Donc je commence à avoir des doutes. Soit Google propose de passer 2 chansons l'une après l'autre. Soit les maisons de disques se sont arrangés pour trafiquer ça. Soit bien sur, il y a rien, mais bon…
J'ai un compte github car les projets ou je contribue sont dessus, mais plus ça va, et plus je vois que le problème n'est pas purement théorique et pose des soucis de pouvoir adapter le workflow de contribution au logiciel (example, ansible, ou le manque de templates et le fait de pas pouvoir trier les bugs sans avoir de droits de commits, et l'impossibilité de bouger un bug d'un dépot à un autre pose de vrais soucis)
oui, enfin "conflit" ouvert, faut pas exagérer, ça reste des divergences techniques, rien de plus. Y a pas de violences ou de combats.
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).
Pas vraiment. Déjà, le kernel importe pas mal pour les perfs, pour le support matériel, pour tout un tas de trucs.
Ensuite, go est compilé en statique, mais y a plein de dépendances ignorés dans docker et/ou kubernetes.
Par exemple, il faut qu'iptables soit la ce qui pose la question de la future migration à nftables, pour ne citer que ça.
Autre exemple, kubernetes à un un type de volume gitRepo, qui requiert d'avoir git dispo pour le kubelet, et ça fait parti de la plateforme (et par défaut, il est pas par exemple dans les images docker que Google fourni pour hyperkube).
3eme exemple, pour assurer la sécurité et l'isolation des containers docker, une des méthode est d'utiliser un équivalent de sVirt (ie, mettre chaque containeur dans un domaine selinux séparé, ce qui fait que root a pas trop d'accès dans le containeur, même si il en sort), et ça, ça requiert une platforme qui supporte avec la policy, etc. Pareil pour l'équivalent avec apparmor.
Y a plein d'exemple comme ça. La portabilité, c'était déjà la promesse de java il y a 10 ans, et c'est pas vraiment ce qui est arriver en pratique. Et je pense pas que les ingénieurs de l'époque soient moins bon que maintenant.
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
Donc tu va utiliser tes conteneurs comme un rpm mais sans dépendances. Et sans facilité pour combiner les binaires (exemple, si je veux rajouter git et iptables sur l'image, bah, j'ai quand même besoin d'avoir un paquet pour rajouter à l'image de base, vu que ton image ne peux dépendre que d'une image à la fois).
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.
Je ne pense pas que systemd cherche à gagner une bataille quelconque. Systemd supporte de démarrer un container docker, donc bon, les options sont déjà la. Et globalement, vu que docker engine est plus une brique de base qu'autre chose, tu es obligé d'avoir des outils à coté, notamment pour l'orchestration, et les outils de docker inc sont trop simplistes pour ça. Donc tu as tout un écosystème qui supporte plus que docker (genre kubernetes supporte rkt, mesos supporte kubernetes ou docker en natif, etc, etc). Donc la question se pose pas vraiment comme ça.
Le fait que les Windows conteneur utilisent l'API Docker c'est
plutôt impressionnant je trouve.
Ben c'est logique, ils vont bénéficier de l’écosystème sans rien faire.
Bah, donc même docker inc voit que leur approche de démon centralisé n'est pas suffisante.
Il faut bien voir que runc, c'est juste une réaction suite à la sortie de rkt. Et pendant que docker inc tente d'éviter que les gens aillent ailleurs, rkt bosse sur la sécurité en profondeur, avec l'attestation des images, une approche federé pour les images de base, etc).
À la fin, utiliser runc/rkt (ou systemd-nspawn) est plus propre pour un orchestrateur (qui va être capable de surveiller le processus, de récuperer les logs, de ne pas attendre que docker incorpore les derniers changements niveau noyau, etc). Donc je pense que les gens vont migrer vers ça à terme.
Tu as oublié aussi rkt, qui est globalement né de la frustration des gens de coreos à traité avec docker, et qui se veux être plus sur en ayant pas un demon central, une approche vu plus sur et plus intégré avec des choses comme systemd, la ou docker réinvente beaucoup de choses étant déjà dans systemd, sans avoir le même niveau d'intégration avec l'OS, vu que docker inc. cherche à surtout faire passer le message que la plateforme sous jacente n'est plus importante, ce qui est faux).
Déjà, il y a un coût de formation des équipes en place (même
actuellement, IPv6 n'est que rarement enseigné dans les écoles,
on est déjà content quand il est survolé).
Alors non, y a 10 ans, on me disait déjà en fac que ipv6, c'était l'avenir, etc, etc.
Ensuite, il y a des équipements (routeur, pare-feu, switch…) qui
ne gèrent pas IPv6 et qu'il faut remplacer (ça commence à
disparaître quand même).
Sauf si tu gardes le matos 10 ans, je pense que la majorité supporte ipv6 depuis un bout de temps. Ensuite comme tu le dit, c'est plus du coté des frontends et du coté des applicatifs.
La formation est pas trop coté réseau lui même, mais la multitude de façon de faire de l'ipv6 coté applicatif. Des applis qui ont besoin de la déclaration de 2 listens au lieu d'un, d'autre ou le fait d'écouter en ipv6 écoute aussi en ipv4, etc, etc.
Et le plus gros souci, c'est que maintenir le réseau en ipv4 et en ipv6, c'est maintenir 2 réseaux au lieu d'un, et que les équipes réseaux, c'est comme toujours dans le département informatique, et tout le monde pense que ça sert à rien et que ça coute cher.
Donc oui, la méthode propre, c'est déjà de filer de l'ipv6 pour une sous portion de tes services, de voir comment ça marche et une fois que c'est sous controle, de continuer. Mais même ça, c'est deja trop pour des équipes
Ouais, enfin on parle de Mint. Ils ont pas vraiment de listes pour annoncer les mises à jour de sécurité, n'ont pas d'email pour envoyer les failles et réagissent pas sur ce qu'on leur rapportent.
La sécurité de Linuxmint dépend uniquement du travail fait par Ubuntu/debian, et donc les paquets fait maison sont pas géré.
Faut dire que ça se renouvelle pas. les trucs vieux sont pourris, les trucs nouveaux sont pourris. Et globalement, dans la mesure ou rien n'a changé, on peut dire que l'initiative n'a eu vraiment aucun effet, à part pour le conférencier qui a du perdre un temps fou à répondre aux discussions.
Personne ne pointe le vrai souci, à savoir que pas assez de monde travaille sur le desktop, et que visiblement, ça choque plus personne de ne payer pour rien.
je me dit qu'ils devraient plutot filer une image de VM et basta.
Mais je suis sur aussi qu'avec le temps, des images dockers plus propres vont arriver.
Par exemple, utiliser des containers basés sur les paquets des distros, déployés dans un pod kubernetes. Ou faire ça avec docker-compose. Et en fait, sortir tout un tas de trucs fait pour le moment dans le containeur en dehors (exemple avec discourse, le fait d'avoir runit et cron dans le même container).
Mais pour ça, je pense qu'il faut commencer à faire une vraie distribution (ou du moins un sous projet) qui va fournir des containers standardsisés, fait par la distribution avec les paquets et la base de la distribution, pour usage avec d'autres containers. Genre je veux redis sur une centos, je prends centos/redis/, et j'aurais une interface connu, une politique de packaging (genre, qui ouvre les bons ports, qui demande un volume pour l'endroit y a besoin d'un volume, etc, etc).
Et on est pas encore la. Mais on a aussi tout ce qu'il faudrait pour le faire.
Je ne suis pas d'accord sur "coute à utiliser et à déployer". Si tu fait les choses à la main, ouais. Mais entre temps, on a des trucs qui existent et qui font ça pour toi. Exemple, j'utilise freeipa, et ça le fait sans souci, cf howto https://www.freeipa.org/page/Howto/DNSSEC
(ça fait aussi vachement la CA interne quand il faut, avec renouvellement, etc).
Et dire que c'est une architecture de sécurité contrôlé par le gouvernement, c'est sur l'internet publique. Tu peux avoir ton réseau interne aussi si tes contraintes de sécurité le requiert.
Non, mais tu as le coté vitrine de la chose. Tu montres qui tu suis (ce qui est franchement un peu naze), les projets mettent en avant le nombre de contributeurs et d'étoiles, et tu as une liste de ce que tel personne a fait.
Ceci dit, github a changé son slogan maintenant "where software is built".
D'abord, je ne pense pas qu'on puisse dire "c'est verrouillé" ou "c'est pas verrouillé" vis à vis d'une migration.
C'est plus un spectre de possibilité, allant de "c'est facile de bouger" à "c'est très couteux". L'API aide, mais si tu as rien pour recevoir les données, tu va pas loin. Et l'API, c'est juste un truc sympa pour t'éviter de faire du scrapping, qui est pas non plus du domaine de l'impossible.
Ensuite, même avec l'API, tu restes coincé sur les comptes, et malgré le fait que des choses existes (openid, saml, persona), on s'apercoit qu'au final, les entreprises préferent mettre des moyens pour que tu restes chez elles (et donc parfois avoir tes infos) que de pousser vers la décentralisation. Donc tu as une forte adhérence à ce niveau.
Et ton nouveau BT va devoir faire un mapping d'info que tu n'as peut être pas pas (email, mot de passe).
Enfin, je pense que la partie verouillage, c'est pas sur le fait de rester sur la plateforme plus que le fait que la gestion des bugs de github est des plus primitives.
Par exemple, tu ne peux pas faire des bugs privés, ce qui est pas terrible pour les failles de sécurité, et du coup, tu te retrouves avec une procédure différente pour ce genre de bugs, et une procédure moins testé, qu'est ce qui peut arriver de mal…
Autre exemple, tu ne peux pas déléguer la classification des bugs sans donner de droits de commits, dans mon souvenir, ce qui est aussi contre productif.
Et je parle que des trucs de bases, je vais même pas chercher du coté automatisation, ou finalement, tu es obligé d'avoir un login/password pour un bot, ce qui l'expose à des risques non requis, et entraine des complications.
Donc oui, github va bien pour des petits projets du dimanche, mais dés que tu grandit, tu te retrouve avec des trucs qui coincent et ou tu peux pas faire grand chose.
(et bien sur, ça reste proprio et centralisé, ce qui visiblement emmerde pas grand monde au sein du libre, et je pourrais sans doute faire un livre entier sur le sujet…)
Alors les serveurs sont pas de Red hat (pas tous), mais de la fondation Gnome. Il y a plein de sponsors (dont Canonical par exemple), mais les serveurs sont un peu vieux, et l'équipe de sysadmin Gnome (à savoir 1 volontaire et 1 à mi temps) est en train de mettre à jour le hardware.
Pour la bande passante, je viens de regarder sur les graphs et j'ai pas l'impression que ça soit saturé à la sortie du DC (qui a 2 liens. Je pense que c'est plutôt coté serveur du coup, soit coté disque, soit c'est un vieux serveur qui est pas en giga ou pas sur un switch giga.
Pour compléter, l'activation par socket permet en effet l'activation automatique, mais pas uniquement, ça permet aussi de démarrer les choses plus ou moins dans le désordre sans avoir des races conditions compliqués à déboguer (cf http://0pointer.de/blog/projects/systemd.html).
[^] # Re: La sécurité ? Une contrainte pour la productivité
Posté par Misc (site web personnel) . En réponse au journal Avant c'est trop cher, après c'est trop tard. Évalué à 10.
Et du coup, c'est quoi la motivation pour ne pas trouver un taf qui soit moins relou ?
Parce que bon, le taf, on y passe pas mal de temps, donc ça me parait important que le truc soit pas trop chiant. Est ce que ça paye tellement bien, le travail en lui même est intéressant, ou d'autres raisons ?
[^] # Re: Backup
Posté par Misc (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 3.
Les fondations comme Apache ne vont aller que dans des cas précis. Comme tu dis, il y a des règles, notamment d'avoir assez de contributeurs (de boites différentes aussi), ce qui rends ça impropre pour la majorité des projets (mais pas forcément pour la majorité des projets qui ont un impact).
Et oui, y a des alternatives, mais pour le moment, si les gens n'utilisent pas, ça ne va pas influer vraiment sur la décentralisation.
[^] # Re: business model de github ?
Posté par Misc (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 4.
Et des goodies, pour que tu payes pour faire de la pub pour eux.
https://github.myshopify.com/
[^] # Re: Pourquoi ?
Posté par Misc (site web personnel) . En réponse à la dépêche Swift sous GNU/Linux - Introduction. Évalué à 4.
On parle d'une présentation Apple. Le but est pas d'être précis mais de tracer des grands traits qui sont repris par les fans.
C'est aussi à cause de ce genre de présentation que les maceux se font vanner à longueur de temps, mais comme Apple fait bien les choses, ça renforce le message principal (à savoir qu'utiliser un mac permet d'être différent).
[^] # Re: Backup
Posté par Misc (site web personnel) . En réponse au journal Comment Github a ressuscité mon logiciel libre. Évalué à 6.
Tu pars du principe qu'un service va emerger. Mais ça, c'est si github fait tellement de la merde que quelqu'un décide de refaire des trucs.
Par exemple, si demain, y a soit github, soit trois fois rien, et que github décide de bannir tout ce qui a trait à la crypto, parce que raison stupide (remplace "la crypto" par "popcorn time" par exemple). Il se passe quoi ?
Si demain, tel gouvernement contraint de fermer un compte à GH, genre la chine qui demande à fermer un miroir d'un soft libre qui contourne son firewall, il se passe quoi ?
Si demain, une entreprise fait fermer un soft qui démontre l'insécurité d'une de ses solutions, il se passe quoi ?
Si on concentre tout l'infra chez 1 fournisseur, alors, ce fournisseur deviens critique, et tu as beau parler d'autres services, ça va causer des soucis.
Si le projet Lua dont on parle se fait bannir de GH pour une raison quelconque, il va être moins vivace si j'en crois l'article. Alors ouais, le code est encore la, mais c'est une piètre consolation.
Donc oui, c'est une raison suffisante pour au moins donner du souffle à des alternatives, et peut être à rendre github moins centrale d'une maniére ou d'une autre.
Par exemple, gitlab.com permet d'avoir un projet qui est un miroir tenu à jour depuis github, ce qui est déjà un bon début.
[^] # Re: Y a-t-il vraiment un risque ?
Posté par Misc (site web personnel) . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 5.
Oracle a aussi du code en GPL dans Linux (btrfs, oc2fs), donc ils sont globalement à pied d'égalité avec les autres personnes ayant la capacité de porter plainte (modulo le fait que eux, ils sont mieux équipés).
Ensuite, Oracle peut aussi avoir décidé pour le moment de pas utiliser ça et faire comme Microsoft et Android. À aucun moment Microsoft n'a été en frontal avec Google sur la question des brevets, car c'est bien plus rentable d'aller demander de l'argent à chaque OEM.
Cf:
http://thenextweb.com/microsoft/2013/05/07/inside-microsofts-android-patent-deals-how-much-money-is-the-company-making-in-reality-and-how-much-will-it-make-in-a-few-years/
http://arstechnica.com/tech-policy/2014/06/chinese-govt-reveals-microsofts-secret-list-of-android-killer-patents/
Attaquer Ubuntu, ça va juste rien apporter, la boite va pas être rentable. Aller voir Amazon ou Azure le jour ou ils respectent pas la license, ça, ça va être bien mieux (avec point bonus qu'Oracle va pouvoir dire "notre OS n'a pas de risque juridique").
[^] # Re: Y a-t-il vraiment un risque ?
Posté par Misc (site web personnel) . En réponse à la dépêche ZFS, Canonical et GPL. Évalué à 3.
Si c'est contre la licence de mélanger du code GPL avec du code CDDL, on peut supposer que les devs kernels vont raler, mais aussi les détenteurs des droits du coté de ZFS. Et c'est la ou ça deviens amusant, car c'est Oracle. Les mêmes à avoir tenter de faire un procès à Google sur Android.
Bien sur, Canonical ne va pas avoir de souci directement. Les gens qui proposent Ubuntu et qui se font du blé, genre Amazon ou Microsoft, ç'est déjà autre chose, car ils ont un chouia plus de quoi payer les amendes.
[^] # Re: Les dates ?
Posté par Misc (site web personnel) . En réponse au journal THSF 2016, on en est où ?. Évalué à 4.
Du 19 au 22 mai 2016
cf le cfp
[^] # Re: service...
Posté par Misc (site web personnel) . En réponse au journal Le danger github. Évalué à 2.
Oui, le jour de l'ansiblefest, après avoir discuté en réunion que c'était relou de pas avoir le support. A la fin de la réunion, l'idée était de faire une surcouche à github pour les bugs.
Mais même si un template est une addition intéressante, je pense que ça ne remplace pas vraiment une UI. Déjà, tu va rentrer les informations, mais tu peux pas être que que les gens ont mis l'information, tu es obligé de parser le markdown si tu veux agir dessus, ce qui est fragile et risqué. Et bien sur, chacun va devoir faire sa propre solution, et tu ne peux pas vraiment agir sur l'UI de github pour diriger les gens vers la ou tu veux.
[^] # Re: Profilage générique/général
Posté par Misc (site web personnel) . En réponse au journal Google Stop. Évalué à 6.
Il faut voir aussi que dans le cas de youtube, c'est parfois pas tant du profilage que de la pur recommendation commercial payé.
Exemple, chaque fois que j'écoute "passenger, let her go", ça bascule toujours sur la même exact chanson après. Chanson que je coupe toujours au bout de 5 secondes pour mettre autre chose, car l'ambiance est pas la même ni rien. Donc je commence à avoir des doutes. Soit Google propose de passer 2 chansons l'une après l'autre. Soit les maisons de disques se sont arrangés pour trafiquer ça. Soit bien sur, il y a rien, mais bon…
[^] # Re: service...
Posté par Misc (site web personnel) . En réponse au journal Le danger github. Évalué à 8.
Moi, j'ai arreté de lire quand j'ai vu un autre billet sur un nouveau soft hosté sur github:
http://carlchenet.com/2016/01/11/feed2tweet-0-2-power-of-the-command-line-sending-your-feed-rss-to-twitter/
J'ai un compte github car les projets ou je contribue sont dessus, mais plus ça va, et plus je vois que le problème n'est pas purement théorique et pose des soucis de pouvoir adapter le workflow de contribution au logiciel (example, ansible, ou le manque de templates et le fait de pas pouvoir trier les bugs sans avoir de droits de commits, et l'impossibilité de bouger un bug d'un dépot à un autre pose de vrais soucis)
[^] # Re: Ce n'est qu'une première étape.
Posté par Misc (site web personnel) . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 4.
oui, enfin "conflit" ouvert, faut pas exagérer, ça reste des divergences techniques, rien de plus. Y a pas de violences ou de combats.
Pas vraiment. Déjà, le kernel importe pas mal pour les perfs, pour le support matériel, pour tout un tas de trucs.
Ensuite, go est compilé en statique, mais y a plein de dépendances ignorés dans docker et/ou kubernetes.
Par exemple, il faut qu'iptables soit la ce qui pose la question de la future migration à nftables, pour ne citer que ça.
Autre exemple, kubernetes à un un type de volume gitRepo, qui requiert d'avoir git dispo pour le kubelet, et ça fait parti de la plateforme (et par défaut, il est pas par exemple dans les images docker que Google fourni pour hyperkube).
3eme exemple, pour assurer la sécurité et l'isolation des containers docker, une des méthode est d'utiliser un équivalent de sVirt (ie, mettre chaque containeur dans un domaine selinux séparé, ce qui fait que root a pas trop d'accès dans le containeur, même si il en sort), et ça, ça requiert une platforme qui supporte avec la policy, etc. Pareil pour l'équivalent avec apparmor.
Y a plein d'exemple comme ça. La portabilité, c'était déjà la promesse de java il y a 10 ans, et c'est pas vraiment ce qui est arriver en pratique. Et je pense pas que les ingénieurs de l'époque soient moins bon que maintenant.
Donc tu va utiliser tes conteneurs comme un rpm mais sans dépendances. Et sans facilité pour combiner les binaires (exemple, si je veux rajouter git et iptables sur l'image, bah, j'ai quand même besoin d'avoir un paquet pour rajouter à l'image de base, vu que ton image ne peux dépendre que d'une image à la fois).
Je ne pense pas que systemd cherche à gagner une bataille quelconque. Systemd supporte de démarrer un container docker, donc bon, les options sont déjà la. Et globalement, vu que docker engine est plus une brique de base qu'autre chose, tu es obligé d'avoir des outils à coté, notamment pour l'orchestration, et les outils de docker inc sont trop simplistes pour ça. Donc tu as tout un écosystème qui supporte plus que docker (genre kubernetes supporte rkt, mesos supporte kubernetes ou docker en natif, etc, etc). Donc la question se pose pas vraiment comme ça.
Ben c'est logique, ils vont bénéficier de l’écosystème sans rien faire.
Bah, donc même docker inc voit que leur approche de démon centralisé n'est pas suffisante.
Il faut bien voir que runc, c'est juste une réaction suite à la sortie de rkt. Et pendant que docker inc tente d'éviter que les gens aillent ailleurs, rkt bosse sur la sécurité en profondeur, avec l'attestation des images, une approche federé pour les images de base, etc).
À la fin, utiliser runc/rkt (ou systemd-nspawn) est plus propre pour un orchestrateur (qui va être capable de surveiller le processus, de récuperer les logs, de ne pas attendre que docker incorpore les derniers changements niveau noyau, etc). Donc je pense que les gens vont migrer vers ça à terme.
[^] # Re: Ce n'est qu'une première étape.
Posté par Misc (site web personnel) . En réponse au journal Docker 1.10 et les user namespace.. Évalué à 8.
Tu as oublié aussi rkt, qui est globalement né de la frustration des gens de coreos à traité avec docker, et qui se veux être plus sur en ayant pas un demon central, une approche vu plus sur et plus intégré avec des choses comme systemd, la ou docker réinvente beaucoup de choses étant déjà dans systemd, sans avoir le même niveau d'intégration avec l'OS, vu que docker inc. cherche à surtout faire passer le message que la plateforme sous jacente n'est plus importante, ce qui est faux).
[^] # Re: Qu'est-ce qui freine la migration à l'IPv6 ?
Posté par Misc (site web personnel) . En réponse au journal Des abonnés Free reçoivent ¼ d’adresse IP. Évalué à 3.
Alors non, y a 10 ans, on me disait déjà en fac que ipv6, c'était l'avenir, etc, etc.
Sauf si tu gardes le matos 10 ans, je pense que la majorité supporte ipv6 depuis un bout de temps. Ensuite comme tu le dit, c'est plus du coté des frontends et du coté des applicatifs.
La formation est pas trop coté réseau lui même, mais la multitude de façon de faire de l'ipv6 coté applicatif. Des applis qui ont besoin de la déclaration de 2 listens au lieu d'un, d'autre ou le fait d'écouter en ipv6 écoute aussi en ipv4, etc, etc.
Et le plus gros souci, c'est que maintenir le réseau en ipv4 et en ipv6, c'est maintenir 2 réseaux au lieu d'un, et que les équipes réseaux, c'est comme toujours dans le département informatique, et tout le monde pense que ça sert à rien et que ça coute cher.
Donc oui, la méthode propre, c'est déjà de filer de l'ipv6 pour une sous portion de tes services, de voir comment ça marche et une fois que c'est sous controle, de continuer. Mais même ça, c'est deja trop pour des équipes
[^] # Re: Précisions
Posté par Misc (site web personnel) . En réponse au journal Attention si vous avez téléchargé l'ISO Linux Mint 17.3 sur leur site depuis le 20-02 !. Évalué à 5.
Ouais, enfin on parle de Mint. Ils ont pas vraiment de listes pour annoncer les mises à jour de sécurité, n'ont pas d'email pour envoyer les failles et réagissent pas sur ce qu'on leur rapportent.
La sécurité de Linuxmint dépend uniquement du travail fait par Ubuntu/debian, et donc les paquets fait maison sont pas géré.
Exemple (et au risque de ressembler à un disque rayé):
https://bugs.launchpad.net/linuxmint/+bug/1008501
Bientöt 3 ans que personne regarde vraiment ce CVE. Je reconnais que c'est mineur, mais la correction est pas non plus compliqué.
Donc ouais, ça m'étonne pas non plus que leur wordpress se soit fait pourrir. L'upstream d'owncloud pointe d'ailleurs:
https://statuscode.ch/2016/02/distribution-packages-considered-insecure/
[^] # Re: Aussi drôle mais moins instructif
Posté par Misc (site web personnel) . En réponse au journal Linux Sucks - Édition 2016. Évalué à 2.
Faut dire que ça se renouvelle pas. les trucs vieux sont pourris, les trucs nouveaux sont pourris. Et globalement, dans la mesure ou rien n'a changé, on peut dire que l'initiative n'a eu vraiment aucun effet, à part pour le conférencier qui a du perdre un temps fou à répondre aux discussions.
Personne ne pointe le vrai souci, à savoir que pas assez de monde travaille sur le desktop, et que visiblement, ça choque plus personne de ne payer pour rien.
[^] # Re: et pour le bureau
Posté par Misc (site web personnel) . En réponse au journal Linux Sucks - Édition 2016. Évalué à 10.
bah voila la solution, utiliser un serveur comme desktop.
[^] # Re: Docker ?
Posté par Misc (site web personnel) . En réponse à la dépêche Discourse, plate-forme de discussion atypique. Évalué à 3.
Ensuite, rien n’empêche un jour de faire des trucs plus propres.
Pour info, les dockerfiles sont la:
https://github.com/discourse/discourse_docker/tree/master/image
Et la personne qui a écrit tout ça a l'air d'utiliser son propre systéme pour remplacer bash ou un truc comme ansible (du nom de pups). Et bon, en regardant ça: https://github.com/discourse/discourse_docker/blob/master/image/base/Dockerfile
je me dit qu'ils devraient plutot filer une image de VM et basta.
Mais je suis sur aussi qu'avec le temps, des images dockers plus propres vont arriver.
Par exemple, utiliser des containers basés sur les paquets des distros, déployés dans un pod kubernetes. Ou faire ça avec docker-compose. Et en fait, sortir tout un tas de trucs fait pour le moment dans le containeur en dehors (exemple avec discourse, le fait d'avoir runit et cron dans le même container).
Mais pour ça, je pense qu'il faut commencer à faire une vraie distribution (ou du moins un sous projet) qui va fournir des containers standardsisés, fait par la distribution avec les paquets et la base de la distribution, pour usage avec d'autres containers. Genre je veux redis sur une centos, je prends centos/redis/, et j'aurais une interface connu, une politique de packaging (genre, qui ouvre les bons ports, qui demande un volume pour l'endroit y a besoin d'un volume, etc, etc).
Et on est pas encore la. Mais on a aussi tout ce qu'il faudrait pour le faire.
[^] # Re: Déjà des correctifs
Posté par Misc (site web personnel) . En réponse au journal OpenSSH, UseRoaming no. Évalué à 3.
Ou une smartcard (genre une yubikey), ou une clé stocké dans le tpm (https://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly )
Par contre, CVE-2016-0778 me parait plus grave.
Je suppose que finalement, ssh client devrait aussi être dans une sandbox, vu qu'il y a pas besoin de grand chose.
[^] # Re: Contre DNSSEC
Posté par Misc (site web personnel) . En réponse au journal L'avenir de la sécurité de nos sites oueb : DNSSEC / HPKP / DANE TLSA / CSP. Évalué à 2.
Je ne suis pas d'accord sur "coute à utiliser et à déployer". Si tu fait les choses à la main, ouais. Mais entre temps, on a des trucs qui existent et qui font ça pour toi. Exemple, j'utilise freeipa, et ça le fait sans souci, cf howto
https://www.freeipa.org/page/Howto/DNSSEC
(ça fait aussi vachement la CA interne quand il faut, avec renouvellement, etc).
Et dire que c'est une architecture de sécurité contrôlé par le gouvernement, c'est sur l'internet publique. Tu peux avoir ton réseau interne aussi si tes contraintes de sécurité le requiert.
[^] # Re: Verrouillage?
Posté par Misc (site web personnel) . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 3.
Non, mais tu as le coté vitrine de la chose. Tu montres qui tu suis (ce qui est franchement un peu naze), les projets mettent en avant le nombre de contributeurs et d'étoiles, et tu as une liste de ce que tel personne a fait.
Ceci dit, github a changé son slogan maintenant "where software is built".
[^] # Re: Verrouillage?
Posté par Misc (site web personnel) . En réponse au journal CPython abandonne Mercurial et passe à Git et Github. Évalué à 10.
D'abord, je ne pense pas qu'on puisse dire "c'est verrouillé" ou "c'est pas verrouillé" vis à vis d'une migration.
C'est plus un spectre de possibilité, allant de "c'est facile de bouger" à "c'est très couteux". L'API aide, mais si tu as rien pour recevoir les données, tu va pas loin. Et l'API, c'est juste un truc sympa pour t'éviter de faire du scrapping, qui est pas non plus du domaine de l'impossible.
Ensuite, même avec l'API, tu restes coincé sur les comptes, et malgré le fait que des choses existes (openid, saml, persona), on s'apercoit qu'au final, les entreprises préferent mettre des moyens pour que tu restes chez elles (et donc parfois avoir tes infos) que de pousser vers la décentralisation. Donc tu as une forte adhérence à ce niveau.
Et ton nouveau BT va devoir faire un mapping d'info que tu n'as peut être pas pas (email, mot de passe).
Enfin, je pense que la partie verouillage, c'est pas sur le fait de rester sur la plateforme plus que le fait que la gestion des bugs de github est des plus primitives.
Par exemple, tu ne peux pas faire des bugs privés, ce qui est pas terrible pour les failles de sécurité, et du coup, tu te retrouves avec une procédure différente pour ce genre de bugs, et une procédure moins testé, qu'est ce qui peut arriver de mal…
Autre exemple, tu ne peux pas déléguer la classification des bugs sans donner de droits de commits, dans mon souvenir, ce qui est aussi contre productif.
Et je parle que des trucs de bases, je vais même pas chercher du coté automatisation, ou finalement, tu es obligé d'avoir un login/password pour un bot, ce qui l'expose à des risques non requis, et entraine des complications.
Donc oui, github va bien pour des petits projets du dimanche, mais dés que tu grandit, tu te retrouve avec des trucs qui coincent et ou tu peux pas faire grand chose.
(et bien sur, ça reste proprio et centralisé, ce qui visiblement emmerde pas grand monde au sein du libre, et je pourrais sans doute faire un livre entier sur le sujet…)
[^] # Re: Réaction à chaud
Posté par Misc (site web personnel) . En réponse à la dépêche GIMP a 20 ans !. Évalué à 6.
Alors les serveurs sont pas de Red hat (pas tous), mais de la fondation Gnome. Il y a plein de sponsors (dont Canonical par exemple), mais les serveurs sont un peu vieux, et l'équipe de sysadmin Gnome (à savoir 1 volontaire et 1 à mi temps) est en train de mettre à jour le hardware.
Pour la bande passante, je viens de regarder sur les graphs et j'ai pas l'impression que ça soit saturé à la sortie du DC (qui a 2 liens. Je pense que c'est plutôt coté serveur du coup, soit coté disque, soit c'est un vieux serveur qui est pas en giga ou pas sur un switch giga.
[^] # Re: présent à Paris
Posté par Misc (site web personnel) . En réponse à la dépêche Le Paris Open Source Summit arrive et LinuxFr.org sera là ! #OSSParis15. Évalué à 2.
ceci dit, le CIO summit aujourd'hui a été annulé.
[^] # Re: Fonctionnalité du patch
Posté par Misc (site web personnel) . En réponse au journal Busybox retire le support de systemd ?. Évalué à 5.
Oui, c'est ça.
Pour compléter, l'activation par socket permet en effet l'activation automatique, mais pas uniquement, ça permet aussi de démarrer les choses plus ou moins dans le désordre sans avoir des races conditions compliqués à déboguer (cf http://0pointer.de/blog/projects/systemd.html).