Suivre

« Nettoyons le Web ! » propose Aral Balkan aux développeurs dans cet article traduit par Framalang
framablog.org/2021/04/20/devel
photo : "Un p'tit coup de Karcher !!!" par Fabrice Denis, licence CC BY-NC-ND 2.0

@Framasoft Merci beaucoup pour le partage, j'ai pris les deux minutes nécessaires pour rajouter le header sur mes sites, j'avais pas encore pris le temps de voir le détail pour FLoC donc j'étais pas au courant qu'il fallait qu'on rajoute un header !

Merci @aral

@Framasoft Taper sur google c'est bien. Considérer que chest que leurs-faute parce que « la faute a pas de chance », mouais…

Si une entreprise impose a ses employés chrome ou n'importe quelle autre des merdes de google (ou de M$, ou de n'imponte quelle autre boite qui fait des profits grâce au capitalisme de surveillance, et/ou en faisant du business avec des dictatures), il n y a absolument aucune raison pour que cette boite ne soit considérée comme tout aussi coupable que google (ou autre…)

@devnull

Ma lecture de l'argument de @aral c'est plus qu'il faut éviter le réflexe qui consiste à culpabiliser les utilisateurices finaux, les individus, afin de concentrer nos énergies sur les géants, les puissants qui représentent de gros collectifs.

Par exemple, lorsqu'on parle d'entreprise, est-ce qu'on différencie la TPE qui impose chrome à ses 3 employé·es (par ignorance numérique) de l'entreprise/industrie dont la DSI gère des milliers de postes ?

- Pouhiou et ses 2 junes.

@Framasoft j'ai une question, quand on utilise des libs node npm etc est ce que y a des trackers qui se glissent dedans?

@lapduck
Bonjour !
Alors moi, Pouhiou, je n'ai pas la réponse... Mais je peux vous proposer :
* de booster votre pouet pour qu'on voit si d'autres savent répondre
* de poser votre question sur notre forum où il y a plus de monde en capacité de répondre : framacolibri.org

@lapduck @Framasoft Des fois oui. Il y avait des exemples, d'une lib npm qui servaient à faire un print (on se demande pourquoi inclure une lib pour ça ?) qui discretement faisait un appel click à une vidéo youtube permettant ainsi à l'auteur de se faire des vues et donc de l'argent. npm, c'est un peu le gros foutoir sans vérification avec des inclusions récursives. Quand je vois que, par exemple, Peertube avait déjà dépassé 1,3Go à l'installation (en version ArchLinux) vers janvier (je sais pas où il en est maintenant), je me dit qu'il y a un sacré problème avec node/npm...
@lapduck @Framasoft Je ne crachait pas ici sur PeerTube qui est un beau projet, mais alerte juste sur les gros dangers de node.js tel qu'il est organisé, je n'ai pas le lien en réserve vers l'article qui décrivait ce module que l'on retrouvait dans différents projets. Je crois que node.js vient surtout de la culture des développeurs de site web, orienté vers les interfaces utilisateurs, qui n'ont pas forcément une culture solide en architecture informatique et développement d'applications serveurs. La page qui décrivait ce problème décrivait plusieurs autres du même type, qui ont des grosses conséquence sur l'efficacité du code, peu d’intérêt pour le code en lui même mais sont souvent intégré. Il suffit qu'un module npm un peu plus utile l'ai en dépendance pour qu'on le retrouve sur des tas de systèmes. Il suffit également que le développeur est une machine de test très puissante et ne test pas avec une charge conséquente, pour que le site une fois en production soit effondré.

@popolon @Framasoft a priori node.js ça sert à faire des serveurs non ? :s en tout cas ça a été vendu comme "faire du javascript coté serveur" avec un gestionnaire de paquet npm pour faciliter le tout.

@lapduck @Framasoft Tout à fait, mais JavaScript a été conçu à la base (Sur Netscape Navigator, ancêtre de Firefox) pour intégrer de la dynamique dans les pages web.
@lapduck @Framasoft Il s'inspirait alors pas mal de Java, que ses promoteurs disait être l'avenir, portable, compatible etc... Qui au final aura toujours eu d'important problèmes de portabilité d'une version à l'autre d'un système à l'autre, et qui est très sur-consomateur de ressources. Son utilisation a grandement diminué, et je suis plutôt content de voir moins de dépendances à ça dans les applications que j'utilise. L'habitude de laisser le ramasse miette travailler plutôt que de nettoyer systématiquement une ressource à la fin de son utilisation, comme on fait en c, ne doit pas être innocent dans son énorme consommation mémoire, mais je pense qu'il n'y a pas que ça.

@Framasoft @lapduck Dans ma vision, probablement très partielle et personnelle des choses, Il y a au moins 2 ou 3 façon d’arriver à la programmation de logiciels serveurs :

Ce qui ont après les bases de l’architecture informatique on programmé bas niveau (assembleur et c), ce sont eux qui font les serveurs web (nginx, apache, lihttpd, H2o, etc…) des serveurs de streaming, mail, serveurs de bases de données (MySQL, PostgreSQL), etc.. tous fait en C, et qui vont développé pour le côté pratique et rapides certains composant en langage de script.
Les admins qui auront très probablement fait du perl+shell aujourd’hui d’avantage du python que du perl. ils ont aussi en général quelques bonne notion d’architecture système et réseau, et une vision globale de celui ci pour optimiser les ressources.
Ceux qui ont appris l’informatique à la FAC avec l’enseignement généralisé du Java dans les années 1990 et 2000, qui auront eu tendance à faire de ça sans trop connaître le bas niveau, je pense qu’une partie à du passer à php, parce que c’était le langage à la mode côté serveur. Il était de plus, très effiace, et ça reste toujours le cas, le plus performants des langages de script, les erreurs de jeunesse ont toutes été nettoyées. Une partie est aussi probablement passé à node, et une grosse partie à Ruby, parce qu’influencé par l’intégration de ruby dans java avec jruby. je trouve ça plutôt une bonne chose, c’est vraiment plus léger et efficace, la tendance est aussi aux tas de modules dans ruby, mais ça part pas en cacahuète comme node+npm non plus. C’est aussi un beau langage bien pensé, rapide à développé et souple, il était très lent mais s’améliorent. Mastodon est écrit en Ruby. Il est très scalable et je n’ai vu personne s’en plaindre. Je suis passé à pleroma (codé enelixir) pour la possibilité d’écrire en Markdown et moins de limite, mais je crois que je me suis planté. Il est moins bien conçu au final, plein d’erreurs fondamentales d’architecture, qui le rendent pas scalable du tout, c’est pas gênant comme je suis le seul utilisateur, mais c’est du grand n’importe quoi, je retrouve les erreurs de base de wordpress (texte des posts dans des champs d’une base SQL, pas de sous dossiers pour les images). Il n’y a pas de filtrage de la taille des images, et Activitypub ne permet d’échanger une prévisualisation avant le fichier lui même j’ai l’impression. Résultat quelqu’un qui poste 5 photos sorties de son apn, rendent Pleroma inutilisable sur un périphérique mobile.
Ceux qui ont appris le développement par javascript dans les pages web et qui arrivent ensuite côté serveur avec node.js, généralement aucune notion de bas niveau, pas forcément des bases solides en développement, mais ça dépend et ça peut s’améliorer avec l’expérience. Ils vont souvent utiliser leur connaissances pas toujours solide pour faire la partie côté serveur. Et on se retrouve avec les mêmes paradigme que sur de nombreux site web, explosion de la mémoire et de la taille de stockage nécessaire, application qui rame à fond. Sauf que côté client, ça handicape le client qui n’a pas la dernière machine la plus puissante (merci NoScript. Côté serveur par contre, ça ne pardonne pas, le site devient tout bonnement inaccessible ou quasi inutilisable. Je ne compte plus le nombre de gens qui ont voulu essayé PeerTube et ont juste dit, ça ne marche pas ce truc, parce que le démarrage est souvent très lent, la vidéo coupe, et du coup on a un cercle vicieux de manque d’attrait, une vidéo PeerTube arrive difficilement à la centaine de vue, beaucoup préférant se déporter vers la version Youtube. Je n’ai jamais vu ce genre de problème sur les vidéos juste streamée en nginx par exemple, même sur une petite VM chez OVH. Je le regrette vraiment PeerTube est vraiment un beau projet. Pocorn Time écrit aussi en nodejs fonctionne qui comporte les même base fonctionnait très bien, sur des machines d’il y a 5 ans, mais c’est une instance nodejs et utilisateur par ordi. PeerTube s’est grandement amélioré dans les dernière version, mais on a toujours très fréquemment sur beaucoup d’instances des coupures, qui découragent une partie des utilisateurs :(. Un simple nginx ou un logiciel basé sur la bibliothèque en C libtorrent, serait probablement beaucoup plus efficace (environ une 1.5M chacun, 3Mo contre 1,3Go. En arrondissant au dessus à 5Mo,, on arrive tout de même à un rapport *266 en taille sur disque). Mais ça serait un travail immense de (re)développement. Je pense qu’il doit y avoir un équivalent des ffi utilisé sous Python et ruby, sous Node, qui permetrait d’utiliser directement les bibliothèques en c pour ces parties, ça permettrait probablement d’économiser des dizaines de mégas, et de gagner énormément en performances.

@Framasoft

Hi, I see Framasoft listed as one of the organizations that signed the open letter to "remove RMS". Then this is for you:

eliasrudberg.se/rms/

Inscrivez-vous pour prendre part à la conversation
Framapiaf

Le réseau social de l'avenir : Pas d'annonces, pas de surveillance institutionnelle, conception éthique et décentralisation ! Possédez vos données avec Mastodon !