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.
Le projet GNU ne dit pas que ces systèmes ne sont pas totalement libre. Il dit qu'il ne peut pas soutenir ces projets car ils aident à l'installation de firmware non libres sur ton OS. C'est totalement différent.
Je peux parler pour le cas de Haiku que je connaît bien.
L'installation par défaut de Haiku contient plusieurs logiciels qui ne sont pas libres. À l'époque ou la page de GNU a été écrite, cela comprenait par exemple:
Wonderbrush, un outil de dessin
liblayout, une bibliothèque pour faciliter la réalisation d'interfaces graphiques, utilisée par le lecteur PDF BePDF
Pour ces deux logiciels, nous avons l'autorisation des auteurs pour les inclure dans notre image d'installation et les préinstaller avec Haiku. Cependant, le code n'était absolument pas libre.
Entretemps, Wonderbrush a été re-licensé et le BePDF a été réécrit pour ne plus avoir besoin de la liblayout. Mais Haiku inclus toujours des firmwares wifi non libres (pas juste de l'aide pour les installer, ils sont inclus directement dans le DVD).
Non tu pars d'une interprétation que tu inventes.
Quelle autre définition peut-on prendre? Est-ce que le moindre bout de logiciel non libre inclus dans un système le rend propriétaire? Est-ce que propriétaire est synonyme de "non libre", ou est-ce qu'il y a des nuances entre les deux?
On peut conclure que pour Hare, l'inclusion de firmware wifi et/ou d'autres morceaux non libres dans un système ne semble pas poser problème et qu'ils considèrent que Haiku et FreeBSD ne sont pas des systèmes propriétaires d'après leur définition.
Mais ça ne répond toujours pas entièrement à la question. Qu'est-ce exactement qu'un système propriétaire?
Mon problème avec cette phrase sur le site web est que chaque mot est sujet à interprétation de la même façon:
Qu'est-ce que veut dire "Hare"? Est-ce que c'est le langage de programmation ou est-ce que c'est l'équipe qui le développe? Cela a des conséquences si une autre équipe voulait assurer le support pour des systèmes propriétaires tout de même, est-ce que l'équipe actuelle y serait franchement hostile, ou est-ce qu'ils soutiendraient l'initiative en étant bien content d'être déchargé de ce travail de support?
Qu'est-ce qu'un "système propriétaire"? J'ai tenté de donner une définition qui n'est bien évidement pas la bonne, mais personne n'a su en donner une autre.
Qu'est-ce que "supporter un système" pour un langage de programmation?
Donc, oui, j'essaie de surinterpréter cette phrase parce que, pour moi, elle n'est pas du tout claire et je ne sais pas quoi en penser. Finalement ça peut vouloir dire plein de choses différentes. Si je voulais utiliser Hare, j'aimerais juste savoir à quoi m'attendre.
je peux dire des bêtises la dessus mais RISC-V me semble plus accessible au commun des mortels et répond à des besoins plus spécialisés qu'un CPU généraliste pas cher comparé à faire pareil en libre.
Oui, ce n'est pas la question, c'est super que RISC-V propose une architecture mieux conçue et c'est super que ce soit libre.
Et il était tant de mettre SPARC à la retraite.
C'est juste que je ne vois pas en quoi RISC-V serait "la première architecture libre" dans ce cas (pourtant je vois cet argument répété partout). Je ne vois pas en quoi SPARC n'est pas une architecture libre.
Mais peut-être devrait-on en effet dire que RISC-V est le premier CPU copyfree. Ou le premier libre et utilisable sans trop de fric. Ou le premier libre et utilisable sans réacteur nucléaire. Ou le premier libre et multi-usage.
La license pour avoir le droit d'utiliser le nom "SPARC" coûte 99 dollars (prix inchangé depuis au moins 1997, en tout cas c'est ce que j'ai trouvé sur les versions archivées par archive.org de sparc.org). ça me semble plutôt raisonable.
L'adhésion à RISC-V à un niveau suffisant pour pouvoir faire une utilisation commerciale de la marque RISC-V, c'est 2000$ pour une entreprise créée il y a moins de 2 ans et avec moins de 10 employés, et 15000$ entre 500 et 5000 employés par exemple.
Donc c'est raté pour l'argument "sans trop de fric".
Dans les deux cas, les spécifications sont accessibles sur le site internet des fondations respectives. Celle de RISC-V est sous licence CC-BY, celle de SPARC, il n'y a pas l'air d'avoir d'infos de license (ou j'ai pas cherché au bon endroit). Est-ce que c'est ça qui fait la différence?
On peut re-citer la phrase qui est sur le site de Hare:
Hare does not, and will not, support any proprietary operating systems.
Je traduis:
Hare ne fournit pas et ne fournira pas de support pour aucun système propriétaire.
ça me semble quand même assez fort comme façon de dire les choses. On peut discuter de ce que ça veut vraiment dire:
Quelle est la définition choisie pour "système propriétaire"? Ce n'est pas celle du projet GNU puisque certains systèmes marqués "pas totalement libres" dans la liste du projet GNU sont tout de même listés dans ceux pour lesquels Hare prévoit de fournir du support. Je ne sais pas quelle autre définition utiliser. Donc je ne sais pas dire quel système pourrait recevoir du support ou pas dans le futur.
Qu'est-ce que "Hare" exactement dans cette phrase? Est-ce que c'est le langage de programmation? Ou est-ce que c'est l'équipe derrière le projet? Parce que effectivement ça donne une interprétation assez différente.
Alors, oui, j'ai pris l'interprétation la plus restrictive. Mais si on me demandait de choisir un langage pour écrire un logiciel, c'est comme ça que je m'y prendrais. Peut-être que je suis trop méfiant et prudent. Mais en tout cas ça ne me donne pas confiance.
D'autre part, chacun sa vision des choses, au moins c'est un choix assumé de militer ouvertement contre les "systèmes propriétaires", et on peut être d'accord ou pas. Mais j'aimerais quand même savoir comment ils décident si un système est propriétaire ou pas.
Je ne vois rien qui indique que les processeurs Elbrus sont compatibles SPARC. Il y a bien eu des CPU SPARC fabriqués par le MCST mais on dirait qu'ils sont passé à autre chose avec Elbrus.
[^] # 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.
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 4.
Je peux parler pour le cas de Haiku que je connaît bien.
L'installation par défaut de Haiku contient plusieurs logiciels qui ne sont pas libres. À l'époque ou la page de GNU a été écrite, cela comprenait par exemple:
Pour ces deux logiciels, nous avons l'autorisation des auteurs pour les inclure dans notre image d'installation et les préinstaller avec Haiku. Cependant, le code n'était absolument pas libre.
Entretemps, Wonderbrush a été re-licensé et le BePDF a été réécrit pour ne plus avoir besoin de la liblayout. Mais Haiku inclus toujours des firmwares wifi non libres (pas juste de l'aide pour les installer, ils sont inclus directement dans le DVD).
Quelle autre définition peut-on prendre? Est-ce que le moindre bout de logiciel non libre inclus dans un système le rend propriétaire? Est-ce que propriétaire est synonyme de "non libre", ou est-ce qu'il y a des nuances entre les deux?
On peut conclure que pour Hare, l'inclusion de firmware wifi et/ou d'autres morceaux non libres dans un système ne semble pas poser problème et qu'ils considèrent que Haiku et FreeBSD ne sont pas des systèmes propriétaires d'après leur définition.
Mais ça ne répond toujours pas entièrement à la question. Qu'est-ce exactement qu'un système propriétaire?
Mon problème avec cette phrase sur le site web est que chaque mot est sujet à interprétation de la même façon:
Donc, oui, j'essaie de surinterpréter cette phrase parce que, pour moi, elle n'est pas du tout claire et je ne sais pas quoi en penser. Finalement ça peut vouloir dire plein de choses différentes. Si je voulais utiliser Hare, j'aimerais juste savoir à quoi m'attendre.
[^] # 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é à 4.
Oui, ce n'est pas la question, c'est super que RISC-V propose une architecture mieux conçue et c'est super que ce soit libre.
Et il était tant de mettre SPARC à la retraite.
C'est juste que je ne vois pas en quoi RISC-V serait "la première architecture libre" dans ce cas (pourtant je vois cet argument répété partout). Je ne vois pas en quoi SPARC n'est pas une architecture libre.
La license pour avoir le droit d'utiliser le nom "SPARC" coûte 99 dollars (prix inchangé depuis au moins 1997, en tout cas c'est ce que j'ai trouvé sur les versions archivées par archive.org de sparc.org). ça me semble plutôt raisonable.
L'adhésion à RISC-V à un niveau suffisant pour pouvoir faire une utilisation commerciale de la marque RISC-V, c'est 2000$ pour une entreprise créée il y a moins de 2 ans et avec moins de 10 employés, et 15000$ entre 500 et 5000 employés par exemple.
Donc c'est raté pour l'argument "sans trop de fric".
Dans les deux cas, les spécifications sont accessibles sur le site internet des fondations respectives. Celle de RISC-V est sous licence CC-BY, celle de SPARC, il n'y a pas l'air d'avoir d'infos de license (ou j'ai pas cherché au bon endroit). Est-ce que c'est ça qui fait la différence?
[^] # Re: Et hare, alors?
Posté par pulkomandy (site web personnel, Mastodon) . En réponse au journal Ces langages avec lesquels il faut tout réécrire. Évalué à 2.
On peut re-citer la phrase qui est sur le site de Hare:
Je traduis:
ça me semble quand même assez fort comme façon de dire les choses. On peut discuter de ce que ça veut vraiment dire:
Quelle est la définition choisie pour "système propriétaire"? Ce n'est pas celle du projet GNU puisque certains systèmes marqués "pas totalement libres" dans la liste du projet GNU sont tout de même listés dans ceux pour lesquels Hare prévoit de fournir du support. Je ne sais pas quelle autre définition utiliser. Donc je ne sais pas dire quel système pourrait recevoir du support ou pas dans le futur.
Qu'est-ce que "Hare" exactement dans cette phrase? Est-ce que c'est le langage de programmation? Ou est-ce que c'est l'équipe derrière le projet? Parce que effectivement ça donne une interprétation assez différente.
Alors, oui, j'ai pris l'interprétation la plus restrictive. Mais si on me demandait de choisir un langage pour écrire un logiciel, c'est comme ça que je m'y prendrais. Peut-être que je suis trop méfiant et prudent. Mais en tout cas ça ne me donne pas confiance.
D'autre part, chacun sa vision des choses, au moins c'est un choix assumé de militer ouvertement contre les "systèmes propriétaires", et on peut être d'accord ou pas. Mais j'aimerais quand même savoir comment ils décident si un système est propriétaire ou pas.
[^] # 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.
Je ne vois rien qui indique que les processeurs Elbrus sont compatibles SPARC. Il y a bien eu des CPU SPARC fabriqués par le MCST mais on dirait qu'ils sont passé à autre chose avec Elbrus.
En regardant un résumé du jeu d'instruction ça ressemble vaguement à du SPARC mais ce n'est pas compatible.