CrEv a écrit 4577 commentaires

Perso je trouve que docker hors Linux est un gros hack

C'est à dire ?
Enfin outre qu'un conteneur docker c'est avant tout des primitives linux donc forcément hors linux cela implique de l'émulation quelque part.
Mais à part ça ?

J'avais entendu dire que docker sur M1 c'était balbutiant ça a l'air de pas mal fonctionner.

Docker Desktop sur M1 ça marche. Avec des images arm.
Après oué, forcément, faire tourner des images x86 dessus c'est plus compliqué. Comme à l'époque où les macs ont migrés sous x86, faire tourner les anciens programmes ppc c'était pas toujours évident.

Tu as un lien sur ce point ? J'ai pas trouvé et la FAQ est assez clair sur le fait que ce n'est plus open source du tout.

Certes.
Le point principal étant "la suite elastic n'est désormais uniquement disponible sous des licences non libres."

De même, une licence peut être libre ou open source sans être approuvée par l'OSI, tout simplement parce que les auteurs de la licence n'ont pas entrepris la démarche d'adoubement par l'OSI. Il s'agit donc plutôt ici de savoir si la licence est conforme ou non à l'Open Source Definition (OSD).

Déjà fait : The SSPL is Not an Open Source License
Quant à la license ELv2 elle ne respecte par le point 3 de l'OSD

1. Derived Works The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.

Vous ne pouvez pas :
- fournir les produits en tant que service géré ;

Donc bref, on peut discuter des licences libres par rapport aux définitions de la FSF, de l'OSI, ni la SSPL ni la ELv2 ne sont des licences libres.

J'enfonce un peu des portes ouvertes, mais j'ai l'impression que la dépêche tourne un peu autour du pot :

Bien qu’étant toutes deux des licences « code source disponible », la seconde pose trois limites principales (plus de détails sur ces limites), là où la première se limite à une seule condition : publier les modifications apportées, y compris le code source sous la même licence.
au regard des réponses de la team d’Amazon concernant ce changement de licence en SPPL, qui selon eux ressemble à de l’open-source mais ne respecte pas le côté libre et ouvert.

Le point principal ici est que la suite elastic n'est désormais uniquement disponible sous des licences non libres. Amazon fork donc en permettant de garder cette suite sous licence libre.
Ni la SSPL ni la ELv2 ne sont compatibles GPL ni approuvées par l'OSI.

réimplémenter les API d'un projet libre

J'ai pas bien compris le problème. Réimplémenter les APIs d'elasticsearch (par ex) c'est réimplémenter elasticsearch de manière compatible. En quoi c'est un problème ? C'est pas la base de l'interopérabilité, de nombreux projets libres qui sont compatibles avec d'autres, etc ?

Comment est-ce possible ? Ou bien j'ai loupé qqch ?

Je dirais que ça dépend de comment c'est fait. Si c'est de la mesure d'audience qui est correctement anonymisée ça doit pouvoir être autorisé sans même de choix (enfin avec le choix du moins) non ?
On peut très bien avoir un cookie qui permet juste de ne pas te compter deux vues sans pour autant te tracker.

Un témoignage parmi tant d'autres :

https://medium.com/@thomas.bushnell/a-reflection-on-the-departure-of-rms-18e6a835fd84

But I’ll give you a personal take. By my reckoning, I worked for RMS longer than any other programmer.

4) RMS’s loss of MIT privileges and leadership of the FSF are the appropriate responses to a pattern of decades of poor behavior.

A propos de sa première éviction. On est loin de juste quelques malheureuses prises de positions, mais on parle de décennies de mauvais comportement.

Chasse aux sorcières dont la force a, je rappelle, reposé surtout sur des accusations non prouvées

Nan mais c'était juste la goute d'eau. RMS, de nombreuses personnes ne peuvent pas le pifer depuis un moment du fait de l'ensemble de ses comportements, en déplacement, en conférence, etc. Des exemples il y en a à la pelle.

Moi ce que je ne comprend pas bien c'est pourquoi cet acharnement à le défendre. Qu'à-t-il fait de bien ces dernières années ? Il n'a fait que s'illustrer par ses mauvais comportements, ses mauvais choix techniques, sa mauvaise gestion de projet.
Ou alors j'ai loupé des événements intéressants.

• qu'apporte t-il maintenant au libre?

Maintenant et depuis des années.

ok, donc c'est uniquement à propos du côté daemonless/rootless

J'ai du mal à voir quel est vraiment la différence avec ceci :

docker pull docker.io/alpine:3.12
docker pull docker.io/adoptopenjdk/openjdk8-openj9:alpine-jre

timestamp=$(date +%Y%m%dT%H%M%S)

image_name=minecraft-papercraft

build_and_push() {
    local papercraft_build=$1
    local branch=$2
    local version=${branch}-${timestamp}
    local image_full_name=${image_name}:${version}
    local image_name_no_timestamp=${image_name}:${branch}

    docker build -t "${image_full_name}" \
        --build-arg BUILD=${papercraft_build} \
        --build-arg BRANCH=${branch} \
        .
    docker tag "${image_full_name}" ${BUILDAH_PUSH_REPOSITORY}/${image_full_name}
    docker tag "${image_full_name}" ${BUILDAH_PUSH_REPOSITORY}/${image_name_no_timestamp}
    docker push ${BUILDAH_PUSH_REPOSITORY}/${image_full_name}
    docker push ${BUILDAH_PUSH_REPOSITORY}/${image_name_no_timestamp}
}

En quoi buildah est plus intéressant que docker ici ?

Par exemple, Buildah est largement plus pratique pour tous ce qui est cas d'utilisation en intégration continue

Ça m'intéresse, tu aurais des exemples concrets ?
Parce que à chaque fois que j'ai voulu regarder buildah, j'ai l'impression de revenir en arrière. Utiliser un script shell pour construire une image, ben c'est tout sauf pratique dans la majorité des cas que j'ai vu.

Ça n'a pas grand chose à voir avec Docker ça. C'est la même chose quand tu as du maven, des jar, des gems, ou n'importe quel besoin totalement classique.
Le problème est ici lorsque c'est mal fait :

entreprise, derrière un proxy http

Si tous tes fichiers sont uniquement dans la VM et si tu n'édites tes fichiers que dans la VMs, alors oui forcément c'est mieux. C'est indiscutable, puisque les fichiers sont locaux.

Si tes fichiers sont dans la VM mais que tu les édites depuis l'hôte ou l'inverse, alors tu peux avoir un problème. Sauf que Docker a spécifiquement changé des choses pour l'améliorer, ce que tu ne peux pas avoir avec Virtualbox.

Mais le problème est complexe, et oui c'est un frein malheureusement.

Mitchell Hashimoto (Hashicorp) utilise le principe de la VM, éditant tous ces fichiers dans la VM directement (donc en fait sans partage de fichier) https://twitter.com/mitchellh/status/1346136404682625024
C'est un bon exemple de ce qui peut se faire.

Le support de docker rootless vient aussi de sortir d'experimental, cf https://docs.docker.com/engine/release-notes/#rootless et https://docs.docker.com/engine/security/rootless/

Si c'est pour utiliser tous les jours des containers docker sur ces environnements, je crois que le plus simple et plus performant reste encore d'avoir une VM linux avec Virtualbox et executer docker a partir de cette machine.

Oui et non. C'est une solution, mais de là à dire que c'est plus performant je ne pense pas.

Comme tu dis, le gros point noir c'est le partage de fichier.
Sous Windows comme sous Mac les choses s'améliorent et c'est justement ce que tu ne peux pas retrouver avec une VM sous Virtualbox ou autre.
Voir par exemple ce ticket sur la roadmap publique : https://github.com/docker/roadmap/issues/7
Certaines améliorations sont activées par défaut depuis la version 2.4.0.0 sortie fin septembre : https://docs.docker.com/docker-for-mac/release-notes/#docker-desktop-community-2400

Pour Windows il y a un certain nombre de posts sur le blog de docker sur ce sujet, par exemple https://www.docker.com/blog/new-filesharing-implementation-in-docker-desktop-windows/

Dans tous les cas, partager de nombreux fichiers entre 2 VM est toujours compliqué. Que la VM supporte les fichiers ou que ce soit la machine, le problème reste entier et tout dépend l'action qu'on fait.
C'est aussi très variable suivant les frameworks par exemple.

Est-ce que la version OSX permet d'avoir un conteneur OSX ?

Nope, ça n'existe pas.
Les conteneurs (Docker, OCI) sont basés sur des fonctionnalités Linux uniquement. Les conteneurs Windows c'est autre chose, basé sur l'isolation intrinsèque à windows.
Pour mac je n'ai pas connaissance de solution équivalente. L'idéal serait que ce soit développé pas Apple, mais je n'en ai pas entendu parlé.

OK, cette page contient en effet des infos pas à jour.
Les infos sur ubuntu sont basées sur le temps où il y avait encore deux versions, docker-ce (community) et docker-ee (enterprise).
Désormais il n'y a plus qu'une version fournie par Docker.

🤔
Ce n'est pas la doc de Docker Desktop, Docker Desktop n'est pas sous linux.

La doc d'installation de Docker sous Ubuntu est ici : https://docs.docker.com/engine/install/ubuntu/

Comment tu es tombé sur cette doc pas à jour ?

Enfin le plus gros problème de Docker est que ça n'existe pas sous OSX et à peine sous Windows. Quand tu cibles toutes ces plates-formes ça devient vite limitant.

Mouais, c'est pas totalement vrai. Docker Desktop te fait tourner Docker sous OSX et sous Windows, où d'ailleurs tu as le choix de faire tourner des conteneurs windows ou des conteneurs linux. Les dernières versions utilisent WSL2 et ça marche quand même vachement bien.

Certains logiciels sont d'ailleurs packagés que comme des images docker, utilisables sous windows et mac genre GitPitch.

Bref, tu peux avoir un soft packagé sous forme d'une image Docker et que tu peux faire tourner sur plusieurs architectures (x86, arm, windows) ainsi que sous windows + mac à base de conteneur linux. Y compris sur les derniers mac arm.

Par chance la SSPL peut être remplacée par la ELv2 (cf https://linuxfr.org/news/virevoltantes-valses-de-licences-libres-et-non-libres-dans-les-bases-de-donnees#comment-1840724).

Il y a même fort à parier que si Lucene avait été en (A)GPL elastic n'aurait pas eu le succès actuel car ça aurait empêché d'en faire une version proprio.

J'ai aucun problème avec le fait qu'une version proprio d'elastic existe, avec des features différentes, en plus.
Par contre la situation actuelle c'est une version proprio et une version non libre.

En effet, soyons franc, si ces divers logiciels de base de données n'avaient pas été libres, quel aurait été leur succès?

En fait c'est même "pire" que ça. Elasticsearch est à la base une interface agréable au dessus de lucene, lui aussi libre. Sans le libre, sans lucene, elasticsearch n'existerait juste pas.

Elastic vient de sortir une nouvelle licence, Elastic License v2.

Le problème de ce genre de licence, d'apparence plus simple, est qu'il y a beaucoup trop de place à l'interprétation.

You may not provide the software to third parties as a hosted or managed service, where the service provides users with access to any substantial set of the features or functionality of the software.

C'est toujours mieux que la SSPL qui est juste totalement honteuse :

If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License

Sous certaines vagues conditions, tu dois fournir le "Service Source Code".
Ok, mais c'est quoi le "Service Source Code" ? C'est le code elastic ? C'est le code de ton app ? Non, mieux :

“Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.

Donc en gros tu dois publier absolument tout, de ton outil de build à ton monitoring en prod, ton code d'infra, d'automatisation, ton code de backup. Juste absolument tout.

J'ai rarement vu pire licence.

Je pense qu'au fond le problème c'est la confusion entre le logiciel et le produit. Quand ton produit n'est que le logiciel, il est plus facile de fermer le logiciel pour que d'autres ne l'utilise pas que de fournir un meilleur produit se basant sur le dit logiciel.

C'est dommage, c'est quand même pas super attractif sans un seul screenshot 🤷‍♂️

Au delà du côté magique, le wd-40 c'est globalement du white spirit. Je n'en mettrais clairement pas dans mes circuits électriques, mais un bon coup de nettoyant contact, c'est fait pour :-)