Marotte ⛧ a écrit 8739 commentaires

Et ça suffira à tout le monde.

Tu verras dans cinq ans !

Je connaissais l’existence de ce débat mais j’ai découvert (enfin si j’ai compris inversement aussi bien que j’ai lu de travers !) que Hurd n’était à ce jour pas le plus prometteur des micro-kernels pour les spécialistes, car pas assez micro et pas aussi performant qu’on pourrait le souhaiter (et ce qui ne serait pas un problème de Mach, mais de Hurd en particulier ?). En tous cas c’est intéressant comme morceau d’histoire pour avoir une idée du chemin qu’a emprunté Linux au cours de ce presque dernier quart de siècle, pour être ce qu’il est aujourd’hui. À savoir, sans tentative de de troll d’aucune sorte de ma part, le noyau *NIX le plus florissant de tous les temps, même si des noyaux BSD ont eux (lui ?) aussi quelques réussites notables, mais fatalement moins visibles du fait de leur licence je pense.

Je me suis dit que de nombreux utilisateurs ou contributeur aux LL et à Linux parmi les moins dégarnis pouvaient probablement ne jamais avoir entendu parler de ce débat, quasi préhistorique, d’où ce post.

Sur l’artificialisation des sols : une grande partie sont des mine à ciel ouvert mais ce n’est pas toute. Je ne crois pas qu’on puisse, mais peut-être ai-je tort (?), considérer qu’une mine souterraine artificialise les sols est je crois plus faible. La production de biocarburant qui accaparerait des hectares de terres cultivables me semble plus dangereuse.

Aucune solution actuelle n'est vraiment acceptable sur le long terme.

Donc en fait, on devrait se résoudre à principal du changement climatique (si on ne compte pas la décroissance et la sobriété?

Je me demande également c’est que pourrait-être une « activité professionnelle non rémunérée pour son propre compte »…

Je me demande également c’est que pourrait-être une « activité professionnelle non rémunérée pour son propre compte »…

Tu utilises CoreOS/ContainerOS sur ta machine personnelle, ou ton poste de travail professionnel si tu es informaticien ?

Même pour les serveurs, la conteneurisation vient avec sa problématique, tout comme la virtualisation qui en possède aussi, comme elle a des avantages.

La conteneurisation est une très bonne solution aux déploiements complexes, distribués, et avec un fort besoin de changement de mise à l’échelle rapide.

C’est typiquement le cas d’un fournisseur de solution SaaS. Pas que, mais c’est quand même le cas le plus évident et sur lequel je pense que personne ne remet en cause la supériorité de la conteneurisation pour ça.

Si tu as besoin d’un cluster on-pemises distribué sur deux ou trois sites comme backend pour du big-data, avec la possibilité de disposer de hardware dédié, alors y ajouter une couche de conteneurisation « parce que c’est possible et que c’est l’avenir » me semble pas judicieux.

Je serais dans ce cas très curieux d’entendre les arguments en faveur de ce que je pense être un mauvais choix d’architecture.

Les aficionados des la conteneurisation te diront peut-être qu’il faut utiliser Kubernetes, Rancher (et sûrement d’autres trucs additionnels) et écrire/utiliser un opérateur qui se chargera de faire tout cela à ta place ensuite. Puis développer sous Eclipse Che, c’est beaucoup mieux !

Les containers c'est nickel pour packager pour de la prod. Mais pour itérer en dev …

Moi aussi j’ai un peu de mal avec cette hype autour de la conteneurisation. C’est une technologie très intéressante, voire indispensable aujourd’hui, pour gérer les déploiements complexes sur des systèmes d’information immenses et protéiformes, ou pour la prod’ éventuellement comme tu le dis, mais sur de petits SI avec une topologie relativement simple, et à fortiori en tant que développeur « isolé », c’est la définition même d’overkill je trouve.

Quand on ajoute à ça la continuelle métamorphose de l’écosystème, où tous les six mois un nouveau produit va enfin résoudre les problèmes, ce qu’il fait généralement, mais que six mois plus tard un nouveau produit est présenté comme tel, pareillement, ça donne pas une confiance terrible dans la viabilité de l’approche, et surtout pas en tant que solution universelle et évolution incontournable.

Je ne comprends pas trop ce que tu veux dire, mais les environnements virtuels permettent justement de résoudre ce problème.

Je m’interroge sur la question de savoir si de cette solution (les venv) au problème (des incompatibilités nombreuses) ne découlerait pas un autre problème : celui de la redondance et de la complexité globale.

heureusement car bon nombre se scripts d'initialisation dont en Bash dans l'os

De moins en moins grâce (ou à cause selon le point de vue) à systemd.

Tu prêches un convaincu.

Je pense aussi aux mots clés et built-in : wait, trap, kill voire coproc.

Le multiprocessing en Python perso je trouve ça lourdingue à écrire.

offre la possibilité par exemple d’utiliser le noyau de FreeBSD

Ce qu’offre aussi bien évidemment le système FreeBSD lui-même (je préfère préciser).

C’était plus de l’ordre de la boutade que du troll mais oui, je réalise bien que ce n’est pas un propos sérieux. Les propos sérieux ne sont pas ma spécialité, j’y très recours très rarement ;).

Je disais « de l’Univers » car Debian ne se veut pas une « simple » distribution GNN/Linux, mais un « OS universel », qui vise à faire fonctionner TOUT les ordinateurs, offre la possibilité par exemple d’utiliser le noyau de FreeBSD, et développe même, avec le FSF, un noyau (basé sur un micro noyau et donc, sur le papier, censé être mieux que Linux). C’est à ma connaissance, en tant que distribution GNU/Linux celle qui supporte le plus d’architectures matérielle.

Le noyau Linux est d’ailleurs lui-même assez « universel », étant donné le nombre d’architectures et de matériel qu’il supporte (du gadget connecté au super-calculateur…), à ma connaissance (relativement limitée), aucun autre noyaux type *NIX commercial n’était jamais arrivé à ça.

Ils disent aussi que les dauphins se sont mieux débrouillés que nous quand ils leur ont passé le sonar, et que s'ils ont besoin d'un OS un jour, c'est à eux qu'ils le passeront. Ou aux manchots, bien sûr.

si un interfaçage direct entre cerveau et machine est disponible je suis d’accord qu’on le réserve en priorité aux dauphins ! Sans aucun doute. ^^

Commentaire supprimé

environnement virtuel dédié précisément à cette application.

Un environnement par appli ça veut bien dire que l’on peut se retrouver avec appliA qui nécessite bibtruc.≥ X.Y.Z et appli2 qui nécessite bibtruc =X.Y.U ?

Ce qui aura une fâcheuse tendance à l’effet boule-de-neige, avec les dépendances de dépendances, et qu’il faut donc avoir peu d’applis en cour de développement ou bien beaucoup d’espace disque à disposition ? Pas simple à gérer, sans parler de l’effort intellectuel nécessaire quand on se retrouve à devoir travailler en parallèle avec deux versions d’une lib qui sont « un peu différente » ?

J’ai l’impression que les lib externes, il faut vraiment réfléchir à deux fois, en Python comme pour tout langage, et que « réinventer la roue », ou internaliser le morceau de code de la dite lib au sein même de son appli, vaut parfois mieux que prendre une lib pas hyper stabilisée dont on va utiliser p-e 10%, non ?

On peut à mon avis le qualifier de langage de programmation en bon est dû forme du fait qu’il soit « Turing-complet ». Ceci dit le Brainfuck l’est également, ce dernier est d’ailleurs le plus dépouillé que l’on puisse faire comme langage Turing-complet à ma connaissance (et c’est très beau, àmha ^^).

Mais un shell est conçu, et de plus configuré par défaut, pour servir d’interface entre l’utilisateur et le système, pour une utilisation « interactive ». Pour prendre un des exemples les plus parlant : en Python, Perl ou d’autres langages interprétés, une erreur de syntaxe entraîne la fin de l’exécution de l’interpréteur, il « n’ira pas plus loin », alors qu’en Bash (et autres), à moins de lui spécifier de s’arrêter sur tout code d’erreur (via set -e), et donc pas uniquement les erreurs de syntaxe… il continuera, en passant à la commande suivante. C’est compréhensible : si une erreur de syntaxe stoppait ton shell, par exemple que tu te trompais et essayais d’exécuter une commande qui n’existe pas, et que tu devais alors de re-logger au système à chaque fois, tu deviendrais fou.

Une autre manière de saisir la différence : essaye d’utiliser l’interpréteur Python comme shell de connexion, à la place de Bash. C’est techniquement tout à fait possible. Tu lances en automatique un import os histoire d’avoir des commandes (qui seront des fonctions Python donc) pour afficher/copier/supprimer/etc des fichiers, etc, etc… tu te rendras vite compte que ce n’est pas fait pour.

Entendons nous bien, je ne veux décourager personne d’écrire des programmes en shell, c’est le langage que j’utilise moi-même le plus, mais ce que je souhaite faire passer comme message, c’est que sans prendre conscience de cela, je ne crois pas qu’on puisse avoir une bonne expérience avec Bash. On ne peut pas comparer sur un pied d’égalité un shell d’un côté, et de l’autre un langage de programmation conçu comme tel « dès le départ ».

Certes il a un rôle particulier mais n'est-ce pas le cas de tout les langages?

Sans aller jusqu’au Brainfuck, qui est d’abord un jeu et clairement pas un outil qui puisse rendre le moindre service en dehors de l’exercice intellectuel, oui, des langages il en existe de toute sorte (on peut prendre CommonLisp ou Erlang par exemple, relativement exotiques comparé aux langages les plus répandus), peu se ressemblent vraiement. Mais « shell interactif » c’est vraiment un rôle (et pas un paradigme de programmation…), assez à part. Selon moi, on est pas obligé de voir les choses de la même manière.

Pour avoir eu à migrer une appli toute simple en Python (écrite par quelqu’un d’autre), simplement de RHEL7 vers RHEL8, je vois ce que tu veux dire. Le fait qu’il m’ait fallu, comme l’explique Benoît Sibaud, recourir à pip freeze pour installer très précisément la version X.Y.Z des quatre ou cinq bibliothèques utilisées (de mémoire stomp, request, … me souviens plus des autres) ça m’a surpris.

Je suis peut-être un vieux con qui n’a rien compris à la vie, ce qui me va parfaitement jusqu’à maintenant, mais lorsqu’il s’agit d’« appli » destinée à répondre à des problématiques de devops, qui ne sont ni énormes ni potentiellement destiné à devoir « passer à l’échelle » comme on dit, je n’ai jamais rien trouvé de plus satisfaisant que Bash. Certes c’est absolument incommode à écrire, bourré de subtiles pièges plus surprenant les uns que les autres, mais une fois que ça fonctionne ça ne va pas casser aussi facilement, simplement parce qu’on passe à une version majeur supérieure du système. La plupart du temps ça fonctionne avec zéro modification. Au pire, il faut voir que Bash 5 (la version actuelle) propose des « mode de compatibilité », pour faire tourner le script écrit il y a 15 (?) ans pour Bash 3.2 et qui tourne depuis, que personne ne veut, ne peut ou n’a les moyens de ré-écrire entièrement, et que les utilisateurs finaux considèrent comme crucial de ne surtout pas perturber.

Ce serait totalement idiot de développer des applications complexes, pour lesquelles le paradigme objet, ainsi que la cohérence et les performances brutes de l’interpréteur sont pratiquement indispensables, en Bash (ou un autre shell), mais ça me semble tout aussi idiot de se priver de l’intégration d’un shell avec le système, qui rend de fait le concept de « déploiement » anecdotique, offert par le shell en la matière.

Attention je n'ai pas dit que l'on ne pouvait pas utiliser pip sous Debian. Juste qu'il faut passer par un environnement virtuel.

OK je vois. Oui le recours à un “Virtual env” pour utiliser Python c’est devenu indispensable. Il faut s’y habituer. C’était une vrai question, je me demandais si tu ne faisais pas référence au fait que pip ne permettait plus l’utilisation de sa fonctionnalité de recherche des dépendances (peut-être est-ce de nouveau possible ? Ça fait un moment que je n’ai pas fait de Python). Pour Bash la recherche, et l’installation, de dépendances ça passe par apt ou dnf, what else !? ^^

Pour résumer le fond de ma pensée : Python est un outil formidable, mais il ne remplace pas le shell, ce sont vraiment deux outils différents, àmha.

Ceci dit pour Python comme pour Bash, le soin à apporter à la sélection des dépendances qu’on va utiliser (leur pérennité, stabilité, notoriété) ne doit pas être négligée.

Faudrait lui montrer que sous Linux elle peut utiliser des smileys et des symboles divers pour les noms de fichiers. ^^

$ ls plop*
'plop ✔'

on ne peut plus installer de dépendance avec pip (sur Debian du moins). On a accès qu'aux version disponibles et gérées par les mainteneurs de la distribution.

Je ne savais pas et je suis très étonné, pourquoi donc un tel malheur sur le meilleur OS de l’univers ?

Le premier langage interprété "en live" est le Shell (Bash, pour les Linuxien).

Gardons à l’esprit que Bash est d’abord un shell, et non un langage de programmation à proprement parler bien que ce soit le mailleur langage pour programmer, si on veut bien se le dire.

Je plaide coupable. Ton commentaire est très juste par ailleurs.

mais un isolant tout à fait médiocre. Par contre il est très ignifugé, ce qui est la raison de son large emploi.

Est-il si médiocre que cela s’il a été choisi parmi d’autre lorsque prise en compte cette contrainte de résistance au feu ?

Ceci dit j’ai effectivement tort dans les grande largeurs. Je n’avais même pas en tête le caractère ignifuge. Donc oui, j’aurais dû affirmer ça avec moins d’aplomb certainement, et surtout, ne pas l’affirmer du tout. C’est évident.

pas toujours noyée dans le ciment.

Ça semble être l’utilisation la plus répandue quand même ? Ceci dit en écrivant mon message j’avais pensé aux toitures/tuiles en contenant et dont, me semble-t-il, même avec tout le soin de l’entretenir convenablement, il est inévitable qu’il s’en répande dans l’air.

une idiotie doublé d'un jugement de valeur douteux.

Une parfaite idiotie j’en conviens. Cependant aurais-tu encore la force mentale et la pitié suffisantes pour m’expliquer en quoi c’est un jugement de valeur ?

Serait-ce que je juge que les bâtiments sont de manière générale mal entretenus ?

Un bon entretien n’aurait pas évité le problème, ça j’ai bien compris, maintenant. Mais je continue de m’interroger : le mauvais entretien des bâtiments (ou machines) utilisant ce matériau n’aurait-il eût pas tout de même un rôle non négligeable dans la dangerosité effective de celui-ci ?

Encore merci à toi pour la correction qu’apporte ce second message. Et au cas, que j’espère très peu probable, où tu pourrais t’en soucier et avoir un doute : je ne te tiendrais pas rigueur de ne pas me répondre encore une fois de plus.

Je cite la page FR Wikipédia sur cet enfouissement à Asse. Du « cherry-picking » oui, mais en tout objectivité bien sûr ! ;)

il s'agit là de la plus haute concentration en césium-137 mesurée depuis la fin du stockage en 1978. Cela correspond à 24 fois la limite de la concentration négligeable, mais encore significativement en dessous de la limite supérieure autorisée. Dans le trou, il y avait environ 1 l de saumure radioactive, provenant de l'espace des déchets.

Les déchets doivent maintenant être entreposés définitivement dans le puits Conrad, une mine de fer fermée en 1982 à Salzgitter.

(ça va compter un bras ce déménagement, certes, mais la solution on l’a bien).

En fait quand les antinucléaire disent qu’on n’a pas de solution c’est sous-entendu une solution parfaite ? Dans ce cas alors ok, mais faut être honnête, le dire, sinon on ne fait que déformer la réalité.

Une remarque pour finir : la résistance quasi systématiques des populations locales ne participe pas à ce qu’on puisse choisir les lieux de premiers choix, les plus adaptés du point de vue des ingénieurs spécialistes.

Ce qui me préoccupe c'est que ces centrales et les déchets produits nous engagent pour des durées très longues. Et que cet engagement ne pourra pas diminuer.

Nous engage à quoi précisément ? Continuer à cramer les hydrocarbures fossiles ce nous engagent pas ? Raser les forêts primaires ne nous engagent pas ? Miser sur l’IA ne nous engage pas ?

Ce que je veux dire c’est que tous nos choix nous engagent, ils engagent l’avenir de nos descendants je dirais, mais c’est le cas de tout ce qu’on fait et qui consiste à transformer notre environnement finalement, non ? J’ai peut-être mal compris ce que tu voulais dire (ça m’était déjà arrivé une fois en 1993 ! ^^).

Je sais parfaitement que j’emploie un ton souvent péremptoire. Mais dans ce cas précis, je ne sais pas comment tu interprètes :

et c’est toujours je crois

ce serait OK encore pour plein d’usage, non ?

C’est toujours épatant de voir des gens soucieux de signaler aux autres quand ils ont tort sans autre « argument » que d’inviter à aller lire la page Wikipédia, enfin, « la », « une » page Wikipédia non précisée, aussi simple soit-elle à deviner, à priori.

Non, enfin pas précisément.

Ça c’est le pompom. donc en plus, ce que tu dis c’est « non, mais enfin si un petit peu en quelque sorte » ?

Affirmer des choses dont on doute, même si ça peut souvent faire passer pour un con, ce dont je me fous, ou finir par énerver ses interlocuteurs, un peu plus embêtant mais bon, personne est obligé de lire, encore moins adhérer, émettre une affirmation au lieu d’une question c’est souvent une bonne manière, la plus rapide, de connaître la vérité, d’avoir une réponse (même si ça rate, comme ici).

Il y a des gens qui te disent : < Tu t’as trompé, la vérité c’est ceci, parce que cela. ».

Et puis il y des gens qui, comme tu viens de le faire, te disent : « C’est faux, enfin pas précisément, tu pourrais avoir été lire une encyclopédie avant de l’ouvrir. »

C’est pas un problème, tu fais et tu penses ce que tu veux. Moi aussi et c’est pourquoi je te fais ces remarques.

Tout à fait mais en pratique on utilise toujours 8 bit par caractère, le 8e bit qui servait à l’origine de bit de parité pour la détection d’une corruption de donnée, par exemple lors d’un transfert par un réseau, n’est pas utilisé du tout (pour l’ASCII de base comme tu le précises).
Merci pour la correction en tous cas.

Si je tenais celui qui tient ce foutu marteau je lui ferais bouffer quelque clous. Les clous sont même pas alignés, c’est ni fait ni à faire, un travail d’art absent, talent ? Même pas un chouïa !

Ya longtemps ça coûtait rien de balancer de l'amiante partout dans un nombre considérable d'ouvrages en tout genres (écoles, usines, sous marins etc etc). On s'en est pas privé d'ailleurs.

C’était comme tu dis il ya longtemps, et contrairement aux matières radioactives qu’on cherche à enfouir, l’amiante ce n’était pas pour s’en débarrasser mais parce que c’était (et c’est toujours je crois), l’un des matériaux isolant les plus efficace qu’on connaisse.

L’amiante telles qu’utilisée pour les bâtiments, si on avait entretenu correctement ces bâtiments, ce serait pas un problème. Ce n’est de la matière radioactive qui nécessite un « emballage » de plusieurs centimètres de plomb (par exemple) pour être inoffensif.

Dans les plaquettes de freins de train ou ce genre d’usage, qui répand des particules dans l’air, c’est sûr qu’il faudrait mieux éviter, mais dans le cas des bâtiments, s’ils sont entretenus ce serait OK encore pour plein d’usage, non ?

Faudra bien qu’on maîtrise un tant soit peu les cycles de vie de toutes les merdes qu’on fabrique.

Notre maison brûle certes, mais il s’avère surtout que la poubelle déborde !

Our goal is to promote usage and support of the UTF-8 encoding and to convince that it should be the default choice of encoding for storing text strings in memory or on disk, for communication and all other uses.

Pas trouvé quand avait été écrit ce manifeste mais n’est-ce pas aujourd’hui un fait établi ?

Je crois que ce qui a rendu UTF-8 incontournable c’est le fait qu’un texte encodé en ASCII 8 bit est sans la moindre modification déjà un texte encodé en UTF-8. L’adoption d’Unicode aurait à mon avis pas été gagnée sans cette caractéristique.