Le paradoxe actuel est que les ordinateurs vont beaucoup moins vite à executer les actions (de l'utilisateur) les plus basiques qu'auparavent alors qu'ils sont inifiniments plus puissant
Mais ils sont aussi infiniment plus faciles à programmer aussi. Si tu es près à revenir au bon vieux temps de la programmation en assembleur, à ne pas utiliser des bibliothèque mais à recoder toi même juste la fonction dont tu as besoin dans ton appli, etc vas-y, fonce. Pour moi c'est non. Pouvoir programmer avec des frameworks propres, complets et évolutifs dans des langages de haut niveau permet de gagner du temps et de se concentrer sur son appli et pas sur "comment je fait pour envoyer une IRQ machin à la carte son". Les machines de bureau passent de toutes façon le plus clair de leur temps en idle.
Mais globalement je persiste, Gnome et KDE deviennent bloatted.
Tu as des mesures à l'appui ou c'est juste une impression ? L'équipe de KDE a plutot amélioré les choses depuis KDE3. Je n'ai plus le lien sur les mesures qui avaient été faites mais c'était assez significatif. Idem pour Gnome. Le plus dur est souvent de comprendre ce que les utilisateurs trouvent "lent". On entend dire "machin est lent" mais qu'est-ce qui est lent exactement ? A ce propos les slides Federico Mena-Quintero sont intéressants : http://primates.ximian.com/~federico/docs/2005-GNOME-Summit/(...) Souvent les utilisateurs se plaignent de lenteur alors que le CPU/GPU est loin d'être à 100%. C'est plutot la réactivité qui pose problème. L'utilisateur ne fait rien de sa machine 99% du temps mais quand il clique sur une bouton il s'attend à ce que quelque chose s'affiche à l'ecran dans la miliseconde. Ce n'est même pas le temps de traitement des taches qui gêne, c'est juste que la fenêtre n'apparait pas instantanément. La taille du framework derrière ne change pas grand chose. Il suffit de ne charger que le strict minimum lorsque l'action est déclenchée et de charger le reste en tache de fond, un peu comme Windows qui démarre soit disant plus vite mais qui en fait affiche rapidement l'invite de login mais continue à se charger en arrière plan. Peu d'utilisateurs se loguent et commencent à bosser dans le 1/4 de seconde mais ils se plaignent que leur machine est longue à démarrer donc on leur fait croire qu'elle est plus rapide. Bien sur s'ils se loguent tout de suite est tentent de bosser ils vont se rendre compte que la machine rame comme la mort parce qu'elle mouline encore sans le montrer mais comme personne ne le fait tout le monde est content.
[^] # Re: Ce qui est dommage
Posté par Croconux . En réponse au journal Phonon et gstreamer : un voyage dans le temps. Évalué à 8.
Mais ils sont aussi infiniment plus faciles à programmer aussi. Si tu es près à revenir au bon vieux temps de la programmation en assembleur, à ne pas utiliser des bibliothèque mais à recoder toi même juste la fonction dont tu as besoin dans ton appli, etc vas-y, fonce. Pour moi c'est non. Pouvoir programmer avec des frameworks propres, complets et évolutifs dans des langages de haut niveau permet de gagner du temps et de se concentrer sur son appli et pas sur "comment je fait pour envoyer une IRQ machin à la carte son". Les machines de bureau passent de toutes façon le plus clair de leur temps en idle.
Mais globalement je persiste, Gnome et KDE deviennent bloatted.
Tu as des mesures à l'appui ou c'est juste une impression ? L'équipe de KDE a plutot amélioré les choses depuis KDE3. Je n'ai plus le lien sur les mesures qui avaient été faites mais c'était assez significatif. Idem pour Gnome. Le plus dur est souvent de comprendre ce que les utilisateurs trouvent "lent". On entend dire "machin est lent" mais qu'est-ce qui est lent exactement ? A ce propos les slides Federico Mena-Quintero sont intéressants : http://primates.ximian.com/~federico/docs/2005-GNOME-Summit/(...) Souvent les utilisateurs se plaignent de lenteur alors que le CPU/GPU est loin d'être à 100%. C'est plutot la réactivité qui pose problème. L'utilisateur ne fait rien de sa machine 99% du temps mais quand il clique sur une bouton il s'attend à ce que quelque chose s'affiche à l'ecran dans la miliseconde. Ce n'est même pas le temps de traitement des taches qui gêne, c'est juste que la fenêtre n'apparait pas instantanément. La taille du framework derrière ne change pas grand chose. Il suffit de ne charger que le strict minimum lorsque l'action est déclenchée et de charger le reste en tache de fond, un peu comme Windows qui démarre soit disant plus vite mais qui en fait affiche rapidement l'invite de login mais continue à se charger en arrière plan. Peu d'utilisateurs se loguent et commencent à bosser dans le 1/4 de seconde mais ils se plaignent que leur machine est longue à démarrer donc on leur fait croire qu'elle est plus rapide. Bien sur s'ils se loguent tout de suite est tentent de bosser ils vont se rendre compte que la machine rame comme la mort parce qu'elle mouline encore sans le montrer mais comme personne ne le fait tout le monde est content.