Çadépend des endroits. Chez moi il y a des heures creuses la nuit (de 4h à 7h, je crois) mais aussi dans l'après-midi (14h30-16h30).
C'est ajusté en fonction de la consommation électrique locale, le but étant de lisser la consommation sur la journée.
Il est possible pour enedis (ou edf, j'ai du mal à suivre qui fait quoi) de changer les horaires et techniquement ils pourraient le faire de façon dynamique, le compteur électrique signale le passage en heures creuses et les appareils ménagers le détectent pour se déclencher.
C'est donc envisageable de le faire en fonction de la consommation effective plutôt que d'horaires fixes.
La compression consiste à supprimer ou réduire la redondance des données.
Ne pas stocker/transmettre 2 fois la même chose
Ne pas stocker/tranmettre ce qui n'a pasbesoin de l'être
On peut regarder du côté de la théorie de l'information et la façon dont on peut définir la quantité d'information présente dans une donnée quelconque, en étudiant la probabilité dechaque bit d'être un 0 ou un 1, en fonction des bits précédents et de toute autre connaissance du récepteur de la donnée. Ce qui donne une limite théorique à la réduction de taillle qu'on peut obtenir, si on atteint le fomat de compression idéal ou chaque bit a exactement une probabilité de 0.5 d'être un 0 ou un 1.
Euh, Zstd, développé par Facebook pour avoir un truc plus rapide et plus efficace que la zlib?
Alors oui si on regarde le web frontend, le desktop et les applis mobiles, en ce moment, c'est pas trop l'aspect privilégié. Mais ça ne veut pas dire que les compétences sont perdues, seulement qu'il y a des endroits ou ça n'est pas justifié/pas rentable de le faire.
Le logiciel embarqué a toujours des contraintes, mais pas forcément les mêmes. Pour gagner en durée de batterie sur un téléphone, il vaut mieux avoir des données moins compressées mais accessibles sans faire plein de calculs cpu pour les décoder, par exemple.
Pendant le mois de septembre 2020, près d'une vingtaine de nouvelles oeuvres de la demoscene dans les catégories <= 4Ko (je ne sais pas d'ou sort cette histoire de 5Ko, ça fonctionne par multiples de 2 bien sûr).
La page de LZSA donne une comparaison des différents outils souvent utilisés, en terme d'efficacité de la compression ainsi que du temps de décompression.
Dire que "cet art noble du hacker s'est perdu", ça me semble… quelque peu exagéré, au moins.
(ce ne sont pas forcément les algorithmes les plus efficaces en terme de taille économisée, il y a des compromis pour garder une vitesse de décompression acceptable y compris pour des CPUs peu performants).
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.
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.
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.
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
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…
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.
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.
[^] # Re: Précision
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Énergies renouvelables - Une centrale solaire aussi puissante (2.2 GW) que 2 réacteurs nucléaires. Évalué à 3.
Çadépend des endroits. Chez moi il y a des heures creuses la nuit (de 4h à 7h, je crois) mais aussi dans l'après-midi (14h30-16h30).
C'est ajusté en fonction de la consommation électrique locale, le but étant de lisser la consommation sur la journée.
Il est possible pour enedis (ou edf, j'ai du mal à suivre qui fait quoi) de changer les horaires et techniquement ils pourraient le faire de façon dynamique, le compteur électrique signale le passage en heures creuses et les appareils ménagers le détectent pour se déclencher.
C'est donc envisageable de le faire en fonction de la consommation effective plutôt que d'horaires fixes.
[^] # Re: ...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 10.
En tout cas il y a toujours autant de grincheux qui pensent que c'était mieux avant!
[^] # Re: Travaux
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 2.
La compression consiste à supprimer ou réduire la redondance des données.
On peut regarder du côté de la théorie de l'information et la façon dont on peut définir la quantité d'information présente dans une donnée quelconque, en étudiant la probabilité dechaque bit d'être un 0 ou un 1, en fonction des bits précédents et de toute autre connaissance du récepteur de la donnée. Ce qui donne une limite théorique à la réduction de taillle qu'on peut obtenir, si on atteint le fomat de compression idéal ou chaque bit a exactement une probabilité de 0.5 d'être un 0 ou un 1.
[^] # Re: Comment ça perdu?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 2.
Euh, Zstd, développé par Facebook pour avoir un truc plus rapide et plus efficace que la zlib?
Alors oui si on regarde le web frontend, le desktop et les applis mobiles, en ce moment, c'est pas trop l'aspect privilégié. Mais ça ne veut pas dire que les compétences sont perdues, seulement qu'il y a des endroits ou ça n'est pas justifié/pas rentable de le faire.
Le logiciel embarqué a toujours des contraintes, mais pas forcément les mêmes. Pour gagner en durée de batterie sur un téléphone, il vaut mieux avoir des données moins compressées mais accessibles sans faire plein de calculs cpu pour les décoder, par exemple.
[^] # Re: ça n'avance pas tellement
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Darling, Lamulateur de MacOS X pour linux. Évalué à 5.
Ou peut-être que le code fonctionne parfaitement et qu'il n'y a pas besoin de faire de changements.
Personellement, voir des douzaines de commits par jour sur un projet ne me rassure pas quant à sa maturité et stabilité :)
# Comment ça perdu?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un compresseur par ci, un compresseur par là. Au temps de l'algo des hackeurs.. Évalué à 10.
Pendant le mois de septembre 2020, près d'une vingtaine de nouvelles oeuvres de la demoscene dans les catégories <= 4Ko (je ne sais pas d'ou sort cette histoire de 5Ko, ça fonctionne par multiples de 2 bien sûr).
La page de LZSA donne une comparaison des différents outils souvent utilisés, en terme d'efficacité de la compression ainsi que du temps de décompression.
Dire que "cet art noble du hacker s'est perdu", ça me semble… quelque peu exagéré, au moins.
(ce ne sont pas forcément les algorithmes les plus efficaces en terme de taille économisée, il y a des compromis pour garder une vitesse de décompression acceptable y compris pour des CPUs peu performants).
# Ça peut arriver à tout le monde
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le câblage enterré innovant. Évalué à 10.
Il est enterré à -30cm de profondeur, ça peut arriver à tout le monde une erreur de signe sur ce genre de chose.
[^] # Re: objectif de l'hacktober feast
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 5.
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?
# L'enquête continue
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 8.
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
# Je confirme
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien pull request «DDoS» par DO sur github?. Évalué à 10.
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:
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:
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.
[^] # Re: Ha...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Cyclimse en Anjou. Évalué à 0.
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.
# CoAP
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Mozilla abandonne le web des objets. Évalué à 5.
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.
[^] # Re: Titre non éditorialisé
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Ça commence à se voir : en 10 ans, paye management x5 quand usage (en % PdM certes) /5. Évalué à 3.
Plus il reste longtemps dans une entreprise qui fonctionne pas, plus ça va être compliqué de trouver un autre employeur après.
Non?
[^] # Re: Le plus intéressant
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Revue de code de toml++. Évalué à 3.
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!
[^] # Re: Au lave-vaisselle ??
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Un lecteur vidéo pour regarder Big Buck Bunny sur un Macintosh IIcx de 1989. Évalué à 3.
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…
[^] # Re: Pourquoi il profite des sanctions de Trump pour avancer très vite
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC-V profite des sanctions de Trump pour avancer très vite. Évalué à 4.
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.
[^] # Re: Pourquoi il profite des sanctions de Trump pour avancer très vite
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC-V profite des sanctions de Trump pour avancer très vite. Évalué à 5.
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)
[^] # Re: Pourquoi il profite des sanctions de Trump pour avancer très vite
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC-V profite des sanctions de Trump pour avancer très vite. Évalué à 3.
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?
[^] # Re: Le B.A. BA du béotien
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le saviez-vous?. Évalué à 10.
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.
[^] # Re: Phosphine ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De la vie sur Vénus ?. Évalué à 9. Dernière modification le 14 septembre 2020 à 15:25.
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 :)
[^] # Re: encore ce fake ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Coup de tonnerre : la 5G serait 3 fois plus énergivore que la 4G. Évalué à 4.
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.
# Je fais ma propre distrib
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au sondage Votre invite de commande de shell…. Évalué à 4.
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.
[^] # Re: encore ce fake ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Coup de tonnerre : la 5G serait 3 fois plus énergivore que la 4G. Évalué à 2.
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?
[^] # Re: Why You Should **NOT** Use the Boost Software License
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Why You Should Use the Boost Software License. Évalué à 5. Dernière modification le 08 septembre 2020 à 11:28.
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:
Mais ils ont raté le fait que "the Software" est défini ainsi trois lignes plus haut:
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)
[^] # Re: De l'usage des paramètres
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Rust pour Haiku: l'affaire des threads morts qui disparaissent. Évalué à 6.
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.