On dirait la fenêtre de rendue CATIA V5 (je connaissais bien en 2000)… Il y avait une version OpenGL 1.2, et DirectX alors.
Si on retrouve CATIA et Solidworks sous Linux, ça m'arrangerait pas mal! Quelque soit la méthode, si elle est légale. Si il faut passer par proton, pas de problème !
Au final ça semble se résumer à :
On ne peut pas faire les choses comme on veut, parce que ça peut avoir un impact sur la pléthore de logiciels, d'outils, et de personnes (et d'emplois !) qui dépendent de comment les choses sont faites.
Et donc Mesa a atteint un point où ils doivent absolument faire attention à ne pas casser les fonctionnements actuels, et donc se poser la question des usages, et tester en amont la compatibilité de leurs changements.
Par chance pour eux, ça se fait alors qu'il y a des entreprises impliquées dans le projet, et des personnes payées pour bosser sur le projet, donc ce n'est pas une problématique bénévole, et travail gratuit pour des entreprises, ici.
Pour ce qui est du problème de mise à jour de zlib en interne, comme bien expliqué dans plusieurs des commentaires sur Phoronix, des solutions techniques il y en a, il va suffire de faire les choses un peu différemment et voilà.
Si ça peut leur permettre de séparer un peu plus la tambouille interne des interfaces externes, ça ne peut être que positif.
Parce que si j'ai bien compris, le lien dynamique avec une version trop récente de zlib, va casser un outil répandu qui a aussi besoin de zlib, mais pas à la même version, et boum.
Ce n'est pas un problème insurmontable, et il pourrait même paraître gênant qu'une contrainte interne à un outil soit en conflit avec une contrainte interne à un autre outil : chacun sa tambouille.
Un changement mineur de Mesa empêche le benchmark de référence en 3D pro de fonctionner SPECViewPerf). C'est dangereux parce que Mesa pourrait disparaître des radars et perdre ses financements. Le changement mineur est une mise à jour de Zlib, une dépendance secondaire. On enlève ce changement pour l'instant.
On trouvera d'autres solutions pour cette dépendance, ce n'est ni urgent, ni indispensable, etc. Wait and see.
Enfin, maintenant que Mesa joue dans la cour des grands et que les fabricants de matos paient les développeurs, ceux-ci ne peuvent plus "se la jouer perso". Y'a des responsabilités!
Sinon, sur les traductions proposées, il faut bien avouer que la prose de M. Larabel me reste souvent un peu hermétique. Pas étonnant qu'il soit délicat de s'entendre sur ce qu'il convient d'en comprendre. Mais à peu près, on s'y retrouve.
# Screenshot CATIA v5 ???
Posté par YBoy360 (site web personnel) . Évalué à 4.
On dirait la fenêtre de rendue CATIA V5 (je connaissais bien en 2000)… Il y avait une version OpenGL 1.2, et DirectX alors.
Si on retrouve CATIA et Solidworks sous Linux, ça m'arrangerait pas mal! Quelque soit la méthode, si elle est légale. Si il faut passer par proton, pas de problème !
[^] # Re: Screenshot CATIA v5 ???
Posté par alberic89 🐧 . Évalué à 3.
Apparemment, c'est possible avec Wine : https://appdb.winehq.org/objectManager.php?sClass=application&iId=6153
Mais je n'ai pas testé.
L'informatique n'est pas une science exacte, on n'est jamais à l'abri d'un succès
# Beaucoup de bruit ?
Posté par Yth (Mastodon) . Évalué à 8.
Au final ça semble se résumer à :
On ne peut pas faire les choses comme on veut, parce que ça peut avoir un impact sur la pléthore de logiciels, d'outils, et de personnes (et d'emplois !) qui dépendent de comment les choses sont faites.
Et donc Mesa a atteint un point où ils doivent absolument faire attention à ne pas casser les fonctionnements actuels, et donc se poser la question des usages, et tester en amont la compatibilité de leurs changements.
Par chance pour eux, ça se fait alors qu'il y a des entreprises impliquées dans le projet, et des personnes payées pour bosser sur le projet, donc ce n'est pas une problématique bénévole, et travail gratuit pour des entreprises, ici.
Pour ce qui est du problème de mise à jour de zlib en interne, comme bien expliqué dans plusieurs des commentaires sur Phoronix, des solutions techniques il y en a, il va suffire de faire les choses un peu différemment et voilà.
Si ça peut leur permettre de séparer un peu plus la tambouille interne des interfaces externes, ça ne peut être que positif.
Parce que si j'ai bien compris, le lien dynamique avec une version trop récente de zlib, va casser un outil répandu qui a aussi besoin de zlib, mais pas à la même version, et boum.
Ce n'est pas un problème insurmontable, et il pourrait même paraître gênant qu'une contrainte interne à un outil soit en conflit avec une contrainte interne à un autre outil : chacun sa tambouille.
Voilà mon résumé, en français, des débats.
[^] # Re: Beaucoup de bruit ?
Posté par orfenor . Évalué à 7.
Je le dirai un peu autrement :
Un changement mineur de Mesa empêche le benchmark de référence en 3D pro de fonctionner SPECViewPerf). C'est dangereux parce que Mesa pourrait disparaître des radars et perdre ses financements. Le changement mineur est une mise à jour de Zlib, une dépendance secondaire. On enlève ce changement pour l'instant.
On trouvera d'autres solutions pour cette dépendance, ce n'est ni urgent, ni indispensable, etc. Wait and see.
Enfin, maintenant que Mesa joue dans la cour des grands et que les fabricants de matos paient les développeurs, ceux-ci ne peuvent plus "se la jouer perso". Y'a des responsabilités!
[^] # Re: Beaucoup de bruit ?
Posté par Pol' uX (site web personnel) . Évalué à 2.
Mais alors, pour éviter les mésaventures, il faut que quelqu'un leur dise « mais attention ! »
Adhérer à l'April, ça vous tente ?
[^] # Re: Beaucoup de bruit ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 4.
Mes amis, ça c'est bien dit :-).
Sinon, sur les traductions proposées, il faut bien avouer que la prose de M. Larabel me reste souvent un peu hermétique. Pas étonnant qu'il soit délicat de s'entendre sur ce qu'il convient d'en comprendre. Mais à peu près, on s'y retrouve.
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.