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.
[^] # Re: pas un mal
Posté par Sytoka Modon (site web personnel) . En réponse au journal Munich revient sur Windows. Évalué à 8.
Ç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.