CrEv a écrit 4577 commentaires

pu****, 9 ans déjà qu'on radote sur le même truc et pas d'alternative, faut se rendre à l'évidence, non?

Quand tu écris "se rendre à l'évidence", tu veux dire "se rendre à l'évidence qu'en vrai systemd ça fonctionne bien", c'est bien ça ?

Savoir que le monitoring existe ne t'aide pas forcément à trouver une solution moderne pour le mettre en place. (ça fait plus d'un an que je cherche la perle rare, si tu l'as, 22 😋)

Pourtant des solutions de monitoring c'est pas forcément ce qui manque. Genre prometheus-alertmanager-grafana est plutôt sympa, mais c'est sans connaitre le besoin.

et qu'on laisse pleurer

Il peut y avoir plein de raisons pour lesquelles un enfant pleure, et plein de raisons pour lesquelles parfois un enfant ne va pas arrêter.
Laisser pleurer sous-entend qu'il est possible de ne pas laisser pleurer et que l'arrêt des pleurs est dépendant du bon vouloir des parents.
D'expérience ce n'est vrai que partiellement et il existe plein d'autres cas qui ne marchent pas comme cela.

le monde du jeux vidéos et des streamer Twitch

Mais alors quel est le lien avec

une partie des professionnels de l'infos sur LinuxFR

?

Ça veut dire que si Pierre Tramo voulait discuter avec sa communauté aujourd'hui il choisirait Discord?

thème sombre (comme pour plein de logiciels geek)

Comme linuxfr ?

C'est une question épineuse mais pour moi c'est à l'application de créer un mode "Secure" sans pilotes.

Bon, sans pilotes c'est un poil exagéré parce qu'il faut bien un pilote dans l'avion quelque part.

Mais au fond, c'est exactement ce qu'ils ont fait, proposer un mode "secure" par défaut. Pourquoi attendre que ça crash ? Si l'objectif est d'abord d'avoir un logiciel qui fonctionne, ensuite d'optimiser ses performances, alors ça le rempli parfaitement.

Vraiment ?

(attention, ça pique 😂)

C'est a cause de ce genre de réflexion

J'ai pas suivi, mais réflexion c'est le nouveau mot pour "se foutre de la gueule de msn messenger" ?

que peux penser un nouveau venu qui connaît Discord et qui découvre le board ?

Say quoi Discord ?

Justement, si des devs ont été convaincu je vois pas bien pourquoi subitement ils reviendraient en arrière.

L'intérêt de GitHub est justement l'aspect social, collaboratif qui en résulte. Et lui ne va pas disparaître.
C'est comme si on disait que GitLab tue le libre car offre des dépôts privés.

Ce que ça va changer c'est que certains payaient pour des dépôts perso privés et qu'ils n'auront plus besoin de le faire.

Voilà qui révèle

Voilà qui révèle rien du tout, à part que je trouvais les deux exemples lisibles et simple à comprendre, avec une plus grande proximité math/info que art plastique/info.

Est-ce vraiment du ressort de Chrome de décider quel driver peut être utilisé ou non?

J'ai l'impression que c'est prendre la décision à l'envers.

We want a stable & secure browser first, a GPU-accelerated one second, only if possible

Chrome ne décide pas quel driver peut être utilisé, ils restreignent certains fonctionnalités en fonction du driver présent. Chrome continue à fonctionner, juste qu'il n'y aura pas d'accélération GPU.

Les bugs dus au driver nouveau ne sont pas leurs problèmes, c'est indéniable. Mais justement, en décidant unilatéralement de prendre position simplement tout mettre en liste noire, ça devient leur problème!

En fait je vois exactement l'inverse. Si Chrome plante avec nouveau lorsque l'accélération est activée, les utilisateurs se retournent vers Chrome. Ce n'est pas aux utilisateurs de savoir que le problème vient d'un mauvais support dans nouveau. Donc c'est leur problème.
En désactivant l'accélération avec nouveau ils suppriment totalement ce problème, en offrant (ce sont leurs mots) un logiciel d'abord fiable et ensuite plus performant.

je doute que faire une armée d'informaticien au lycée/collège soit d'une grande utilité

Avoir des cours d'informatique, de programmation au lycée/collège ne fabrique en rien une armée d'informaticiens. Ce serait comme dire que avoir des cours d'art plastique fabrique une armée de peintres.
Par contre, tout comme avoir des notions de mathématiques est utile, avoir des notions de programmation (et on ne parle pas ici de langage mais de logique, de concepts) peut l'être. Ne serait-ce que parce que justement de plus en plus l'informatique est "partout".

Savoir coder en C, ou connaître la stack TCP/IP

Idem, faut sortir un peu des exagérations inutiles.

comprendre/analyser les effets de masse généré par les réseaux sociaux et leurs collectes de données personnelles associés
plus de monde à se positionner contre les "réseaux sociaux" centralisé et privateur

A moins que je me trompe ça n'a rien à voir avec la choucroute, là on est dans de la politique et plus sur le sujet d'avoir des cours d'informatique.

Et pour finir, à la fin des années 90 quand j'ai eu "option informatique" au lycée on voyait certes de la programmation mais aussi des notions de droits liés aux licences, le rôle de la CNIL, etc.

Je ne pense pas qu'il y ait de problème à faire tourner des images from scratch sur heroku, du moment qu'on respecte leurs contraintes.
Je ne l'ai pas fait, mais j'ai fait tourner du distroless qui est assez proche.

C'est proche de scratch dans le sens où ce n'est pas une distribution, il n'y a pas de gestionnaire de paquet, pas de runtime, pas de shell.

C'est mieux que scratch dans le sens où ça inclus un certain nombre de composants de base et quasi obligatoires :

• glibc
• libssl
• openssl
• ca-certificates
• A /etc/passwd entry for a root user
• A /tmp directory

(source)

Et je trouve que c'est mieux que Alpine dans le sens où ce n'est pas basé sur musl mais bien sur glibc (on se retrouve souvent avec des alpine + couche de compatibilité glibc, j'avoue ne pas bien comprendre le but).

C'est aussi mieux dans le sens où l'image n'a pas de shell, on est plus dans l'idée d'isolation de processus que de virtualisation légère. Il y a tout de même une version :debug avec un shell busybox (à utiliser avec --entrypoint=sh par exemple).

Par contre, c'est plus gros qu'une alpine de base, 16Mo contre 4Mo. Faudrait comparer avec une alpine et les mêmes composants.

Bref, je recommande du distroless, surtout pour du Go mais je pense que pour rust c'est pareil.

Si les PaaS comme Heroku permettent facilement de déployer des applications dans les « langages web classiques », il est également souvent possible de déployer des images Docker, et donc des applications C++.

Avec tout de même un bémol dont il faut être conscient: Heroku n'execute pas d'images docker. Les layers sont extraits et ça tourne sous LXC.

Et ça a quelques incidences à prendre en compte.

Expose

De base en docker une image expose un ou plusieurs ports et ça permet de savoir quoi mapper et qui écoute. Pour Heroku ça ne fonctionne pas, il faut passer $PORT.

CMD /root/myrepeat --docroot . --http-address 0.0.0.0 --http-port $PORT

Entrypoint

L'entrypoint des images est surchargé par /bin/sh -c s'il n'est pas définit.
Par exemple si on utilise distroless pour faire une image Go, l'entrypoint est null et la commande est le binaire Go. Et ça fonctionne bien sous Docker. Mais sous heroku c'est /bin/sh -c <binaire> qui est executé.

En mettant le binaire dans l'entrypoint et la commande à "" ça fonctionne.

HealthChecks

Les healthchecks ne sont pas supportés, le Dyno manager fait automatiquement ses propres checks.

Pour avoir une idée des autres limites, voir Unsupported Dockerfile commands.

Sinon j'ai jamais essayé avec Nix, mais les images multi-stage say bon mangez-en !

C'est exactement le genre de truc débile que je prévoyais de rencontrer avant même d'utiliser ce machin.

C'est cool, tu as donc pu en parler avec les devs avant même que ce soit disponible, non ?

Parce que quelqu'un utilise encore des UNIX ?

La doc officielle est pas mal, mais elle est totalement insuffisante pour faire des déploiements dans la vraie vie

C'est en partie parce que docker n'est que la partie conteneur, pas orchestration (si on oublie swarm). Donc forcément tu n'aura pas les infos sur tout.

• comment faire des Dockerfile en respectant les bonnes pratiques

Pour ça, j'utilise principalement deux techniques:

• utiliser des linter sur Dockerfile (genre hadolint mais il y en a d'autres) : ça ne va pas te présenter les bonnes pratiques mais tu pourra au moins valider ce que tu écris (et tu peux aller voir tout la liste des règles)
• lire les Dockerfile d'autres personnes, par exemple ceux de Jessie Frazelle mais il y en a plein d'autres

• comment tester des Dockerfile en local sans avoir trop d'écart avec ta prod

Tout dépend ce que tu veux tester vraiment.
Pour ce qui est des images en elles-même, tu peux chercher du côté de Container Structure Test par exemple.
Ensuite, je sais pas bien ce que c'est "tester des Dockerfile". Si ton conteneur contient toute ton app, ben tu testes en prod comme ailleurs. Si la question c'est comment tester une application composée de plusieurs services (sous forme de docker) s'en est une toute autre et la réponse peut être beaucoup plus complexe (docker ou non d'ailleurs).

• comment écrire des unit systemd pour démarrer les containers, avec gestion des dépendances entre containers sur une même machine

Ok, donc ça s'est purement systemd, que ce soit des containers ou non ne devrait pas changer grand chose. Je ne sais pas si on trouve de la doc dessus facilement. Je limite au max les units systemd que j'écris, et j'utilise un orchestrateur pour le reste. Et j'évite qu'il y ait des dépendances entre les conteneurs, que chaque service puisse démarrer sans que les autres soient disponible.

• comment scripter le déploiement et la mise à jour de containers sur un petit lot de serveurs, proprement

Je dirais, ne pas le faire.
Les orchestrateurs sont là pour ça. Et nomad c'est bien.

• bonnes et mauvaises pratiques d'administration système avec Docker sur une petite install (moins de 5 serveurs)

On parle de docker ou d'orchestration de conteneurs ? (et donc k8s, nomad, mesos, swarm)

sans nécessité d'un lourd développement logiciel

Ok…

la proposition d'un système expert qui sache produire des réponses multimédia adaptatives aux requêtes des internautes (formulées en langage naturel contrôlé), permettant de naviguer intelligemment dans un corpus de connaissances.

associer, en complément à un système expert, des réseaux de neurones pour suppléer à la lourdeur des calculs impliqués par un système expert

…ok

pensée parasite de plug anal vert gonflable…

Ha oui quand même

j'envisage de fermer ce compte aussitôt le présent message posté (et de bouder à nouveau pour quelques mois)

Ça fait plaisir d'avoir des nouvelles de zino et zind, mais juste une question : pourquoi ne pas avoir envisagé de fermer le compte avant de poster le message ?

Les « bonnes crèmeries », ce sont celles qui ont de la crème fraîche, non ?

Et moi qui croyait que c'était là où on trouve de bonnes glaces 🇨🇦

Cher journal qu'en penses-tu?

Que si ce n'étais pas totalement exagéré au ridicule ça pourrait être intéressant, mais là…

L’application clavier de Google consomme constamment 150 Mo de mémoire. Est-ce qu’une application qui dessine 30 caractères sur un écran est réellement cinq fois plus complexe que Windows 95 tout entier ?

On parle bien d'un clavier qui gère plusieurs agencements, de la prédiction de mots, le fait de pouvoir écrire des mots en reliant des lettres par un trait continu au doigt (désolé je sais pas si ça a un nom cette fonctionnalité) et probablement pas mal d'autres choses comme l'affichage portrait, paysage, en plusieurs résolution, plusieurs modes d'affichage (je peux l'avoir en pleine largeur ou plus petit à gauche ou à droite pour un usage à une main), etc ?

Bref c'est assez représentatif de tout l'article, un biais et une exagération au ridicule qui dessert le problème et qui ne convaincra que les convaincus.

beaucoup d'enfants, entre 9 et 14 ans, préféraient le touchpad à la souris o_O ils semblent difficilement s'y habituer.

C'est peut-être pas qu'une histoire de génération mais aussi que le touchpad saymieux.
Bon ok, pas tous, mais honnêtement je dois utiliser une souris moins d'une fois par mois, et c'est uniquement pour jouer. Le reste du temps je n'utilise que des touchpad (celui de mon xps 15, assez grand et agréable, et un touchpad apple).
Bref ce que je veux dire c'est que même en ayant connu les temps où il n'y avait que la souris comme dispositif de pointage, ça n'empêche pas de préférer aujourd'hui les touchpad et d'être désormais peu à l'aise avec une souris.

Tiens pourquoi tu privilégie distrless pour du statique ?

Parce que sans inclure grand chose ça contient tout de même quelques bricoles quasi tout le temps nécessaires :

The image contains:

• glibc
• libssl
• openssl
• ca-certificates
• A /etc/passwd entry for a root user
• A /tmp directory

Je ne connais vraiment pas bien le build python, mais ça peut pas être résolu par du multistage ?

La dernière fois que j'avais essayé je n'avais pas réussi, mais je viens de rechercher de nouveau et il semblerait que ce soit possible. Pas comme dans leur exemple trop réduit, mais je vais retester de nouveau. Faut dire que je ne suis pas un grand spécialiste de python.

Ce que j'aime dans scratch/distroless c'est aussi une histoire de principe.

Ça dépend de pleins de choses les containers ce n'est pas que des runners de prod

Anéfé. Sans préciser je parlais bien que de services à exécuter (en prod ou autre), et pas d'outils, dev, etc.

Jusqu'à présent j'utilisais pas mal d'alpine, et maintenant dès que je peux du distroless.
Disons que distroless pour embarquer du static, c'est un peu comme du scratch mais en mieux.

Alpine c'est sympa, mais ça finissait toujours par avoir besoin à un moment ou à un autre de la glibc (ou compat) donc l'intérêt se réduit franchement.

Ce que j'aime dans scratch/distroless c'est aussi une histoire de principe. J'aime voir les containeurs comme étant juste mon app/service avec ses dépendances et rien d'autre. Juste une sandbox. La plus petite possible, le reste étant superflus, inutile, source problème, de failles, de maintenance, etc.
Le contraire exact de "containers comme des VMs".

Le seul problème que j'ai pour le moment avec distroless (outre le manque d'une image ruby) c'est pour faire tourner du python avec du pip install durant le build du container. Je crois qu'on peut faire des choses avec BAZEL mais j'ai pas encore vraiment tenté.
Si quelqu'un sait embarquer au build des dépendances python sur distroless, ça m'intéresse grandement :-)

Il y a pas mal de bonnes conférences sur pourquoi c'est bien d'avoir des images petites et comment faire (entre autre de Abby Fuller, par exemple https://www.youtube.com/watch?v=pPsREQbf3PA de mémoire)

---

Après tout dépend aussi du contexte, parfois ça peut se faire d'avoir des images plus lourdes avec un layer commun, partagé entre toutes les images et qui sera dispo sur toutes les machines. Dans certains contextes ça peut le faire, avec l'avantage de mutualiser certains problèmes de sécu, d'outils dispo, de version, etc.
L'avantage si tout est dans une image de base c'est qu'un docker pull ne téléchargera que les layers manquant, donc lui sera relativement rapide.

Je ne pense pas.
Même si oui on injecte aussi du curare.
On le fait par exemple quand le patient ne doit pas bouger mais qu'il ne peut pas être sous anésthésie. Je suis pas médecin, loin de là, mais c'est ce dont je me rappele lorsque mon fils s'est retrouvé quelques temps torax ouvert : anésthésie durant l'opération, curare ensuite pour ne pas bouger, et (je sais pas comment on dit) drogues pour limiter l'effet de la mémoire de l'opération et des suites qui peuvent être traumatiques

Ca va spammer les news de linuxfr et donc gêner beaucoup de monde

Ici ce sont les journaux.

Les journaux sont destinés aux discussions et aux informations qui n'auraient pas leur place en dépêches.

j'ai constaté aussi des trous dans ma mémoire, pour la période avant l'intervention et allant jusqu'à quelques heures après mon réveil

Je dirais que c'est normal mais pas lié à l'anesthésie en tant que telle. En fonction des interventions il est aussi très courant de justement injecter des médicaments qui vont permettre d'altérer volontairement la mémoire pour supprimer (au moins partiellement) les traumatismes de l'intervention.