Sushi aussi aime Tux

Dans le monde actuel, il est devenu important, pour trouver du travail, de posséder une adresse Email, d’avoir le PDF de son CV et de pouvoir accéder aux offres d’emploies sur Internet.
A une époque, j’allais tous les jours à l’ANPE pour utiliser leur PC et ainsi pouvoir avoir une chance dans ce contexte.

Pour d’autres, ça peut être très difficile d’accéder à ce genre de choses, car très coûteux.
Sans compter l’éducation et le divertissement des enfants: l’ordinateur est devenu indispensable.

Le 20 Juin, je me suis promené au grand salon Emmaüs à Porte de Versailles.
Il y avait bien sûr plein de meubles, livres, vêtements, etc. Mais il y avait aussi des ordinateurs, certes vieux, mais encore très utiles.

Certaines distributions Linux ont d’ailleurs fait le choix d’optimiser les performances et d’adopter des outils léger afin de convenir à du vieux matériel: tout le monde n’a pas la dernière machine dernier cris, et tous les geek ont déjà essayé de recycler leurs vielles machines en serveur Linux

Pour des distributions Desktop légères, on peut citer http://www.fluxbuntu.org/ et http://www.xubuntu.org/ , mais il en existe bien d’autres…

Même si ces versions sont dites “légères”, cela ne veut pas dire qu’elles sont dénuées de jeux! Linux n’est pas connu pour être la plateforme des gamers, mais on peut toutefois s’amuser avec.
Il y avait d’ailleurs une LAN avec rediffusion sur vidéo-projecteur au milieu du salon Emmaüs

Concernant l’éducation, la solution Skolelinux.fr était proposée comme alternative peu coûteuse, du serveur jusqu’au desktop. Là aussi, Linux veut pouvoir s’offrir à n’importe qui avec tous les outils nécessaires à la vie d’aujourd’hui.

Je ne peux que dire: Vive le logiciel libre!

Pas de conteneur d’application en .Net… ou presque

En fait, c’est suite à une frustration absolue datant du premier jour ou j’ai découvert .Net (car je faisais du Java, avant, dans mon temps libre…).
Après avoir lourdement digéré J2EE, les EJB, RMI/IIOP, j’ai été déçu de ne rien voir de tel en .Net.
Certains dirait que ce n’est pas une grosse perte En effet, J2EE n’a rien de simple, mais c’est quand même parfois puissant.

Je trouve stressant qu’une application .Net “d’entreprise” doit forcement dépendre des services Windows, des tâches schédulées, ou d’IIS. Déployer une application Java sur Tomcat est d’une simplicité déconcertante, et Microsoft propose un équivalent seulement dans le future Windows Server 2008 R2 avec Windows AppFabric.
Et encore, pour avoir vu la présentation aux Techdays, je suis plutôt déçu.

Gigaspaces? Un conteneur d’application malgré lui.

Ces derniers temps, de développe avec un DataGrid: Gigaspaces. Ce dernier est en Java, mais possède une API .Net. Je bénéficie alors de son infrastructure pour déployer facilement mes applications .Net.
En effet, ce dernier fonctionne sur le principe de “container” tournant sur plusieurs machines, sur lesquels on peut déployer X instance d’une application, appelé “Processing Unit”.
Comme Gigaspaces fournit une mémoire distribuée sur ces “containers” (c’est une peut l’objectif d’un DataGrid ), mes instances d’applications peuvent échanger des données via cette mémoire “partagée/distribuée”.

Gigaspaces fournie une notion de “Primary/Backup” ce qui permet de rendre une instance active/inactive en cas de crash.
Il est même possible d’activer des “moniteurs” pour rendre une instance inactive s’il n’y a plus assez de ressource (CPU/Mémoire/etc.) sur une machine, et activer une autre instance sur une autre machine. La répartition de la charge est donc super bien gérée, et presque transparente puisqu’on déploie un “zip” de notre application, et le service “Manager” se charge de l’installer sur les “containers”.

Mais voila, Gigaspaces c’est du lourd, du payant, et du Java.
Mon but est d’offrir quelque chose de similaire sans la performance de Gigaspaces ni sans la richesse de son API autour du cache.
Mon but est de pouvoir déployer une application Web, en uploadant un ZIP depuis une page d’administration, que cette dernière soit déployer sur X instances d’un coup, et qu’elles travaillent ensembles à l’aide d’un cache (Memcache et un très bon cache est suffisant pour mon besoin), d’une queue ou de service RPC.
Mon but est aussi de fournir un environnement d’exécution pure .Net, indépendant de l’OS, indépendant d’IIS/MSMQ/DCOM/etc, et donc compatible Mono/Linux.
C’est le “Write once, run anywhere” de Java, mais en .Net.

DotNetServer ou la quête du saint graal

J’ai donc commencé à voir comment héberger mes applications Web dans un container, à l’aide d’XSP…chose faite.
J’ai ensuite voulu calquer au modèle OSGI pour le “conteneur d’application”, avec séparation des applications par AppDomain, gestion de dépendance entre les applications, et cycle de vie de ces dernières.
Et enfin, j’ai cherché un moyen efficace de publier/souscrire à des services entre les applications.

J’ai passé ma journée à cherche un mécanisme de communication inter-AppDomain (ou inter-processus):

• PIPE/Mémoire partagée/Sémaphore: … je vais éviter de re-inventer la roue…
• .Net Remoting: la solution officiel de Microsoft pour une communication Inter-AppDomain, même s’ils disent que .Net Remoting est obsolète pour laisser place à WCF
• WCF avec le NAMED-PIPE: WCF n’existant pas sous Mono, je n’y pense même pas, surtout que c’est un peu une usine à gaz
• RMI/IIOP: pourquoi pas, mais c’est une solution plutôt distribuée (basé sur .Net Remoting).
• COM/DCOM: Solution Microsoft pure, étant même préconiser par Microsoft à la place de remoting (car plus de sécurité, transaction distribué, etc.). Mais pure Microsoft/Windows = pas pour moi
• XPCOM: en gros, dans la famille Corba, je veux le fils, celui qui n’est pas chez Microsoft. C’est peut-être une solution à envisager, mais Corba est abandonné dans le monde Linux pour du DBus
• DBus: protocole inventé pour une communication inter-processus sous Linux, pour remplacer l’ORB de Gnome ou DCop de KDE. C’est clairement un équivalant à COM, sans être un “Corba’like”, et c’est devenu standard sous Linux. De plus, une implémentation pure .Net existe.

Je me suis donc lancé sur DBus, tout comme J2EE à choisie RMI/IIOP… l’avenir me dira si j’ai fait le bon choix.

Bref, cela donne pas grand chose pour l’instant, mais voici le prototype:

On voit ici que j’ai démarré un “bundle” qui est une instance d’XSP, le serveur ASP.net (qui dans cet exemple héberge 2 applications Webs http://localhost:456/App1 et htpp://localhost:456/App2).

J’ai aussi démarré le bundle “MyAnotherBundle“, qui dépend de “MyBundle” qui dépend de “DBusBundle“.
Ces derniers se chagent car ils ne l’étaient pas encore.

• Le bundle DBus est simplement un démon DBus, qui offre un bus de message, un peut comme un broker dans Corba.
• Le bundle MyBundle va alors publier des services auprès de DBus.
• Le bundle MyAnotherBundle va alors consommer les services de MyBundle (il affiche le résultat de la fonction “sayHello” de MyBundle).

Comme je gère moi même les AppDomains, je configure leurs chemin de résolution de dépendance. Comme ça, chaque Bundle est installé dans un dossier, et n’a pas besoin de contenir TOUTES LES DLL qu’il a besoin, afin de ne pas les dupliquer entre les applications. Les DLL communes sont alors dans un dossier LIBS.

Conclusion

C’est loin d’être parfait et c’est un premier jet. Je ne sais pas si je vais avoir autant de motivation qu’aujourd’hui pour mener le projet à bien.
J’ai même découvert qu’un projet similaire existe: http://www.dotnetpowered.com/appserver.aspx mais il est mort depuis bien longtemps, et les sources sur le CSV ne sont plus disponible. Espérons qu’on n’en dise pas autant de mon projet dans plusieurs années
Mon projet est ambitieux, mais si ça vous plait de jeter un oeil aux sources, voir même contribuer, n’hésitez pas à faire votre branche des sources GIT: http://github.com/grozeille/DotNetServer
Le README explique un peut plus mes intentions, ou les schémas dans la doc, il faudrait maintenant que je rende ça plus attirant dans le Wiki de github (ainsi qu’un nom plus cool, comme le nom d’un animal?)

J’ai posé la question lors de la soirée ALT.Net en présence de Jean-Baptiste Evain, à savoir si on ne va pas se retrouver avec 2 standards : .Net et Mono.
ATTENTION, je ne parle pas des spécifications de la VM ou du langage C#, mais des assembly fournies en standard avec le SDK.

Pour comparer avec le monde Java, Sun établi des spécifications (JSR), et certifie une JDK car elle contient les “fonctionnalités” demandées. C’est indispensable pour le “Write once, Run anyware“.

Mais pour l’instant, Mono reste sur les traces de Microsoft, et il n’y a pas de volonté de standardisation commune, Microsoft faisant le standard de facto.

On dit même Mono être à la traine, car une application .Net ne marchera pas forcement sur Mono (à vérifier avec MoMA).
Mais on se rend déjà compte que seulement la 2ème mouture de Mono fournit son lot de nouveautés, et que l’inverse peut se produire (application Mono ne marchant pas « out of the box » sur la SDK de Microsoft).

• Que nous réserve la version 3 ?
• Mono va-t-il suivre un autre chemin (orienté jeux) ?
• Va-t-on assister à une compétition (positive) .NetDK vs MonoDK ?
• Pourra-t-on dire “je préfère l’implémentation de System.Collection.Generic.List de Mono, plutôt que celle de Microsoft” ?
• Les développeurs choisiront-ils la version Libre pour que leurs applications soit le plus compatible possible, et pour être multi-plateforme (comme développer des WebServices sans utiliser WCF n’existant pas encore sous Mono) ?
• Microsoft vont-ils intégrer le travail de Mono dans le .NetDK officiel ?

Un autre point : l’API de Linux est riche (oui oui!) et je trouve incroyable le nombre de binding Mono pour cette dernière :

• DBus : framework de communication inter-application orienté message
• GStreamer : framework multimedia
• Cairo : framework vectoriel 2D
• Telepathy : framework de chat (xmpp, sip, etc.)
• GTK : remplaçant des winforms ?
• etc.

Ils existent plusieurs applications Mono-Linux qui ne sont pas « portables » sous une autre plateforme, car trop liées aux API natives. Mais la communauté a la volonté de les faire porter sous Mac/Windows (Tomboy,  Banshee), et ça passe forcement par une migration de ces API natives.

Assiste-t-on à un Linux qui envahi notre Windows/Mac grâce à Mono ??

On peux se demander “oui, mais pourquoi faire?” et je ne trouve pas de réponse à la question. En effet, il arrive souvent qu’une application .Net possède du Legacy et donc des dépendances COM ou P/Invoke. Dans ce cas, on ne peut pas la migrer (pour tester si une migration est possible: http://www.mono-project.com/Moma)

Mais comme je suis exigent en terme d’interface, je n’aime pas avoir une application “alien” qui ne ressemble pas à mon environnement Linux (GTK/QT). Certes, il est prévu d’avoir un meilleur support du moteur de thème lors du prochain GSoC, donc wait and see.

Rappelons que les Winforms sont une sur-couche .Net de l’API WIN32. Cette dernière n’existant pas sous Linux et MacOS, j’en profite alors pour féliciter les équipes de Mono pour leur implémentation “from scratch”.

D’un autre coté, l’implémentation WPF chez Mono avance plutôt vite. D’ailleurs, la première release de Moonlight vient de sortir. Il n’y a pas de dépendance WIN32 dans ce cas, et je vois plus l’avenir des applications .Net dans ce sens. Mais l’approche WPF est d’avoir un thème propre à l’application, comme c’est le cas pour les sites Web, on obtient la même interface sous Linux et Windows (et MacOS). Mais finalement je trouve que ces interfaces ne s’intègrent à aucun des 3 environnements.

J’avais déjà rédigé un billet sur la guerre entre les technologies de “présentation” dans le domaine du Web (Ajax/Flash/etc.). Je ne vous l’apprend pas, le monde “Desktop” et “Web” convergent. L’idée est plutôt simple: aujourd’hui on doit exécuter un OS qui héberge des applications “Desktop”, et on doit exécuter un navigateur pour les applications Web. On obtient une certaines confusion entre la barre des tâches pour les application et les onglets pour les sites Web. Tout ceci est beaucoup mieux expliqué sur ce blog.

Mais de plus en plus, le navigateur ne sert qu’à exécuter un plugin (Silverlight/Flash/Java) qui lui charge l’application.
L’objectif est de lancer une application Web comme une application “Dekstop”, en exécutant le dis plugin en standalone, ou de passer par un “mini navigateur” (qui ne sert que pour le rendu HTML+Ajax, sans navigation etc). C’est en tout cas ce que propose Adobe Air ou Mozilla Prism.

Il va donc être difficile de distinguer une application “Desktop” ou “Web”. Ceci me fait un peu penser aux Widgets du Dashboard sous MacOS (ou autre plagia).

Au même titre que le Web se rapproche du Bureau, les applications “lourdes” copient les techniques du Web question apparence. Il y a des tentatives d’utilisation de CSS en Swing/SWT, mais l’exemple le plus flagrant est la description de l’interface à l’aide de XML comme dans XAML.

On obtient ainsi des applications “Desktop” ne copiant pas du tout le style standard de l’OS, mais ayant son propre thème telle un site Web.

Le résultat peut s’avérer très jolie, très ergonomique, mais très “inconsistant” avec les autres applications. Pourquoi devrais-je apprendre une nouvelle interface? Pourquoi ne pas utilise un standard? Pourquoi ne pas me laisser choisir mon thème dans l’OS plutôt que de me l’imposer pour une application donnée?

Personnellement, je ne suis pas fan de toutes ces interfaces différentes, et je ne suis pas le seul.
Pour revenir sur l’OS Linux, un grand effort est fourni pour rendre les interfaces homogènes. On peut par exemple citer le projet Portland allant dans cette direction. Je peux alors apprécier ces efforts puisqu’il m’est devenu difficile de distinguer une application QT dans mon environnement GTK (essayez Skype sous Linux pour vous en convaincre).

Je voulais aussi citer Redhat comme, à mon humble avis, les pionniers en matières d’homogénéisation avec leur thème Bluecurve identique sous KDE est Gnome. D’autre projets ont suivis dans le même genre comme Tango.

Enfin, les interfaces graphiques sont en pleines évolutions ces derniers temps, avec l’exploitation des cartes graphiques récentes, offrant des “eye candy” très alléchants. Le monde GTK est en pleine réflexion pour les futures versions, et les thèmes supportent de plus en plus d’effet.
Je préfère de loin cette approche ou l’OS propose un système de thème avancé (avec des techniques proches du CSS) et l’applique à toutes les applications, rendant le tout homogène. Néanmoins, je distinguerai toujours les applications type “Widget” qui ressemblent plus à de “mini-site” ou “application Web” qui elle ont une apparence propre à elles.

Comment seront les interfaces des OS du futures? Va-t-on vers un gros bordel graphique, ou une homogénéisation? WPF va-t-il percer sous Linux? Quels vont être les applications Winforms qui vont être migré sous Linux?

Après lecture de ce "Howto", on découvre qu'il existe plusieurs refonte de DukeNukem, dont la plus connue est la JFDuke.
Ces versions permettent de faire fonctionner DukeNukem en réseau, bénéficier d'OpenGL, et d’installer des mods.

Je vous ai déjà parler du mod "HRP" qui permet de faire marcher DukeNukem avec des résolutions allant jusqu'à 1280×1024 et avoir des models 3D (au lieu des sprits) pour les monstres, armes et éléments du décort.
Je vous conseil aussi le mod "SD_Duke" qui rajoute des giclés de sang et des gibs en 3D…
Ces mods sont compatible avec plusieurs versions de Duke, dont la JFDuke… et peux importe l'OS.

Malheureusement, la version Linux de Duke ne se télécharge pas (comme la version Mac d'ailleur). Donc j'ai télécharger les sources de JFDuke pour les compiler sous Linux afin de pouvoir y jouer, mais aussi de pouvoir bénéficier des mods.

Pour les plus "geek" d'entre vous, voici alors les binaires compilés pour Linux x86. Il y a sans doute des problèmes de sons (d'ailleur il est conseillé sur les forums de désactiver les sons d'ambiances) car cette version utilise la librairie FMod, et l'utilise pas forcement comme il faut… L'auteur ne corrige pas les bugs car il travail sur une nouvelle architecture (JFAud) basé sur OpenAL (donc patience pour le sons nickel sous linux).

Alors, bon jeux les penguins !

"[...]faire une application qui s'intégre bien dans Gnome, le tout réalisé dans l'élégant langage qu'est le Java [...] générer un exécutable natif sous linux [...] qui compile avec GCJ (de toutes façon, vous avez déjà vu Gnome sous Windows???).

C'est la mon erreur : je savais très bien que gnome existait sous Windows, mais je n'avais jamais vraiment essayé…
Alors voila chose faite ! Grâce à Cygwin + CyGnome.

Explication : Cygwin est un environnement linux sous windows (donc pas de kernel linux mais Bash, Gcc, Vi etc.. recompilé sous windows).

CyGnome c'est tout simplement Gnome recompilé en natif sous windows grâce à Cygwin. Bien évidement on bénéficie pas des avantages du noyau Linux et des nouveautés, mais j'ai enfin un explorateur (Nautilus) avec un thème GTK qui a de la gueule (et puis je peut utiliser mes commandes linux préféré comme GCJ pour recompiler mon appli sous Windows )

Bref, tout pour faire une application qui s'intégre bien dans Gnome, le tout réalisé dans l'élégant langage qu'est le Java , et tout en pouvant bénefficier du très puissant IDE Eclipse. Et puis le fin du fin, c'est de générer un exécutable natif sous linux à l'aide d'un script ANT qui compile avec GCJ (de toutes façon, vous avez déjà vu Gnome sous Windows???).

Alors, après une petite soiré de dev, j'ai réalisé un petit carnet d'adresse en Java compilé en natif :

Vous pouvez télécharger les sources ici et les binaires ici. 

Bien évidement, la question se pose pas mal dans la communauté : les futures applications Gnome… en C++, Java ou Mono ?

Bien évidement, ce n’est pas le seul lecteur RSS que j’ai testé, et il mérite un coup d’oeil :

• Thunderbird, en plus de lire les mails, on peut lire les RSS. Je l’utilise d’ailleur sous Windows.
• RSSOWL, vraiment bien fait. Réalisé en Eclipse RCP, cad en Java, donc existe aussi sous Windows.
• Blam, très simple, réalise en .Net sous linux, cad en mono
• Sage, extension pour Firefox, donc bien évidement, il existe aussi sous Windows.
• Straw, une autre application de lecture RSS pour Gnome
• Netvibes, c’est carrément un portail web, il existe donc sur toutes les plateformes, et est surtout disponnible depuis n’importe où !

Je voulais tester Cygnome en en faire mon shell par défaut sous windows…. je n’y arrive pas.

De même pour Xorg. La Warty d’Ubuntu est fournie avec XFree, mais je voulais tester les effets d’ombres et de transparences avec Xorg…. mais je dois m’armer de patience.

Bref, je passe à autre chose. Mes projets sont :

• continuer mes recherches sur lwjgl
• re-coder ma petite appli .Net à la WhereIsIt avec sérialisation XML (SOAP ?)
• re-coder mon projet de licence en .Net avec Maverick.

En ce qui concerne le serveur ASP.Net, je me suis amusé avec Apache2 couplé à Cassini (ou le serveur XPS de Mono) grâce à mod_proxyredirect ^^