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.
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.
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…
Je crois qu'un des problèmes est le passage de 4K à 16K pour la taille des pages mémoire du MMU. A priori on se dit que ça devrait pas être bien important pour les applications, mais en fait, beaucoup d'applis qui ont besoin d'un peu de performance ont probablement réécrit leur propre allocateur mémoire par exemple. Et c'est pas du code qu'on modifie sans faire bien attention à ce qu'on fait, en général.
Et c'est probablement juste un exemple de truc qui change. C'est pas exclu que les devs d'Apple aient aussi profité de l'occasion pour supprimer plein de vieilles APIs inutiles au passage?
Pour l'exécution out of order, faire l'ordonnancement dans le compilateur fonctionne bien quand on cible un cpu spécifique. Le problème, c'est que le code ainsi optimisé ne sera peut-être pas optimal sur une autre architecture (nouvelle génération, puce développée par un concurrent…). C'est pour ça que le cpu se permet d'intervenir.
C'est sûr que si on réfléchit en terme d'une architecture cible stable et bien connue, plein de choses pourraient être faites complètement en statique. Par exemple on pourrait laisser le compilateur gérer lui-même la mémoire cache. Sauf que si le compilateur optimise pour 1Mo de cache et que la génération de cpu suivante en a 2Mo, ce code ne l'exploitera pas. Et du coup les gains de performance ne seront pas trop visibles.
Il est même co-maintenu par Apple, Sony (qui l'utilise pour la PlayStation), et Igalia (qui fait une partie du dev pour GTKWebKit, utilisé dans Epiphany, ainsi que la version "WPE" de WebKit qui peut être utilisée sur des systèmes embarqués et est conçue pour être plus facilement portable) ainsi que plusieurs contributeurs indépendants. Sans compter les versions maintenues hors du dépôt officiel (par exemple pour Haiku).
Alors oui, d'accord, "bouh c'est pas bien ce sont des entreprises et donc forcément des Grands Méchants". Mais ça reste un développement communautaire et assez ouvert aux contributions externes (la version Haiku a un temps été intégrée dans le dépôt officiel, elle avait été retirée faute de mainteneur actif).
C'est donc beaucoup mieux que Blink/Chromium, ou les sources sont publiées, mais par exemple les patchs pour permettre d'utiliser Blink sous *BSD sont rejetés. C'est donc pas vraiment le même état d'esprit.
Du côté de NetSurf, c'est plutôt un projet du type "4 personnes dans un garage" (quoi qu'il y aie eu occasionellement du sponsoring d'entreprises). Les objectifs du projet sont différents, le but étant d'avoir un navigateur très léger pouvant fonctionner sur des systèmes très divers (AmigaOS, RiscOS, …) ce qui suppose d'assurer, en plus du développement du navigateur, le portage ou la réécriture des bibliothèques nécessaires (curl, openssl, libpng, …) et la maintenance d'une toolchain pour pouvoir cross-compiler le tout pour ces architectures.
Si vous pensez que NetSurf est la solution d'avenir, il va falloir mettre les moyens pour que le projet avance (soit en y contribuant, soit en trouvant les moyens de financer un développeur qui s'y mettrait à plein temps). L'équipe actuelle n'a clairement pas assez de temps pour faire avancer les choses à une vitesse suffisante (même si ce qu'ils ont fait est déjà très bien).
Il s'agit d'un "bundle" de jeux qui a été vendu en reversant les profits au mouvement Black Lives Matter. Victime de son succès car des centaines de développeurs de jeux ont mis leurs jeux dans le bundle. Et du coup, c'est pas pratique de s'y retrouver et de savoir quels jeux on a acheté.
Il était question d'un bouton dans l'application pour récupérer tous les jeux d'un coup, mais finalement ça se fera pas. Les développeurs de l'applis ne pensaient visiblement pas qu'il y aurait autant de jeux dans ce bundle quand ils ont émis l'idée de ce bouton.
Problèmes de riches, donc: des centaines de jeux pour une dizaine d'euros, et se plaindre qu'ils sont compliqués à installer? Alors que des solutions tierces existent pour explorer la liste de jeux et s'y retrouver facilement.
C'est un peu ce qui fait la différence entre Haiku et un OS quelconque :)
On fournit dans Haiku des APIs pour plein de choses (applications graphiques, réseau, multimédia, décodage et encodage d'images…). On fait, en gros, l'équivalent d'un KDE ou d'un GNOME avec tout ce qu'il faut en-dessous pour que ça fonctionne.
Et donc, oui, il y a certes des APIs pour faire des sockets directement, mais aussi une API de plus haut niveau pour faire facilement du HTTP. Ça permet d'intégrer facilement le code réseau avec le reste, en particulier avec les boucles d'évènements BLooper/BHandler, et de faciliter la vie des développeurs d'applications.
On peut facilement combiner ça avec les APIs multimédia pour écouter de la musique ou regarder un flux vidéo en streaming. Ou avec le parser json pour interroger une API en quelques dizaines de lignes de code.
Ainsi que le gestionnaire de paquets de Haiku (aussi bien la version en ligne de commande pour le téléchargement des paquets, que l'interface graphique pour en plus récupérer les captures d'écran, icônes, commentaires des utilisateurs, …)
Le Terminal est développé (entre autres) par un ancien contributeur de Haiku, si jamais vous pensiez que les gens qui travaillent chez Microsoft ne sont pas des "vrais" libristes!
Il y ade plus en plus de morceaux de Windows qui apparaissent sur le compte github de Microsoft. Par exemple, la calculatrice: https://github.com/microsoft/calculator (c'est écrit en toute lettres "ships with Windows" et "MIT license")
[^] # 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.
[^] # Re: Constat similaire
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Où vivre dans 100 ans ?. Évalué à 1.
La bonne nouvelle c'est qu'on va pouvoir mettre des panneaux solaires partout.
Mais c'est bien la seule bonne nouvelle…
[^] # Re: Questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 4.
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).
[^] # Re: Questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 8.
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!
[^] # Re: Questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 6.
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.
[^] # Re: AMD dans les consoles next-gen
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 8.
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.
[^] # Re: Out of order
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 7.
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.
[^] # Re: ce qui tue intel...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 5.
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…
[^] # Re: Questions
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 6.
Je crois qu'un des problèmes est le passage de 4K à 16K pour la taille des pages mémoire du MMU. A priori on se dit que ça devrait pas être bien important pour les applications, mais en fait, beaucoup d'applis qui ont besoin d'un peu de performance ont probablement réécrit leur propre allocateur mémoire par exemple. Et c'est pas du code qu'on modifie sans faire bien attention à ce qu'on fait, en général.
Et c'est probablement juste un exemple de truc qui change. C'est pas exclu que les devs d'Apple aient aussi profité de l'occasion pour supprimer plein de vieilles APIs inutiles au passage?
# Out of order
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le début de la fin pour Intel ?. Évalué à 10.
Pour l'exécution out of order, faire l'ordonnancement dans le compilateur fonctionne bien quand on cible un cpu spécifique. Le problème, c'est que le code ainsi optimisé ne sera peut-être pas optimal sur une autre architecture (nouvelle génération, puce développée par un concurrent…). C'est pour ça que le cpu se permet d'intervenir.
C'est sûr que si on réfléchit en terme d'une architecture cible stable et bien connue, plein de choses pourraient être faites complètement en statique. Par exemple on pourrait laisser le compilateur gérer lui-même la mémoire cache. Sauf que si le compilateur optimise pour 1Mo de cache et que la génération de cpu suivante en a 2Mo, ce code ne l'exploitera pas. Et du coup les gains de performance ne seront pas trop visibles.
[^] # Re: Novice
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Parce que ça n'arrive qu'aux autres. Évalué à 10.
Tellement facile de se tromper, c'est le contraire ;)
Le vrai paquet: https://pypi.org/project/requests/
Et "request" n'existe plus: https://pypi.org/project/request/
[^] # Re: Article vide, titre putaclic, sans sources…
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Mozilla songerait à mettre de côté son navigateur historique Firefox. Évalué à 6.
Il est même co-maintenu par Apple, Sony (qui l'utilise pour la PlayStation), et Igalia (qui fait une partie du dev pour GTKWebKit, utilisé dans Epiphany, ainsi que la version "WPE" de WebKit qui peut être utilisée sur des systèmes embarqués et est conçue pour être plus facilement portable) ainsi que plusieurs contributeurs indépendants. Sans compter les versions maintenues hors du dépôt officiel (par exemple pour Haiku).
Alors oui, d'accord, "bouh c'est pas bien ce sont des entreprises et donc forcément des Grands Méchants". Mais ça reste un développement communautaire et assez ouvert aux contributions externes (la version Haiku a un temps été intégrée dans le dépôt officiel, elle avait été retirée faute de mainteneur actif).
C'est donc beaucoup mieux que Blink/Chromium, ou les sources sont publiées, mais par exemple les patchs pour permettre d'utiliser Blink sous *BSD sont rejetés. C'est donc pas vraiment le même état d'esprit.
Du côté de NetSurf, c'est plutôt un projet du type "4 personnes dans un garage" (quoi qu'il y aie eu occasionellement du sponsoring d'entreprises). Les objectifs du projet sont différents, le but étant d'avoir un navigateur très léger pouvant fonctionner sur des systèmes très divers (AmigaOS, RiscOS, …) ce qui suppose d'assurer, en plus du développement du navigateur, le portage ou la réécriture des bibliothèques nécessaires (curl, openssl, libpng, …) et la maintenance d'une toolchain pour pouvoir cross-compiler le tout pour ces architectures.
Si vous pensez que NetSurf est la solution d'avenir, il va falloir mettre les moyens pour que le projet avance (soit en y contribuant, soit en trouvant les moyens de financer un développeur qui s'y mettrait à plein temps). L'équipe actuelle n'a clairement pas assez de temps pour faire avancer les choses à une vitesse suffisante (même si ce qu'ils ont fait est déjà très bien).
[^] # Re: ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien c'était pas le bundle de l'honnêteté, en tout cas. Évalué à 3.
Il s'agit d'un "bundle" de jeux qui a été vendu en reversant les profits au mouvement Black Lives Matter. Victime de son succès car des centaines de développeurs de jeux ont mis leurs jeux dans le bundle. Et du coup, c'est pas pratique de s'y retrouver et de savoir quels jeux on a acheté.
Il était question d'un bouton dans l'application pour récupérer tous les jeux d'un coup, mais finalement ça se fera pas. Les développeurs de l'applis ne pensaient visiblement pas qu'il y aurait autant de jeux dans ce bundle quand ils ont émis l'idée de ce bouton.
Problèmes de riches, donc: des centaines de jeux pour une dizaine d'euros, et se plaindre qu'ils sont compliqués à installer? Alors que des solutions tierces existent pour explorer la liste de jeux et s'y retrouver facilement.
[^] # Re: HTTP ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Haiku a 19 ans. Évalué à 9.
C'est un peu ce qui fait la différence entre Haiku et un OS quelconque :)
On fournit dans Haiku des APIs pour plein de choses (applications graphiques, réseau, multimédia, décodage et encodage d'images…). On fait, en gros, l'équivalent d'un KDE ou d'un GNOME avec tout ce qu'il faut en-dessous pour que ça fonctionne.
Et donc, oui, il y a certes des APIs pour faire des sockets directement, mais aussi une API de plus haut niveau pour faire facilement du HTTP. Ça permet d'intégrer facilement le code réseau avec le reste, en particulier avec les boucles d'évènements BLooper/BHandler, et de faciliter la vie des développeurs d'applications.
On peut facilement combiner ça avec les APIs multimédia pour écouter de la musique ou regarder un flux vidéo en streaming. Ou avec le parser json pour interroger une API en quelques dizaines de lignes de code.
Quelques exemples d'applications reposant là dessus:
- https://github.com/haikuarchives/streamradio
- https://github.com/haikuarchives/weather
- https://github.com/haikuarchives/maps
- https://github.com/pulkomandy/friss
Ainsi que le gestionnaire de paquets de Haiku (aussi bien la version en ligne de commande pour le téléchargement des paquets, que l'interface graphique pour en plus récupérer les captures d'écran, icônes, commentaires des utilisateurs, …)
[^] # Re: ma petite technique
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Petite histoire de debug. Évalué à 6.
Moi j'ai un dévelopeur en peluche
[^] # Re: Peut-être pas ce qu'on croit...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sur PC, Linux monte et MS-Windows baisse. Juste un effet Covid-19 ou vraie tendance ? . Évalué à 3.
Le Terminal est développé (entre autres) par un ancien contributeur de Haiku, si jamais vous pensiez que les gens qui travaillent chez Microsoft ne sont pas des "vrais" libristes!
[^] # Re: Peut-être pas ce qu'on croit...
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Sur PC, Linux monte et MS-Windows baisse. Juste un effet Covid-19 ou vraie tendance ? . Évalué à 2. Dernière modification le 27 juillet 2020 à 23:16.
Il y ade plus en plus de morceaux de Windows qui apparaissent sur le compte github de Microsoft. Par exemple, la calculatrice: https://github.com/microsoft/calculator (c'est écrit en toute lettres "ships with Windows" et "MIT license")
Le Terminal: https://github.com/microsoft/terminal