Misc a écrit 6254 commentaires

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…

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)

en conflit ouvert

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.

Et docker Inc travaille sur
une approche non daemon aussi , ça s'appelle containerd
(https://github.com/docker/containerd).

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é.

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/

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.

bah voila la solution, utiliser un serveur comme desktop.

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.

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.

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.

ceci dit, le CIO summit aujourd'hui a été annulé.

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).

Question de point de vue.

Par exemple, Sauron a crée de l'emploi et à revitaliser le tissu socio économique du Mordor via sa politique de grands travaux, et j'ai entendu dire que c'était aussi un peintre amateur. Certes, il y a eu quelque incidents par ci par la qui ont émaillés son règne et sa politique expansionniste parait surannée maintenant, mais dans le contexte de l'époque, il a négocié la transition vers l'industrialisation.

En effet, en relisant, j'ai trouvé plus. Ensuite, sur les 8, j'en compte 3 dont la contribution est d'avoir été la femme/compagne/victime d'un des autres membres de la liste.

Amusant de voir qu'il y a bien plus de personnages imaginaires que de femmes dans ta liste (5), c'est assez troublant quand on y réfléchit.

C'est marrant qu'on soit dans une communauté dont la base est la collaboration, mais que les gens préfèrent quand même mettre en avant l'individuel plutôt que le collectif.

(individu qui sont quand même tous dans le même moule quand on regarde ta sélection mais bon, on va pas parler de la diversité, on va se fâcher).

Alors, c'est visiblement lié à des conditions particulières sur le passage à l'heure d'été, dans des timezones spécifiques :

https://bugzilla.gnome.org/show_bug.cgi?id=736722

Donc est ce qu'on peut dire qu'un patch difficile à relire est un patch de qualité correct ?

Si on le refuse pour ça, la réponse est "non".

Parcequ'il n'y a aucune volonté que cela le soit ?

je connais plein de gens qui le voudrais, donc la volonté est la.

Il n'y a pas exclusion mutuelle entre ces affirmations (me semble t il)

Et pourtant si.

Si les décisions sont prises pour des raisons purement techniques, alors une raison non technique prouve que les décisions ne sont pas prises que sur la technique, et donc que les affirmations "on prends en compte que la technique" est visiblement fausse. De la à dire que ce patch est juste un exemple parmi tant d'autres, il y a un pas que je n'hésite pas à franchir.

C'est pas dur de trouver des gens qui vont dire que Brad Spengler a l'air d'avoir une certaine colère dans ses écrits et visiblement n'attire pas grand monde pour bosser avec lui ou faire des efforts.

Même si des gens dans la communauté du libre rationalise ce comportement comme une qualité (sans doute parce que ne pas pointer les soucis des gens permet de justifier notre propre comportement vis à vis des autres), ça reste dans son cas un comportement antisocial. Et sauf à me trouver assez de gens qui vont me dire clairement et sérieusement "moi, j'aimerais bosser avec lui", je pense qu'il y a personne (à tort ou à raison) voulant le faire.

Donc ouais, je persiste à dire que "meritocratie mes fesses".

Si la qualité technique n'est pas remise en cause, pourquoi c'est pas upstream ? ( sauf à dire que le kernel n'est pas une meritocracie comme on le dit si souvent, et qu'au final, l'humain joue )

On m'a toujours dit que l'orient, c'était à l'est.

C'est compliqué ces histoires de points cardinaux, c'est jamais pareil selon la ou on regarde.