pulkomandy a écrit 1703 commentaires

De ce que j'ai compris ça partait d'une bonne intention. Un développeur chez eux s'est dit "hey on devrait faire un truc pour remercier les contributeurs aux logiciels open source pour leur travail". Visiblement c'était plus facile d'avoir un budget auprès du département marketing de la boîte pour imprimer et expédier des T-Shirts et des stickers, que de verser des sous directement aux gens (je suis pas surpris).

Une page web pour annoncer le truc, on se branche sur les APIs de Github pour compter les pull requests, et c'est parti. Le développeur est content et passe à autre chose.

Quelques années plus tard, ça a pris de l'ampleur, d'autres boîtes ont trouvé que l'idée était cool et ont décidé de sponsoriser le truc (70000 T-Shirts ça finit par faire un budget pas négligeable finalement). Hacktoberfest est devenu un moyen pour pas mal de gens de se lancer dans les contributions.

Apparament, certaines écoles d'informatique en Inde se sont dit "hé mais c'est cool ça, on va en faire la promotion à nos étudiants et les encourager à participer à des projets opensource" (ou bien certains étudiants ont commencé à participer, puis avec leurs T-Shirts, fait de la publicité à leur collègues).

Voilà. Personne là dedans n'avait de mauvaises intentions.

Seulement, ils n'ont pas pensé au départ que des gens voudraient tricher (pour gagner un T-Shirt? en effet ça paraît improbable). Ils n'ont pas pensé non plus que tous les projets sur github ne souhaitaient peut-être pas accepter des contributions de n'importe qui (par exemple un des projets victime de spam cette année est le whatwg qui travaille sur les spécifications du html5, pas vraiement le genre de trucs ou n'importe qui envoie des pull requests en général…). Ils n'ont pas anticipé que accueillir et former des dizaines de milliers de contributeurs, ça demande du temps et de la préparation. Là aussi on peut les comprendre, au départ l'idée était plutôt de récompenser des contributeurs existants, que d'encourager les gens à se lancer pour faire leur première contribution.

Bref, le succès du truc les a complètement dépassés, mais je pense que ça peut se comprendre, je ne pense pas qu'ils auraient pu le voir venir.

Quant à savoir s'il y aurait une façon plus efficace d'utiliser ce budget, oui, probablement. Et vous, que faites-vous dans vos entreprises respectives pour contribuer au logiciel libre?

A priori cela viendrait d'un youtubeur qui a montré un exemple de pull request qui aurqit été suivi un peu trop littéralement par les gens qui ont vu sa vidéo.

Source: https://joel.net/how-one-guy-ruined-hacktoberfest2020-drama

Pour la première fois cette année nous sommes chez Haiku victime de ce "spam". C'est d'autant plus ridicule que notre dépôt principal n'est pas sur github, c'est le dépôt contenant notre site web qui est visé. Avec des changements du genre rajouter "an amazing project" n'importe où dans le titre d'une page.

Ça partait d'une bonne intention, pourtant, encourager les contributions à l'open source. Mais rien ne va dans la façon dont c'est mis en place:

• Il est obligatoire pour participer, d'être sur Github. Le truc qui n'est même pas open source, là.
• Tout github est ouvert à la participation, a priori y compris les projets qui n'ont pas une license libre.
• Les gens qui ont mis leurs sources sur github reçoivent ces contributions sans savoir de quoi il s'agit. Rien n'indique que c'est pour hacktoberfest dans les pull requests.
• Hacktoberfest demande aux mainteneurs de dépôts de fermer les merge requests et de leur appliquer un label pour les exclure de hacktoberfest, si ce n'est pas fait, la pull request est automatiquement validée. Donc il suffit de trouver un dépôt inactif et de faire une pull request dessus, personne ne pourra la fermer.
• Les mainteneurs qui participent (contre leur gré, donc) ne sont même pas rémunérés.
• Il n'y a aucun encadrement des participants pour leur expliquer comment ça fonctionne. Hacktoberfest part du principe que tout le monde sait déjà comment fonctionne Github, alors même que le but est d'encourager les nouveaux contributeurs à se lancer.

Pourtant, il y avait une solution qui marchait bien. Google, entre 2010 et 2019, organisait le Google Code-In, qui fonctionnait de la façon suivante:

• Limité à un petit nombre de projets volontaires (une dizaine au départ, puis cela a augmenté petit à petit)
• Des tâches spécifiques et adaptées pour des contributeurs débutants (d'autant plus que seuls les 13-17ans pouvaient participer)
• Un site web dédié permettant de ne pas innonder les moyens de communication normaux des projets avec les participants au concours
• Une compensation financière pour les projets participants, étant donné la charge de travail que cela représente
• Il n'était pas nécessaire d'être sur github, chaque projet participant pouvait donc héberger son code comme il le souhaitait,
• Un choix des gagnants, pas seulement en fonction du nombre de pull requests complétées, mais par une revue des tâches par les membres des projets participants, afin de privilégier la qualité du travail.

Voilà, ça semble pourtant pas compliqué de faire les choses correctement. Mais Google a décidé que cela ne les intéressait plus. Probablement parce que la charge de travail pour faire fonctionner tout ça était trop importante et qu'ils ont mieux à faire ailleurs. Dommage.

En assumant du genre "moi je suis riche donc j'ai le droit d'avoir un gros SUV polluant"? Mouais, je suis moyennement convaincu par cette approche.

Pourquoi vouloir mettre du HTTP partout alors que pour les objets connectés il y a CoAP? Avec tout plein de RFCs, on ne pourra pas dire que c'est pas standard.

Plus il reste longtemps dans une entreprise qui fonctionne pas, plus ça va être compliqué de trouver un autre employeur après.

Non?

Et puis merci pour le "de toutes façons tout le monde a un écran fullhd" muis:
- c'est faux, j'écris et je relis beaucoup de code sur mon pc portable en 1280x768,
- tout le monde n'utilise pas une police de caractères minuscule,
- sur monn écran full hd avec une petite police je trouve utile de pouvoir avoir 3 x 80 colonnes de large et donc de pouvoir avoir 5 ou 6 fichiers visibles en même temps (même si c'est probablement un signe que le code en question est plutôt mal organisé

D'autre part, la limite à 80colonnes sert de rappel que au-delà de 4 niveaux d'indentation, le code est peut être trop compliqué pour rester dans une seule fonction

Bref, de toutes façons, chacun ses goûts!

C'est spécifié dans la documentation des composants, normalement (avec courbe de température en fonction du temps). Mais franchement si tu fais ça avec ton four de cuisine sur un composant déjà utilisé et mal soudé, tu n'es plus à 10 degrés près,tu n'as aucune chance de respecter ces spécifications: ton four chauffe et refroidit trop lentement et ne permet pas un contrôle très précis de la température. C'est pour ça que ce genre d'opération ne se fait que sur du matériel hors service quand il n'y a plus grand chose à perdre.

Pourun rebillage de composant bga, tu dois avoir la fiche techniques des nouvelles billes qui t'indique le profil de température, je pense. Mais s'il s'agit juste de refondre le métal déjà présent, personne n'a prévu ça dans les spécifications.

Note: c'est une mauvaise idée d'utiliser le même four pour faire la cuisine après…

Je pense que c'est un peu plus compliqué que ça.

Tu as le droit de concevoir un CPU compatible x86. Mais:
- Tu dois faire attention à ne pas utiliser quelque chose qui serait breveté, sans autorisation appropriée. Et il faut pour cela savoir ce qui est breveté: le format d'encodage d'une instruction? L'implémentation matérielle d'une opération?
- Tu n'as peut-être pas le droit de dire que ton CPU est compatible x86 même si en pratique, il l'est.

L'avantage de RISC-V est principalement sur le premier point: le jeu d'instruction est constitué uniquement d'instructions qui existent déjà dans d'autres architectures depuis au moins 20 ans. Cela suffit à prouver qu'il n'y avait pas de brevets dessus, ou bien qu'ils ont déjà expiré.

Sur le deuxième point, l'approche a l'air d'être la suivante: RISC-V est pas mal modulaire, et donc on peut facilement dire "compatible RISC-V" en implémentant seulement une partie du jeu d'instructions.

Si on compare avec SPARC, par exemple, le jeu d'instructions est également publié en intégralité. Mais son développement n'est pas vraiment ouvert (Oracle et Fujitsu se mettent d'accord entre eux, au mieux). Et pour avoir le droit de dire qu'un CPU est compatible SPARC, il faut le faire certifier par SPARC international. La license coûte 100 dollars, ce qui semble plutôt raisonable (https://sparc.org/technical-documents/)

Si on compare avec ARM, ils ne vendent pas que le jeu d'instructions, mais aussi l'implémentation du CPU dans différentes variantes (du tout petit Cortex-M0 jusqu'au Cortex-A72 ou je sais plus ou ils en sont maintenant). Il n'y a pas grand monde à part Apple qui conçoit ses propres CPUs compatibles avec le jeu d'instruction ARM.

C'est pour ça que j'ai précisé "jusqu'à lundi dernier". Et que le rachat par nVidia n'a pas d'influence sur le succès de RISC-V par rapport à ARM jusqu'à maintenant (il en aura probablement à l'avenir)

On parle bien de ARM, le concepteur de puces anglais (pas américain) qui était jusqu'à lundi dernier la propriété du japonais softbank (pas américain non plus)? Quel est le rapport avec les USA?

La plupart du temps les polices utilisées sont au format ttf (via l'extension Xft) et de toutes façons, même ça, c'est pas super utilisé par GTK ou Qt qui se débrouillent de leur côté pour faire le rendu du texte, et demande juste à X d'afficher l'image résultante.

Donc une nouvelle version sortie il y a 28 ans d'un format obsolète que personne n'utilise pour 2 raisons, ça va pas apporter grand chose.

Donc soit il y a de la vie, soit il y a une façon de produire de la phosphine qu'on ne connaît pas encore. La deuxième option n'est pas forcément moins intéressante :)

Pour préciser pour les gens qui n'ont pas forcément suivi tous les détails.

La 5G permet d'utiliser de nouvelles fréquences plus élevées. Les ondes à ces fréquences traversent mal les obstacles (elle vont rebondir sur les murs, etc). Mais du coup, l'idée c'est plutôt d'utiliser ça dans des zones très denses (dans une gare, par exemple).

Mais, la 5G permet aussi d'utiliser plus efficacement les ondes aux fréquences existantes. Et dans ce cas, elle permet de faire mieux que la 4G.

Le "mieux" est donc, au choix:
- Augmenter beaucoup le débit et la couverture en ajoutant plein d'antennes
- Garder le même nombre d'antennes, améliorer un peu le débit, ne pas changer la couverture, et aussi simplifier l'infrastructure derrière les antennes

La question n'est pas vraiment sur la 5G, ça serait un peu comme dire "faut-il passer à IPv6?". La question qu'il faut se poser, c'est plutôt:
- à quel rythme on y va; est-ce qu'on essaie de déployer ça très vite, ou de faire durer les équipements existants le plus longtemps possible?
- Est-ce qu'on continue à autoriser les vieux téléphones 2G a utiliser la moitié des fréquences disponibles avec un vieux protocole pas du tout efficace, ou bien est-ce qu'on se décide à arrêter la 2G pour mieux utiliser ces fréquences pour autre chose - et donc fournir une connexion à plus de téléphone avec un nombre d'antennes équivalent?
- Comment on peut réduire l'utilisation du débit disponible afin d'avoir besoin de moins d'antennes dans les zones denses?

Le fait d'avoir de la 5G permet d'avoir plus de débit. On peut l'utiliser en faisant des pages web plus grosses, plein de vidéos qui servent à rien, etc. Ou alors on peut l'utiliser pour avoir plus de téléphones utilisant la même antenne, si leurs besoins deviennent plus réduits. Le fait de ne pas avoir la 5G ne va rien changer à la taille des pages webs et des vidéos, et donc, soit on reste où on en est, ou soit on continue de toutes façons à ajouter des antennes pour essayer de couvrir l'augmentation des besoins.

Alors, j'ai voté "la configuration par défaut de ma distribution" mais en fait, je l'utilisais avant ou'elle soit adoptée par Haiku. Juste le path suivi d'un caractère >. Le prompt est vert en temps normal et rouge en cas d'erreur. Maintenant je suis incapable d'utiliser un shell qui n'affiche pas les erreurs de façon très facilement visible.

Et c'est normal de réduire la puissance des antennes et de pas forcément utiliser le même mode de fonctionnement la nuit quand 1) il y a moins de monde qui les utilise 2) il y a moins d'interférences (venant du soleil, par exemple). On fait quoi, on préfère les vieilles antennes qui émettent à pleine puissance toute la journée?

Je peux comprendre dans le cas spécifique de Boost qu'ils aient choisi une licence sans attribution dans les binaires, parce que une partie de leur code a vocation a être réutilisée dans les libs standard C++ de certains compilateurs.

Cela dit, je pense qu'ils ont mal lu la license.

Ils font référence à cette ligne:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

Mais ils ont raté le fait que "the Software" est défini ainsi trois lignes plus haut:

this software and associated documentation files (the "Software")

Et donc, mettre la licence et le copyright dans la documentation (et pas dans le logiciel lui-même) est suffisant. Et ils ont forcément un endroit ou ils mettent leur blabla sur les marques déposées et autres machins du genre.

(pour rappel le texte complet de la licence)

Dans le cas de Haiku on peut dire que quelques part Haiku n'avait pas été conçut a l'époque pour avoir une aussi grosse utilisation de threads.

C'est pas gentil ça, pour un OS dont l'utilisation de très nombreux threads est le principal argument de vente :)

En fait cette limitation (arbitraire) concerne uniquement les threads "joinable", déjà terminés, et dont personne n'a encore récupéré le code de retour (via un pthread_join). Il y a une autre limite pour le nombre total de threads en cours d'exécution sur le système (pour l'instant, 4096 threads, ce qui n'a pas encore posé problème).

Le développeur qui a écrit ce code (et introduit cette limitation) ne participe plus à Haiku, on aura donc probablement jamais d'explications sur ce qu'il voulait faire. Je pense que son raisonnement était que les threads ne devraient normalement pas rester longtemps dans cet état. Le fonctionnement habituel est qu'on lance un ou plusieurs threads qui vont faire des traitements longs, puis on attend qu'ils se terminent. Cette liste est là pour le cas ou certains threads se termineraient avant qu'on aie commencé à les attendre.

Dans le cas de Rust, il semblerait que l'attente de la fin des threads ne survient que beaucoup plus tard et n'est même pas vraiment nécessaire (jusqu'à présent le problème avait été contourné en supprimant cette attente). C'est une façon différente, mais pas incorrecte, d'utiliser cette API.

La limitation du nombre de threads dans cet état est pertinente, parce qu'un programme qui fait "n'importe quoi" (de façon involontaire via un bug, ou volontaire pour essayer de faire planter le système) peut remplir cette liste sans limite, et finir par remplir l'espace mémoire du noyau. Mais la limite a été placée au mauvais endroit et ne permettait pas aux applications de traiter l'erreur.

La meilleure solution (sous-entendue dans la spécification POSIX, d'ailleurs) est de vérifier le nombre de threads dans cet état lors du pthread_create, et de refuser la création de nouveaux threads tant qu'il y en a trop. Cela permet de signaler l'erreur à l'application, et ensuite au développeur de la dite application de chercher le problème. C'est beaucoup mieux que de faire discrètement disparaître le cadavre d'un thread.

La bonne nouvelle c'est qu'on va pouvoir mettre des panneaux solaires partout.

Mais c'est bien la seule bonne nouvelle…

Ce qui est "amusant" c'est que dans une sd card le contrôleur intégré va faire les tests sur la mémoire et gérer les erreurs, donc on s'en fiche un peu d'avoir une mémoire de bonne qualité. Résultat, a capacité équivalente, une carte sd coûte moins cher qu'une puce de nand-flash toute seule (qui elle nécessite du matériel de test spécifique).

Pour les CD/DVD, le principe est différent. Le but au départ est plutôt de se protéger des erreurs de lecture (poussière sur le disque, rayures, vitesse de rotation pas précise, vibrations…). Pour les cd audio, la lecture se fait en temps réel et c'est pas possible de tenter une deuxième lecture d'un secteur si la première a raté.

Pour le cdrom, un niveau supplémentaire de contrôle a été ajouté, et de mémoire on arrive à presque 10% des bits utilisés pour la correction (le secteur "brut" fait 2200 octets environ, dont 2048 de données utiles et le reste pour détecter et corriger les erreurs).

Et ça a permis ensuite de faire fonctionner raisonablement bien les CD-R ou les erreurs de lecture (ou même d'écriture) sont encore plus fréquentes.

Avec des codes correcteurs bien choisis, on arrive à vraiment augmenter la fiabilité et à compenser les défaillances de la mémoire. Pour de la Nand-flash, par exemple, c'est pas surprenant d'avoir des garanties du genre "pas plus de 4 bits défectueux par secteur marqué 'ok', et pas plus de 0.001% de secteurs marqués 'ko' en sortie d'usine". Et avec le code correcteur approprié, ça fonctionnera très bien et l'utilisateur ne se @endra compte de rien. Les secteurs de la mémoire sont séparées en une partie "données" et une partie dite "out of band", la deuxième servant à mettre les infos pour la détection/correction d'erreurs, à marquer les blocs inutilisables, etc.

Sur les SSD ça se voit qu'il y a de la marge. Par exemple un SSD de 60Go est probablement basé sur 64Go de mémoire. Et ils sont en général tous comme ça, une taille puissance de 2, moins 5 à 10% parce que c'est plein de secteurs inutilisables (bon c'est pas que pour ça, il y en a une partie pour le stockage d'infos internes du ssd aussi).

Il faut voir aussi que la surface du die n'est pas ce qui coûte le plus cher (en fait on sait pas trop quoi faire de toute cette place et on remplit avec des mégaoctets de mémoire cache). Les trois trucs qui empêchent de minaturiser les cpus aujourd'hui c'est le nombre de pins nécessaires pour les connecter à la carte mère, la dissipation de chaleur, et la consommation électrique qui empêche de faire des connections trop petites au moins pour l'alimentation.

Ces critères définissant en gros la taille du package du cpu, autant mettre du silicium qui fait à peu près la même taille dedans. Mais ça fait grand, et plus ton silicium a de surface, plus, statistiquement, y'a de chances qu'il aie un problème quelque part (par exemple ça peut être une poussière qui passe là ou elle devrait pas).

Du coup, avoir des coeurs désactivés n'est pas délirant. Y'a la place de les mettre,et une fois désactivés ils ne chauffent pas et ne consomment pas d'électricité. Et comme c'est dit dans un autre comrentaire, ça permet de lancer les premiers cpus (mettons avec 4 coeurs) puis quelques mois plus tard une fois les soucis réglés ou une fois un stock suffisant accumulé, hop, la version à 8 coeurs avec le même silicium!

Ce sont pas les premiers à faire ce genre de choses (désactiver les coeurs non fonctionnels). C'est le cas sur le processeur de la PlayStation 3, et c'est une solution qui est tout à fait raisonnable quand le "die" est un peu large. De la même façon, par exemple, que les mémoires NAND ont des blocs défectueux et de la correction d'erreur intégrée. Pareil pour les disques durs qui sont vendus avec un stock de secteurs à utiliser en remplacement. Pareil pour les CD et DVD qui ont plusieurs niveaux de détection et de correction d'erreurs pour que la lecture soit fiable.

Y'a que comme ça qu'on arrive à faire croire que le matériel fonctionne de manière fiable et prédictible.

Par exemple chez Dell il n'y a aucun PC dans les gammes pro avec un CPU AMD:

https://www.dell.com/en-us/work/shop/dell-laptops-and-notebooks/sr/laptops/all-amd-processors?appliedRefinements=6077 (il trouve deux Inspiron, qui n'est pas une gamme pro)

Alors je sais pas si c'est un choix de Dell de ne faire que du Intel, ou si c'est Intel qui leur met la pression pour ne rien faire avec les CPUs concurrents.

En poussant les choses un peu loin dans cette direction on a Java: le compilateur (javac) traduit le code Java en bytecode complètement générique et fait assez peu d'optimisations. Et laisse la machine virtuelle se débrouiller pour optimiser les choses pour la machine sur laquelle le code s'exécute en mettant en oeuvre les stratégies appropriées: JIT ou pas, différentes possibilités de garbage collector, mise en cache du code compilé définitif, …

L'inconvénient c'est qu'un code qui s'exécute très bien dans un cas peut devenir très lent dans un autre, et c'est souvent assez obscur à débugger quand il faut comprendre pourquoi.

Il a fallu attendre que AMD implémente le SSE2 dans ses processeurs 64bit pour que ça devienne un standard de fait, en effet. Avant ils avaient leur propre jeu d'instruction (3dNow!). Mais je ne vois pas ce que Intel pouvait y faire. Enfin si, ils auraient pu utiliser 3dNow! au lieu d'inventer le SSE qui est arrivé après…