totof2000 a écrit 1856 commentaires

je crois que tu n'as pas compris le second degré.

Donc, transformer un "vieux" datacenter, pour le mettre à l'état de l'art, c'est mieux que d'en construire un neuf, je suis d'accord.

Oui, c'est comme transformer GTK/Gnome2 en GTK/Gnome 3, ou KDE3 en KDE4 : c'est mieux de les transformer plutôt que de reparetir de zero … MAis en pratique ce n'est pas toujours possible. Pour les datacenters, il faut le faire alors qu'il y a déjà des choses qui tournent dedans. Donc tu n'as pas forcément la même marge de manoeuvre pour transformer, parce que l'existant doit continuer à fonctionner. Donc il est potentiellement plus efficace de reconstruire autre chose que d'adapter l'existant. Après rien n'empêche de reconstruire/adapter l'ancien site lorsqu'il est vide (ou quasi vide), mais le faire sur de l'existant c'est pas toujours évident (par exemple, il n'y a peut-être pas ce qu'il faut aux alentours pour mettre en place un système de refroidisse ment en circuit fermé, etc …).

En France, et probablement en Europe, les systèmes de production de froid dit "PAC air à eau perdue" (adiabatique) ne sont plus autorisés (pensez légionnellose) à l'installation neuve. Et puis la facture d'eau… et la maintenance supplémentaire que ça demande (et qui se paye).

Oui, donc c'est pour ça qu'il faut arrêter de construire des datacenters plus respectueux de l'environnement, mais garder les anciens qui eux ne le sont probablement pas.

Il est parfois (voire même souvent) bien plus efficace de refaire from scratch plutôt qquer de patcher l'existant.

Dans le ca sde datacenters avec du matériel en service, la méthode c'est de reconstruire, déplacer les services et arreter l'ancien.

On peut aussi se dire qu'on limite nos besoins.

Peut-être dans une certaine mesure (l'exemple que tu donnes est intéressant), mais en réalité, le fait est que si le besoin n'est pas couvert ici, il le sera ailleurs mais dans des conditions potentiellement plus néfastes que si c'était fait ici. D'autant plusqu'en France on a la possibilité d'avoir une énergie peu chère, mais par idéologie certains veulent la rendre artificiellement plus onéreuse (alors qu'on pourrait investir l'argent dans des mesures permettant de réduire l'empreinte environnementale des datacenters).

Ne construisons plus de datacenter en France. Laissons les se construire aux US, ou en Chine (ou tout le monde sait que l'énergie y est décarbonnée), ou en AMérique du Sud (ou il y a pas mal de régions ou l'eau manque). On sait que ce sont nos gentils amis, que jamais ils n'iront inspecter nos données, que jamais ils ne s'en serviront comme pression cntre nous. D'ailleurs on le voit bien, le fait d'avoir fait disparaitre la plupart des industries de France nous a bien rendu service (masques en abondance pendant la pandémie Covid, pas de problème d'approvisionnement de médicaments, et j'en passe).

Avec un bon tutoriel c'est beaucoup plus simple que tu ne le crois. Tu pourrais le faire avec une machine qui a quelques Go de RAM (pour y mettre un Virtualbox ou un libvirt/kvm). Il suffit juste d'être méthodique et on y arrive.

De nos jours il semble que récupérer l'adresse IP (via nslookup par exemple) d'un site web ne suffit souvent plus du tout a y accéder en la tapant dans la barre d'adresse du navigateur web.

La formulation n'est pas claire : j'ai du m'y reprendre à trois fois pour tenter de comprendre ce qui est dit …

J'ai bien compris que cela venait du fait de "l'industrialisation des sites web" (via virtualisation, utilisation d'outils d'optimisation type cloudflare, …), mais donc je n'ai pas trouvé comment le navigateur web arrivait à accéder au site web.

reverse proxy, virtualhost Apache par exemple (ou nginx : voir https://www.digitalocean.com/community/tutorials/how-to-set-up-nginx-server-blocks-virtual-hosts-on-ubuntu-16-04 ) pourront t'aider à comprendre pourquoi l'IP ne suffit plus ( le serveur web ou le reverse proxy analysent le FQDN de l'URI que tu demandes et te redirigent vers le bon site en fonction de cette information).

Tu peux le tester chez toi, sur ton PC avec des VMs et un dns local par exemple. En regardnt les logs des divers maillons de la chaine tu pourras comprendre le pourquoi du comment

… faire un script shell qui fait plein de trucs puis appeler du python ?

Pourquoi ne pas tout faire en python ? Ce serait plus cohérent. parce que faire du shell qui appelle bc, pus un autre truc qui appelle Python … je suis sûr que Python contient déjà tout ce qu'il faut.

… pour les nombres à virgule flottante.

C'est un peu court jeune homme. ;)

Un peu moins de condescendance SVP. c'est aussi court que "On peut avoir la sécurité sans libertés, mais aucune liberté sans sécurité." (qui au passage est encore une phrase creuse digne d'un pipotron sortie juste pour convaincre des gens qui sont satisfaits de phrases toutes faites qui sonne bien sans y réfléchir).

On peut même s'y sentir libre.

C'est une croyance non étayée, un dogme même digne de 1984. Je n'y crois pas du tout. Dans un régime tiotalitaire seuls ceux qui ont le pouvoir se sentent libre (et encore …).

On peut avoir la sécurité sans libertés, mais aucune liberté sans sécurité.

Non c'est faux : sans liberté tu n'es pas en sécurité.

Ca n'a aucun intéret, mis à part ajouter une couche de complexité. A moins que les contructeurs ne continuent à implémenter UEFI comme des gorets …

Je parle en terme de compatibilité ascendante : la libc reste plutôt stable à ce niveau. Toi tu me parles de problèmes inter-distributions qui est un autre problème et qui n'a pas grand chose à voir avec la libc.

I can pull down a 20 year old exe and still run it today on Windows.

Pas sûr que ça fonctionne pour tous les programmes.

While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not.

While the Linux syscalls themselves are very stable and reliable, the c library on top of them is not.

La libc est plutôt stable. Il doit confondre avec d'autres bibliothèques non ?

juste pour une application

Non, ce n'est pas la première fois que je rencontre ce genre de problème avec Python : je ne l'ai juste pas systématiquement posté sur Linuxfr.

Je soupçonne surtout que le truc est assez mal packagé en fait.

C'est bien LE problème de python … enfin l'un des principaux problèmes. Devoir installer un virtualenv pour une appli GUI c'est loin d'être top (déjà devoir faire du virtualenv pour n'importe quelle appli c'est pas génial).

Je préfère largement Ruby à Python, mais pour être franc, je ne pense pas que je l'utiliserais si j'avais ce genre d'appli à développer : on pourrait je pense rencontrer les mêmes problèmes.

C'est quoi ton soucis avec Python exactement

Peut-être entre autres un peu le même souci qu'avec XML à une époque : l'utiliser pour tout et n'importe quoi …

Et du coup tu conseilles quoi comme langage de script

Peut-être que dans le cas présent, un langage de script n'était pas le plus adapté au développement de l'appli en question.

Bon, c'est vrai j'ai été un peu provocateur, mais c'est le genre de problème que je rencontre bien plus souvent avec des programmes écrits en Python qu'avec des programmes écrits avec d'autres langages.

Je me suis posé la question, mais quand je vois le nombre de liens de propagande politique orientée ici même, je me suis dit que je pouvais quand même poster. On reste dans le sujet global de Linuxfr, et l'article en soi est intéressant.

Avoir un outil qui les vérifie globalement c'est un peu compliqué. Il faut être vigilant je pense sur tous les trucs qui peuvent exécuter des actions : je pense aux documents de bureautique avec macros ( word, excel, access, powerpoint, libreoffice, etc …), potentiellement les documents postscripts et pdf. Le seul outil je pense qui puisse scanner tout ça devrait être un bon antivirus. Mais pour les autres documents je ne vois pas comment faire pour détecter la corruption de ceux-ci.

Et pour les gens qui sont allergiques au mot « syndicat », il y a aussi le code d'éthique de l'ACM.

Pour ma part je ne suis pas allergique au mot "syndicat" mais je suis allergique à ce que sont devenus les syndicats en France aujourd'hui (tout comme je ne suis pas allergique à la gauche, mais à ce qu'est la gauche aujourd'hui en France). Mais bon, je ne sais pas si c'est le lieu ou le moment pour débattre du sujet.

Allez poster ça sur des sites spécialisés. J'essaie de m'éloigner ces temps-ci de toutes ces polémiques à la c**, et les retrouver ici commence sérieusement à me gaver.

Bien souvent ce ne sont pas les admins qui mettent un nginx, mais les architectes ou les devs ( dans un contexte devops …).

Ça vaut VRAIMENT le coût d’aller voir des services mesh ou de simplement installer un vpn quand tu as ce genre de contraintes.

Je ne dis pas le contraire, mais dans certains cas la mise en place du service mesh est tellement complexe (parce qu'il faut commencer à expliquer ce que c'est, ce que ça fait, etc …) que mettre un nginx est bien plus pratique (en tout cas dans l'immédiat).

installer un vpn

Euh … pas sûr que mettre en place un VPN entre conteneurs soit plus simple que de mettre en place un nginx pour communication https. Mais bon, j'ai fait le même constat que toi : on parle de UUOC lorsqu'on fait du shell, et j'ai l'impression qu'on a souvent un UUON (Useless Use of NGINX) lorsqu'on met en place du docker …

Les cartons de vins, ça dépend lesquels : j'en ai déjà eu, ils ont eu tendance à se déformer. Mais je vais voir ce que kje peux trouver de ce côté.