Sytoka Modon a écrit 4544 commentaires

Non. Un machin qui a 20 ans et qui est aussi important mais n'est pas encore vraiment déployé a un problème de conception.

Le problème n'est pas Humain. Essaye de déployer IPv6 sur une grande université multi-site et tu verras que ce n'est pas si simple… Heureusement, les outils changent et évoluent et c'est chaque jour de plus en plus simple. Cependant, je n'ai pas encore vu personnellement de plan détaillé pour le faire chez nous.

Je sais que le multicast existe en IPv4 mais il est peu utilisé et franchit rarement les routeurs. Il est un peu partout dans IPv6… Pour le mobileIP, c'est plus que cela a du occupé les spéciales un paquet de temps pour un truc qui a très peu de chance de vraiment être utilisé.

Il a fallu un paquet de temps pour avoir des passerelles. Si celles-ci étaient si bien que cela, on aurait IPv6 à coté d'IPv4 sans soucis. Mais elles ne sont au final pas si transparente ces passerelles…

Perso, j'ai jamais compris pourquoi il n'avait pas simplement rallongé les adresses IPv4 avec un préfixe choisis et avoir ainsi une passerelle transparente. Si la transition est longue, c'est en partie parce que les acteurs historiques ont un paquet d'IP publiques donc n'ont pas de réelle pression. C'est aussi que cela arrange un paquet de monde que les particuliers aillent chez Netflix, Youtube et les ampoules et capteurs de température chez machin.com plutôt que d'avoir chacun des serveurs chez soi.

Le vrai problème est que bien que non spécialiste, le projet a été mal monté avec des trucs trop ambitieux qui juste marche pas à grande échelle (multicast, mobileIP…) voire ne serve à rien (un service comme mosh en UDP chiffré symétrique résout très bien les problèmes de mobilité du client) et une non compatibilité v4 v6 obligeant à faire des passerelles 6to4. Bref, un beau bordel qui dure depuis trop longtemps. Je pense que cette migration sera un modèle pour les générations futures de ce qu'il ne faut pas faire ;-)

Comme il y a pas mal de manière de tester tout cela, il y a un checker en bash facilement lisible qui capitalise tout cela : Spectre & Meltdown checker

https://github.com/speed47/spectre-meltdown-checker

wget https://raw.githubusercontent.com/speed47/spectre-meltdown-checker/master/spectre-meltdown-checker.sh

Par contre, je ne comprends comment vous voulez remplir en faisant juste l'annonce 4 jours avant…

Et puis, cela anime le débat ;-)

On aurait un boot un peu standard et un système de reconnaissance du matériel aussi sur ARM (type BIOS ou équivalent) qu'on pourrait envisager bien plus facilement de basculer sur des OS alternatifs. Il me semble qu'ARM a amélioré les choses ces dernières années mais si cela ne bouge pas plus, le jour ou Intel (là ils sont bien occupés par autre chose) fait une puce x86 aussi puissante et qui consomme moins, il aura du mal à se maintenir…

mais le user doit également se renseigner un minimum avant d'acheter.

Il faut arrêter de rêver. Voir mon post plus haut sur une expérience en Asie centrale. Si on veut protéger la planète, on ne peut pas dire que l'acheteur doit juste se renseigner. Cela ne fonctionne tout simplement pas !

Si on veut passer des 5 ou 10% d'acheteur qui achètent en pensant développement durable à 90%, il faut contraindre plus les choses avec des critères plus sévères. Le juste : les gens sont intelligents et vont donc faire le bon choix ne marche pas, en tout cas, je n'y crois pas sur ce cas là. Les prix bas sont trop irrésistibles pour une majorité d'entre nous !

Augmenter la durée de garantie est toujours possible mais ce n'est pas gratuit.

En pratique, cela impose aux vendeurs de ne pas vendre de la merde. J'ai été en Asie centrale, les marchés sont envahis par des produits super bas de gamme : jouet, pile, électronique… Tout cela finit rapidement à la poubelle.

Il arrive un moment ou pour la planète, il faut protéger l'acheteur contre lui même donc les produits trop peu chers !

Comment faire ? Là est toute la question.

Et pourquoi Google a laissé pendant tant d'années (et semble continuer encore) des fabricants de smartphone vendre des Android sans garantie de maintenance sur la durée ?

Surtout, pourquoi la France n'impose pas une garantie de 2 (ou 3) ans minimum sur tous les téléphones ainsi qu'une obligation de maintenance (pièce détachée…) par exemple 5 ans après la vente du dernier téléphone, comme dans l'automobile (ou il me semble que c'est 10 ans) ? D'ailleurs, on pourrait généraliser cela à une grande partie du matériel informatique afin de limiter l’obsolescence programmé.

Dans beaucoup de domaines, le constructeur serait obligé (légalement ou pour des raisons commerciales) d'échanger gracieusement le matériel défectueux, puisqu'il s'agit ici assez clairement d'un vice caché.

Heu non. Je suis dans un bâtiment (public) assez neuf (moins de 5 ans) et malgré les défauts multiplement signalés depuis l'origine, on se démerde pour bidouiller notamment le logiciel de GTC pour trouver non pas un fonctionnement optimal mais un fonctionne qui marchouille a peu près… Je ne parle pas du scotch que j'ai du mettre aujourd'hui sur une gaine de ventilation pour éliminer un sifflement insupportable !

Tu as déjà vu des machines POWER a des prix LOWER ?

L'université/l'école doivent être « professionnalisantes ». Peu importe ce que ça veut dire

Le noyau numéro un au monde est très très certainement LINUX et cela depuis des années. Bon allez tous les écoliers du primaire et plus apprennent LINUX, peu importe ce que ça veut dire ;-)

Il y a l'historique de ipython il me semble… Le pb est du à sqlite.

A par quelques rares logiciels daubés qui veulent être sous root, la première chose à faire est

chown -R toto /opt/matlab/R2017b

su - toto

./install

chown -R root:root /opt/matlab/R2017b

Bref, on peut faire propre sans kubernetes ;-)

Un container docker, c'est bien pareil…

Tu installes ton Matlab (ou autre, ils font tous pareil) dans /opt/matlab/R2017b, puis tu fais un petit 'module' qui va bien ou les quelques alias nécessaires… Pas de mise à jour (de toute manière très rare dans les logiciels propriétaires) et en 2018, tu installes la version suivantes dans /opt/matlab/R2018b. De toute manière, chaque version doit faire entre 3 et 5Go actuellement (le pire doit être Ansys à plus de 20Go)…

Pour supprimer -> rm -rf /opt/matlab/R2017

En pratique, sauf la taille qui devient démentielle pour chaque logiciel, c'est plutôt pratique ! Et comme dis plus haut, cela marche quelque soit ta distribution puisque cela ne l'utilise quasiment pas !

Que préfères-tu : un réseau dédié très limité ou un réseau TCP/IP par pigeon voyageur USB ?

Donc tout dépend des usages mais des XP sur le réseau, il en reste plein.

Ta debian sarge marche peut être, mais qu'est ce que tu fais avec ?

Tu n'as rien compris… Je dis juste que la Debian Sarge marche toujours pour les vieux logiciels qui n'ont pas évolué. Évidement, je ne met pas une Sarge sur un porte moderne d'une personne qui fait de la bureautique !

On fait exactement la même chose avec Windows donc pas de guerre entre OS. Ils sont tous à la même enseigne.

Oui, les Matlab et autres fonctionnent tous ainsi et ils sont de plus en plus gros. Il y a effectivement le problème des mises à jour car en pratique, il n'y en a pas (j'en ai même vu qui embarquait plusieurs Python n'étant pas capable de s'entendre en interne sur une version)…

Cela dit, cette mode devient aussi la mode dans le libre -> on te balance des images docker toutes faites ce qui revient exactement à cela. C'est une mode actuelle que l'on voit bien dans Javascript mais aussi Python d'avoir pleins de dépendances avec des versions spécifiques de chaque modules… Bref, avec la mode "Agile", les API sont parfois un peu trop instable de nos jours ;-) Du coup, le développeur fait une image avec tout dedans et seule celle-ci est validée (et garantie)…

Bref, toujours les mêmes problèmes de base qui auraient dû être résolus il y a 10 ans… Et après on s'étonne (et on hurle au pot de vin) que Munich repasse sous Windows, sans se dire que c'est sa communauté qui merde, vraiment?

Ça va les chevilles ?

On a deux types d'applications : celles qui évoluent et celles qui n'évoluent pas. Celles qui n'évoluent plus posent effectivement un problème sur le long terme car un jour, cela ne marche plus. Sous GNU/Linux (et Windows cela doit être pareil), on arrive à bidouiller un certain temps en copiant des anciennes bibliothèques, en modifiant quelques variables puis un jour, plouf, ça ne marche plus.

J'ai eu deux exemples en 20 ans : -1- Une ancienne version de Tecplot car la personne ne voulait pas racheter de licence… Un jour, les bidouilles n'ont plus marché. Je n'ai pas chercher pendant 10 jours non plus car elle pouvait aussi acheter une version plus récente ! -2- Le logiciel de contrôle du bâtiment, conçu en 2013 et qui est une merde innommable en Java dont les services infrastructures n'ont pas pris de maintenance… Bilan : le logiciel est mal signé et nous met des alertes à chaque changement de page, c'est de pire en pire à chaque évolution des navigateurs (quel que soit le navigateur). La solution -> aller chercher un vieux navigateur donc en général un Mozilla.

C'est pareil avec des daubes ayant ActiveX -> Vieux navigateurs…

La garantie, je n'y crois pas du tout. On aura toujours un logiciel qui n'est pas un gros acteur du marché qui utilisera une fonctionnalité epsilon de l'OS qui aura changé sur 20 ans… Aucun constructeur ne peut assurer 100% de compatibilité des logiciels sur son OS !

À partir de là, on peut faire du Flatpak ou autre (par exemple NIX)… On a toujours un cas merdique. Par exemple, on a une ancienne version d'un logiciel qui utilise d'ancienne version de CUDA ! Ah merde, CUDA n'est pas rétro-compatible et impossible d'avoir deux versions du module noyau !

Bilan : pour ces rares cas, il n'y a pour moi qu'une solution actuellement, un container (un des premiers systèmes facilement utilisable était schroot par exemple et pour ne pas mettre le dernier à la mode) ou une machine virtuelle. La VM est très bien pour les vieux machins car si cela pète, on prends la sauvegarde et on relance ailleurs. C'est juste pas possible s'il y a des cartes d'acquisition ou de pilotage dédié… Mais là, comme je l'ai dit, on ne met pas à jour et on bloque la machine sur quelques applications dédiées.

Je m'en fiche de ton blabla… Je te dis que les PC d'acquisition sous XP reste sous XP. Ne cherche donc pas à me faire dire ce que je n'ai pas dit !

Le Windows 10 n'arrête pas de changer… Le net n'arrête pas de changer… Le client SAP change tous les 6 mois… C'est pareil avec Ansys Matlab et ainsi de suite. Donc ta garantie, c'est quoi !

Ma Debian Sarge marche pareil aujourd'hui qu'hier. Jamais mis un anti-virus dessus, jamais eu de problème. Qu'elle meilleure garantie. Toi tu mets ton vieux Windows 7 en frontal sur le web ?

Bref, vous vendez des mots au final assez creux et je me fou de ta morale à deux balles ;-)

Mon dernier poste Debian a eu 4 versions de la distribution via des apt-get dist-upgrade… L'actuel va en avoir 3. On ne peut pas comparer tel quel du Microsoft et du GNU/Linux en se basant uniquement sur les pratiques des habitués de Microsoft ;-)

Certes cela demande de l'organisation pour mettre à jour les postes mais la montée en version se fait. Par contre, c'est rare de passer un Windows 7 en Windows 8 puis 10…

Pour les PC d'acquisition, c'est une autre problématique mais souvent, il reste opérationnel même bien après la fin du support (cf Windows XP).

Vous utilisiez x2go pour l'accès distant sur les serveurs ? C'était les mêmes serveurs en terme de puissance ? Bizarre vos problèmes d'impression, avec CUPS, cela fonctionne mieux sous GNU/Linux que sous Windows avec la couche Samba+CUPS !

Ensuite, cela dépend des usages. Les étudiants, s'ils programment, sont-ils content aussi ?

Pour les petits postes informatiques (je ne parle pas de client léger que je trouve cher et peu performant), le coût de la licence Windows plus celle de MS Office sont non négligeable. Ton analyse intéressante est-elle faite à coût constant ?

De notre coté, on viens d'équiper une salle commune de 4 postes GNU/Linux. Il y en a un 5ème acheté l'an passé sous Windows (SolidWorks oblige). Bref, nos stagiaires sont content du matériel. Avoir plus de postes Windows ne les aideraient pas dans leur traitements…

On n'utilise pas Google Calendar normalement pour son boulot… (sauf contrat).

Mais avec Zimbra, tout cela marche très bien (même si c'est une usine à gaz).

J'ai au moins 40% d'utilisateurs sous GNU/Linux, je vois pas de migration massive à l'horizon. Les riches vont vers MAC mais la raison est principalement l'autonomie…

Qui a parlé de GNU/Linux ?