Je me souviens d’un temps un peu lointain (mon bts info indus), mes prof nous montrais des études montrant le gain de productivité sur des tâches basique sur l’utilisation de commande clavier plutôt que l’tilisation de la souris pour lancer des applications…
Il y avait un exemple entre word et Vi…
Je n’était pas convaincu à l’époque, j’avoue qu’aujourd’hui pour certaine utilisation je préfère de loin mon bon vieux terminal linux… Il est aussi important de souligner que Bon nombre de gros site sont géré par des système linux BSD et que les administrateurs font quasiment tout en ligne de commande…
A ce jeux les ligne de commande MSDOS standard sont très pauvre.
Je n’ai pas gardé c’est bonne vieilles études (ont parle du siècle précédent) et je suis curieux si ça existe encore, mais dans les année 2010 je me souviens d’un article qui faisait la comparaison entre XFCE (configurer…) contre Windows. Il mettais en avant le gain de productivité rien qu’en ayant l’équivalent du menu démarrer dans le clic droit et ce peut importe l’application… La dernière fois que j’ai installé xfce je n’ai pas retrouvé cette fonctionnalité.
J’en profite avez-vous connaissance d’étude récente sur le sujet ?
Un bon codeur est important peut importe le système… Et d’ailleurs il ne suffit pas d’avoir un bon codeur, il faut aussi que la sécurité informatique du système soit irréprochable…
La encore l’OS joue forcément un rôle, mais pas plus que la politique informatique qui stocke les données, les moyens mis en place sur le réseau de l’entreprise qui exploite les données etc…
Le fait d’avoir et garder les 2 mais sur le clavier et le regard sur l’écran ou le clavier reste plus efficace que de lâcher le clavier, bouger la souris, trouver le curseur, viser, cliquer…
La navigation pur clavier, même maintenant, est un gage de qualité et de sérieux d’un logiciel et d’un site web.
Malheureusement comme les OS ont tendance à voler le focus, c’est difficile à utiliser tout le temps.
Dans les applis de banques, en plus de la parti graphique, il y avait souvent des raccourcis en « code 3 lettres » à taper pour aller directement dans la bonne option plutôt que de chercher dans les menus.
Sauf que ce ne sont pas que des vidéos justement, surtout avec les UI informatiques qui permettent une compression énorme et facile. Tu as beau avoir un dual screen en 4k, il ne va pas envoyer un flux vidéo 4k X fois par seconde. Il ne va envoyer que s’il y a un changement déjà, par exemple si la souris bouge il ne va envoyer qu’une region de 400 pixels. Voire que des coordonnées XY. Tu passes de plusieurs Mbps a quelques bps seulement.
Et des optis comme ca t’en as un paquet qui permettent d’eviter un flux pleine résolution en mode brute force.
C’est ptet la qu’est une partie du problème, pour faire ce que tu fais ca me prendrait meme pas quelques Mo, tout se fait sur l’ordi a distance comme si c’etait mon ordi local. Au final aucun fichier ne transite chez moi juste un flux « video ». Ca coute beaucoup moins cher a tous les points de vue tout en étant transparent.
Pour le dev Android des fois il y a vraiment besoin d’avoir l’appli physiquement, mais un « émulateur » suffit la grande majorité du temps
Ca n’a rien a voir, ce sont deux choses différentes qui ne se tirent pas dans les pattes, au contraire la compression aide meme au chiffrement.
Ces parasites qui n’ont jamais rien produit, vivants sur notre dos éternellement qui ne savent plus quoi faire pour buzzer en nous pourrissant la vie. Le plus incroyable sont ceux qui applaudissent en se pensant intelligent.
Je parlais des vidéoconférences. C’est bien de la vidéo Et un encodeur temps-réel ne sera jamais aussi performant qu’un encodeur offline.
Nous avons aussi ça (et ça fonctionne très bien). Mais tout usage avancé d’un GPU ne fonctionnera pas bien sur l’émulateur Android, non. C’est bien juste pour des apps « basiques ». Pour de la 3D avancée, et/ou du ML, il faut l’appareil physique. Donc télécharger l’app, et de temps en temps télécharger les modèles ML de plusieurs centaines de Mb.
Citation
Par contre dès que tu dois coder et tester en local (*ex : un binaire compilé dans la boite puis > envoyé sur mon tél portable avec info de debug et co = x * 100Mb), ça va vite
Du coup, c’est pas en local: tu codes et compil à distance, puis récupération du binaire et injection dans le tel.
Question: pourquoi compiler sur le serveur?
Question2: comment se fait-il que tout doive être recopié lors d’une modification de code pendant les tests???
Fausse approche : ça n’est pas qu’il n’y a pas de compression; c’est que l’encryptage des données passant dans la connexion empêchent une bonne compression ; par sécurité.
Mauvaise utilisation: on chiffre les données compressées, on ne compresse pas les données chiffrées.
Pour ca je passe directement par mon telephone/PC plutôt que le remote maintenant, c’est bien plus agréable sans parler des problèmes de micros.
Quand on aura ca dans tous les logiciel la consommation sera encore plus opti https://www.youtube.com/watch?v=NqmMnjJ6GEg
Mais meme en passant par le remote ca consomme que dalle les visios, je me demande meme si ca consommerait pas moins sur notre connection en passant par un logiciel de remote car ca rajoute une compression par dessus, mais rien n’est moins sur
A moins que ce soit littéralement des projections de vidéos avec plein de trucs qui bougent a 24FPS là oui, c’est le truc qui consomme beaucoup.
Ca fait des années qu’on sait faire des encodeurs temps reel extrêmement performant. C’est surtout que t’as une perte de perfs CPU/GPU ou en qualité par rapport a un encodeur qui prendra son temps.
Mais il n’y a pas que sur l’encodage que les logiciels de prise de contrôle optimisent le flux, surtout ca n’encode pas sur l’entiereté de l’image contrairement a un encodeur classique.
Jamais vu de soucis avec la 3D avancé ou le ML pour dev/tester sur PC pour le moment, il n’y a que sur certaines grosses étapes de dev que je veux tester en conditions réelles et sur différents périphériques pour être sur. Ca permet des itérations beaucoup plus rapides, et surtout beaucoup moins de frustration humaine
C’est optimisé grace aux instructions matériels ou logiciels nvidia ou autres, maintenant ils font tout le boulot même plus besoin de puce de décodage/encodage spécifique.
Les codec visio son plutôt légers. Il n’ont pas un gros débit de pointe pour la vidéo (qui doit souvent être rattrapée/compensée/abandonnée), par contre l’audio se doit d’être nickel.
Ils ne font pas travailler la même chose qu’un codec de film qui travaille sur un contenu connu à l’avance.
Et un encodeur temps-réel ne sera jamais aussi performant qu’un encodeur offline.
