• [^] # Re: Un outil est pas mauvais en soi, il dépend de l'utilisateur

    Posté par . En réponse au journal Conseils aux libristes, 2ème partie: résister à la tentation de la réécriture à partir de zéro. Évalué à 2.

    je me suis dit que tu étais un trolleur

    j'avais plutôt l'impression que c'était toi, après tout, le troll n'est il pas le fait d'affirmer des opinions sans les justifier ?

    Il ne parle pas du noyaux mais de git (C'était d'ailleurs très clair en lisant la citation) et plus précisément, la performance de son point de vue d'utilisateur de git (oui, il n'est plus vraiment le dèv. de git). Il parle de l'expérience des utilisateurs au niveau de l'utilisation de git. Donc, c'est en plein dans le sujet.

    J'ai du mal à voir le rapport entre git et GTK3, mais bon. L'important avec git, c'est qu'il ai fini sa tâche le plus rapidement possible.
    L'important avec GTK3, c'est qu'il ait réussi à dessiner ce qu'on lui demande de manière assez rapide pour que l'utilisateur ne remarque pas la différence. Pour prendre un exemple dans le domaine du graphisme, à quoi ça sert de calculer plus de 60 FPS sur un écran de 60Hz ?

    Sur un serveur, un envoi de mail qui a tous les coups prends 1s au lieu de 1/2s, cela signifie :
    - Au moins le double de connexions tcp, de la mémoire, et des ressources réseaux monopolisées
    - Du stockage sur les disques
    - Et un effet en cascade

    Je ne parle pas d'un serveur, ou en effet la performance a son importance. Je parle d'un client. Dans le monde de l'UX, de plus en plus d'opérations sont asynchrones, et n'affectent pas l'UI. Par exemple, quand j'ajoute une tâche dans le calendrier, je peux fermer la popup de l'utilisateur avant d'avoir ajouté réellement la tâche. L'ajout se faisant en arrière plan, la durée importe peu. Et cela a lieu trés souvent.

    De même quand tu envois ton mail, il est placé dans la boite d’envoi, le temps que ça prend pour qu'il soit envoyé t'importe vraiment peu.