Que ce soit gdm ou un autre logiciel, le problème est le même. Faire du code rapide, pas cher et de qualité ça n'existe pas. Tout le monde (Libre ou pas) fait avec les moyens du bord.
Comparer des environnements d'il y a 20 ans et qui consommaient peu de ressources à ce qui se fait maintenant ne sert à rien: les besoins n'étaient pas les mêmes. Moi aussi j'ai connu l'Amiga 500 en 1993 avec un environnement de bureau, des fenêtres, avec 1Mo de RAM, mais on ne peut pas sérieusement comparer cela à une interface graphique moderne, et les exigences actuelles. Tu as encore une scène de demomakers pour faire des applis les plus petites et riches possible, mais toutes les applications, GNOME ou pas, ne reçoivent pas le même degré d'optimisation.
Tout le monde fait un peu pareil: d'abord tu essaies de faire un truc qui marche, et ensuite tu l'améliores. Un projet qui fonctionne, c'est bien. Un projet qui consomme peu, c'est mieux. Mais pour ça il faut des gens qui s'impliquent sur les problématiques de performance, du temps (et donc de l'argent) à dédier à cela, des outils... GNOME a amélioré son intégration continue avec le passage à gitlab. Il doit y avoir des tests unitaires, des tests fonctionnels sur certain projets, mais à ma connaissance, peu de projets doivent avoir des tests de performance. Donc impossible d'attraper les régressions de performance au vol. En 2006 déjà, on parlait de performance dans GNOME, pour essayer de sensibiliser les développeurs à ces aspects.
Alors bien sûr qu'il y a des problèmes de performances, qu'il y a encore des "low-hanging fruits" qui permettent de gagner beaucoup de ressources sans trop d'effort, mais c'est plus un problème de l'informatique moderne (« software gets slower faster than hardware gets faster ») qu'un problème de GNOME.
[^] # Re: Super les gars
Posté par liberforce (site web personnel, Mastodon) . En réponse à la dépêche Parution de GNOME 3.30. Évalué à 3. Dernière modification le 25 septembre 2018 à 17:54.
Que ce soit gdm ou un autre logiciel, le problème est le même. Faire du code rapide, pas cher et de qualité ça n'existe pas. Tout le monde (Libre ou pas) fait avec les moyens du bord.
Comparer des environnements d'il y a 20 ans et qui consommaient peu de ressources à ce qui se fait maintenant ne sert à rien: les besoins n'étaient pas les mêmes. Moi aussi j'ai connu l'Amiga 500 en 1993 avec un environnement de bureau, des fenêtres, avec 1Mo de RAM, mais on ne peut pas sérieusement comparer cela à une interface graphique moderne, et les exigences actuelles. Tu as encore une scène de demomakers pour faire des applis les plus petites et riches possible, mais toutes les applications, GNOME ou pas, ne reçoivent pas le même degré d'optimisation.
Tout le monde fait un peu pareil: d'abord tu essaies de faire un truc qui marche, et ensuite tu l'améliores. Un projet qui fonctionne, c'est bien. Un projet qui consomme peu, c'est mieux. Mais pour ça il faut des gens qui s'impliquent sur les problématiques de performance, du temps (et donc de l'argent) à dédier à cela, des outils... GNOME a amélioré son intégration continue avec le passage à gitlab. Il doit y avoir des tests unitaires, des tests fonctionnels sur certain projets, mais à ma connaissance, peu de projets doivent avoir des tests de performance. Donc impossible d'attraper les régressions de performance au vol. En 2006 déjà, on parlait de performance dans GNOME, pour essayer de sensibiliser les développeurs à ces aspects.
Alors bien sûr qu'il y a des problèmes de performances, qu'il y a encore des "low-hanging fruits" qui permettent de gagner beaucoup de ressources sans trop d'effort, mais c'est plus un problème de l'informatique moderne (« software gets slower faster than hardware gets faster ») qu'un problème de GNOME.