Nous avons décidé de ne plus fournir de support officiel pour Windows.
Les utilisateurs de Duniter sous Windows restent libres de builder Duniter eux-mêmes à partir des sources, mais si vous êtes dans ce cas nous vous recommandons plutôt d’installer GNU/Linux sur la machine qui vous souhaitez dédier à Duniter.
De plus, nous ne garantirons plus la compatibilité des futures versions de Duniter avec Windows, donc peut-être que le build pour Windows depuis les sources deviendra impossible dans une future version.
Plusieurs raisons ont motivé ce choix :
Nous manquons de ressources humaines pour développer, maintenir et tester Duniter, nous souhaitons donc nous concentrer sur l’essentiel (réduire légèrement la voilure). Une release de moins a builder/tester/maintenir, c’est du temps et de l’énergie en plus que l’on peut consacrer au reste.
Cela va nous permettre d’oxyder progressivement Duniter afin de pouvoir lui apporter des améliorations substantielles sans avoir besoin d’attendre la v1 de Dunitrust. (Oxyder signifie migrer en Rust une partie du code).
Cela est plus en cohérence avec la philosophie du logiciel libre qui nous est très proche, consacrer du temps et de l’énergie pour livrer Duniter sur un système d’exploitation privateur n’est, au fond, pas très cohérent.
Cela sécurise davantage notre monnaie, car les systèmes d’exploitation libres sont plus sécurisés, le risque de pirater un nœud Duniter est donc plus faible.
Rien ne dit que ce choix est définitif, si un développeur très motivé est prêt à concevoir une VM Windows à jour pour permettre de continuer à livrer Duniter sous Windows après son oxydation partielle, nous étudierons alors la possibilité de revenir sur ce choix.
Pour les nœuds forgerons, bonne nouvelle, comme dit dans le point 4, ça sécurise notre monnaie.
Par contre, il reste intéressant d’avoir beaucoup de nœuds miroir, même s’ils sont sur des systèmes vulnéralbes, puisqu’ils ne forgent pas et contribuent malgré tout à la résilience, non ?
Mais je comprends bien sûr et j’approuve, c’est mieux de concentrer l’énergie des devs là où c’est le plus utile et cohérent !
Bon, et bien voilà, il y aura 5 noeuds en moins…
Perso, je n’ai pas la possibilité de dédier un Pc qui tourne sous Linux.
Je peux comprendre le manque de resources,et c’est bien dommage que je ne maîtrise pas, car je me serais associé aux développeurs.
Par contre ce choix dédie la participation au réseau Duniter a un seul type profil d’utilisateurs. Et c’est bien dommage.
Je vais donc désinstaller mon noeud
Le profil des forgerons se réduit comme le dit @MarcelDoppagne. Je comprend le manque de ressource, mais je déteste la ghettoïsation des devs qui s’installe.
La Monnaie Libre devait être « grand public » non ? Elle se recroqueville en abandonnant 80%, 90% (?) des utilisateurs de PC. Bien sûr tout les forgerons Windows sont les moins compétents techniquement, c’est pour cela qu’il était intéressant de les associer. Nœud en moins et démotivation donc.
Imposer un logiciel libre devrait être une recommandation et non pas imposé car la liberté alors s’éloigne.
Trop de forgerons qui ne sécurisent pas leur noeud, c’est plus dangereux qu’autre chose pour le réseau. Il y a un niveau technique minimum à avoir aujourd’hui pour ajouter un noeud au réseau sans l’affaiblir. C’est normal : on ne va pas demander à un lambda dans la rue de faire la sécurité de la banque, on passe par des gens formés et équipés pour ça.
@matograine Docker ne tourne que sous linux, les solutions qui permettent de faire tourner Docker sous windows font en réalité de la virtualisation, donc oui c’est possible, tout comme c’est possible avec les paquets debian. Dans les 2 cas ça passe par une VM linux.
Ça semble plus simple en apparence avec Docker car les solutions existantes gère la virtualisation à la place de l’utilisateur, mais techniquement c’est pareil.
Bon, pour info, j’arrive à compiler Duniter pour Windows. Je peux même synchroniser.
Je ne sais pas trop comment accueillir cette nouvelle (@elois qu’en penses-tu ?), en tout cas c’est possible moyennant plusieurs ajustements (à la marge tout de même).
Pour l’instant je vais pousser une branche windows qui je rebaserais régulièrement sur dev afin de la suivre.
C’est tout à fait normal, je n’ai jamais rien fait qui soit incompatible avec windows. Le problème technique c’était la VM windows que tu avais faite qui ne pouvais pas compiler Duniter car cargo exige une version de TLS suffisamment récente. Je t’avais alors demandé de mettre à jour cette VM, mais tu n’avais pas envie de le faire et j’avais essayé de regarder, mais je ne voyais pas comment faire.
Je n’ai toujours pas envie de gérer le build pour windows, mais je peux m’engager à continuer à faire des choix qui techniques qui permettent la portabilité comme je l’ai fait jusqu’à présent
EDIT: je parle de la variante desktop uniquement, pour la variante server (qui n’a jamais été fournie que sous linux), j’utilise des choses spécifiques aux systèmes unix.
EDIT2: pour que Duniter sous windows soit disponible aux utilisateurs, il faudrait quelqu’un qui prenne le rôle de mainteneur d’un livrable windows, ce rôle implique : créer le process de build, le tester, le documenter et le maintenir (l’adapter entre chaque version de Duniter pour qu’il reste fonctionnel).
Cela peut très bien être géré dans un dépôt git à part comme le fait @Moul pour le livrable pour yunohost
Je viens de pusher une branche feature/dev-on-windows qui permet à qui le souhaite de compiler Duniter sur Windows, basée sur la branche dev. Je la mettrai régulièrement à jour (rebase + push force).
Effectivement, j’ai désactivé 3 bouts de code spécifiques Unix :
La démonisation
Les signaux Unix
Le watcher de logs
Pour 1., en effet aucun besoin sur Windows. Pour 2. et 3., je ne comprends pas trop, quelle est l’utilité ?
Aussi, je ne connais pas encore bien Rust. Mais de la même façon que tu as désactivté GVA pour ARM, ne serait-il pas possible d’exclure le code Unix pour les plateformes Windows ? Plutôt que supprimer/commenter le code comme je l’ai fait.
@cgeek je ne comprends pas ce que tu veux faire. Est-ce que ton objectif est de builder la variante desktop pour windows (seule variante que l’on fournissait) ? Où de builder la variante server pour windows (chose que l’on a jamais faite il me semble) ?
Si ton objectif et de builder la variante desktop, alors tu n’as aucun code à commenter. La crate duniter-cli est spécifique à la variante server, que j’aimerai d’ailleurs renommer variante cli (pour command line interface) car la variante desktop contient aussi un server duniter.
Il te suffit de mettre à jour (ou refaire de zéro) un script de build pour windows dans le dossier release/arch/windows.
Quant à xtask, je l’ai créé pour les utilisateurs qui souhaitent compiler manuellement la variante server de Duniter, il n’est pas conçu pour la variante desktop, car j’ai considéré que les utilisateurs qui veulent compiler Duniter eux-mêmes n’utilisent pas la variante desktop.
Si ton objectif est de builder la variante server pour windows, alors oui on peut mettre en place tout ce qu’il faut en compilation conditionnelle, la aussi pas besoin de commenter quoi que ce soit. Mais perso j’ai pas envie de passer du temps pour fournir la variante server sous widows alors qu’on ne l’a jamais fournie avant et que ça me semble pas pertinent.
Je veux juste compiler la variante desktop pour Windows. C’est juste qu’aujourd’hui avec cargo xtask build ça ne fonctionne pas sans mes modifications pushées sur la branche susmentionnée.
Mais tu viens de m’expliquer, il suffit de créer une autre xtask. Compris
En fait, non, c’est un abus de langage. Je veux pouvoir compiler et utiliser Duniter sur Windows, qui y fonctionne en mode programme CLI à quelques limitations près (la démonisation, en gros).
Ensuite, je dois pouvoir builder le livrable desktop, basé sur ce programme. Mais ça c’est une autre étape.
Ou variante “nix” ?
Pour l’instant, duniter-cli semble surtout ajouter des fonctions spécifiques aux systèmes Unix par rapport au programme principal (duniter_js) : démonisation et surveillance de fichiers (de log). Il semble aussi y avoir d’autres choses étant donné l’utilisation de la ligne ci-dessous, mais je ne sais pas à quoi elle sert :
use nix::{errno::Errno, sys::signal::Signal, unistd::Pid, Error};
Du coup je vois deux pistes à moyen terme, quand le seul point d’entrée deviendra une crate :
soit avoir deux crates :
duniter-cli : programme principal Duniter, non spécifique à un système
duniter-nix : surcouche spécifique aux systèmes Unix, permettant la démonisation et autres spécificités
soit n’avoir qu’une crate (duniter-cli), et alors il va falloir choisir entre :
soit supporter aussi bien les systèmes Unix que Windows avec la compilation conditionnelle
soit la rendre spécifique Unix
Bien sûr si tu choisis l’option 2.2, builder une version desktop pour Windows devient impossible.
Pour l’instant, c’est bon, la branche dev compile mais de cette façon :
Ni l’un ni l’autre, ce que j’ai déjà prévu c’est d’avoir 2 crates principales différentes :
duniter-cli: point d’entrée de la variante server
duniter-desktop: point d’entrée de la variante desktop
Dans tous les cas, pour builder la variante desktop il n’y à pas besoin de compiler la crate duniter-cli, cette crate est spécifique à la variante server.
Pour builder desktop, la seule « base » dont tu es besoin est ce qui est produit par un npm ci. La crate duniter-cli ne fais pas partie de la base commune entre les 2 variantes.
