.NET en open source : Microsoft transfère Mono à WineHQ

.NET en open source : Microsoft transfère Mono à WineHQ

.NET en open source : Microsoft transfère Mono à WineHQ

Le projet Mono, framework open source destiné à la mise en œuvre de la plateforme de développement .NET de Microsoft dans des environnements autres que Windows, aurait-il trouvé son ultime refuge ? Microsoft, qui assurait la maintenance du projet depuis le rachat de Xamarin en 2016, vient d’annoncer son transfert à WineHQ, l’équipe en charge du développement de Wine.

« Nous tenons à souligner que le projet Mono a été la première implémentation de .NET sur Android, iOS, Linux et d’autres systèmes d’exploitation », salue Microsoft dans un message publié sur le site dédié, avant de rappeler que l’activité du projet s’est considérablement ralentie, victime indirecte de l’évolution des environnements de développement multiplateformes. La dernière version majeure remonte en effet à 2019, et Mono ne reçoit plus depuis que des correctifs, dont le dernier a été diffusé en février dernier.

Dans le cadre de ce transfert, WineHQ assure donc maintenant la responsabilité du projet, dont les sources sont disponibles sur son Gitlab, tandis que les dépôts et binaires historiques devraient quant à eux être archivés. Dans la mesure où WineHQ, comme Microsoft, exploitent déjà chacun leur propre fork, plus moderne, de Mono, l’intendance ne devrait revêtir qu’une portée symbolique.

Lancé en 2001 par Miguel de Icaza (par ailleurs créateur de GNOME), Mono a connu une histoire tumultueuse, sur fond de rachats successifs et de controverses liées à de potentielles atteintes aux droits de la propriété intellectuelle de Microsoft, bien avant que ce dernier ne prenne la décision d’ouvrir .NET à l’open source.  

Commentaires (36)


Ca par exemple !
Manquerait plus que @Flock et on se croirait dans une dimension parallèle :o

Sébastien Gavois

Manquerait plus que @Flock et on se croirait dans une dimension parallèle :o
Je déploie beaucoup d'efforts pour rester mesuré ! Ne m'encouragez point !! En parlant de @Flock je me demande bien qui avait pu dessiner cette PP de compétition qu'est la mienne ?

JulienJay

Je déploie beaucoup d'efforts pour rester mesuré ! Ne m'encouragez point !! En parlant de @Flock je me demande bien qui avait pu dessiner cette PP de compétition qu'est la mienne ?
D’ailleurs à propos de Flock, je te conseille de te tenir prêt demain, IL EST EN MEGA FORME

Sébastien Gavois

D’ailleurs à propos de Flock, je te conseille de te tenir prêt demain, IL EST EN MEGA FORME
Nous serons au rendez-vous!
J'ai hésité à rappeler que Mono jouait un rôle non négligeable dans la bataille menée par Microsoft autour de Silverlight puis je me suis dit que l'appeau à JJ serait trop évident ! :p

Alexandre Laurent

J'ai hésité à rappeler que Mono jouait un rôle non négligeable dans la bataille menée par Microsoft autour de Silverlight puis je me suis dit que l'appeau à JJ serait trop évident ! :p
Mon coeur saigne en pensant à Silverlight. Mais démarrer avec une actualité Mono/Xamarin j'avoue ne pas l'avoir vu venir!! C'est beau! Scott, si tu nous regardes!
Les développeurs dotnet sous Linux, comptez-vous: ... 0 ... 0 ... 0 ... toujours 0.
1 (et je ne compte pas mes collègues sinon je passe direct à plusieurs chiffres).
Modifié le 29/08/2024 à 17h58

Historique des modifications :

Posté le 29/08/2024 à 17h56


1

linux pas encore ici mais MAUI je l'utilise et c'est la forme actuelle de Xamarin. Je ne l'utilise pas pour le moment mais l'idée de faire du .net mvc / sqlserver sur linux me séduit bien... et surtout se passer de windows server c'est séduisant pour les clients...

cognitys

linux pas encore ici mais MAUI je l'utilise et c'est la forme actuelle de Xamarin. Je ne l'utilise pas pour le moment mais l'idée de faire du .net mvc / sqlserver sur linux me séduit bien... et surtout se passer de windows server c'est séduisant pour les clients...
encore en train de reflechir en maui, uno ou avalonian. Je suis pas sur que maui fase pas pschitt malgré le support de ms
C# n'est pas inexistant, ce n'est pas populaire dans les distributions.
Des applications multiplateformes sont portées sous linux comme l'émulateur Ryujinx.
Mono est fourni avec wine (wine-mono) tout comme wine-gecko pour remplacer les closedsource .net (< 5.0) et ie.
Microsoft avec Azure Linux doit l'utiliser.
Les dev dotnet legacy effectivement (version .Net Framework <= 4.8), il n'y en a pas des masses. Par contre dotnet core (ou .Net 5 et supérieur maintenant) oui

fdorin

Les dev dotnet legacy effectivement (version .Net Framework <= 4.8), il n'y en a pas des masses. Par contre dotnet core (ou .Net 5 et supérieur maintenant) oui
Le premier exemple qui m'est venu en tête est Keepass 2 qui est développé en .Net et tourne avec Mono (keepassxc, celui que j'utilise, est en C++ d'après GitHub par contre).

Mais c'est le cas aussi du logiciel de sauvegarde Duplicati.

SebGF

Le premier exemple qui m'est venu en tête est Keepass 2 qui est développé en .Net et tourne avec Mono (keepassxc, celui que j'utilise, est en C++ d'après GitHub par contre).

Mais c'est le cas aussi du logiciel de sauvegarde Duplicati.
duplicati vient de migrer sous .net core (en beta je pense, c'est relativement recent)

fdorin

Les dev dotnet legacy effectivement (version .Net Framework <= 4.8), il n'y en a pas des masses. Par contre dotnet core (ou .Net 5 et supérieur maintenant) oui
encore quelques vieux projets que je maintiens sous 4.x / mono sur Rpi, de mon coté :D

graveen

encore quelques vieux projets que je maintiens sous 4.x / mono sur Rpi, de mon coté :D
Mais je ne dis pas le contraire ;) Je dis juste que le Framework .Net étant bloqué en v4.8, il n'y à guère de raison de faire évoluer Mono (hormis la correction de bogue, sécurité ou les rares API encore manquantes).
Aeeuuuuuhhhhhh... En fait j'en ai déjà rencontré quelques brouettes dans le cadre de mon travail... entre autres tous ceux qui veulent passer leurs "microservices" dans kubernetes sans les redévelopper dans un vrai langage...

ragoutoutou

Aeeuuuuuhhhhhh... En fait j'en ai déjà rencontré quelques brouettes dans le cadre de mon travail... entre autres tous ceux qui veulent passer leurs "microservices" dans kubernetes sans les redévelopper dans un vrai langage...
Je vois pas de quoi tu parles. Un pod qui a besoin de la puissance du cluster complet pour démarrer, c'est pas le standard en matière de pratique IT ?

Comme containeriser une VM pour faire croire qu'une appli monolithique de l'enfer est subitement "cloud native" ?

SebGF

Je vois pas de quoi tu parles. Un pod qui a besoin de la puissance du cluster complet pour démarrer, c'est pas le standard en matière de pratique IT ?

Comme containeriser une VM pour faire croire qu'une appli monolithique de l'enfer est subitement "cloud native" ?
Je parle surtout de microservices en .Net dans des images .Net linux déployées comme pods dans kubernetes...

Au passage, un pod ne peut pas utiliser la puissance de calcul d'un cluster entier, un pod ne peut jamais excéder la capacité disponible du nœud sur lequel il tourne (dans un scénario où tu n'aurais pas toi-même mis des limites à la consommation de ressources du pod)

J'ai déjà eu un client avec ~200 microservices en .Net dans ce type de scénario.

La bonne pratique n'est pas de convertir des VM en pod, juste de déployer les applis dans des images dans un flux ci/cd. On ne gère pas des pods comme des VM et convertir des VM, même si c'est partiellement possible, en dit plus sur la qualité de l'architecture d'une entreprise qu'autre-chose.

ragoutoutou

Je parle surtout de microservices en .Net dans des images .Net linux déployées comme pods dans kubernetes...

Au passage, un pod ne peut pas utiliser la puissance de calcul d'un cluster entier, un pod ne peut jamais excéder la capacité disponible du nœud sur lequel il tourne (dans un scénario où tu n'aurais pas toi-même mis des limites à la consommation de ressources du pod)

J'ai déjà eu un client avec ~200 microservices en .Net dans ce type de scénario.

La bonne pratique n'est pas de convertir des VM en pod, juste de déployer les applis dans des images dans un flux ci/cd. On ne gère pas des pods comme des VM et convertir des VM, même si c'est partiellement possible, en dit plus sur la qualité de l'architecture d'une entreprise qu'autre-chose.
L'absurde et l'exagération de mon message devaient être trop subtil. :craint:

SebGF

L'absurde et l'exagération de mon message devaient être trop subtil. :craint:
Désolé, mais si tu voyais les demandes de certaines entreprises... ce que tu as-mis est largement en dessous des absurdités que j'ai pu rencontrer. Un cas par exemple: as-tu déjà vu des gens développer directement dans des containers sous Openshift tournant un émulateur de mainframe faisant tourner des applications Cobol ? Moi oui :eeek2:

ragoutoutou

Désolé, mais si tu voyais les demandes de certaines entreprises... ce que tu as-mis est largement en dessous des absurdités que j'ai pu rencontrer. Un cas par exemple: as-tu déjà vu des gens développer directement dans des containers sous Openshift tournant un émulateur de mainframe faisant tourner des applications Cobol ? Moi oui :eeek2:
Non ça va, j'ai juste eu droit aux 5 VM qui font tourner chacune un docker. Ou encore à l'appli balancée sur un kube et qui demandait 8GB de RAM pour démarrer.

Ou encore ceux qui disent "azy t'inquiète" en mettant leur BDD dessus et qui ont eu droit à une cellule de crise car ils avaient perdu toutes les données.

À trop prévenir que ça marchera pas, parfois je me dis qu'il vaut mieux les laisser expérimenter le skateboard dans l'escalier.

SebGF

Non ça va, j'ai juste eu droit aux 5 VM qui font tourner chacune un docker. Ou encore à l'appli balancée sur un kube et qui demandait 8GB de RAM pour démarrer.

Ou encore ceux qui disent "azy t'inquiète" en mettant leur BDD dessus et qui ont eu droit à une cellule de crise car ils avaient perdu toutes les données.

À trop prévenir que ça marchera pas, parfois je me dis qu'il vaut mieux les laisser expérimenter le skateboard dans l'escalier.
Ah oui, ceux là je les connais bien ces cas là... Mon préféré pour le stockage, c'est le scénario Openshift avec Openshift Data Foundation (du ceph) installé sur de l'Openstack avec volumes cinder sur ceph... parceque l'architecte "cloud" a dit que ... et pour chaque giga utilisé par une application, tu as à minima 9 gigas physiques utilisés grâce à une réplication 3*3... et tu met tout sur des blades HP anémiques de récup et sur du SAS parceque tu as claqué ton budget sur la partie logicielle... et ensuite arrive un projet qui a besoin de faire tourner une DB en HA DR, et là tu les laisse faire l'import des données de 2To et tu vas te faire un sandwich ... et par se faire un sandwich je ne parle pas juste de prendre un pain et de le garnir, ni même de pétrir la pâte à pain, de la laisser lever et avant de la cuire, mais de commencer l'exercice en semant les blés.
Modifié le 30/08/2024 à 17h35

Historique des modifications :

Posté le 30/08/2024 à 17h34


Ah oui, ceux là je les connais bien ces cas là... Mon préféré pour le stockage, c'est le scénario Openshift avec Openshift Data Foundation (du ceph) installé sur de l'Openstack avec volumes cinder sur ceph... parceque l'architecte "cloud" a dit que ... et pour chaque giga utilisé par une application, tu as à minima 9 gigas physiques utilisés grâce à une réplication 3*3... et tu met tout sur des blades HP anémiques et sur du SAS parceque tu as claqué ton budget sur la partie logicielle... et ensuite arrive un projet qui a besoin de faire tourner une DB en HA DR, et là tu les laisse faire l'import des données de 2To et tu vas te faire un sandwich ... et par se faire un sandwich je ne parle pas juste de prendre un pain et de le garnir, ni même de pétrir la pâte à pain, de la laisser lever et avant de la cuire, mais de commencer l'exercice en semant les blés.

1 (et en plus, je fais du powershell). par contre, dotnet core bien sûr, pas le vieux mono.

Wosgien

1 (et en plus, je fais du powershell). par contre, dotnet core bien sûr, pas le vieux mono.
Ils avaient pas prévu d'appeler .Net Core "Mono Nucléos", mais ont renoncé pour une raison marketing?
Modifié le 04/09/2024 à 17h11

Historique des modifications :

Posté le 04/09/2024 à 17h11


Ils avaient pas prévu d'appeler .Net Core "Mono Nucléos", mais ont renoncé pour une raison marketing.

y'a une erreur dans le titre. voici le vrai:
.NET en open source : Microsoft se débarrasse de Mono chez WineHQ

:cap:
C'est complètement ça ^^

Après, c'est loin d'être étonnant. .Net Core (ou .Net 5 et supérieur) est la seule version de .Net encore en développement. Et cette version est portable.

Le .Net framework (dont la version officielle était limité à Windows) s'est arrêté en 4.8 et il n'y aura pas d'autres versions.

Mono n'a donc guère d'intérêt à continuer aujourd'hui.

fdorin

C'est complètement ça ^^

Après, c'est loin d'être étonnant. .Net Core (ou .Net 5 et supérieur) est la seule version de .Net encore en développement. Et cette version est portable.

Le .Net framework (dont la version officielle était limité à Windows) s'est arrêté en 4.8 et il n'y aura pas d'autres versions.

Mono n'a donc guère d'intérêt à continuer aujourd'hui.
Comprends pas : perso, ça fait très, très longtemps que je mixe et masterise en stéréo, voire en 5.1 !

Le mono, même en Core, mais c'est d'un ringard !... :fumer: :phiphi:

DantonQ-Robespierre

Comprends pas : perso, ça fait très, très longtemps que je mixe et masterise en stéréo, voire en 5.1 !

Le mono, même en Core, mais c'est d'un ringard !... :fumer: :phiphi:
De toutes façons, les évolutions orientées objet sont là. Avec un cadriciel Atmos, par exemple, on peut porter facilement son environnement de 5.1 à 14.4 sans refactoring, il y a même une rétrocompatibilité en 2.0 et 2.1.
Mono et CoreCLR ont été fusionnés il y a des années, ce que Microsoft à transféré est l'ancienne version plus utilisée 🤷‍♀️🤷‍♀️🤷‍♀️
Non. Il n'y a pas eu de fusion entre Mono et CoreCLR.

Ce sont deux projets distincts, bien qu'ils présentent de nombreuses similarités. L'adoption de CoreCLR (qui est portable) comme implémentation de référence .Net par Microsoft a simplement rendu Mono "quasiment désué" (Mono était très utile par sa portabilité, devenue "inutile" avec CoreCLR car déjà présente).

fdorin

Non. Il n'y a pas eu de fusion entre Mono et CoreCLR.

Ce sont deux projets distincts, bien qu'ils présentent de nombreuses similarités. L'adoption de CoreCLR (qui est portable) comme implémentation de référence .Net par Microsoft a simplement rendu Mono "quasiment désué" (Mono était très utile par sa portabilité, devenue "inutile" avec CoreCLR car déjà présente).
Ce qui est déplorable avec .Net, c'est que Ms tenait un environnement correct et théoriquement portable (cf https://www.gnu.org/software/dotgnu/pnet.html).
Malheureusement ... ils l'ont cassé 3 fois minimum: dotnet 4, dotnet core, dotnet 6.
Soit carrément sur le format d'objet, soit sur la lib.

C'est carrément l'enfer si vous pensez que .net standard est utilisable dans les 2 mondes (core et framework): c'est vrai, du moment que vous ne faites pas de chargement à la volée. Car dans ce cas, vous allez mixer au pif des objets des 2 environnement d'exécution et les liens ne se feront pas...

Bref, c'est bien, les langages sont cool, les possibilités intéressantes, les outils déments, mais plein de promesses ne sont pas tout à fait tenues, on est loin de java "write once, run everywhere".

Sans compter qu'ils n'ont pas su le pousser assez pour aller vers du platform agnostic, notamment au moment de swindows phones.

fdorin

Non. Il n'y a pas eu de fusion entre Mono et CoreCLR.

Ce sont deux projets distincts, bien qu'ils présentent de nombreuses similarités. L'adoption de CoreCLR (qui est portable) comme implémentation de référence .Net par Microsoft a simplement rendu Mono "quasiment désué" (Mono était très utile par sa portabilité, devenue "inutile" avec CoreCLR car déjà présente).
Allons bon... Du coup, j'ai enlevé mon pouce en l'air à @teddyalbina, non mais !

(Faites pas gaffe, j'y pige que chique en programmation... Vous pourriez me dire que que Macron a été conçu en .NET par Brigitte, que ce serait du pareil au même...)
(Tout ça, juste pour avoir l'air d'exister... De plus en plus navrant... Désolé... :boulet: :troll: )
Modifié le 30/08/2024 à 20h39

Historique des modifications :

Posté le 30/08/2024 à 20h39


Allons bon... Du coup, j'ai enlevé mon pouce en l'air à @teddyalbina, non mais !

(Faites pas gaffe, j'y pige que chique en programmation... Vous pourriez me dire que que Macron a été conçu en .NET par Brigitte, que ce serait du pareil au même...)

(Tout ça, juste pour avoir l'air d'exister... De plus en plus navrant... Désolé... :boulet: :troll: )

ça manque d'un sous-titre comme "ils ont fini de c#per sur ce sujet"
joli
Fermer