Une API de Google qui décide si les gens sont gentils ou méchants
Les instances bloquées ont en moyenne 4 à 5% d'utilisateurs que l'API en question considère néfastes. On peut se dire que c'est pas beaucoup, mais ça fait une personne sur 25, et on peut aussi dire que la modération des instances en question est laxiste ou peu efficace pour d'autres raisons.
Donc, peut-être que ça bloque plus que ce dont on a l'habitude, mais est-ce une mauvaise chose?
Iris devrait compter quelques centaines de satellites placés sur plusieurs orbites, contrairement à Starlink
Rappelons que Starlink, c'est 3500 satellites sur un total de 14000 objets orbitant la Terre. Soit 20% à eux tout seuls. Et ils ont pas prévu de s'arrêter là…
Il faudrait savoir aussi si c'est de l'orbite basse ou de l'orbite moyenne, ça change un peu les choses pour la visibilité des satellites et les interférences sur les observations astronomiques.
On disait la même chose de Subversion avant l'arrivée de Git. Et il me semble que Git est largement perfectible, même si c'est un bon outil et qu'il a bien fait avancer les choses: il est compliqué à prendre en main et son utilisation ne convient pas forcément à tous les besoins ou pas de façon simple et efficace.
Le fait d'avoir une compatibilité avec les serveurs git est plutôt malin, ça va permettre une transition en douceur vers ce nouvel outil (comme git-svn a permis de passer de SVN à Git facilement).
C'est aussi, je crois, pas mal dans la philosophie de Mercurial qui est d'avoir un cœur simple et de nombreux plug-ins pour personnaliser le comportement. Ce qui est moins le cas pour Git.
L'histoire est en gros que des gens ont demandé l'ajout d'un code de conduite sur le projet, possiblement à l'époque ou il y avait du prosélytisme autour du code de conduite "contributor covenant".
L'équipe de SQLite a donc mis en place un code de conduite plus ou moins humoristique plutôt que de vraiment considérer le problème de l'inclusivité dans le projet et de la mise en place d'un moyen de remonter les éventuels problèmes de harcèlement et de discrimination.
Mais de toutes façons, les développeurs de SQLite n'acceptent pas vraiment les patchs externes, la raison avancée étant que c'est plus sûr de réécrire tout le code et les tests pour s'assurer que tout fonctionne bien, que de relire le code proposé par quelqu'un d'autre. Ce n'est donc pas un projet qui accueille beaucoup de nouveaux contributeurs.
C'est un message qui recommande de faire un mirroir de download.gnome.org, sous-entendu, ça va peut-être bientôt disparaìtre des internets.
Pas plus d'explications ici, mais il y a eu pas mal de gros changements d'infrastructure et de canaux de communication chez Gnome dernièrement (abandon des mailing lists et d'irc pour utiliser des technos web 2.0 à la place)
Le jpeg xl est un format compliqué dans lequel on peut embarquer des instructions exécutables (un peu comme des shaders?) pour faire le rendu de l'image de façon procédurale. La demoscene commence à l'utiliser pour des concours de sizecoding.
J'imagine que cela peut vite devenir compliqué d'un point de vue sécurité?
La GPL ne "fonctionne" que lors de la distribution du logiciel. Si on fournit à quelqu'un une copie du logiciel, alors cette copie doit contenir le code source, et le récepteur a le droit de modifier et redistribuer avec les mêmes conditions.
Pour un logiciel tournant sur un serveur comme Gitea, il n'y a pas de distribution vers les utilisateurs: le code reste sur le serveur. Donc tu ne peux pas demander l'accès au code source d'un site web que tu as simplement visité ou utilisé.
La license AGPL existe pour ce cas d'usage: elle permet à unsimple visiteur du site de demander l'accès aux sources.
Il y a plein d'autres cas ou la GPL n'oblige pas à tout rendre public. Par exemple dans plusieurs de mes projets pro on a utilisé Wireshark et développé plein de plugins sous license GPL. La conséquence est que on livre ces plugins à nos clients, avec les sources, sous license GPL. Pas qu'on doit les rendre publics ou les renvoyer aux développeurs de Wireshark.
(on a choisi, en accord avec nos clients, de contribuer à Wireshark certains plugins qui décodaient des protocoles standards ou normalisés, mais pas ceux implémentant des protocoles internes pour le projet)
Il n'y a pas de version de Rust pour QNX il me semble. Il y a donc deux options:
Si on est Google, on peut réécrire QNX en Rust et dire à tous ses clients d'utiliser ce nouveau système et d'abandonner toute leur expérience avec QNX et C ou C++,
Si on est pas Google, on peut choisir un autre langage de programmation, et dire à ses clients qu'on est d'accord pour porter une application vers l'OS qu'ils ont choisi.
Tout ce qu'on peut en conclure, c'est que Mender n'est pas Google.
Donc effectivement l'article est un genre de rétrospective?
Mais vraissemblablement il a suffi d'un (ou plusieurs) client prêt à payer assez cher pour avoir une version du client fonctionnant sur QNX ou un autre système embarqué où c'est compliqué de faire du Go pour convaincre Mender de changer d'avis. Ils n'avaient pas du tout imaginé ce cas de figure lors de l'écriture de l'article, je pense? En tout cas ce n'est pas listé dans les arguments pour ou contre dans la comparaison.
C'est rare que la réponse à "le logiciel est compliqué à maintenir" soit "il faut tout réécrire à partir de 0".
Le but de Wayland, dès le début, c'était de simplifier les choses en retirant des fonctionalités. Ce n'est finalement pas très surprenant que ça n'est pas très utilisé parce qu'il manque des fonctionalités.
Ça montre aussi l'une des difficultés de la façon de travailler dans "gnu/linux": le système est un assemblage de composants développés par différentes équipes ou personnes. Il est difficile dans ce contexte de faire des gros changements d'architecture qui mettent en jeu plusieurs de ces composants. Résultat: Wayland ne s'en sort qu'en mettant à disposition une couche de compatibilité avec X11, qui fait que les problèmes qu'il était sensé faire disparaître ("X11 c'est compliqué") sont en fait toujours là, mais avec une couche logicielle de plus.
Et le discours dans l'article va pasmal dans ce sens aussi: Wayland s'intègre mal dans les applications existantes. L'article dit que ça marche peut-être très bien pour les smart TV, pour avoir essayé d'aider un collègue sur un système embarqué utilisant Wayland, je n'en suis pas convaincu. On voulait faire un truc simple: placer deux fenêtres, une en haut et une en bas de l'écran (résolution fixe, on peut coder en dur la taille et position). Mon collègue m'a dit que ça ne semblait pas possible. Au début je ne l'ai pas cru. Pourtant il avait raison: pour faire ça, il faut développer son propre gestionnaire de fenêtres. On s'est arrangés pour se débarasser de Wayland dans ce projet…
Qu'est-ce qu'on entend par passerelle dans ce contexte?
Au sens xmpp, il existe un mécanisme qui permet à un serveur xmpp de se connecter comme un client à un autre réseau de messagerie. Pour ça il faut ouvrir une session par utilisateur du serveur, et le serveur doit connaître (et stocker en clair) les mots de passe des services auxquels il se connecte.
Ici l'idée semble plutôt d'avoir une connexion serveur à serveur, ce qui se fait naturellement aussi bien dans Matrix que dans XMPP, tous deux étant des protocoles fédérés. Cela peut rendre les choses transparentes entre les deux protocoles: les clients xmpp pourront se connecter à des salons Matrix, et inversement, les salons de discussion du serveur xmpp seront disponibles directement via le réseau Matrix.
Je ne pense pas qu'une passerelle externe permettrait ce niveau d'intégration dans les 2 directions?
Gemini est conçu pour faire que de la lecture seule globalement. On oublie dont les sites de vente en ligne, la réservation de billets de train, etc. ça fait donc moins bien que le Minitel.
Il peut trouver ses usages mais ça ne remplacera pas une grande majorité des usages du web.
des navigateurs qui restreignent l'utilisation de services non écologiques par défaut
Oui mais la question est, qu'est-ce qui est vraiment non-écologique dans une page web.
Comme le disent les commentaires au-dessus, c'est parfois contre-intuitif, et en plus c'est difficile à mesurer parce que ça implique du matériel un peu partout sur internet (le terminal qui lit la vidéo ou affiche la page, le serveur qui envoie les données, les routeurs au milieu). Et c'est pas sûr que ça fasse une différence massive parce que un équipement qui ne fait rien ne consomme pas forcément beaucoup plus qu'un équipement qui transmet un flux vidéo.
Donc c'est bien de vouloir rendre la "consommation" de la page visualisée, mais avant ça il faudrait pouvoir savoir ce qui consomme vraiment des ressources.
Oui la migration est déjà en cours pour les listes dont je suis responsable.
Depuis environ 1 an, il y a de nombreux problèmes de mails qui n'arrivent plus chez différents abonnés des listes hébergées chez free. Je suppose que Free a préféré abandonner le service plutôt que de passer plus de temps à essayer de régler le problème.
Le but du journal est surtout de prévenir si jamais vous avez de vielles archives de listes de diffusion à récupérer avant que le service soit coupé plus ou moins dans l'indifférence générale.
Je n'ai pas été clair apparemment, il y a confusion entre Caprice Forever (windows, toujours maintenu) et Caprice Reloaded (Linux et Windows, projet mort depuis 10 ans).
Ces deux projets sont tous les deux des forks de Caprice 32 mais à part ça, ils n'ont rien en commun.
Le lien dans votre message pointe sur une page qui s'appelle "Caprice Forever" et parle bien de Caprice Forever.
Euh il faut pas tout mélanger, Caprice Reloaded c'est un projet sur lequel j'ai pas mal travaillé (mais pas tout seul) et ça fonctionnait sous Linux (mieux que sous Windows). Le projet était un genre de "WinAPE, mais pour Linux".
Il y avait pas mal de problèmes dedans liés à l'utilisation de WxWidgets et WxFormsBuilder (il fallait utiliser une version patchée de ce dernier…) plus divers problèmes de fiabilité du coeur de l'émulateur malgré les efforts de Ramlaid qui en avait réécrit de gros morceaux. En particulier l'émulation du contrôleur de disquettes était assez mauvaise.
Le projet est abandonné depuis longtemps. Tout le code de Caprice 32 avait été réécrit en C++ ce qui a rendu compliqué la collaboration avec les nombreux autres forks de Caprice 32, dont Caprice Forever vers lequel ce lien pointe.
Le point le plus intéressant de Caprice Reloaded était d'avoir une interface graphique similaire à celle de WinAPE, avec un debugger, etc. Mais ça n'a jamais vraiment abouti.
Aujourd'hui le projet est abandonné, les efforts se concentrent sur ACE, avec la version Haiku pour ma part et du travail en cours mais pas fini et non diffusé pour une version Linux pour les deux autres développeurs qui avaient participé à Reloaded. Malheureusement ce n'est pas sous licence libre (par choix de l'auteur de ACE qui préfère garder ses secrets).
Amstrad avait prévu de pouvoir connecter un lecteur de disquettes mais ils (ou plutôt Locomotive Software qui s'occupait du logiciel) ont développé la ROM correspondante après la sortie de la machine. Ils avaient tout prévu pour le faire, avec un mécanisme générique pour ajouter des ROMs a posteriori, qui est utilisé encore aujourd'hui.
Par exemple on peut (avec du matériel de ma conception) connecter une carte microsd ou une clé USB et y accéder avec une ROM qui remplace l'AMSDOS en apportant de nombreuses fonctionalités supplémentaires (répertoires, gestion de différents supports de stockage, …).
Cela aurait été impossible si la gestion des disques avait été "en dur" dans la ROM interne.
De plus, la ROM AMSDOS peut se substituer complètement au BASIC, on obtient alors un CPC qui va démarrer directement sur une disquette pour lancer un logiciel CP/M. Cela a pu être utilisé dans des applications industrielles (pilotage de chaîne de montage) ou ainsi la machine peut démarrer directement avec le logiciel dédié.
C'est plutôt bien pensé tout ça. Et je doute que ça fasse des économies, cela a forcé à utiliser 2 ROMs (le système + l'AMSDOS) là ou ils auraient pu tout rentrer dans une seule.
Ce schéma non légendé n'est vraissemblablement pas conçu pour être sorti de son contexte: il est effectivement incompréhensible sans lire avant la page dont il est tiré qui fournit les données brutes.
Je tente une légende:
Une flèche a->b indique que la proposition 'a' a reçu plus de votes que 'b'. Le nombre indiqué est la différence de points entre les deux.
La proposition en bleu en haut du graphe a gagné sur toutes les autres.
Les propositions dans le schémas n'ont qu'une description courte, les détails sont dans les pages mises en lien.
Mais c'est effectivement quelque chose qu'on peut repprocher aux méthodes de vote Borda/Condorcet: pas de résultat sous forme d'un simple score en % pour chaque candidat et de classement final. Ce qui complique un tout petit peu l'interprétation des résultats au-delà de la simple détermination du gagnant. Mais il y a l'avantage qui va avec: on a un peu plus d'information à interpréter
À noter que le choix gagnant implique un changement du contrat social (SC pour « social contact ») donc il n'est pas exclu qu'il y ait encore des débats pour arriver au résultat attendu.
La proposition contient le changement précis qui doit être appliqué et a obtenu, si je lis bien les résultats détaillés, une majorité qualifiée suffisante (2/3 des votants).
Sur quoi peut-il y avoir encore débat? (vraie question, je ne connaît pas en détail l'organisation du projet Debian).
Il semblerait plutôt (vu la liste d'options de vote possibles d'une part, et le vote très en faveur de ce résultat d'autre part) que les débats ont déjà eu lieu et que ce vote n'était quasiment plus qu'une formalité pour valider la décision déjà prise après cette discussion.
Perso, je prends des cartouches, mais surtout parce que la cartouche me parait plus durable que la carte SD que je vais devoir acheter pour stocker les jeux de 20 gigas qu'on trouve.
ça m'étonnerait, aujourd'hui les jeux sur cartouches (je crois qu'il n'en reste que chez Nintendo?) utilisent de la mémoire flash qui n'a pas une meilleure durée de vie que celle utilisée dans les cartes SD.
La durée de vie de ce type de support est peut-être de 10 ou 20 ans, ensuite il est probable qu'on commence à voir des corruptions sur les cartouches et les cartes SD surtout si elles ne sont pas utilisées.
On est loin des durées de vie des "mask ROMs" utilisées quelques années auparavant qui peuvent conserver leurs données quelques dizaines d'années supplémentaires.
Les deux solutions qui marchent:
Compter sur soi-même pour avoir un plan de backup,
Faire confiance à une plateforme en ligne (Steam, Stadia, ou autre forme) pour gérer ça et pour pouvoir continuer de retélécharger ou d'accéder à ses jeux dans le futur.
Oui je voulais juste dire que ce n'est pas très cher dans les deux cas.
Bref, la licence sur le nom n'est pas le sujet du prix, le sujet est combien tu dois mettre au minimum sur la table pour fabriquer un CPU minimal en production. Je veux 1000 unités d'un CPU qui me fait 100 additions par secondes avec 4 KB de RAM (nombre au pif complet), combien ça me coûte en SPARC et combien en RISC V? Je ne connais pas les prix mais rien qu'à voir la différence de taille entre les intervenants SPARC et ceux RISC V, j'ai une idée que ce n'est pas la même ordre de grandeur au détriment de SPARC.
Probablement, le RISC-V a commencé par se développer sur le marché des microcontrôleurs sur lequel SPARC n'avait pas forcément mis les pieds. Je ne pense pas que ça serait impossible de le faire, mais c'était pas le marché ciblé.
Wikipedia me parle de GPL, d'où ma remarque sur la différence copyleft vs copyfree.
Il s'agir de la license de plusieurs implémentations de SPARC en VHDL, pas de la license de la spécification du jeu d'instructions et de l'architecture.
# Pendant ce temps en Russie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le TLD de la Grande-Bretagne (.gb) en cours de retrait. Évalué à 5.
Il est toujours possible d'acheter un domaine en .su (pour 'Soviet Union'): https://fr.wikipedia.org/wiki/.su
# Surbloquage?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Une étude sur la modération décentralisée (spoiler : surbloquage massif) . Évalué à 5.
Surbloquage par rapport à quoi?
Donc, peut-être que ça bloque plus que ce dont on a l'habitude, mais est-ce une mauvaise chose?
[^] # Re: RIP l'astronomie
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien L'UE lance Iris, une constellation de satellites pour sécuriser Internet - letemps.ch. Évalué à 4.
Comme indiqué dans l'article:
Rappelons que Starlink, c'est 3500 satellites sur un total de 14000 objets orbitant la Terre. Soit 20% à eux tout seuls. Et ils ont pas prévu de s'arrêter là…
Il faudrait savoir aussi si c'est de l'orbite basse ou de l'orbite moyenne, ça change un peu les choses pour la visibilité des satellites et les interférences sur les observations astronomiques.
# Message pour la modération
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien ZealOS, un fork de TempleOS. Évalué à 3.
étiquette "religions" https://linuxfr.org/tags/religions/public utilisée pour un seul contenu, à masquer et fusionner avec "religion"?
Merci.
[^] # Re: Résumé rapide
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Meta publie Sapling, un nouveau SCM dont le client est compatible avec git. Évalué à 3. Dernière modification le 17 novembre 2022 à 15:46.
On disait la même chose de Subversion avant l'arrivée de Git. Et il me semble que Git est largement perfectible, même si c'est un bon outil et qu'il a bien fait avancer les choses: il est compliqué à prendre en main et son utilisation ne convient pas forcément à tous les besoins ou pas de façon simple et efficace.
Le fait d'avoir une compatibilité avec les serveurs git est plutôt malin, ça va permettre une transition en douceur vers ce nouvel outil (comme git-svn a permis de passer de SVN à Git facilement).
C'est aussi, je crois, pas mal dans la philosophie de Mercurial qui est d'avoir un cœur simple et de nombreux plug-ins pour personnaliser le comportement. Ce qui est moins le cas pour Git.
[^] # Re: Pourquoi
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien DuckDB: une base de données embarquée pour ceux qui en ont mare de sqlite. Évalué à 3. Dernière modification le 17 novembre 2022 à 15:39.
L'histoire est en gros que des gens ont demandé l'ajout d'un code de conduite sur le projet, possiblement à l'époque ou il y avait du prosélytisme autour du code de conduite "contributor covenant".
L'équipe de SQLite a donc mis en place un code de conduite plus ou moins humoristique plutôt que de vraiment considérer le problème de l'inclusivité dans le projet et de la mise en place d'un moyen de remonter les éventuels problèmes de harcèlement et de discrimination.
Mais de toutes façons, les développeurs de SQLite n'acceptent pas vraiment les patchs externes, la raison avancée étant que c'est plus sûr de réécrire tout le code et les tests pour s'assurer que tout fonctionne bien, que de relire le code proposé par quelqu'un d'autre. Ce n'est donc pas un projet qui accueille beaucoup de nouveaux contributeurs.
[^] # Re: La ou les mathématiques ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Des nouvelles du Frido. Évalué à 3.
Il me semble qu'au lycée j'avais bien des cours de sciences physiques, au pluriel. Et des cours de sciences naturelles au pluriel aussi.
[^] # Re: pas compris
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Que se passe-t-il chez Gnome ?. Évalué à 5.
C'est un message qui recommande de faire un mirroir de download.gnome.org, sous-entendu, ça va peut-être bientôt disparaìtre des internets.
Pas plus d'explications ici, mais il y a eu pas mal de gros changements d'infrastructure et de canaux de communication chez Gnome dernièrement (abandon des mailing lists et d'irc pour utiliser des technos web 2.0 à la place)
# Format compliqué
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Vie et mort (?) de JPEG-XL. Évalué à 10.
Le jpeg xl est un format compliqué dans lequel on peut embarquer des instructions exécutables (un peu comme des shaders?) pour faire le rendu de l'image de façon procédurale. La demoscene commence à l'utiliser pour des concours de sizecoding.
J'imagine que cela peut vite devenir compliqué d'un point de vue sécurité?
[^] # Re: "decentralized autonomous organization" ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Open source sustainment and the future of Gitea . Évalué à 5.
La GPL ne "fonctionne" que lors de la distribution du logiciel. Si on fournit à quelqu'un une copie du logiciel, alors cette copie doit contenir le code source, et le récepteur a le droit de modifier et redistribuer avec les mêmes conditions.
Pour un logiciel tournant sur un serveur comme Gitea, il n'y a pas de distribution vers les utilisateurs: le code reste sur le serveur. Donc tu ne peux pas demander l'accès au code source d'un site web que tu as simplement visité ou utilisé.
La license AGPL existe pour ce cas d'usage: elle permet à unsimple visiteur du site de demander l'accès aux sources.
Il y a plein d'autres cas ou la GPL n'oblige pas à tout rendre public. Par exemple dans plusieurs de mes projets pro on a utilisé Wireshark et développé plein de plugins sous license GPL. La conséquence est que on livre ces plugins à nos clients, avec les sources, sous license GPL. Pas qu'on doit les rendre publics ou les renvoyer aux développeurs de Wireshark.
(on a choisi, en accord avec nos clients, de contribuer à Wireshark certains plugins qui décodaient des protocoles standards ou normalisés, mais pas ceux implémentant des protocoles internes pour le projet)
[^] # Re: Pourquoi pas Rust ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Mender abandonne le Go pour faire du C++. Évalué à 4.
Il n'y a pas de version de Rust pour QNX il me semble. Il y a donc deux options:
Tout ce qu'on peut en conclure, c'est que Mender n'est pas Google.
[^] # Re: Pas vraiment un abandon
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Mender abandonne le Go pour faire du C++. Évalué à 6.
Le client Mender était écrit en Go au moins depuis 2016 d'après https://github.com/mendersoftware/mender/commits/69da9a6a90c73fd218ad0d34addfc7617371c246/client.go?browsing_rename_history=true&new_path=client/client.go&original_branch=master
Donc effectivement l'article est un genre de rétrospective?
Mais vraissemblablement il a suffi d'un (ou plusieurs) client prêt à payer assez cher pour avoir une version du client fonctionnant sur QNX ou un autre système embarqué où c'est compliqué de faire du Go pour convaincre Mender de changer d'avis. Ils n'avaient pas du tout imaginé ce cas de figure lors de l'écriture de l'article, je pense? En tout cas ce n'est pas listé dans les arguments pour ou contre dans la comparaison.
# Message pour la modération
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Mender abandonne le Go pour faire du C++. Évalué à 4.
étiquettes à fusionner: go et golang
[^] # Re: développement interminable
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien "Wayland ne sauvera pas le bureau Linux", par un dev Wayland déçu. Évalué à 5.
C'est rare que la réponse à "le logiciel est compliqué à maintenir" soit "il faut tout réécrire à partir de 0".
Le but de Wayland, dès le début, c'était de simplifier les choses en retirant des fonctionalités. Ce n'est finalement pas très surprenant que ça n'est pas très utilisé parce qu'il manque des fonctionalités.
Ça montre aussi l'une des difficultés de la façon de travailler dans "gnu/linux": le système est un assemblage de composants développés par différentes équipes ou personnes. Il est difficile dans ce contexte de faire des gros changements d'architecture qui mettent en jeu plusieurs de ces composants. Résultat: Wayland ne s'en sort qu'en mettant à disposition une couche de compatibilité avec X11, qui fait que les problèmes qu'il était sensé faire disparaître ("X11 c'est compliqué") sont en fait toujours là, mais avec une couche logicielle de plus.
Et le discours dans l'article va pasmal dans ce sens aussi: Wayland s'intègre mal dans les applications existantes. L'article dit que ça marche peut-être très bien pour les smart TV, pour avoir essayé d'aider un collègue sur un système embarqué utilisant Wayland, je n'en suis pas convaincu. On voulait faire un truc simple: placer deux fenêtres, une en haut et une en bas de l'écran (résolution fixe, on peut coder en dur la taille et position). Mon collègue m'a dit que ça ne semblait pas possible. Au début je ne l'ai pas cru. Pourtant il avait raison: pour faire ça, il faut développer son propre gestionnaire de fenêtres. On s'est arrangés pour se débarasser de Wayland dans ce projet…
[^] # Re: implémenté sous forme d'une passerelle
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Le serveur XMPP ejabberd est maintenant aussi un serveur Matrix. Évalué à 7.
Qu'est-ce qu'on entend par passerelle dans ce contexte?
Au sens xmpp, il existe un mécanisme qui permet à un serveur xmpp de se connecter comme un client à un autre réseau de messagerie. Pour ça il faut ouvrir une session par utilisateur du serveur, et le serveur doit connaître (et stocker en clair) les mots de passe des services auxquels il se connecte.
Ici l'idée semble plutôt d'avoir une connexion serveur à serveur, ce qui se fait naturellement aussi bien dans Matrix que dans XMPP, tous deux étant des protocoles fédérés. Cela peut rendre les choses transparentes entre les deux protocoles: les clients xmpp pourront se connecter à des salons Matrix, et inversement, les salons de discussion du serveur xmpp seront disponibles directement via le réseau Matrix.
Je ne pense pas qu'une passerelle externe permettrait ce niveau d'intégration dans les 2 directions?
[^] # Re: Mauvais côté
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 8.
Gemini est conçu pour faire que de la lecture seule globalement. On oublie dont les sites de vente en ligne, la réservation de billets de train, etc. ça fait donc moins bien que le Minitel.
Il peut trouver ses usages mais ça ne remplacera pas une grande majorité des usages du web.
[^] # Re: En quoi c’est écologique ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Cahier d'idées pour un navigateur écologique. Évalué à 6.
Oui mais la question est, qu'est-ce qui est vraiment non-écologique dans une page web.
Comme le disent les commentaires au-dessus, c'est parfois contre-intuitif, et en plus c'est difficile à mesurer parce que ça implique du matériel un peu partout sur internet (le terminal qui lit la vidéo ou affiche la page, le serveur qui envoie les données, les routeurs au milieu). Et c'est pas sûr que ça fasse une différence massive parce que un équipement qui ne fait rien ne consomme pas forcément beaucoup plus qu'un équipement qui transmet un flux vidéo.
Donc c'est bien de vouloir rendre la "consommation" de la page visualisée, mais avant ça il faudrait pouvoir savoir ce qui consomme vraiment des ressources.
[^] # Re: Ne pas paniquer
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Fermeture du service de mailing list ml.free.fr. Évalué à 10.
Oui la migration est déjà en cours pour les listes dont je suis responsable.
Depuis environ 1 an, il y a de nombreux problèmes de mails qui n'arrivent plus chez différents abonnés des listes hébergées chez free. Je suppose que Free a préféré abandonner le service plutôt que de passer plus de temps à essayer de régler le problème.
Le but du journal est surtout de prévenir si jamais vous avez de vielles archives de listes de diffusion à récupérer avant que le service soit coupé plus ou moins dans l'indifférence générale.
[^] # Re: Bug ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Merci à l'auteur de xcpc!. Évalué à 6.
Je n'ai pas été clair apparemment, il y a confusion entre Caprice Forever (windows, toujours maintenu) et Caprice Reloaded (Linux et Windows, projet mort depuis 10 ans).
Ces deux projets sont tous les deux des forks de Caprice 32 mais à part ça, ils n'ont rien en commun.
Le lien dans votre message pointe sur une page qui s'appelle "Caprice Forever" et parle bien de Caprice Forever.
[^] # Re: Bug ?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Merci à l'auteur de xcpc!. Évalué à 7.
Euh il faut pas tout mélanger, Caprice Reloaded c'est un projet sur lequel j'ai pas mal travaillé (mais pas tout seul) et ça fonctionnait sous Linux (mieux que sous Windows). Le projet était un genre de "WinAPE, mais pour Linux".
Il y avait pas mal de problèmes dedans liés à l'utilisation de WxWidgets et WxFormsBuilder (il fallait utiliser une version patchée de ce dernier…) plus divers problèmes de fiabilité du coeur de l'émulateur malgré les efforts de Ramlaid qui en avait réécrit de gros morceaux. En particulier l'émulation du contrôleur de disquettes était assez mauvaise.
Le projet est abandonné depuis longtemps. Tout le code de Caprice 32 avait été réécrit en C++ ce qui a rendu compliqué la collaboration avec les nombreux autres forks de Caprice 32, dont Caprice Forever vers lequel ce lien pointe.
Le point le plus intéressant de Caprice Reloaded était d'avoir une interface graphique similaire à celle de WinAPE, avec un debugger, etc. Mais ça n'a jamais vraiment abouti.
Aujourd'hui le projet est abandonné, les efforts se concentrent sur ACE, avec la version Haiku pour ma part et du travail en cours mais pas fini et non diffusé pour une version Linux pour les deux autres développeurs qui avaient participé à Reloaded. Malheureusement ce n'est pas sous licence libre (par choix de l'auteur de ACE qui préfère garder ses secrets).
[^] # Re: Bah oui
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Merci à l'auteur de xcpc!. Évalué à 10.
Je vois pas le rapport avec les économies.
Amstrad avait prévu de pouvoir connecter un lecteur de disquettes mais ils (ou plutôt Locomotive Software qui s'occupait du logiciel) ont développé la ROM correspondante après la sortie de la machine. Ils avaient tout prévu pour le faire, avec un mécanisme générique pour ajouter des ROMs a posteriori, qui est utilisé encore aujourd'hui.
Par exemple on peut (avec du matériel de ma conception) connecter une carte microsd ou une clé USB et y accéder avec une ROM qui remplace l'AMSDOS en apportant de nombreuses fonctionalités supplémentaires (répertoires, gestion de différents supports de stockage, …).
Cela aurait été impossible si la gestion des disques avait été "en dur" dans la ROM interne.
De plus, la ROM AMSDOS peut se substituer complètement au BASIC, on obtient alors un CPC qui va démarrer directement sur une disquette pour lancer un logiciel CP/M. Cela a pu être utilisé dans des applications industrielles (pilotage de chaîne de montage) ou ainsi la machine peut démarrer directement avec le logiciel dédié.
C'est plutôt bien pensé tout ça. Et je doute que ça fasse des économies, cela a forcé à utiliser 2 ROMs (le système + l'AMSDOS) là ou ils auraient pu tout rentrer dans une seule.
[^] # Re: Détails de votes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Debian va inclure des binaires non-libres de firmwares dans ses images d'installation. Évalué à 4.
Ce schéma non légendé n'est vraissemblablement pas conçu pour être sorti de son contexte: il est effectivement incompréhensible sans lire avant la page dont il est tiré qui fournit les données brutes.
Je tente une légende:
Une flèche a->b indique que la proposition 'a' a reçu plus de votes que 'b'. Le nombre indiqué est la différence de points entre les deux.
La proposition en bleu en haut du graphe a gagné sur toutes les autres.
Les propositions dans le schémas n'ont qu'une description courte, les détails sont dans les pages mises en lien.
Mais c'est effectivement quelque chose qu'on peut repprocher aux méthodes de vote Borda/Condorcet: pas de résultat sous forme d'un simple score en % pour chaque candidat et de classement final. Ce qui complique un tout petit peu l'interprétation des résultats au-delà de la simple détermination du gagnant. Mais il y a l'avantage qui va avec: on a un peu plus d'information à interpréter
[^] # Re: Détails de votes
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Debian va inclure des binaires non-libres de firmwares dans ses images d'installation. Évalué à 3.
La proposition contient le changement précis qui doit être appliqué et a obtenu, si je lis bien les résultats détaillés, une majorité qualifiée suffisante (2/3 des votants).
Sur quoi peut-il y avoir encore débat? (vraie question, je ne connaît pas en détail l'organisation du projet Debian).
Il semblerait plutôt (vu la liste d'options de vote possibles d'une part, et le vote très en faveur de ce résultat d'autre part) que les débats ont déjà eu lieu et que ce vote n'était quasiment plus qu'une formalité pour valider la décision déjà prise après cette discussion.
[^] # Re: Jouer en streaming
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien Google ferme son service de jeu en streaming Stadia . Évalué à 5.
ça m'étonnerait, aujourd'hui les jeux sur cartouches (je crois qu'il n'en reste que chez Nintendo?) utilisent de la mémoire flash qui n'a pas une meilleure durée de vie que celle utilisée dans les cartes SD.
La durée de vie de ce type de support est peut-être de 10 ou 20 ans, ensuite il est probable qu'on commence à voir des corruptions sur les cartouches et les cartes SD surtout si elles ne sont pas utilisées.
On est loin des durées de vie des "mask ROMs" utilisées quelques années auparavant qui peuvent conserver leurs données quelques dizaines d'années supplémentaires.
Les deux solutions qui marchent:
[^] # Re: Le dernier clou dans le cercueil
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au lien RISC V pourrait permettre aux deux agences spatiales ESA et NASA et de travailler main dans la main. Évalué à 3.
Oui je voulais juste dire que ce n'est pas très cher dans les deux cas.
Probablement, le RISC-V a commencé par se développer sur le marché des microcontrôleurs sur lequel SPARC n'avait pas forcément mis les pieds. Je ne pense pas que ça serait impossible de le faire, mais c'était pas le marché ciblé.
Il s'agir de la license de plusieurs implémentations de SPARC en VHDL, pas de la license de la spécification du jeu d'instructions et de l'architecture.