GitHub et le crime contre les logiciels

 (eblog.fly.dev)
1 points par GN⁺ 22 시간 전 | 1 commentaires | Partager sur WhatsApp
  • GitHub est utilisé comme une pièce maîtresse de l’infrastructure de développement, mais sa fiabilité de base est jugée fragilisée par des incidents fréquents, des pages lentes et des dysfonctionnements dans le navigateur
  • Microsoft a indiqué que la charge avait fortement augmenté avec les agentic workflows, mais les critiques se multiplient aussi sur le fait que GitHub a lui-même poussé les fonctions Copilot et agent pour en encourager l’usage
  • Dans une expérience menée sur un dépôt minimal, GitHub a téléchargé 291 requêtes, 15 MiB de réponses compressées et 544 564 lignes une fois décompressées, en fort contraste avec les 11 requêtes de Codeberg
  • Côté frontend, GitHub utilise environ 69 MiB de heap au repos, et la page de pull request de rust-lang 148 MiB, ce qui est jugé excessivement gaspilleur pour des pages essentiellement textuelles
  • La conclusion est que le gaspillage de GitHub n’est pas une simple dégradation produit, mais un échec logiciel plaçant les fonctions IA et les priorités centrées sur les investisseurs devant la résolution des problèmes des utilisateurs

Fiabilité et priorités de GitHub

  • GitHub est utilisé comme un élément central de l’infrastructure de développement logiciel, mais sa fiabilité de base est remise en cause à cause des pannes, des baisses de performances et des problèmes de compatibilité navigateur
  • L’historique GitHub Status fait apparaître des dizaines d’incidents chaque mois, et il existe, selon les critères de la page d’état officielle et du SLA, des situations pouvant être vues comme des violations
  • Le service se casse souvent sur Firefox et Safari, les pages de commentaires et de review de pull request sont lentes, et il est critiqué pour une consommation RAM excessive et de forts pics de heap
  • GitHub Actions est décrit comme lent et mal documenté, et l’écran de logs est présenté comme provoquant depuis plusieurs années des fuites mémoire et des crashs navigateur
  • Le comportement de cache d’actions de base comme setup-go est lui aussi jugé sans mécanisme d’invalidation ou excessivement simpliste
  • Il existe des sites comme githubstars.com qui font ouvertement la publicité d’achat d’étoiles, et la formule “fake stars are highly related to malicious activities” issue d’un article de Carnegie Mellon est également citée
  • La cible de GitHub devrait être un système distribué à haute performance, haute disponibilité et grande capacité, mais le produit réel est jugé comme donnant la priorité aux fonctions IA et aux flux agent plutôt qu’à la fiabilité de base

La charge “agentic” et la responsabilité de Microsoft

  • Dans ‘an update on github availability’, GitHub affirme qu’à partir du second semestre 2025, les agentic development workflows se sont accélérés brutalement, avec une hausse rapide de la création de dépôts, de l’activité pull request, de l’usage des API, de l’automatisation et des workloads sur les grands dépôts
  • Cette explication traite la hausse de charge comme un phénomène externe, mais elle alimente la critique selon laquelle GitHub et sa maison mère Microsoft ont eux-mêmes poussé l’IA et les “agents” dans de nombreux produits pour provoquer directement cet usage
    • La barre supérieure de presque toutes les pages GitHub contient 3 boutons IA, dont 2 servent uniquement à lancer un agent, et beaucoup de pages en affichent 4
    • La zone en haut à droite d’une page d’accueil de dépôt ordinaire propose 4 façons de lancer Copilot
    • GitHub a subventionné pendant des années le coût d’utilisation de ces outils pour favoriser leur adoption, ce qui revient, selon ce lien critique, à subventionner contre lui-même un déni de service distribué
  • Microsoft explique qu’une seule pull request peut toucher le dépôt Git, les vérifications de fusion, la branch protection, GitHub Actions, la recherche, les notifications, les permissions, les webhooks, les APIs, les tâches en arrière-plan, les caches et les bases de données
  • À grande échelle, même de petites inefficacités peuvent entraîner un approfondissement des files d’attente, des cache misses, une charge DB, des retards d’indexation et une amplification du trafic de retry, mais les inefficacités de GitHub sont jugées non pas “petites” mais massives et écrasantes
  • Microsoft a déclaré “availability first, then capacity, then new features”, mais dans le changelog public de GitHub, sur les 30 jours suivant cette mise à jour, “copilot” apparaît 59 fois dans les notes de version, “agent” 8 fois, tandis que “performance” et “reliability” n’apparaissent 0 fois
    • Le filtre du changelog a une catégorie copilot, mais pas de catégorie performance ni reliability
    • Visual Studio Code est lui aussi directement intégré à GitHub et aux fonctions “agentic”, et il est critiqué pour l’ajout de fonctions agent alors même que des fonctions de base comme le terminal intégré se dégradent
  • Le passage où Microsoft dit travailler à réduire le “unnecessary work”, améliorer le caching, isoler les services critiques, éliminer les points uniques de défaillance, déplacer les chemins sensibles aux performances, réduire les couplages cachés, limiter le rayon d’explosion et mettre en place une graceful degradation est interprété comme un aveu de mauvaise conception système

Pourquoi le frontend laisse entrevoir des problèmes backend

  • La racine des problèmes de fiabilité de GitHub se trouve dans le backend et les bases de données, mais cela n’est pas visible de l’extérieur, alors qu’on peut au moins observer le code frontend téléchargé à chaque chargement, comme le HTML, le JavaScript et le CSS
  • De la même manière que voir des rats dans la salle d’une pizzeria rend difficile de croire que la cuisine est propre, la dégradation visible du frontend de GitHub est vue comme un indice de problèmes backend sans pour autant les prouver
  • Les pages d’accueil de dépôt de GitHub, GitLab et Codeberg se composent de listes de liens, de petits éléments UX, de boutons, d’onglets et d’un champ de recherche, avec très peu d’éléments coûteux comme des médias interactifs ou des images
  • De telles pages devraient fonctionner à faible coût sur presque n’importe quel ordinateur ou téléphone, même sans bonne connexion Internet, et il est indiqué que GitHub fonctionnait réellement ainsi autrefois, y compris sur un iPhone 4 en 3G
  • À fonctionnalités identiques, le meilleur code est défini comme celui qui consomme le moins de bande passante réseau, de temps CPU et de RAM, et qui contient le moins de bugs
  • On ne peut pas connaître directement le nombre de bugs frontend, mais des recherches historiques avancent que le nombre de bugs est généralement proportionnel au nombre de lignes de code
    • Steve McConnel, Code Complete, 2nd Ed (2004) est cité pour une moyenne sectorielle de 1 à 25 erreurs pour 1 000 lignes de code dans un logiciel livré
    • Il est cité que la Microsoft Applications Division observait, lors des tests internes, 10 à 20 défauts pour 1 000 lignes de code, et 0,5 défaut pour 1 000 lignes dans les produits publiés

Conception de l’expérience et méthode de collecte

  • Afin de réduire les variables confondantes, la vitesse Internet a été limitée à une connexion « fast 3G »
    • Ce réglage vise à réduire l’effet des variations de conditions réseau et à simuler l’expérience client GitHub dans des situations moins idéales, comme les zones rurales
  • Les trois services utilisent le même dépôt minimal ghsucks
    • une seule branche master
    • un seul fichier README.md
    • zéro élément additionnel comme des issues ou des tags
  • Le même navigateur et le même ordinateur ont été utilisés
    • Firefox
    • Apple Macbook Pro M5 Max
    • 48 GiB de RAM
  • Quatre types de pages ont été examinés sur chaque service
    • page “landing” : disposition du code
    • page “pull requests” ou “merge requests”
    • page “issues”
    • page “settings”
  • Les archives HTTP (HAR) ont été collectées avec un cache propre pour analyser les requêtes réseau, puis des heap snapshots ont été relevés après chargement complet afin d’obtenir une estimation de l’usage RAM à l’état stable
  • Pour l’analyse HAR, l’auteur a utilisé anhar, pour l’analyse de prise en charge de la compression testcompress, et pour la vérification croisée pagespeed.web.dev

Utilisation du heap et gaspillage mémoire

  • L’utilisation du heap mesurée sur la page principale d’un dépôt est de 69 MiB pour GitHub, 68 MiB pour GitLab, 14 MiB pour Codeberg et 1,3 MiB pour eblog.fly.dev
  • Le rendu de la première page d’issues de https://github.com/rust-lang/rust/pulls utilise 148 MiB de RAM
  • 148 MiB, c’est plus de mémoire que l’iPhone d’origine, ce qui est considéré comme un gaspillage extrême pour une page surtout textuelle avec quelques liens
  • Les mémoires des appareils cités pour comparaison sont notamment l’Apple iphone 1 avec 128 MiB, l’iphone 4 avec 512 MiB, la Sony playstation 2 avec 32 MiB et la Nintendo wii avec 88 MiB

Comparaison du volume des requêtes et des réponses

  • anhar est un programme Go qui parse du HAR JSON, reformate automatiquement le HTML, le CSS et le JavaScript des réponses avec deno fmt, puis calcule la taille des requêtes et des réponses, les totaux par MIME, les temps de chargement et le nombre de lignes des réponses
  • Les principaux indicateurs sont la taille des requêtes, la taille réelle des réponses minifiées reçues, la taille et le nombre de lignes des réponses après expansion via deno fmt, Content-Load pour le temps de chargement du HTML de base, et Load pour le temps de chargement de tout le contenu
  • La page de dépôt Codeberg affiche au total 11 requêtes, 9 KiB de requêtes, 1 MiB de réponses, 1 MiB de réponses expansées, 3 480 lignes après expansion, un Content-Load de 2.934s et un Load de 3.172s
  • La page de dépôt GitHub affiche 291 requêtes, 178 KiB de requêtes, 15 MiB de réponses minifiées, 22 MiB de réponses expansées, 544 564 lignes après expansion, un Content-Load de 843ms et un Load de 21.330s
    • application/javascript : 214 requêtes, 12 MiB de réponses, 19 MiB de réponses expansées, 481 849 lignes après expansion
    • text/css : 42 requêtes, 2 MiB de réponses, 60 016 lignes après expansion
    • GitHub pulls : 266 requêtes, 14 MiB minifiés, 20 MiB expansés, 487 922 lignes après expansion, Content-Load 592ms, Load 6.754s
    • GitHub settings : 255 requêtes, 14 MiB minifiés, 20 MiB expansés, 486 067 lignes après expansion, Content-Load 778ms, Load 6.963s
  • GitLab est plus léger que GitHub, mais reste lourd
    • Dépôt GitLab : 78 requêtes, 8 MiB de réponses, 101 682 lignes après expansion, Content-Load 6.880s, Load 12.941s
    • GitLab merge_requests : 65 requêtes, 7 MiB de réponses, 90 567 lignes après expansion, Content-Load 6.947s, Load 12.096s
    • GitLab edit : 117 requêtes, 7 MiB de réponses, 71 916 lignes après expansion, Content-Load 6.964s, Load 13.302s
  • GitHub récupère environ 540K lignes de code et de données même pour afficher un dépôt vide, une comparaison indiquant que c’est plus que les 35K lignes de DOOM, les 120K lignes de Windows Quake, les 332K lignes de MS-DOS 4.0 et les 460K lignes de la toolchain Zig
  • La structure dans laquelle chaque page récupère 40 fichiers CSS et plusieurs centaines de fichiers JavaScript est jugée problématique
  • Le découpage en chunks de Webpack peut en théorie séparer les fonctions essentielles et optionnelles et être favorable au cache et au CDN, mais ici il est interprété comme un choix qui ralentit le chargement parce que chaque fichier nécessite une requête HTTP distincte
  • Attendre 22 secondes pour voir une page vide est jugé inacceptable, et même avec une fibre à plus de 1 GiB/s et un processeur grand public haut de gamme, il faudrait plus d’une seconde avant qu’un dépôt ne devienne un minimum utilisable

Comparaison de la prise en charge de la compression

  • La compression est présentée comme une méthode utile pour réduire la charge côté client, côté serveur et sur le trajet intermédiaire
  • gzip est un standard de compression éprouvé que tous les sites web devraient prendre en charge, tandis que zstd, aux caractéristiques de performance intéressantes mais plus moderne, est considéré comme un simple “plus”
  • testcompress est un programme Go qui teste si une URL prend en charge la compression gzip et zstd, et qui, si ce n’est pas le cas, compresse directement le corps de la réponse pour montrer les économies potentielles
  • eblog.fly.dev/startingsystems3.html : encodages pris en charge zstd gzip, original 575.77KiB, gzip 67.64KiB, zstd 60.17KiB
  • github.com/ef0xa/ghsucks : encodages pris en charge gzip, original 224.70KiB, gzip 43.27KiB, zstd 37.96KiB
  • gitlab.com/efronlicht/ghsucks : encodages pris en charge gzip, original 43.08KiB, gzip 11.48KiB, zstd 11.34KiB
  • codeberg.org/efronlicht/ghsucks : encodages pris en charge n/a, original 43.88KiB, gzip 13.00KiB, zstd 12.79KiB

Résultats mobiles PageSpeed

  • Dans les mesures mobiles de pagespeed.web.dev, Codeberg obtient PASS avec un First Contentful Paint à 1.2s, un Largest Contentful Paint à 1.3s et un Interaction to Next Paint à 86ms
  • eblog.fly.dev obtient PASS avec un First Contentful Paint à 1.1s, un Largest Contentful Paint à 1s et un Interaction to Next Paint à N/A
  • GitHub obtient FAIL avec un First Contentful Paint à 1.8s, un Largest Contentful Paint à 2.1s et un Interaction to Next Paint à 242ms
  • GitLab obtient FAIL avec un First Contentful Paint à 2.1s, un Largest Contentful Paint à 2.4s et un Interaction to Next Paint à 243ms

Évaluation par service

  • GitHub

    • Environ 300 fichiers, avec quelque 550 000 lignes de code et de données récupérées, et un total estimé à 550 bugs
    • Le Content-Load est d’environ 800 ms, le Load total d’environ 7 s, et le heap à l’état stable est résumé à environ 69 MiB
    • gzip est pris en charge, mais pas zstd
    • La note est F, avec l’appréciation que le poids du code est extrêmement élevé
    • Il est reproché à GitHub de charger tous les thèmes sur toutes les pages, qu’ils soient utilisés ou non
    • Comme pagespeed.web.dev indique que 528 KiB de JavaScript et de CSS ne sont absolument pas utilisés, il est estimé que c’est par là qu’il faudrait commencer à réduire
    • S’il faut rester sur GitHub, il est avancé que le service viole le SLA de GitHub lui-même, et il est proposé de soumettre un ticket de support pour obtenir un remboursement

  • GitLab

    • Le Content-Load est d’environ 7 s, le Load d’environ 13 s, avec plus de 70 fichiers pour 7 MiB et environ 10 000 lignes récupérées
    • Le heap à l’état stable est d’environ 68 MiB, et gzip est pris en charge, mais pas zstd
    • La note est D+, avec l’évaluation que le service est moins gaspilleur que GitHub, mais qu’il récupère trop de ressources sans les exploiter correctement
    • Plus de 1 MiB de JavaScript et de CSS sont chargés alors qu’une partie n’est en réalité pas utilisée du tout, et même dans le code réellement utilisé, il existe des chunks de 3 MiB dont le parsing prend à lui seul 255 ms
    • Il est estimé qu’une landing page n’a pas besoin de 55 000 lignes de CSS, et que le CSS comme le JavaScript pourraient probablement être ramenés à un dixième de leur volume actuel

  • Codeberg/Forgejo

    • Le Content-Load est de 2,9 s, le Load de 3,1 s, avec 1 MiB sur 11 fichiers et environ 1 100 lignes récupérées
    • Le heap à l’état stable est d’environ 14 MiB, et ni gzip ni zstd ne sont pris en charge
    • La note est C+, avec l’évaluation que les bases sont là, mais que l’attention aux détails et l’expérience font défaut
    • L’absence de minification HTML est jugée comme un petit problème, mais l’absence de prise en charge de la compression est considérée comme un manque majeur
    • La plupart du JavaScript et du CSS ne sont pas nécessaires au rendu de la page, mais le problème signalé est qu’ils sont chargés de manière bloquante pour le rendu
    • Il est proposé de regrouper les payloads JavaScript et CSS afin de réduire le nombre de requêtes, et de prendre en charge la compression gzip et zstd pour les payloads HTTP, y compris le HTML
    • Comme il s’agit de logiciel libre, la possibilité de migrer vers une autre instance ou vers de l’auto-hébergement est présentée comme un avantage

  • eblog.fly.dev

    • eblog.fly.dev/startingsystems3.html est mesuré avec un Content-Load de 76 ms, un Load de 1,1 s, 766 KiB sur 5 fichiers, et environ 3 800 lignes
    • Le fichier HTML unique pèse 576 KiB et peut être compressé jusqu’à environ 70 KiB avec zstd
    • Le heap à l’état stable est d’environ 11 MiB, et zstd comme gzip sont tous deux pris en charge
    • La note est A-, avec l’évaluation que l’ensemble est bon, mais que le HTML reste volumineux et répétitif même en tenant compte de la compression, et qu’une page qui pourrait se terminer en une seule requête en nécessite 5

Une question de coût, pas seulement de dégradation produit

  • L’« enshittification » est résumée comme un processus dans lequel un bon produit commence par être favorable aux utilisateurs et aux clients business, puis devient défavorable aux utilisateurs, puis défavorable aussi aux clients business, tout en devenant favorable à son opérateur
  • Il est estimé que Microsoft et GitHub ne sont pas sans rapport avec Embrace, Extend, Extinguish, mais que le problème ici est différent en ce qu’il génère des coûts non seulement pour les utilisateurs et les clients business, mais aussi pour Microsoft
  • Une codebase gonflée augmente directement les coûts de serveurs et de bande passante, et consomme indirectement du temps d’ingénierie pour maintenir une base de code instable et hypertrophiée
  • En supposant qu’il y ait environ 800 ingénieurs chez GitHub, et que chacun travaille 40 heures par semaine sur 48 semaines par an, cela représente 1 536 000 heures-ingénieur par an
  • Il est avancé que la plupart des problèmes frontend pourraient être corrigés ou atténués en moins d’une semaine par un ingénieur compétent, simplement en suivant les recommandations de pagespeed
  • Le fait que des améliorations de bas niveau, pourtant susceptibles de réduire les coûts, soient laissées de côté est interprété comme relevant soit du désintérêt, soit d’une incompétence extrême, soit d’un blocage dû à un leadership centré sur l’IA et les investisseurs
  • Le logiciel est décrit comme un outil puissant et beau, car une fois correctement écrit, il peut être reproduit parfaitement, pour toujours, gratuitement, et utilisé par tous
  • La conclusion est que le gaspillage et l’incompétence de GitHub et des services similaires ne constituent pas seulement un mauvais produit, mais bien un crime contre les logiciels

À lire aussi

1 commentaires

 
GN⁺ 22 시간 전
Avis sur Lobste.rs

  • Ce serait bien d’inclure aussi Trac et Sourcehut dans cette comparaison

  • Les 4 boutons d’agent IA sont drôles, et les chiffres relatifs cités dans l’article sont intéressants, mais sans vouloir du tout défendre GitHub, une partie des détails manque de contexte et ne semble pas suffisante pour étayer la thèse de l’auteur.
    L’utilisation de mémoire au repos peut indiquer que GitHub fait plus de choses que Codeberg, mais il est difficile d’en tirer une conclusion pertinente en comparant l’usage absolu de RAM sur un ordinateur avec 48 Go de RAM à l’ordinateur de guidage d’Apollo.
    Formater un bundle JavaScript minifié pour estimer un nombre de lignes de code, puis le comparer au nombre de lignes d’un projet Zig hors dépendances, c’est comparer des choux et des carottes. Autant décompiler l’exécutable Zig pour voir combien de lignes on obtient.
    Je ne comprends pas non plus la recommandation selon laquelle Codeberg devrait « fusionner les payloads JavaScript et CSS pour réduire le nombre de requêtes ». Vu qu’il parle du « surcoût supplémentaire » des requêtes HTTP, je me demande même si l’auteur connaît HTTP/2.
    J’aurais encore beaucoup à dire sur les performances web, mais je le garderai pour un autre billet. Pour un meilleur angle sur un sujet proche, je recommande de relire l’article de Danluu de 2017 sur l’obésité du web : https://danluu.com/web-bloat

  • Si l’auteur lit ceci, il devrait jeter un œil à la controverse entre Casey Muratori et Uncle Bob. Le premier a trouvé un problème de performances très intéressant.
    « Je n’ai pas pu résister, j’ai regardé une capture de performance Chrome, et j’ai trouvé le coupable :) c’était le “emoji picker” ! »
    « Je n’ai regardé le code qu’en diagonale, mais le problème semble être que, chaque fois qu’on saisit un caractère, le “emoji picker” remonte en arrière pour vérifier si ce qui vient d’être tapé est un emoji. »
    Aïe. Cela dit, dans ce cas, le coupable pourrait être non pas le code frontend de GitHub, mais un navigateur basé sur Chromium

  • La formulation « Codeberg est un produit fourni par des bénévoles libres et dépendant de dons indépendants » n’est pas exacte.
    Codeberg dépend de ses membres. Pas seulement financièrement via les cotisations, mais aussi sur le plan de la gouvernance. À l’heure actuelle, les cotisations ne suffisent pas à embaucher du personnel à temps plein, donc le projet repose fortement sur le bénévolat, mais si j’ai bien compris, il y a aussi des prestataires.
    Je ne suis pas Codeberg de très près (je préfère plutôt sourcehut), mais son statut de coopérative fait partie des éléments centraux de sa proposition de valeur. Le projet essaie aussi de publier ses dépenses de manière transparente. Par exemple : https://blog.codeberg.org/codebergs-budget-of-2026.html
    Si vous utilisez Codeberg, vous pouvez envisager d’y adhérer dès maintenant : https://join.codeberg.org/

  • Je déteste vraiment GitHub. Mon problème n’est pas la disponibilité, c’est le fait que ce soit absurdement lent et gourmand en mémoire. « Ce diff est trop volumineux pour être affiché par défaut », sérieusement ?
    C’est aussi cassé pour des flux de travail de développement tout à fait raisonnables. Si on rebase une PR, le feedback de review et les commentaires disparaissent, et si on squash les commits, le feedback de review et les commentaires disparaissent aussi.
    Même si on a un lien vers un commentaire précis, si le commit concerné disparaît, le commentaire disparaît aussi \o/
    Quand il y a un correctif, on vous dit d’ouvrir une PR, et même si le bug a été corrigé par un autre changement, la PR et le bug existent au même niveau, donc les PR mortes restent éternellement dans la file de review.
    Si vous voulez savoir quel bug ce commit a corrigé, on ne vous montre que l’historique de la PR. On vous pousse à regarder la PR plutôt que le bug, et si vous voulez connaître le bug, il faut aller le retrouver vous-même.

    • Le concept même de « pull request » vient, comme git, du développement du noyau Linux. Le flux consiste à demander à un mainteneur du noyau de « pull » un patch dans la branche principale.
      GitHub a rendu ce flux plus pratique avec le bouton « fork », l’a rendu plus « social » avec des noms d’utilisateur centralisés, puis a conquis le monde en y ajoutant un gestionnaire d’issues et un wiki. D’un point de vue business, c’était effectivement génial.
      Mais tout le flux reste adapté au développement open source où des personnes dispersées demandent qu’on « pull » leurs patchs.
      Je ne comprends pas pourquoi une équipe de développement étroitement coordonnée, dont le mécanisme réel est « discuter d’une branche et approuver une fusion », devrait utiliser des « pull requests ». Pull depuis quoi ? C’est dans le même dépôt, et les changements ont déjà été push.
      Même en laissant de côté le problème de terminologie, l’absence de changements empilés, de commentaires stables et de diff par ensemble de changements n’a aucun sens.
      Désolé d’ajouter encore une plainte ennuyeuse sur GitHub. Existe-t-il une meilleure alternative ? Bien sûr, on ne peut obliger personne à l’utiliser…

  • J’ai vu plusieurs fois la réaction « les graphiques sans étiquettes d’axe ni points de données individuels sont toujours suspects » à propos de graphiques publiés par GitHub.
    Le maximum est indiqué sur le graphique, donc on peut estimer visuellement que les valeurs médianes de l’axe y sont d’environ 45M, 0.7B et 10M respectivement. À moins, bien sûr, que l’échelle soit logarithmique en douce et que la charge n’ait pas été multipliée par 100000.
    Je n’irais pas jusqu’à qualifier un mauvais graphique de « suspect », je dirais simplement que la communication est maladroite. Personnellement, je préfère presque toujours une sortie ggplot brute.
    Je suis d’accord avec le sentiment général, mais j’ai eu un peu de mal à suivre la partie sur les chevaux gros et les nombreuses tables. Cela dit, si j’essayais moi aussi de lister tous les défauts de GitHub, je finirais probablement par rêver de partir au coucher du soleil sur un gros cheval.
    J’ai moi aussi commencé une liste du même genre, puis abandonné quand j’étais arrivé à une douzaine de problèmes d’UX/performance. J’apprécie l’analyse approfondie de cet article et j’espère que l’équipe GitHub l’examinera sérieusement.
    Comme je l’ai dit précédemment, Microsoft devrait affecter quelques ingénieurs performance à GitHub. Tant que des métriques de performance ne feront pas réellement partie des KPI, cette obésité continuera et d’autres plateformes paraîtront plus attractives. S’il y a un prochain CEO de GitHub, j’espère qu’il en fera une priorité.

    • Cela suppose que l’axe y du graphique commence à 0. Dans ce genre de graphiques à la sauce business, c’est très souvent faux.
      On voit souvent des cas où on prétend montrer une « croissance énorme », la courbe traverse toute la zone du graphique en diagonale, mais l’axe y ne va en fait que de 100 à 101.

  • Je suis d’accord avec l’idée que « les logs GitHub Actions ont des fuites mémoire qui tuent mon navigateur depuis des années, et il n’existe toujours pas de moyen simple de juste pipe stdout ailleurs ».
    Malheureusement, Forgejo a hérité de ce problème. Il m’arrive de recevoir une alerte d’échec de build et de vouloir la consulter rapidement sur mon téléphone, mais dans un nombre non négligeable de cas, le navigateur mobile n’arrive même pas à charger la sortie.

  • En cliquant sur cet article, je m’attendais totalement à tomber sur une énième plainte au sujet de la disponibilité de GitHub, mais j’ai été agréablement surpris : c’est au final une évaluation posée et raisonnable des problèmes actuels de GitHub, GitLab et Codeberg, avec en plus des propositions de solutions.
    Ce serait bien d’inclure aussi Tangled dans la comparaison.
    L’auteur devrait écrire un peu de CSS pour que le site soit lisible sur mobile. J’ai dû utiliser le mode lecture du navigateur.
    Le seul point avec lequel je ne suis pas d’accord, c’est l’affirmation selon laquelle aucun site ne devrait charger plus d’un fichier JavaScript/CSS.
    Si ces 550 000 lignes de JavaScript étaient toutes dans un seul fichier, le parsing et l’exécution prendraient bien plus de temps. Pour le CSS, on peut faire du bundling, mais par exemple avoir un chunk commun et un chunk par route peut être utile. Une approche de ce genre, ou similaire, me semble tout à fait pertinente.

  • Cette page est illisible.
    Et si vous n’aimez pas GitHub, n’utilisez pas GitHub. Je suis surpris que des gens aient le temps de compiler des listes de plaintes aussi longues. Soit ils sont payés pour l’utiliser, soit il suffit d’utiliser autre chose.