20% des 15 millions de dockers stockés chez Docker Hub sont malveillants.

Docker a envoyé un email à tous les utilisateurs déclarés comme "organisation" en leur disant que s'ils ne commencent pas à payer, tout va être supprimé. L'abonnement est à 420 dollars l'année.
Et PAN dans la gueule des projets Libres.

EDIT: article en français : https://linuxfr.org/users/bortzmeyer/journaux/docker-supprime-l-acces-gratuit-aux-groupes-et-organisations

EDIT: Docker s'excuse : https://www.docker.com/blog/we-apologize-we-did-a-terrible-job-announcing-the-end-of-docker-free-teams/

EDIT: Docker annule son plan. https://www.docker.com/blog/no-longer-sunsetting-the-free-team-plan/

Je vais redire tout le bien que je pense de cette distribution Linux.
Elle est juste parfaite pour faire un serveur sur un SBC (Raspberry, etc.) ou pour recycler de vieux ordinateurs (des versions x86/x64 sont disponibles et il y a aussi des environnements de bureau).
Pourquoi ?

- c'est vraiment une distribution minimaliste, donc légère (plus légère qu'une debian standard).
- ça reste une debian (donc bidouillable comme n'importe quelle debian)
- si on veut (mais pas d'obligation), on peut installer *et* configurer tout un tas de packages/logiciels/services avec beaucoup de facilité.

On a à la fois la bidouillabilité et l'installation de services prêts à l'emploi.

Par exemple, cochez juste "NextCloud" dans leur installeur (dietpi-software) et quelques minutes plus tard vous n'avez plus qu'à ouvrir votre navigateur et vous connecter à NextCloud.
Derrière il va :
- automatiquement aller télécharger la dernière version de NextCloud du site officiel.
- vous donner le choix du serveur web à utiliser (Apache, nginx, lighttpd)
- installer tous les modules php nécessaires à NextCloud.
- configurer php et ces modules.
- configurer le serveur web (y compris les mod_* nécessaires à NextCloud)
- installer et configurer mariadb
- donner le login/mot de passe de mariadb à NextCloud et lui demander d'aller créer ses tables.
- installer php-fpm et le configurer dans le serveur web pour avoir de meilleures performances.
- etc.

Donc ce n'est pas juste un "apt install" qu'il réalise : il va configurer les différents modules pour qu'ils marchent entre eux.
(Ce qui ne vous empêche pas, ensuite, d'aller bidouiller vous-même la config de NextCloud ou du serveur web.)

Et il y a des tonnes de modules prêts à l'emploi:
- bureaux graphiques: lxde, mate, xfce, GnuStep, Lxqt...
- accès à distance : NoMachine, XRDP, TigerVNC...
- médias : Kodi, Ampache, Plex, mpd, IceCast...
- cloud & backup : NextCloud, Syncthing, Gitea, RClone...
- Jeux : serveurs Minecraft (Cuberite, Nukkit, PaperMC...)
- et beaucoup d'autres: FreshRSS, Wordpress, phpBB, Synapse (Matrix), WebMin, Docker, Let's Encrypt, piHole, vsftpd, OpenVPN, Wireguard, HAProxy, IPFS, TOR, Mumble...

Et comme elle est en prime adossée aux dépôts Debian, tous les paquets dont vous avez besoin sont à portée de apt.

On notera aussi :
- les intelligentes adaptations pour les SBC (comme l'usage de log2ram et de tmpfs pour éviter de tuer les microSD, l'adaptation de cron pour limiter les réveils inutiles, etc.)
- la faible consommation de RAM (160 Mo avec un bureau graphique, 80 Mo pour un système en ligne de commande).

Est-ce qu'on réalise bien ?  160 Mo et vous avez un système d'exploitation avec un environnement de bureau (gestionnaire de fichiers, navigateur...). À une époque où les éditeurs de texte bouffent à eux seuls des GIGA-OCTETS de RAM, moi je trouve ça beau.

Pour résumer, on pourrait dire que cette distribution est faite pour ceux qui n'ont pas peur de la ligne de commande mais qui ne sont pas sysadmin pour autant. Cette distribution peut tout aussi bien servir à se faire son petit serveur à la maison que de recycler de vieux PC pour la bureautique (et plus).

Je partage son coup de gueule. L'industrie de l'informatique (en particulier le web) a ajouté des tonnes de couches et une complexité énorme, ce qui donne des applications lourdes, lentes et peu fiables.
De nos jours avoir un serveur web qui sert une page html à un client, ce n'est pas à la mode.
Non, il faut un gros moteur javascript de dizaines de milliers de lignes, réparti dans des dizaines de fichiers, qui va à son tour effectuer des tonnes de requêtes http pour aller chercher du json, qui sera parsé, traité, et va servir à construire dynamiquement un DOM. Même merde avec les CSS: récupéré, parsé, compilés à la volée par le javascript. Et puis vous embarquez tout ça dans un Docker - pardon DES dockers - et vous ajoutez une couche de Kubernetes parce que vous avez trop de Dockers à gérer.

Et après on s'étonne que la moindre page web mettre trois plombes à se charger, bouffe plein de CPU et 1 Go de RAM pour s'afficher ?
Je suis peut-être rétrograde, mais comme l'auteur de cet article, je trouve que c'est de la merde.

Les conséquences de tout ça ? Ces stacks deviennent extrêmement difficiles à maîtriser même pour les tâches les plus simples. Et cela entretient le mythe de la rockstar en informatique, ce qui n'est globablement pas bon pour l'estime des développeurs. Les recruteurs tombent aussi dans le panneau en demandant des moutons à 5 pattes ayant 15 ans d'expérience dans une techno vieille de 5 ans (et qui sera abandonnée dans 2 ans). Recruteurs, vous ne voulez pas un DevOps, vous voulez un département informatique entier en une personne. Ce n'est ni sain, ni tenable. Le metier de DevOps, ça sert surtout à presser les devs pour en tirer un maximum de jus.  Ça peut être stimulant j'en conviens, mais ça peut aussi être une source de burn-out.
Ce n'est pas bon non plus pour les entreprises: En choisissant ce genre de stack complexe, elles ont du mal à trouver des compétences, et s'embourbent dans une dette technique énorme qui se paie très cher. Sur le moment c'est très cool: C'est rapidement fait, c'est beau, ça présente bien. Quelques années après quand le DevOps a quitté la boîte et que les frameworks sont laissés à l'abandon parce que leurs auteurs ont décider d'aller faire quelque chose de plus intéressant, la maintenance devient douloureuse.

Merci Riduidel pour cet article (http://nicolas-delsaux.hd.free.fr/Shaarli/?_Abm9A), ça me fait réaliser une chose:

Un développeur a deux choses en main: Le problème qu'on lui demande de résoudre, et la technique qui lui permet de le résoudre.
On cherche à avoir la technique la plus efficace, afin de se concentrer sur le problème. L'objectif, c'est le problème. La technique n'est qu'un moyen.
Donc nous avons conçu des outils pour nous simplifier la vie, pour rendre la partie technique plus efficace. C'est tout naturel.

Seulement ces outils censés nous simplifier la vie ajoutent en réalité une *charge mentale* aux développeurs.
Git est censé nous aider à gérer plus facilement les sources et leur modification. Mais il est complexe et impose un investissement intellectuel non négligeable, une charge mentale pour l'utiliser correctement.
Docker/Kubernetes sont censés simplifier le déploiement. Mais ils ont leur lot de problèmes et imposent une charge mentale pour savoir les utiliser et régler leurs problèmes spécifiques.
Les frameworks comme Vue.js/Angular/React sont censés simplifier et fluidifier le développement du front au back, mais nécessitent de comprendre et maîtriser leurs arcanes bien spécifiques avant même de produire un écran.

Tout ces outils, cumulés, finissent par imposer aux développeurs une charge mentale énorme sur la partie technique avant même de pouvoir commencer à produire du code, avant même de commencer à travailler concrètement sur le problème initial à résoudre. Vous dépensez du temps et de l'énergie pour comprendre la technique au lieu de dépenser ce temps et cette énergie pour réfléchir au problème que vous avez à résoudre.

Est-ce que ça vaut le coup ?  Est-ce qu'on a vraiment gagné du temps ?   Est-ce qu'on en gagnera à plus long terme avec ces outils ?  Je ne sais pas.

En fait si, je sais un peu.  Si on maîtrisait totalement *chacun* de ces outils, on gagnerait sans doute du temps, à court et à long terme. Cela ne fait aucun doute. Ces outils ont été conçus par des gens brillants, qui arrivent (par des sites web ou des conférences) à nous montrer tout le bien qu'ils peuvent produire. C'est beau, ça a l'air de marcher magnifiquement. Mais c'est normal: Ils maîtrisent à la perfection ces outils. Ils les ont conçus.
Dans la pratique, je constate que ces énormes cathédrales sont rarement bien maîtrisées (c'est le sujet de l'article), et que les gens perdent du temps à trouver comment bien faire les choses, voir comment faire les choses tout court. Non pas à cause du code qu'ils ont produit, mais déjà à cause des outils eux-mêmes.

Et c'est même pire que ça: Ces outils imposent une façon de penser spécifique. Mal comprise - et donc mal utilisée - cela impactera le code produit, qui non seulement sera sous-optimal par rapport au framework mais - comme il ne rentre pas bien dans l'état d'esprit du framework - sera compliqué à maintenir et faire évoluer. J'ai constaté ça sur divers projets.

Le monde du développement a oublié le principe du KISS pour se faire plaisir sur des outils qui - pris individuellement - sont séduisants. Du moins sur leur promesses.
Faites attention à la charge mentale que vous vous imposez en ajoutant ces outils.

Et un dernier mot d'avertissement: Faites attention à la perennité des outils que vous choisissez. Je pense en particulier aux frameworks Javascript dont la durée de vie est parfois particulièrement courte. C'est une dette technique que vous paierez. Et cher.
(Je le sais, je bosse en partie sur du WebObjects. Vous ne connaissez pas WebObjects ? Pourtant c'est le framework web qui était porté par une boîte aux moyen titanesques: Apple. Qui a décidé du jour au lendemain que ça ne l'intéressait plus.)
Grosse pensée pour les gens qui ont investi du temps à comprendre et maîtriser des technos mortes (Silverlight, etc.))

EDIT: Le xkcd approprié: https://xkcd.com/1597/

Un jour quand j'aurai le temps, il faudra vraiment que je me mette à LXC. Ça a l'air vachement sympa, et moins usine à gaz que Docker.

Selon la légende, "php c'est de la merde".
Sauf que depuis, php a évolué, son écosystème et ses outils aussi, et il a aussi de bons côtés.
À l'heure des horreurs lovecraftiennes node.js/npm/docker et autres usines à gaz montées en production, la simplicité du php est peut-être plus saine (et puis il y a des frameworks comme Laravel).

J'ai pas envie de prendre un marteau-pilon pour écraser une fraise: Il va falloir que je prenne le temps de jeter un oeil à #LXC.
Ça a l'air assez sympa. Bien plus léger que Docker ou VirtualBox, et facile à utiliser.

Liens complémentaires:
https://blog.imirhil.fr/2015/03/11/virtualisation-facile-lxc.html
http://fabian-affolter.ch/blog/lxc-with-virt-manager/
https://www.maketecheasier.com/introduction-ubuntu-lxd-containers/

Un tutoriel sur docker.

« Ian Murdock est décédé. Pour les béotiens, c'est le fondateur du projet Debian, une distribution GNU/Linux extrêmement importante dans la communauté, et à la base de centaines d'autres projets, dont la célèbre Ubuntu. »
Oh mince :-(
EDIT: autres liens: http://linuxfr.org/news/in-memoriam-ian-murdock-1973-2015
http://framablog.org/2016/01/04/debian-perd-son-ian/

Un petit retour d’expérience sur Docker par Marien Fressinaud.
Voir aussi: http://sebsauvage.net/links/?searchterm=docker

Petite présentation de Docker (à mi-chemin entre les machines virtuelles et un chroot). Voir aussi: http://sebsauvage.net/links/?NLBVVg
Voir aussi:
http://jolicode.com/blog/naviguer-sur-votre-infrastructure-avec-docker
http://www.infoq.com/fr/articles/docker-sous-le-capot