Supprimer les 'ages pour empêcher le vandalisme, ça me rapelle les pirates dans Astérix et Obélix qui coulent leur bateau hour ne pas se faire attaquer par les Gaulois
Pour Github, compter le nombre de comptes utilisateur n'est pas forcément pertinent pour détecter un exode: on peut supprimer ses projet de Github, ou encore continuer à y stocber un miroir du code, et s'y garder quand même un compte.
Et d'autre part, en fait, on s'en fiche un peu si il ya des millions d'étudiants qui stockent leur code de projets de travaux pratiques sur github, ça n'apporte pas grand chose au logiciel libre (voir rien s'ils ont pas mis de licence) et ça n'apporte pus de sous à github non plus.
Il faut plutôt regarder les déploiements en entreprise, dans la mienne c'ets Gitlab mais on a un historique oe privilégier les logiciels libres. Chez nos clients il y avait plutôt du bitbucket, qui a arrêté ses licenses pour l'autohébergement pour passer sur une offre choud, et ça a l'air d'être github qui est en position pour récupérer une hartie de ce marché, en bénéficiant de l'intégration avec les comptes Microsoft.
Drew est certes plutôt engagé politiquement et assez franc et direct sur ses opinions sur la façon dont les choses devraient fonctionner, mais, en général, il a plutôt raison (à mon avis, si vous êtes pour les cryptomonnaies, contre les codes de conduite et pour les bots qui ferment les rapports de bug automatiquement alors que rien n'est résolu, allez voir ailleurs).
C'est à prendre en compte si vous voulez héberger des trucs chez lui, mais pour moi ça ne le met pas forcément dans la case "à éviter". Cwest un peu la même chose pour ForgeJo/Codeberg, ça a tendance à me rassurer sur le fait que ces projets vont rester des logiciels libres jusqu'à leur mort, et pas se vendre à un fond d'investissement au bout de 5 ans avec un communiqué du type "on aime toujours le libre, mais ça rapporte pas de sous"
Je ne sais pas pour Datadog, mon message était plus sur la trajectoire des startups à base de logiciel libre après un rachat.
Da adog a l'air d'avoir racheté plein de trucs d'après https://en.m.wikipedia.org/wiki/Datadog mais ce sont des technos dont j'ai jamais entendu parler (c'est pas vraiment dans mes domaines d'expertise). Donc je ne sais pas ce que sont devenus les produits rachetés.
Le code est libre pour l'instant, mais il est possible que les nouvelles versions après le rachat ne le soient plus. Ce qui pourrait conduire à un fork et une migration vers ce dernier, mais ce n'est peut-être pas un projet simple et léger qui peut être repris par 1 ou 2 personnes. Surtout si le Gitlab non opensource continuait ses développements au rythme actuel.
Il y a encore d'autres solutions, plus modulaires et avec un workflow assez différent, par exemple Gerrit pour la revue de code et la gestion des dépôts Git, ou Trac pour le suivi des tickets et le wiki.
Pas de cache (ça n'aurait pas vraiment de sens: un cache est intéressant s'il est plus rapide que ce qu'il remplace), mais par contre avoir de l'espage vide déclaré au disque (via trim ou blkdscard, je ne connait pas exactement les commandes à utiliser sous linux) hermet de pré-effacer ces zones pour ensuite pouvoir les écrire. Sur de la mémoire flash, il faut effacer une zone avant de l'écrire, et l'effacement prend plus de temps que la lecture.
On gagne donc des meilleures performance si le disque peut se préparer d'avance des secteurs effacés et prêts à écrire.
D'autre part, il y a le "wear levelling": le disque déplace en permanence des données peu souvent modifiées d'un endroit à un autre sur le disque, dwune part afin d'avoir un nombre d'écritures équivalent sur tous les blocs, et d'autre part parce que si on laisse des données trop longtemps sans les réécrire, elles finissent par s'effacer petit à petit au bout de quelques années.
SLC (single level cell) stocke 1 bit par transistor (le transistor est chargé ou déchargé)
DLC (dual level) en stocke 2 (4 niveaux de charge)
TLC (triple level) en stocke 3 (8 niveaux de charge)
QLC (quad level) en stocke 4 (16 niveaux de charge)
MLC veut dire "multi level cell" et veut donc juste dire "ce n'est pas du SLC".
Le coût du disque est proportionnel (en gros) au nombre de transistors. Donc un disque SLC coûtera le même pris qu'un QLC pour stocker 4 fois moins de données. Mais ce sera plus fiable, parce que utiliser autant de niveaux différents dans un transistor, ça demande une électronique qui fonctionne de façon assez précise, ce qui est compliqué sur le long terme (les composants vieillissent).
Les disques SLC seront donc les plus fiables mais aussi les plus chers. Le QLC aura une plus grande capacité mais sera moins fiable.
Il ne serait pas complètement surprenant que le firmware passe sur un algorithme d'écriture plus lent, mais plus fiable, au bout d'un certain nombre d'heures de fonctionnement ou de cycles d'écriture, pour compenser le vieillissement des transistors qui se réécrivent de moins en moins facilement avec le temps. Ce qui permettrait d'avoir des bonnes performances sur un disque neuf, mais une fiabilité correcte sur le long terme. Mais ce n'est pas très honnête.
C'est le problème du logiciel libre, on paie une personne pendant un an à un salaire à peine compétitif, et on se retrouve avec un projet de ouf qui fait le café. Du coup c'est plus difficile de filer des milliards à une grosse entreprise qui ferait moins bien pour beaucoup plus cher.
C'est mauvais pour l'économie et la création d'emplois!
(je taquine un peu, mais c'est probablement ce qui explique le changement proposé: cet argent va être réattribué aux personnes et aux entreprises qui ont les moyens de faire du lobbying auprès des parlementaires, et je pense que les développeurs de logiciels libres n'y sont pas super bien représentés).
Surtout ici je crois (mais ça m'a mis en tête une confusion entre les deux et peut-être que j'ai sur-interprété pour la suite du paragraphe):
De fait il y a un tronc commun de balises entre HTML et XML
Les balises en commun sont dans XHTML. Dans XML, il n'y a que la syntaxe qui est en commun (les <> et </>), mais pas les balises elle-mêmes (h1, strong, p, img, …).
En fonction de la syntaxe XML du document, s’il est transmis avec le type MIME text/html, il est vu par les navigateurs comme un fichier HTML. En revanche, s’il est transmis avec un type XML MIME, il sera traité comme un document XML. Dans le deuxième cas de figure, des erreurs de syntaxe même mineures empêcheront un document étiqueté XML d’être correctement restitué alors qu’elles seraient ignorées dans la syntaxe HTML.
Ça laisse penser que le fonctionnement est identique dans les 2 cas, ce qui est vrai seulement si le document en question est du XHTML.
Dans le cas contraire, le navigateur web ne saura pas quoi en faire, sauf si le document contient une feuille de style XSLT contenant des instructions pour le convertir en XHTML.
Rien d'incorrect au final dans ce paragraphe là-dessus, mais avec la phrase précédente, j'ai eu l'impression que ça parlait plus de XHTML que de XML.
Et j'ai aussi un autre problème avec ce paragraphe (mais c'est un point technique pas forcément intéressant). La différence entre HTML et XML n'est pas vraiment que HTML ignore des erreurs, mais plutôt que le format HTML est conçu pour qu'il n'y ait pas d'erreurs. Même si on écrit "n'importe quoi", le comportement du navigateur est précisément spécifié et la page pourra s'afficher en entier, et de façon prédictible. Ce ne sont donc pas vraiment des erreurs de syntaxe, mais une syntaxe plus tolérante qui accepte toutes les possibilités, là ou en XML, certaines choses sont interdites et débouchent sur une erreur et un arrêt du traitement.
Il me semble qu'il y a un peu de confusion entre XML et XHTML. Le XHTML reprend les balises et le fonctionnement général de HTML, mais est implémenté en XML, avec une syntaxe plus stricte (mais plus facile à traiter pour les ordinateurs). Le format XML est beaucoup plus générique, et utilisé pour beaucoup d'autres choses (pas nécessairement du texte) avec des balises différentes. On peut citer par exemple Docbook, un format basé sur XML mais qui ne ressemble pas du tout à du HTML, et conçu pour écrire des livres (avec des notions oe chapitres, sections, paragraphes, …).
Ça se fait avec la visibilité des symboles ça (compiler avec -fvisibility=hidden et ajouter des déclarations de visibilité à chaque classe ou méthode qui doit être accessible de l'extérieur). Mais c'est vrai que c'est dommage de devoir recourir à des attributs non standards pour le faire.
Il y a quand même Dillo (qui s'est réveillé y'a pas longtemps) et NetSurf dans la catégorie challenger. Ils n'ont pas forcément les ambitions de Ladybird, mais est-ce que les ambitions ne sont pas arrivées avec les donations qui ont permisd'avoir des développeurs à plein temps?
Haiku participe au Google Summer of Code et a participé au Google Code-In, concrètement ça veut dire que:
Google nous sous-traite l'encadrement de stagiaires
Pour un stagiaire encadré pendant 3 mois, Google nous donne une compensation de 500$ (et paie le stagiaire un montant qui dépend de son pays de résidence)
En contrepartie, on choisit sur quoi va travailler le stagiaire
Et pour le Google Code-In:
Google nous envoie des centaines d'adolescents (13-18 ans)
On doit leur fournir des tâches liées au projet pendant 1 mois (couvrant noël et thanksgiving, périodes où les ados ont pas mal de temps libre et nos contributeurs sont pas mal occupés)
Il faut répondre en moins de 12h aux demandes, car les participants sont en compétition et doivent compléter un maximum de tâches, il ne faut donc pas les laisser bloqués en attente de revue
Toute l'équipe (plusieurs dizaines de personnes) finit en quasi burn-out, même en ne faisant rien d'autre pour le projet pendant 1 mois
Le tout sans compter le travail en amont pour préparer les tâches que les participants devront accomplir (tout doit être extrêmement bien documenté pour qu'un adolescent de 13 ans puisse suivre les instructions)
On gagne 2500$
Pour le Google Code-In, c'est tellement intense que aucun autre projet n'a participé tous les ans. Haiku a réussi à le faire en recrutant les participants d'une année pour aider à encadrer ceux de l'année suivante. De plus, les tâches proposées sont plutôt autour du portage d'applications venant d'autres systèmes, ou encore du développement d'applications hors du système Haiku en lui-même.
En dehors de ça, Haiku n'a reçu aucun autre soutien de Google. On est donc à 5000$ par an pendant la période où il y a eu le Google Code-In, et plutôt autour de 1500 à 2000$ maintenant. Ce qui ne rembourse pas du tout le temps et l'énergie dépensé dans le Google Summer of Code et le Google Code-In. Donc parler de "largesses", c'est un peu exagéré. Andreas Kling recevait 2000$ de donations par mois en 2021, et maintenant on compte carrément en millions pour Ladybird. Lequel des deux bénéficie de largesses d'entreprises?
Et oui, SVN était déjà vieux à la naissance en pratique,
Il faut peut-être pas exagérer, avant SVN il n'y avait pas grand chose d'autre et SVN est quand même un très gros progrès par rapport à CVS en termes de facilité d'utilisation.
Il a vieilli assez vite après (malgré pas mal d'efforts pour incoroporer quelques bonnes idées de Git), mais c'est pas une raison.
Dans le he-gate dont on parle, on n'est pas loin de ça : refuser un patch qui change 5 occurences de "he" en "they" dans une doc confidentielle d'un logiciel pas très connu est décrit comme un acte exécrable, qui conduit à des accusations de mysogynie et de transphobie.
Non pas comme un acte exécrable, mais comme quelque chose qui semble assez révélateur de la façon de penser de la personne qui a refusé ce patch en disant que utiliser des pronoms neutres, c'est avoir un agenda politique.
Rien de grave, certes, mais pour moi c'est un signal suffisant pour ne pas avoir envie de mettre les pieds dans le projet en question, ou en tout cas pour être sur mes gardes. C'est tout. Il peut continuer à penser ce qu'il veut et à gérer son projet comme il veut. Et j'ai le droit de penser que c'est pas le genre de personne avec qui j'ai envie de collaborer. Je crois que personne n'a rien demandé d'autre.
Éviter une monoculture avec un seul moteur de rendu pour tout l'internet, c'est une bonne raison. Tout comme on parle de biodiversité, la technodiversité est une bonne chose pour la résilience.
Si un projet est abandonné par ses auteurs, se retrouve dirigé par une entreprise qui mise tout sur l'IA et les cryptomonnaies, …, c'est pas mal d'avoir un plan B.
D'ailleurs c'est vrai pour beaucoup de technologies qui ont fort évoluées et se sont complexifiées à un tel point qu'il est difficilement envisageable de réimplémenter depuis zéro : un noyau comme UNIX, un toolkit graphique comme GTK ou Qt, le support du multimédia, et sûrement plein d'autres.
Ce n'est pas parce que les implémentations actuelles sont lourdingues et compliquées que c'est devenu impossible de faire plus simple, à condition d'accepter un champ d'application un peu plus restreint.
Quand on a une documentation qui référence l'utilisateur en utilisant le pronom "he", et que quelqu'un propose de le remplacer par un pronom neutre, selon l'usage en pratique depuis plusieurs centaines d'années en anglais, quand on refuse sous prétexte de "oulala on ne fait pas de politique ici", le message est clair: ce système s'adresse uniquement à des gens qui se genrent au masculin, les autres ne sont pas concernées, et c'est intentionnel et pas juste une mauvaise habitude grammaticale (ce qui peut arriver et serait tout à fait excusable).
Pour les 2 dernières, cela a pris moins de temps (1 mois pour Bullseye, 3 mois pour Bookworm), mais l'équipe de Debian ne prend pas d'engagement à reproduire un cycle aussi rapide.
ça me semble peu efficace comme conversion, à première vue.
Sur les chaînes hi-fi des années 70-90, découpées en différents modules, on peut certainement remplacer le récepteur FM par un récepteur DAB.
Mais sur les systèmes tout-en-un, est-ce que c'est vraiment pertinent de recevoir du DAB, le décoder, le remoduler en FM, pour le renvoyer dans un autre récepteur? Autant directement recevoir le DAB et l'envoyer dans un amplificateur audio et un haut-parleur, non?
Il reste toujours l'option de tenter une modification d'un récepteur FM existant pour en retirer la partie démodulation radio, et y greffer un récepteur DAB, à la limite, pourquoi pas.
Ah oui, un cas particulier auquel je n'avais pas pensé: votre récepteur FM est intégré dans un véhicule automobile, il est peu pratique de remplacer tout le véhicule. Dans ce cas, oui, des convertisseurs existent, par exemple: https://radiofidelity.com/best-dab-car-radio-adapter/
Le but est surtout de rendre le message du kernel panic visible si on est dans une session graphique. Actuellement il est affiché uniquement si on est dans une console, ce qui est bien pour les serveurs et les systèmes embarqués, mais pour tout le reste, c'est quand même pas courant d'avoir un système en console.
[^] # Re: Comprendre avant de critiquer
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien La page Wikipédia de Lucie Castets, candidate (NFP) pour le poste de Premier ministre, supprimée. Évalué à 10.
Supprimer les 'ages pour empêcher le vandalisme, ça me rapelle les pirates dans Astérix et Obélix qui coulent leur bateau hour ne pas se faire attaquer par les Gaulois
[^] # Re: Nouvel exode
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien GitLab chercherait à se vendre et Datadog est sur les rangs. Évalué à 3.
Pour Github, compter le nombre de comptes utilisateur n'est pas forcément pertinent pour détecter un exode: on peut supprimer ses projet de Github, ou encore continuer à y stocber un miroir du code, et s'y garder quand même un compte.
Et d'autre part, en fait, on s'en fiche un peu si il ya des millions d'étudiants qui stockent leur code de projets de travaux pratiques sur github, ça n'apporte pas grand chose au logiciel libre (voir rien s'ils ont pas mis de licence) et ça n'apporte pus de sous à github non plus.
Il faut plutôt regarder les déploiements en entreprise, dans la mienne c'ets Gitlab mais on a un historique oe privilégier les logiciels libres. Chez nos clients il y avait plutôt du bitbucket, qui a arrêté ses licenses pour l'autohébergement pour passer sur une offre choud, et ça a l'air d'être github qui est en position pour récupérer une hartie de ce marché, en bénéficiant de l'intégration avec les comptes Microsoft.
[^] # Re: Nouvel exode
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien GitLab chercherait à se vendre et Datadog est sur les rangs. Évalué à 8.
Drew est certes plutôt engagé politiquement et assez franc et direct sur ses opinions sur la façon dont les choses devraient fonctionner, mais, en général, il a plutôt raison (à mon avis, si vous êtes pour les cryptomonnaies, contre les codes de conduite et pour les bots qui ferment les rapports de bug automatiquement alors que rien n'est résolu, allez voir ailleurs).
C'est à prendre en compte si vous voulez héberger des trucs chez lui, mais pour moi ça ne le met pas forcément dans la case "à éviter". Cwest un peu la même chose pour ForgeJo/Codeberg, ça a tendance à me rassurer sur le fait que ces projets vont rester des logiciels libres jusqu'à leur mort, et pas se vendre à un fond d'investissement au bout de 5 ans avec un communiqué du type "on aime toujours le libre, mais ça rapporte pas de sous"
[^] # Re: Nouvel exode
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien GitLab chercherait à se vendre et Datadog est sur les rangs. Évalué à 2.
Je ne sais pas pour Datadog, mon message était plus sur la trajectoire des startups à base de logiciel libre après un rachat.
Da adog a l'air d'avoir racheté plein de trucs d'après https://en.m.wikipedia.org/wiki/Datadog mais ce sont des technos dont j'ai jamais entendu parler (c'est pas vraiment dans mes domaines d'expertise). Donc je ne sais pas ce que sont devenus les produits rachetés.
[^] # Re: Nouvel exode
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien GitLab chercherait à se vendre et Datadog est sur les rangs. Évalué à 8.
Le code est libre pour l'instant, mais il est possible que les nouvelles versions après le rachat ne le soient plus. Ce qui pourrait conduire à un fork et une migration vers ce dernier, mais ce n'est peut-être pas un projet simple et léger qui peut être repris par 1 ou 2 personnes. Surtout si le Gitlab non opensource continuait ses développements au rythme actuel.
[^] # Re: Nouvel exode
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien GitLab chercherait à se vendre et Datadog est sur les rangs. Évalué à 4.
Il y a encore d'autres solutions, plus modulaires et avec un workflow assez différent, par exemple Gerrit pour la revue de code et la gestion des dépôts Git, ou Trac pour le suivi des tickets et le wiki.
[^] # Re: Taux d'occupation des disques
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le mystère des disques SSD lents. Évalué à 4.
Pas de cache (ça n'aurait pas vraiment de sens: un cache est intéressant s'il est plus rapide que ce qu'il remplace), mais par contre avoir de l'espage vide déclaré au disque (via trim ou blkdscard, je ne connait pas exactement les commandes à utiliser sous linux) hermet de pré-effacer ces zones pour ensuite pouvoir les écrire. Sur de la mémoire flash, il faut effacer une zone avant de l'écrire, et l'effacement prend plus de temps que la lecture.
On gagne donc des meilleures performance si le disque peut se préparer d'avance des secteurs effacés et prêts à écrire.
D'autre part, il y a le "wear levelling": le disque déplace en permanence des données peu souvent modifiées d'un endroit à un autre sur le disque, dwune part afin d'avoir un nombre d'écritures équivalent sur tous les blocs, et d'autre part parce que si on laisse des données trop longtemps sans les réécrire, elles finissent par s'effacer petit à petit au bout de quelques années.
[^] # Re: Quelle est la meilleure alternative à la mémoire QLC ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Le mystère des disques SSD lents. Évalué à 10.
SLC (single level cell) stocke 1 bit par transistor (le transistor est chargé ou déchargé)
DLC (dual level) en stocke 2 (4 niveaux de charge)
TLC (triple level) en stocke 3 (8 niveaux de charge)
QLC (quad level) en stocke 4 (16 niveaux de charge)
MLC veut dire "multi level cell" et veut donc juste dire "ce n'est pas du SLC".
Le coût du disque est proportionnel (en gros) au nombre de transistors. Donc un disque SLC coûtera le même pris qu'un QLC pour stocker 4 fois moins de données. Mais ce sera plus fiable, parce que utiliser autant de niveaux différents dans un transistor, ça demande une électronique qui fonctionne de façon assez précise, ce qui est compliqué sur le long terme (les composants vieillissent).
Les disques SLC seront donc les plus fiables mais aussi les plus chers. Le QLC aura une plus grande capacité mais sera moins fiable.
Il ne serait pas complètement surprenant que le firmware passe sur un algorithme d'écriture plus lent, mais plus fiable, au bout d'un certain nombre d'heures de fonctionnement ou de cycles d'écriture, pour compenser le vieillissement des transistors qui se réécrivent de moins en moins facilement avec le temps. Ce qui permettrait d'avoir des bonnes performances sur un disque neuf, mais une fiabilité correcte sur le long terme. Mais ce n'est pas très honnête.
[^] # Re: Affligeant et ridicule: 27 M€ / 500 = 54 k€
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche L’Union Européenne doit poursuivre le financement des logiciels libres. Évalué à 6.
C'est le problème du logiciel libre, on paie une personne pendant un an à un salaire à peine compétitif, et on se retrouve avec un projet de ouf qui fait le café. Du coup c'est plus difficile de filer des milliards à une grosse entreprise qui ferait moins bien pour beaucoup plus cher.
C'est mauvais pour l'économie et la création d'emplois!
(je taquine un peu, mais c'est probablement ce qui explique le changement proposé: cet argent va être réattribué aux personnes et aux entreprises qui ont les moyens de faire du lobbying auprès des parlementaires, et je pense que les développeurs de logiciels libres n'y sont pas super bien représentés).
[^] # Re: XML et XHTML
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Une histoire de formats : il n’y a pas que la taille qui compte. Évalué à 3.
Surtout ici je crois (mais ça m'a mis en tête une confusion entre les deux et peut-être que j'ai sur-interprété pour la suite du paragraphe):
Les balises en commun sont dans XHTML. Dans XML, il n'y a que la syntaxe qui est en commun (les <> et </>), mais pas les balises elle-mêmes (h1, strong, p, img, …).
Ça laisse penser que le fonctionnement est identique dans les 2 cas, ce qui est vrai seulement si le document en question est du XHTML.
Dans le cas contraire, le navigateur web ne saura pas quoi en faire, sauf si le document contient une feuille de style XSLT contenant des instructions pour le convertir en XHTML.
Rien d'incorrect au final dans ce paragraphe là-dessus, mais avec la phrase précédente, j'ai eu l'impression que ça parlait plus de XHTML que de XML.
Et j'ai aussi un autre problème avec ce paragraphe (mais c'est un point technique pas forcément intéressant). La différence entre HTML et XML n'est pas vraiment que HTML ignore des erreurs, mais plutôt que le format HTML est conçu pour qu'il n'y ait pas d'erreurs. Même si on écrit "n'importe quoi", le comportement du navigateur est précisément spécifié et la page pourra s'afficher en entier, et de façon prédictible. Ce ne sont donc pas vraiment des erreurs de syntaxe, mais une syntaxe plus tolérante qui accepte toutes les possibilités, là ou en XML, certaines choses sont interdites et débouchent sur une erreur et un arrêt du traitement.
# XML et XHTML
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Une histoire de formats : il n’y a pas que la taille qui compte. Évalué à 3.
Il me semble qu'il y a un peu de confusion entre XML et XHTML. Le XHTML reprend les balises et le fonctionnement général de HTML, mais est implémenté en XML, avec une syntaxe plus stricte (mais plus facile à traiter pour les ordinateurs). Le format XML est beaucoup plus générique, et utilisé pour beaucoup d'autres choses (pas nécessairement du texte) avec des balises différentes. On peut citer par exemple Docbook, un format basé sur XML mais qui ne ressemble pas du tout à du HTML, et conçu pour écrire des livres (avec des notions oe chapitres, sections, paragraphes, …).
[^] # Re: Modules et visibilité
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal De retour de conférence. Évalué à 3.
Ça se fait avec la visibilité des symboles ça (compiler avec -fvisibility=hidden et ajouter des déclarations de visibilité à chaque classe ou méthode qui doit être accessible de l'extérieur). Mais c'est vrai que c'est dommage de devoir recourir à des attributs non standards pour le faire.
[^] # Re: l'islamodroitisme est il pro casseroliste?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien le langage est libre il a forké . Évalué à 5.
Dans les années 50 on avait des cryptocommunistes, qui ont presque disparu et c'est fort regrettable.
https://www.lalanguefrancaise.com/dictionnaire/definition/cryptocommuniste
[^] # Re: très bonne nouvelle..
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs. Évalué à 3.
Il y a quand même Dillo (qui s'est réveillé y'a pas longtemps) et NetSurf dans la catégorie challenger. Ils n'ont pas forcément les ambitions de Ladybird, mais est-ce que les ambitions ne sont pas arrivées avec les donations qui ont permisd'avoir des développeurs à plein temps?
[^] # Re: très bonne nouvelle..
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs. Évalué à 6.
Les largesses de Google?
Haiku participe au Google Summer of Code et a participé au Google Code-In, concrètement ça veut dire que:
Et pour le Google Code-In:
Pour le Google Code-In, c'est tellement intense que aucun autre projet n'a participé tous les ans. Haiku a réussi à le faire en recrutant les participants d'une année pour aider à encadrer ceux de l'année suivante. De plus, les tâches proposées sont plutôt autour du portage d'applications venant d'autres systèmes, ou encore du développement d'applications hors du système Haiku en lui-même.
En dehors de ça, Haiku n'a reçu aucun autre soutien de Google. On est donc à 5000$ par an pendant la période où il y a eu le Google Code-In, et plutôt autour de 1500 à 2000$ maintenant. Ce qui ne rembourse pas du tout le temps et l'énergie dépensé dans le Google Summer of Code et le Google Code-In. Donc parler de "largesses", c'est un peu exagéré. Andreas Kling recevait 2000$ de donations par mois en 2021, et maintenant on compte carrément en millions pour Ladybird. Lequel des deux bénéficie de largesses d'entreprises?
[^] # Re: La suite
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien A Git story: Not so fun this time. Évalué à 6.
Il faut peut-être pas exagérer, avant SVN il n'y avait pas grand chose d'autre et SVN est quand même un très gros progrès par rapport à CVS en termes de facilité d'utilisation.
Il a vieilli assez vite après (malgré pas mal d'efforts pour incoroporer quelques bonnes idées de Git), mais c'est pas une raison.
[^] # Re: dev principal de Ladybird
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs. Évalué à 7.
Non pas comme un acte exécrable, mais comme quelque chose qui semble assez révélateur de la façon de penser de la personne qui a refusé ce patch en disant que utiliser des pronoms neutres, c'est avoir un agenda politique.
Rien de grave, certes, mais pour moi c'est un signal suffisant pour ne pas avoir envie de mettre les pieds dans le projet en question, ou en tout cas pour être sur mes gardes. C'est tout. Il peut continuer à penser ce qu'il veut et à gérer son projet comme il veut. Et j'ai le droit de penser que c'est pas le genre de personne avec qui j'ai envie de collaborer. Je crois que personne n'a rien demandé d'autre.
[^] # Re: débordements quand tu nous tiens
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs. Évalué à 1.
Il y a aussi le Frido, un livre avec une macro LaTeX pour genrer le lecteur ou la lectrice aléatoirement: https://linuxfr.org/news/des-nouvelles-du-frido
J'ai aussi vu she utilisé pour genrer l'utilisatrice dans certains documents en anglais mais je ne me souviens plus où.
[^] # Re: Pourquoi refaire un moteur de rendu ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Pour 100 briques t'as plus rien : le navigateur Ladybird reçoit un million de brouzoufs. Évalué à 10.
Éviter une monoculture avec un seul moteur de rendu pour tout l'internet, c'est une bonne raison. Tout comme on parle de biodiversité, la technodiversité est une bonne chose pour la résilience.
Si un projet est abandonné par ses auteurs, se retrouve dirigé par une entreprise qui mise tout sur l'IA et les cryptomonnaies, …, c'est pas mal d'avoir un plan B.
[^] # Re: Barrière d'entrée très haute pour être compétitif
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Changement de gouvernance pour le navigateur indépendant Ladybird . Évalué à 4.
Ce n'est pas parce que les implémentations actuelles sont lourdingues et compliquées que c'est devenu impossible de faire plus simple, à condition d'accepter un champ d'application un peu plus restreint.
[^] # Re: Tout le monde aime le Milkshake Duck
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Changement de gouvernance pour le navigateur indépendant Ladybird . Évalué à 10.
Quand on a une documentation qui référence l'utilisateur en utilisant le pronom "he", et que quelqu'un propose de le remplacer par un pronom neutre, selon l'usage en pratique depuis plusieurs centaines d'années en anglais, quand on refuse sous prétexte de "oulala on ne fait pas de politique ici", le message est clair: ce système s'adresse uniquement à des gens qui se genrent au masculin, les autres ne sont pas concernées, et c'est intentionnel et pas juste une mauvaise habitude grammaticale (ce qui peut arriver et serait tout à fait excusable).
[^] # Re: Quand aura lieu la prochaine freeze ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Debian 12.6. Évalué à 3.
les statistiques sur la durée du "freeze" sont listées sur la page "releases" de Debian: https://wiki.debian.org/DebianReleases
Pour les 2 dernières, cela a pris moins de temps (1 mois pour Bullseye, 3 mois pour Bookworm), mais l'équipe de Debian ne prend pas d'engagement à reproduire un cycle aussi rapide.
[^] # Re: Continuité?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Arrêt de la diffusion radio FM en Suisse. Évalué à 2. Dernière modification le 01 juillet 2024 à 23:04.
D'après https://www.generation-nt.com/reponses/svp-legislation-exacte-transmetteurs-fm-entraide-3187231.html c'est autorisé depuis 2008 en France.
[^] # Re: Continuité?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Arrêt de la diffusion radio FM en Suisse. Évalué à 5. Dernière modification le 28 juin 2024 à 11:23.
ça me semble peu efficace comme conversion, à première vue.
Sur les chaînes hi-fi des années 70-90, découpées en différents modules, on peut certainement remplacer le récepteur FM par un récepteur DAB.
Mais sur les systèmes tout-en-un, est-ce que c'est vraiment pertinent de recevoir du DAB, le décoder, le remoduler en FM, pour le renvoyer dans un autre récepteur? Autant directement recevoir le DAB et l'envoyer dans un amplificateur audio et un haut-parleur, non?
Il reste toujours l'option de tenter une modification d'un récepteur FM existant pour en retirer la partie démodulation radio, et y greffer un récepteur DAB, à la limite, pourquoi pas.
Ah oui, un cas particulier auquel je n'avais pas pensé: votre récepteur FM est intégré dans un véhicule automobile, il est peu pratique de remplacer tout le véhicule. Dans ce cas, oui, des convertisseurs existent, par exemple: https://radiofidelity.com/best-dab-car-radio-adapter/
[^] # Re: article de merde
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le BSOD pour Linux, ce sera dans le noyau 6.10. Enfin ;-). Évalué à 5.
Le but est surtout de rendre le message du kernel panic visible si on est dans une session graphique. Actuellement il est affiché uniquement si on est dans une console, ce qui est bien pour les serveurs et les systèmes embarqués, mais pour tout le reste, c'est quand même pas courant d'avoir un système en console.