Et pour ce qui est de la disponibilité du driver, s'il n'est présent de base que dans les versions commerciales, l'installation est quand même assez simple (si c'est trop compliquer, il suffit d'acheter une version commerciale)
Disont que leur modèle propriétaire fragilise un peu l'ensemble du "desktop sous Linux": nvidia ou ati peuvent décider de ne plus supporter Linux, ou d'imposer leurs conditions. L'interface du noyau ou de x.org pourraient changer, et les drivers rester inutilisables avec ces nouvelles api pendant longtemps (c'est arrivé plusieurs fois avec nvidia et surtout ati). Ils pourraient ne pas corriger (ou prendre beaucoup de temps pour corriger) d'éventuelles failles de sécu. Ils pourraient forcer la mise à jour (l'achat) de matériels plus récents en ne maintenant pas le driver pour leurs anciens modèles. etc.
Mais par contre, devrait-on sous ce pretexte ne pas évoluer du tout
On est d'accord. La question soulevée par l'article c'est plutot de determiner comment et vers où évoluer.
Mon propos initial c'était qu'un bureau en 3D, c'est très bien, mais quand même pas si follement inovant que ce qu'X11 à pu faire auparavant (archi client-serveur, multi-utilisateurs etc.). Et que ça ne mérite peut-être pas de sacrifier aveuglément la portabilité et le support fonctionel du matériel ancien, ni d'augmenter notre dépendance aux drivers propriétaires. D'autant qu'il y a déja un support optionel pour l'accélération OpenGL dans x.org (mais à ce stade, il reste facultatif).
Avec une organisation correcte, ne pourrait-il pas simplement être possible d'ajouter des fonctionnalités, améliorer X tout en permettant de ne pas activer ces fonctions pour les archis / cartes graphiques ne les supportant pas ?
Justement, concernant l'utilisation d'OpenGL, Smirl souhaiterai qu'il n'y ai qu'un seul moteur sous-jacent, cf. sa conclusion ; ça demanderait d'ailleur un énorme travail d'adaptation (dans x.org et dans mesa) pour émuler ça avec les vieilles cartes graphiques. C'est ce que lui ont fait remarquer ses camarades de x.org, dans l'ensemble (heureusement) pas emballés par son troll.
[^] # Re: x.org et GNU/Linux
Posté par benp . En réponse à la dépêche Le point sur le traitement graphique sous Linux. Évalué à 5.
Disont que leur modèle propriétaire fragilise un peu l'ensemble du "desktop sous Linux": nvidia ou ati peuvent décider de ne plus supporter Linux, ou d'imposer leurs conditions. L'interface du noyau ou de x.org pourraient changer, et les drivers rester inutilisables avec ces nouvelles api pendant longtemps (c'est arrivé plusieurs fois avec nvidia et surtout ati). Ils pourraient ne pas corriger (ou prendre beaucoup de temps pour corriger) d'éventuelles failles de sécu. Ils pourraient forcer la mise à jour (l'achat) de matériels plus récents en ne maintenant pas le driver pour leurs anciens modèles. etc.
Mais par contre, devrait-on sous ce pretexte ne pas évoluer du tout
On est d'accord. La question soulevée par l'article c'est plutot de determiner comment et vers où évoluer.
Mon propos initial c'était qu'un bureau en 3D, c'est très bien, mais quand même pas si follement inovant que ce qu'X11 à pu faire auparavant (archi client-serveur, multi-utilisateurs etc.). Et que ça ne mérite peut-être pas de sacrifier aveuglément la portabilité et le support fonctionel du matériel ancien, ni d'augmenter notre dépendance aux drivers propriétaires. D'autant qu'il y a déja un support optionel pour l'accélération OpenGL dans x.org (mais à ce stade, il reste facultatif).
Avec une organisation correcte, ne pourrait-il pas simplement être possible d'ajouter des fonctionnalités, améliorer X tout en permettant de ne pas activer ces fonctions pour les archis / cartes graphiques ne les supportant pas ?
Justement, concernant l'utilisation d'OpenGL, Smirl souhaiterai qu'il n'y ai qu'un seul moteur sous-jacent, cf. sa conclusion ; ça demanderait d'ailleur un énorme travail d'adaptation (dans x.org et dans mesa) pour émuler ça avec les vieilles cartes graphiques. C'est ce que lui ont fait remarquer ses camarades de x.org, dans l'ensemble (heureusement) pas emballés par son troll.