barmic 🦦 a écrit 5800 commentaires

Pourquoi n'avoir qu'une seule sauvegarde hors site ? Aussi rapide que soit ta connexion, lors d'une destruction totale de ton équipement local, tu as un spof pour au moins plusieurs jours.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comment ce genre d'offre à vie peut être viable ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

J'aurais bien voulu avoir un go rien que pour la marque déjà, et puis bah par respect pour l’œuvre aussi car j’inclue dedans des extraits audios de ses vidéos pour la partie Lore :D

Je comprends tout à fait. Après une des vidéos au sujet du livre il semblait dire qu'il n'y avait pas de problème pour lui tant que ça restait du faire use en tout cas.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Si l'appli contient des sons des vidéos de bob lennon je suis pas sûr que ce soit éligible.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Cool ! Moi j'ai pas encore commencé le miens…

Tu en a parlé à Bob Lennon ? Je suis sur qu'il sera très content de voir ça :)

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

L’accompagnement des parents sur Internet n’est pas seulement destiné à éviter que l’enfant y soit confronté à des images difficilement supportables. Il doit lui permettre d’intégrer trois règles essentielles : tout ce que l’on y met peut tomber dans le domaine public, […]

Je trouve dommage de le dire comme ça. Le domaine public fais souvent référence (dans le contexte même de choses que l'on publie) un état légal. L'amalgamer avec la divulgation contre la volonté de l'auteur de contenu est dommage tant parce que ça donne un idée que le domaine public est illégitime, mais aussi parce qu'il donne l'impression que ce genre de divulgation est légal.

Par ailleurs, ils doivent bénéficier d’une éducation qui leur permette de comprendre les conditions de production des divers médias et leurs modèles économiques.

Comprendre les conditions de production et le modèle économique de tout ce que l'on est amené à accéder sur internet ? Je doute que la personne qui écrive ça soit véritablement au fait sur le sujet.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ce n'est pas de la drosophilie avancée, c'est très important pour comprendre comment Docker fonctionne et comment il faut l'utiliser.

Si si si

Container images become containers at runtime and in the case of Docker containers - images become containers when they run on Docker Engine.

Ce they ce sont les images qui run (Use containers to Build, Share and Run your applications).

Le principe est qu'une image devrait toujours pouvoir être complètement détruite et, quand tu la rebuild avec un Dockerfile, tu retrouves le même résultat à peu près ("à peu près", car ça dépend des commandes exécutées pendant le build).

Le container par contre utilise l'image pour exécuter une commande et il n'y a plus de garantie sur l'état du système de fichier du container.

Reprendre les gens là dessus en allant à l'encontre d'une partie de la documentation ainsi que de l'outillage n'aide en rien.

Je sais très bien ce qu'est une image et ce qu'est un container et reprendre des gens sur le fait de décrire la chose de manière active ou passive c'est ridicule et n'aide personne à comprendre le fonctionnement.

Le principe est qu'une image devrait toujours pouvoir être complètement détruite et, quand tu la rebuild avec un Dockerfile, tu retrouves le même résultat à peu près ("à peu près", car ça dépend des commandes exécutées pendant le build).

Tu n'a donc aucune garanti que cela va produire la même chose. Oui ce serait bien d'avoir des images reproductibles, mais dans la réalité c'est compliqué (tout comme le reste de la chaine de construction). Docker est fait pour ne pas considérer les images comme jetable, mais au contraire pour massivement les réutiliser (c'est entre autre pour ça qu'il y a une distinction entre image et container). Le principe n'est tellement pas de pouvoir détruire une image que le registry docker n'a pas d'API pour supprimer une image. Tu peux la supprimer de ton cache local par contre évidement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Quand tu "run une image" pour reprendre tes mots[…]

Hum https://docs.docker.com/engine/reference/run/

$ docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...]

Si tu penses "redémarrer" comme uniquement "stop" et "start", alors oui, les données sont conservées. Mais ce n'est pas le cas intéressant de Docker.

C'est ce que j'avais compris en lisant :

Ça permet aussi de garder un même volume entre plusieurs démarrages de container.

Je me suis même reposé la question et c'est pour ça que j'ai voulu précisé. Je me suis dis que si moi qui utilise docker régulièrement avait mal compris d'autres pourraient mal comprendre.

Me reprendre pour savoir si c'est le fait de lancer une image qui produit un conteneur ou le fait de créer un conteneur qui se base sur une image c'est de la drosophilie avancée.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Oui dans le cas général. Je vois 2 raisons qui font que c'est très utile de garder intact le système de fichier :

• pouvoir debuger un conteneur qui est parti en caraphe
• garder des données de cache lors de redémarrage

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Le démarrage d'image crée un conteneur. Tu joue sur les mots. Ce que je voulais dire c'est que tu n'a pas besoin de volume pour garder une donnée entre des redémarrages de conteneur.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ça permet aussi de garder un même volume entre plusieurs démarrages de container.

D'image plutôt un conteneur ne perds pas son fs lors d'une extinction ou d'un redémarrage.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je suis pas convaincu. Même avec un flingue sur la tempe, tu ne peux tout simplement pas récupérer la majorité des choses. Je suis pas certains que les SOC soient recyclables ni que ça puisse être rentable et ils existent pas que pour réduire les coûts mais aussi pour avoir une efficacité (le rendement de puissance par rapport à l'énergie consommée).

Mon avis c'est qu'ont ne peux pas faire ce que l'on a fait ces 60 dernières années sans attaquer gravement notre écosystème. Je dis sincèrement pas ça de gaieté de cœur. Je ne suis pas de ceux qui parlent d''"idiotphone" ou autre barbarismes ridicules. Mais il me semble que la société basée sur la consommation est l'opposée de ce qu'il faut. Même si cette société n'a pas produit que de mauvaises choses. Mais tout ce qu'elle a produit l'a était au détriment de la planète (on aurait peut être pu produire autrement mais pas aussi vite).

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Ouais, enfin, en même temps, tu dois impérativement prendre en considération des "microinterruptions" quand tu montes un service. Les sources sont nombreuses (connectivité réseau, surcharge réseau, collisions, attaque DDOS, etc…).

Ce qu'il faut voir c'est quel est le contrat qu'on te donne (en terme de fiabilité, de performance, etc) et quand tu séquence des contrats (samba puis S3QL puis S3) tu as, au mieux, le pire des contrat dans chaque domaine et sinon l’interfaçage va empirer le résultat.

Donc non rien est parfait. En soit ce sont tout un tas de techno très complexes avec pleins de possibilités de plantages et de ralentissement qui tentent de simuler un contrat avec un haut niveau de garantie mais on risque d'empirer les choses.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tes accès fond un passage sur NFS puis un sur le protocole S3-like, puis tu ajoute un heart beat, puis une élection pour savoir qui prend le relais.

C'est pleins de "petits" trucs plus ou moins simple qui doivent se coordonner avec autant de chance de ne pas très bien se comporter les uns avec les autres et avec de potentiels effet de bord (au changement de serveur primaire tu démonte/remonte tous tes points de montages je présume ?).

Je suis pas sûr que ce soit simple quelque soit le sens qu'on lui donne.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je pense que tu surestime beaucoup les clients standard de ces fournisseurs.

Si c'est pour être purement client, l'hébergement c'est bien.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Par exemple sur de la conf d'iLO HPE pour en savoir un peu plus pour de l'authentification.

Le truc tourne indépendamment de l'OS, hein. Par contre je ne connais pas la contractualisation, mais dire vous n'avez pas assez payé pour ce niveau de support c'est différent de "vous avez pas l'OS qu'on veut donc débrouille toi".

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu es jeté sur quel type de demande exactement ?

Par exemple sur de la conf d'iLO HPE pour en savoir un peu plus pour de l'authentification.

Ça c'est ta vision du boulot d'un constructeur (et la mienne aussi). Mais ce n'est pas ce qui est attendu par les clients entreprises qui veulent ouvrir un ticket en disant "ça ne marche pas" et que le fournisseur lance des outils de debug (ou en fasse lancer par le client) pour avoir un diagnostique pour savoir s'il doit envoyer un disque, une carte mère ou dire au client que c'est normal que la diode verte soit allumée quand le serveur tourne.

Ils file ces machines à des professionnels dont c'est le boulot de les garder en condition opérationnel. Le constructeur donne des spec il n'est pas là pour mettre à leur norme la pièce dans la quelle les machines sont installées, vérifier le réseau électrique, etc. Ils te fournissent même des formations si tu veux en savoir plus sur leurs machines.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je pige pas la question. je dit juste que décider de ne supporter que le kernel n'a aucun sens car il n'est pas un composant isolé, vu que l'userspace plus haut en dépend.

L'énorme majorité des cas le userspace dépend du HAL et il n'y a pas de raison particulière pour que le matériel expose autre chose. Si j'ai bien compris ton lien parle d'autre chose : faire tourner des applications d'une version à une autre d'un noyau. Là c'est l'ABI du noyau qui est en question.

Ensuite, ça n'a pas l'air d'avoir été ton expérience et je crois comprendre qu'on a du te dire "merde" à un ticket pour divers raisons lié à la distro.

Pas qu'un seul, mais oui c'est ce que j'ai dis plusieurs fois.

Dès mon premier commentaire :

Par contre j'ai vu des fabricants refuser tout support qui tu n'a pas RHEL ou centos

Dans mon second :

Par contre j'ai souvent vu des fabricants refuser tout SAV si tu n'est pas sur RHEL.

Encore dans un autre :

Si c'était le cas, on ne te jetterais pas pour cause d'utilisation non conforme pour des problèmes purement hardware.

Ce n'était pas clair ?

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Du coup, tu n'as aucune distribution utilsée en entreprise qui est supportée. Vu qu'elles ont toutes des patchs spécifiques.

Bof, non, soit il s'agit de patch du constructeur et les distributions vont les inclures soit c'est mergé upstream et ça passe aussi.

Non, c'est surtout "il faut un point de contact pour exister".

Comprends moi. Je vois pas pourquoi on me jette parce que j'utilise un gentoo quand je demande des conseils sur des éléments purement matériel. Il n'est pas question que les constructeurs soient experts toutes distributions juste qu'elles acceptent que leur job c'est de fournir du matériel et le minimum logiciel pour le faire tourner.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu peux pas juste avoir le support du noyau, vu qu'une partie de l'userspace en dépend. Par exemple, iptables/nftables va dépendre du noyau, vu que tu as des bouts dans le kernel. Gluster peut utiliser des appels systèmes spécifiques du kernel (genre io_uring), SElinux (ou apparmor) interagit aussi avec le kernel, la glibc va masquer certains syscall ou en émuler d'autres. Ou simplement udev.

Parce que tu pense que les fabriquants (je pense aux fabriquants de matériel - on parle de DELL, IBM, Oracle,… - qui supportent actuellement RH pas d'embarquer où RHEL est inexistant) ont une intrication aussi grande ? Par exemple tu aurait un iptables-hp qui utilise l'appel système créé par HP qui utilise le circuit top moumout de la carte réseau HP ?

Comme je le dis plus haut, je n'arrive pas à trouver de cas où ce que tu affirme se révèle. Dans les faits, ses constructeurs sont supporté upstream (de leur fait ou pas) et tu marche aussi bien avec une slackware qu'avec la RHEL.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Pour moi il faut distinguer 2 choses :

• ce qui est présenté par Ethan Lee arrive aussi dans des projets libres communautaires. Je vois pas comment on pourrait arguer que le libre est un monde de consensus (en particulier ici sur linuxfr)
• par contre Microsoft affirme « Microsoft <3 Linux » et dans les faits il y a des contre points

Mais linux n'est pas le libre et les décisions controversées ne sont pas l'apanage du code fermé.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Tu extrapole beaucoup il me semble. J'ai plutôt l'impression que c'est "on ne veut pas gérer 42 distributions" (rien que pour pouvoir reproduire facilement) et "on veut pouvoir payer quelqu'un pour corriger en cas de besoin". Donc avoir RHEL et Suse de supporter, c'est pas mal. D'ailleurs, on voit Ubuntu qui commence à être supporté, pareil parce qu'il y a quelqu'un qu'on peut payer et il y a de la demande client.

Si c'était le cas, on ne te jetterais pas pour cause d'utilisation non conforme pour des problèmes purement hardware.

Après je me suis peut être pas très bien exprimé, je ne crois pas que ce soit quelque chose de particulièrement machiavélique, soit c'est une reproduction de comportement que l'on trouve ailleurs (sur le matériel avec vente liée par exemple) soit c'est de l'incompétence/mauvaise organisation/volonté de réduire le nombre de demande de support.

S'ils ne voulaient pas supporter 42 distributions, ils pourraient parfaitement supporter le nombre qu'ils veulent de noyau LTS (la dernière, les 2 dernières, les 3 dernières…) et te dire de te débrouiller avec ton OS (éventuellement avoir une préco pour une distrib', mais une préconisation pas un truc qui sert à t'invalider en support).

Ce n'est pas simplement parce que c'était une (grosse) boîte américaine avec les contacts chez les constructeurs déjà établis ?

Si c'est le cas du coup c'est moins "on veut pas supporter 42 distributions" que "on ne supporte que les distributions avec qui on a un accord financier". Mais ça revient plus ou prou au même, faut avoir une cravate et un chéquier pour pouvoir exister en tant que distribution.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Notons quand même que dans un monde où on conserve 20 ans son smartphone, ça ne va pas être simple de révolutionner la technologie tous les 6 mois. ça ne va pas être simple pour les fabricants de survivre.

Avec un taux de pénétration à 100% un renouvellement tous les 20 signifie aucune vente pendant longtemps.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Comme je disais c'est un peu plus puisque tu retrouve de la part des fabricants un peu la même démarche que pour les ventes liées. Je dis ça sans complotisme je ne crois pas du tout que RH soit derrière ça. Juste que RH rassure les fabricants parce que c'est une entreprise qui a une image de sérieux et puis 10 ans de support (oulala c'est bien 10 ans de support (non¹)). C'est pour ça qu'on a pu voir Suze à l'époque de Novel avoir le même traitement.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

Je n'ai jamais pu constater de support matériel différent entre RHEL et une autre distribution.

Par contre j'ai souvent vu des fabricants refuser tout SAV si tu n'est pas sur RHEL.

https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll