|
|
|
|
|
| ..:: Dossiers » Dossiers archivés » Dossiers 2007 » Septembre 2007
::..
|
|
|
page 1page 2page 3page 4page 5page 6
Mac en entreprise
MAC-PC : MARIONS-LES !
Par Loïc Duval - Copyright L'Informaticien, tous droits réservés
L’intégration des Mac dans les infrastructures
Intégrer des postes et des serveurs Mac dans un système d’information est non seulement possible mais simple. Encore faut-il que les administrateurs s’y investissent…
Présenté depuis ses origines comme l’ennemi juré du PC, le Mac traîne derrière lui une lourde image d’incompatibilité génétique avec les environnements Windows. Si cette image n’a pas varié dans l’opinion publique (et si les fans d’un environnement y reste toujours aussi fidèle quels que soient les arguments de l’autre camp), les choses se sont assouplies dans la réalité au fil des années. À dire vrai, rien n’empêche désormais, l’entrée des Mac dans les systèmes d’informations Windows. L’inverse est même largement envisageable : les X-Serveurs d’Apple peuvent servir d’épine dorsale d’un SI principalement Mac dans lequel les PC ont également leur place.
Mais bien plus que les difficultés techniques ou organisationnelles se sont davantage des freins psychologiques qui interdisent l’entrée des Mac dans les réseaux Windows ou l’entrée des PC dans les réseaux Mac. Des freins psychologiques en partie savamment orchestrés par Apple et Microsoft, les deux éditeurs qui, sous des faux semblants d’ouverture, donnent systématiquement la priorité à leur bastion et ne vont vers l’autre qu’à contre-cœur pour ne pas dire à reculons (sans même évoquer les campagnes de pubs caricaturales d’Apple).
Grâce aux Macintosh Services de Windows Server, un administrateur peut spécifier lors d’un partage de dossier si celui-ci sera ou non accessible par les Mac.
Scénarios envisageables
En matiere d’intégration Mac-PC au sein d’un même réseau, voyons un peu les différents scénarios envisageables :
Dans sa forme la plus simple, le réseau point à point d'une TPE peut être constitué d'un ensemble de Mac et PC. Dans une telle configuration, les dossiers partagés entre Mac et PC seront de préférence placés sur les Mac sous OS-X.
Une TPE disposant essentiellement de Mac peut envisager une amélioration de son architecture informatique par l'adjonction d'un serveur. Dans ce cas, l'adoption d'un serveur X-Serve prend tout son sens. Et les dossiers partagés seront placés sur le serveur Apple qui apparaîtra aux PC comme un serveur Windows, directement accessible du voisinage réseau. Il est cependant recommandé d'utiliser la dernière édition de Mac OS-X « Tiger » Server qui résout différents problèmes de compatibilités des précédentes moutures et offrent à travers son Workgroup Manager un outil convivial pour administrer les ressources partagées, définir les quotas disque, gérer les comptes utilisateurs.
Dans une forme plus traditionnelle, on adoptera en général une architecture informatique dans laquelle les Mac s'insèrent dans un réseau PC régit par un Windows Server 2000 ou 2003. Les ressources partagées sont alors situées sur le ou les serveurs Windows. La mise en œuvre est en théorie assez triviale. Il suffit simplement d’installer les « Services for Macintosh » sur le serveur Windows, services livrés en standard avec Windows Server (mais non installés par défaut). En pratique, les choses sont légèrement plus complexes et dépendent notamment des versions de Mac OS et Mac OS X présentes sur le réseau et, par voie de conséquences, des protocoles utilisés. Ainsi, la présence de Mac OS tend à maintenir l’usage du vieux protocole non routable AppleTalk et la présence de Mac OS X nécessite la désactivation du « SMB Signing » dans les politiques de groupe du serveur Windows, une option évidemment plus acceptable sur des petits réseaux que sur des réseaux plus imposants et mieux sécurisés.
Dernière architecture envisageable, un panachage de clients Mac et PC dans un système d’information basé à la fois sur des serveurs Apple et Windows. L’introduction de X-Servers dans un système d’information essentiellement Windows est en effet bien plus envisageable depuis l’apparition de Mac OS X Tiger Server. Mac OS X Server peut être configuré pour accéder aux informations de l’Active Directory sans modification des schémas AD. Et le serveur d’Apple accepte sans broncher l’authentification Kerberos.
Les « Services for Macintosh » de Windows Server ne sont pas installés par défaut. Il suffit de les cocher dans l’utilitaire
d’ajouts de composants Windows.
Principes d’administration
Côté technique, on le voit, l’intégration des Mac dans les Systèmes d’Information Windows est totalement réalisable. D’une part Windows Server est livré en standard avec les services nécessaires, et d’autre part Mac OS X Server possède un ensemble de « services Windows » évolué permettant une intégration Active Directory totale (Mac OS X s’appuyant sur OpenLDAP) allant jusqu’au support des ACL.
C’est davantage du côté de l’administration quotidienne que les problèmes d’intégration du système se font sentir. Les administrateurs non habitués aux Mac et sans expérience Unix, se retrouveront en terre inconnue et devront acquérir un minimum de compétences sur Mac OS X. Toutefois, l’interface utilisateur du Mac, unanimement reconnue pour sa convivialité, facilite en général l’approche du système. Il faudra probablement aux administrateurs intervenir sur les fichiers Hosts (ce qui sous Mac s’effectue via la console Terminal avec une édition dans la pure tradition Unix), notamment pour résoudre certains problèmes de certificats liés à Exchange Server, par exemple. En outre, les administrateurs Windows devront apprendre certaines différences comportementales subtiles entre Mac OS et Windows pour ne pas créer de catastrophes sur les postes (par exemple, la copie destructrice de répertoires du Mac contrairement à Windows). L’administration des postes Mac demandent également à la longue d’apprendre les causes de ralentissement du système Mac OS X, de maîtriser certains paramètres et optimisations, d’adopter les mécanismes de déploiement par images (qui existent également sur Mac, même si ceux-ci ne sont pas aussi évolués que les méthodologies développées par Microsoft avec Vista), d’imaginer des procédures de sauvegardes mixtes et de s’équiper d’outils de récupération de fichiers effacés, de disques endommagés, de gestion de configuration (à l’instar du freeware Sharepoints pour l’édition de la configuration de Samba).
Pour ces administrateurs, deux sites Web seront d’un précieux secours dans l’acquisition des compétences :
• www.MacWindows.com est la source principale de solutions à tous les problèmes de connexion et d’interopérabilité entre Mac et PC.
• www.labo-apple.org est un site francophone, lié à l’école Supinfo, qui comporte également de nombreuses informations pratiques sur l’administration des environnements Apple, les problématiques d’accès VPN, etc.
Un outil à considérer
D’une manière générale, on préfère ne pas avoir à installer de clients particuliers sur les postes Mac pour accéder aux serveurs Windows. Ceci impose cependant de ne pas utiliser la signature numérique des communications – plus exactement des paquets SMB. Or, celle-ci est désormais activée par défaut sur Windows Server 2003 (et ses dérivées, comme SBS). Un problème qui n’affecte d’ailleurs pas que les Mac, mais aussi les machines Windows 95/98. Sur les réseaux hautement sécurisés, la désactivation de cette signature des communications peut s’avérer une brèche inacceptable. La solution la plus simple et la plus efficace consiste alors à installer sur les Mac le petit client Dave 6 de Thursby. En outre, Dave supporte DFS (Distributed File System) ce qui n’est pas le cas Mac OS X en natif. Thursby propose un autre produit similaire mais améliorant les fonctionnalités d’administration des Mac : AdmitMac.
|
L’intégration des Mac dans les processus de l’entreprise
Insérer des Mac et des PC sur un même réseau n’a d’intérêt que si l’entreprise exploite le potentiel de chaque environnement au sein de processus communs et si les données peuvent s’échanger librement entre les environnements.
Office 2008 est attendu en septembre. Cette nouvelle édition Mac
de la suite Office apporte nombre d’améliorations créées pour Office 2007 sur PC et offre au Mac la compatibilité OpenXML
Si l’intégration des deux plates-formes Mac OS et Windows dans un même réseau est une chose, leur intégration au sein d’un même processus d’entreprise en est une autre. Certes, chaque plates-forme a ses atouts, ses applications de prédilection, et ses utilisateurs. Mais on amène difficilement un utilisateur formé au Mac à migrer sur PC, l’inverse étant tout aussi vrai. Toutefois, l’arrivée de Vista au prix fort (tout au moins pour les petites entreprises et les individus, les grosses entreprises n’étant pas touchées par les évolutions tarifaires du système via les programmes Entreprise et Select), la généralisation des processeurs Intel sur les Mac, la sophistication des solutions de virtualisation sont autant d’éléments à même de favoriser un éventuel passage de certains profils du PC vers le Mac. Mais pour qu’un tel passage soit possible, encore faut-il que les Mac puissent s’insérer dans les processus métier et accéder aux applications de l’entreprise.
Graphisme et PAO
On le sait, les machines d’Apple restent l’outil privilégié des métiers de l’édition, de la communication, de la pub et du graphisme. Mais, aujourd’hui, la frontière entre les deux plates-formes est de plus en plus ténue. Il y a belle lurette que les différents formats graphiques sont lus et édités par les deux environnements Mac et Windows. Chez Adobe, les différences entre les applications Mac et PC sont essentiellement cosmétiques. Certes la PAO a connu davantage de déboires en matière d’échanges entre les deux plates-formes. Avec InDesign et Xpress 7 toutefois, ces soucis n’existent plus vraiment ; seul subsiste le problème, certes essentiel, des polices. On continue de trouver au sein des entreprises nombre de polices uniquement disponibles sur l’un des environnements et pas sur l’autre. Cependant, ces problèmes peuvent facilement trouver des solutions en utilisant les formats compatibles avec les deux environnements. En outre, la généralisation du PDF « Haute Définition » tend à rendre agnostique vis-à-vis des plates-formes la production des documents.
Bureautique et Collaboration
En revanche, les problématiques de bureautique et de travail collaboratif sont plus complexes à appréhender. Évidemment, Microsoft Office est disponible sur Mac et PC. Mais les deux versions sont décalées dans le temps et les versions Mac ne sont pas totalement similaires aux versions PC. En outre, les formats de fichiers ont longtemps posé problème et continuent même d’en poser. En effet, les formats OpenXML de la suite 2007 ne sont pas encore disponibles (ils sont en version bêta) sous forme d’extensions pour la suite Office 2004, alors qu’ils le sont pour les éditions XP, 2000 et 2003 d’Office sur PC. La version 2008 d’Office Mac attendue en septembre devrait venir gommer l’essentiel des différences entre les éditions Mac OS et Windows et proposera le support natif du format OpenXML, l’adoption des technologies SmartArt (introduites par Office 2007) et des galeries inspirées de l’interface Ribbon d’Office 2007 sous Windows.
La situation n’est guère meilleure du côté de l’Open Source et d’OpenOffice.org. Longtemps annulée, la version « Aqua » d’OpenOffice devrait au final vraiment voir le jour depuis que Sun a dédié des ressources à ce portage. Jusqu’à aujourd’hui, OpenOffice sous Mac OS X ne fonctionnait que sous X11 et se montrait bien mal intégré à l’esprit et à l’environnement d’Apple.
Côté collaboratif les Mac se connectent sans difficulté à un serveur Exchange. Un simple client comme Apple Mail suffit. Mais, afin de bénéficier des fonctionnalités organisationnelles de la messagerie de Microsoft, on préfèrera employer le client Entourage (présent dans Office Mac) même si ce dernier n’a pas tout à fait les mêmes fonctions qu’Outlook sur PC, ni les mêmes capacités d’extensions et de programmation. Une autre alternative consiste à employer Outlook Web Access, mais les utilisateurs sont généralement plus séduits par la convivialité d’une application native comme Entourage que par celle d’une application Web.
Évidemment, toute entreprise ayant bâti son travail collaboratif autour d’Office System 2007, et notamment autour de Sharepoint 2007 et des serveurs Office, n’aura aucun souci pour intégrer les Mac à ses processus. Suivi de projets, échanges, partages se font en effet au travers d’un simple navigateur Web ou directement à partir des applications Office 2007(PC)/2008(Mac). Certes, question navigateur, l’expérience Sharepoint 2007 varie quelque peu entre PC et Mac. Les éditions « en ligne » de documents se montrent plus riches et plus conviviales sous Internet Explorer que sous Safari par exemple. Mais l’essentiel de l’expérience Sharepoint au quotidien demeure très similaire quel que soit le navigateur utilisé. Il est toutefois préférable d’utiliser Firefox 2 pour Mac plutôt que Safari, afin de bénéficier d’une expérience aussi proche que possible de celle sur PC.
Toujours dans la lignée des composantes de la suite Office System, Microsoft devrait lancer à la fin de l’année la nouvelle version de Live Communication Server 2007. Celle-ci devrait bénéficier d’un client Mac OS X, permettant ainsi de réaliser des échanges, des conférences et des réunions à distance que les collaborateurs soient équipés de Mac ou de PC.
Pidgin est un client PC idéal pour exploiter les services collaboratifs de Mac OS X Server.
Services et applications
Quoi qu’il en soit, la généralisation des formats XML en bureautique sur Mac n’est plus qu’une question de temps, ce qui est un atout essentiel pour la plate-forme dans son intégration au cœur des processus de l’entreprise. Car, dans ces processus, peu importe que l’on adopte OpenXML ou ODF. Ce qui compte n’est pas la fidélité du rendu ou la complexité du document, mais uniquement la facilité (car tout est en XML) d’aller récupérer telle ou telle donnée dans le document. De plus, la généralisation des formats XML facilite l’adoption par l’entreprise de processus basés sur des Web services et l’adoption d’architectures orientées services. Ces architectures à très faible couplage sont par essence davantage ouvertes à la diversité des plates-formes. Évidemment, il demeure dans les entreprises de nombreuses applications client-serveur étroitement liées au monde Windows. Mais, d’une manière générale, les développements actuels et futurs tendent vers une multiplication des services et par voie de conséquence vers une plus grande ouverture. En outre, le développement des technologies comme Ajax, Adobe Appolo, ou Silverlight contribueront dans un proche avenir à offrir des expériences utilisateurs très proches sur toutes les plates-formes. Après tout, n’oublions pas que Silverlight (ex WPF/E) peut être aussi perçu comme un portage partiel du .NET Framework de Microsoft sous Mac OS X.
Travail collaboratif
sur Mac OS X Server
Et pourquoi une entreprise fidèle à l’esprit Apple, n’opterait-elle pas pour des serveurs Apple plutôt que Windows ? Après tout, la plate-forme serveur d’Apple est livrée avec l’incontournable trio Apache-PHP-MySQL. Et son support de Java est l’un de ses chevaux de bataille. Mac OS X Server est également livré avec un serveur de messagerie instantanée, basé sur Jabber, pour lequel on trouve des clients aussi bien sur Mac que sur PC, ou Linux.
|
Mac et PC : La virtualisation pour résoudre l’insoluble
L’incompatibilité des Mac avec les applications Windows développées par l’entreprise n’est plus un frein à leur intégration dans le système d’information. Il existe aujourd’hui plusieurs solutions simples à mettre en œuvre.
Parallels Desktop fut le premier logiciel de virtualisation sur les Mac Intel. Sa version 3 introduit le support partiel de DirectX et OpenGL et une fonction Cohérence qui virtualise les applications Windows sans leur bureau.
RDP, protocole oublié
La division Macintosh de Microsoft a sorti dans l’indifférence générale une extension dénommée « Remote Desktop Connection Client for Mac OS X ». Celle-ci est en réalité un portage du protocole RDP v5 de Microsoft sur le système d’Apple. Or, RDP est un protocole fondamental chez Microsoft. C’est par exemple celui qui permet de prendre le contrôle à distance de chez soi de son PC au bureau. Désormais, il est donc possible d’utiliser un ordinateur Mac familial pour se connecter à distance à son PC professionnel et en prendre le contrôle !
Mais le protocole RDP est surtout le protocole utilisé par Windows Terminal Services. WTS n’est autre que la solution de terminal léger intégrée à Windows Server et qui permet d’exécuter en multipostes des applications clientes sur un serveur. Dès lors, il devient possible aux machines Apple d’exécuter « à distance » les versions PC d’Office, d’Outlook mais aussi n’importe quelle autre application Windows compatible avec les Terminal Services. Les applications s’exécutent alors au sein d’un bureau Windows distant présenté dans la fenêtre de l’application « Remote Desktop Connexion Client for Mac OS X ». Évidemment, ceci nécessite un minimum de connaissance Windows chez les utilisateurs Mac et une certaine ouverture d’esprit. Mais cette solution reste éminemment élégante. Une version 2.0, actuellement en bêta anglaise, est disponible depuis le 1er août sur le site de l’éditeur. Celle-ci, écrite en code Universal, qui prend en charge la version 6 du protocole RDP, utilisée par Vista et Windows Server 2008 et qui permet le contrôle d’applications indépendamment du bureau.
BootCamp, Windows sur le Mac
BootCamp, c’est l’incroyable pari d’Apple et la conséquence logique de sa migration vers les processeurs Intel. Actuellement en bêta (librement téléchargeable) et considéré comme partie intégrante du futur Leopard, BootCamp est un gestionnaire de boot qui permet à un utilisateur Mac de démarrer son ordinateur au choix sous Mac OS X ou sous Windows XP/Vista. C’est en réalité un peu plus que cela, puisqu’Apple ne s’est pas contenté de produire un simple système de Dual Boot, mais livre avec BootCamp tous les pilotes Windows indispensables pour tirer pleinement parti du matériel. Boot Camp permet ainsi de graver un CD contenant tous les pilotes Windows nécessaires évitant de pénibles recherches sur Internet et des expérimentations douloureuses !
Une fois Boot Camp installé, il suffit de maintenir la touche Option enfoncée au démarrage pour choisir le système sur lequel on veut démarrer : Mac OS X ou Windows. Après le démarrage, le Mac exécute Windows en mode natif comme un authentique PC. Pour retourner sous Mac OS X, il suffit simplement de quitter Windows et de redémarrer l’ordinateur. L’installation est triviale : il suffit de télécharger BootCamp et de lancer l’application. Celle-ci vous aide à libérer l'espace disque et à créer la partition nécessaire à l'installation de Windows, sans perdre vos fichiers Mac. Il vous suffit de faire glisser le curseur pour définir la taille de votre partition Windows. Puis, il n’y a plus qu’à insérer le CD de Windows et à procéder à l’installation du système Microsoft comme sous n’importe quel PC. Signalons que lorsque l’utilisateur est sous Mac OS X, il a accès à la partition Windows et peut donc facilement utiliser les mêmes fichiers de travail dans les deux environnements.
Virtualisation, Windows et Mac
La virtualisation n’est pas nouvelle. Des logiciels comme Virtual PC permettent depuis longtemps d’exécuter Windows dans une fenêtre Mac. Mais avant l’adoption des processeurs Intel, ces logiciels de virtualisation devaient systématiquement traduire le code Intel en Power PC. Il en résultait une exécution terriblement lente. Depuis que les Mac sont sous Intel, cette traduction des codes machines n’est plus utile. Et la virtualisation prend une toute nouvelle dimension. Les performances des processeurs sont largement suffisantes pour faire tourner Windows XP parallèlement aux applications Mac OS X (et même Windows Vista) avec un confort d’utilisation maximal. Aujourd’hui, les solutions comme Parallels Desktop 3 ou VMWare Fusion sont incroyablement souples et performantes et s’avèrent même plus évoluées que leurs équivalents sous Windows. Elles permettent d’exécuter simultanément à la fois les applications Mac et les applications Windows. Avec une totale liberté et même une certaine transparence pour l’utilisateur. En effet, grâce à la technologie « Unity » chez VMWare, ou « Coherence » chez Parallels, l’utilisateur peut faire disparaître le bureau Windows. Les applications PC sont alors affichées comme des applications indépendantes sur le bureau Mac. Avec Unity, il est même possible de copier/coller directement des éléments entre les applications Mac et Windows, ou de réaliser des glisser/déposer entre les deux univers ainsi fondus l’un dans l’autre. Le support partiel de Direct X autorise même l’exécution de certaines applications 3D et certains jeux PC sous Mac OS X.
La puissance des machines actuelles et la qualité de ces solutions de virtualisation permettent aujourd’hui aux entreprises d’envisager sereinement des scénarios d’exécution de leurs applications maison Windows sur les Mac, et ceci avec une cohérence et une transparence à même de ne pas rebuter les utilisateurs Mac. Par exemple, avec la fonction SmartSelect de Parallels, l’utilisateur se contente de double cliquer sur un fichier de données pour charger automatiquement l’application correspondante, qu’elle soit native Mac ou virtualisée PC. Autre amélioration, VMWare Fusion permet d’utiliser directement le Windows de la partition BootCamp sans avoir à réinstaller un Windows sous VMWare. Là aussi, un gain de temps et une économie de ressources appréciables. En revanche, il faudra songer à booster les capacités mémoire des machines pour un fonctionnement optimal. Comptez 2 Go minimum de Ram, avec une large préférence pour des configurations 4 Go.
Bref, entre la prise de contrôle à distance très universelle, la fonction dual boot BootCamp pour une exécution optimale, ou les solutions de virtualisation pour une accessibilité et une transparence idéale, les administrateurs informatiques ne sont pas en manque de solutions pour contourner les derniers freins à même d’interdire l’entrée des Mac dans les systèmes d’information.
Mac OS X sur PC
Apple se montre beaucoup plus frileux que Microsoft à voir son OS fonctionner sous d’autres environnements. La firme de Steve Jobs fait tout ce qui est en son pouvoir pour protéger le système et interdire son exécution sur les PC traditionnels. On trouve certes sur Internet des versions « patchées » de Mac OS X à même de s’exécuter sur un vulgaire PC, mais ces solutions sont illégales et enfreignent la licence Apple. En outre elles n’ont jamais les drivers adaptés à votre matériel. Plus incompréhensible en revanche est le veto mis par Apple à voir son système fonctionner en machine virtuelle sur des solutions comme Virtual PC 2007, VMWare Workstation 6 ou Parallels Desktop for Windows. Parallels et VMWare ont tout deux démontré la faisabilité de la chose mais n’ont pu implémenter les profils adéquates dans leurs solutions suite au refus d’Apple. Il existe bien des images VMWare pirates de Mac OS X sur le net, mais celles-ci, en l’absence de profils et de pilotes adéquates, s’exécutent avec une lenteur horripilante. Dommage…
|
Les développeurs mi-figue, mi-raisin sur l’iPhone
Par Bertrand Garé - Copyright L'Informaticien, tous droits réservés
L’iPhone est déjà le produit de l’année. Le bruit fait autour de ce téléphone – est-ce vraiment encore un téléphone ? – est tellement énorme qu’il semble judicieux de faire un point sur son ouverture pour des applications venant d’autres horizons que celui d’Apple.
Apple nous a habitué à un environnement refermé sur lui-même. Steve Jobs, dans son habituel grand numéro de keynote, s’est fendu d’une petite surprise lors de la dernière Apple Developer Conference. L’iPhone sera ouvert aux applications tierces. Ouais ! Mais par le biais du navigateur embarqué Safari. Cette ouverture est donc un peu en trompe-l’œil. Ainsi, les applications développées sur des standards Web 2.0 (comprenez Ajax et consorts) pourront avoir le même aspect ou comportement que les applications natives développées par Apple. Les applications sont donc vues comme des extensions fonctionnelles d’iPhone et non comme des applications cœurs. Et la porte se ferme totalement lors de l’annonce du fait qu’il n’y aura pas d’outils de développement spécifique sur l’iPhone. Selon le patron d’Apple, cette situation serait temporaire en attendant que le modèle soit bien implanté sur le marché. Certains développeurs ont fait part de leur grogne et se voient déjà en acteurs de seconde zone ne développant que des « widgets » pour téléphone mobile. Cela n’empêche pas certains développeurs ou entreprises d’occuper le terrain.
Des add-ons à foison
Morfik, une jeune entreprise, comble pour l’instant ce manque en proposant une plate-forme de développement pour l’iPhone. Dès qu’une API sera livrée par Apple, elle sera intégrée dans la plate-forme comme l’indique la société. Il existe déjà plus de cinquante applications disponibles sur l’iPhone : jeux, comme le jeu d’échecs de Morphik ; utilitaires, tels des outils de transfert de fichiers à distance vers son Mac à la maison ; interfaces, avec par exemple un outil qui permet de faire ses achats sur eBay. Ne manquent que les applications « métier ».
Le Gartner, un cabinet de conseil spécialisé dans les nouvelles technologies, porte un jugement sévère sur le produit, le déconseillant aux professionnels, car il ne serait pour lui qu’un iPod-téléphone sans intérêt pour ceux qui bossent ! Il est possible aussi qu’Apple se réserve ce secteur. Les premières applications ont été rendues publiques lors du premier iPhoneDevCamp qui s’est tenu début juillet à San Francisco. Courant août, Apple a proposé aux États-Unis des ateliers itinérants, les iPhone_Tech_Talks, dans quatre grandes villes : Los Angeles, San Francisco, Chicago et New York. Ces ateliers duraient une journée entière et étaient animés par des ingénieurs d’Apple. Leurs thèmes étaient très variés allant de la gestion de contenu à la synchronisation des données ou la création d’applications Web 2.0. Les après-midi étaient consacrés aux développements et aux tests des applications.
En ce qui concerne les interfaces, le constructeur à la pomme a mis en ligne un site dédié qui reprend les contraintes spécifiques de l’interface tactile de l’iPhone pour le développement et le design.
Casser l’iPhone !
Mais le premier intérêt des développeurs s’est porté sur les fonctions de sécurité de l’appareil, avec une course au hacking et aux solutions pour contourner les contrôles de l’iPhone. D’ores et déjà, des proof of concept ont démontré des failles possibles. Rapidement, d’autres failles et autres possibilités de contourner les sécurités mises en place devraient être rendues publiques. Un ancien d’Apple, désormais chez PGP, expliquait dans la presse que l’iPhone était si puissant qu’il était impossible de le protéger complètement et qu’Apple ferait mieux de se concentrer sur la protection des données sur l’appareil.
Il reste donc à Apple de démontrer qu’un véritable écosystème pourra se développer autour de ce téléphone et quelle sera la part de ces partenaires dans le gâteau commercial annoncé.
|
Avec Mono, DotNet devient compatible Linux et Mac OS X
Par Frédéric Milliot - Copyright L'Informaticien, tous droits réservés
Les développeurs DotNet peuvent maintenant proposer leurs logiciels à des utilisateurs de nombreuses autres plates-formes. Grâce à Mono, la migration s’effectue sans douleur et sans remettre en question de cycle de vie de l’application.
C’est une petite révolution dans le monde du développement. Grâce à Mono, toute application écrite en C# pour DotNet peut être utilisée sur d’autres OS. Lesquels ? Linux, FreeBSD, UNIX, Mac OS X et Solaris. Rien que ça ! Il se peut même, dans certains cas, que la migration ne demande qu’une simple recompilation à partir des API Mono au lieu des API d’origine. Telle n’était pas a priori l’intention de Microsoft, mais le projet Mono, soutenu au départ par Ximian (devenu Novell), puis rejoint in fine par Redmond, est devenu à ce point mature que l’opération peut être envisagée en production pour des applications de toute nature, y compris lorsqu’elles présentent un caractère critique.
Une compatibilité étendue et pérenne
Le projet Open Source Mono est né officiellement en juillet 2001, pour donner naissance à la version 1.0 de l’environnement en juin 2004. On en est aujourd’hui à la version 1.2.4, qui expose une compatibilité étendue aux principales API de DotNet 2.0. Cette compatibilité sera totale, y compris pour ce qui est de l’API Windows.Forms, avec la version 2.2 de Mono prévue pour la fin de l’année. Concernant DotNet 3.0, un sous-projet expérimental baptisé Olive a été créé, mais aucune date précise de disponibilité n’a encore été annoncée.
Techniquement, Mono se présente sous la forme d’un jeu d’outils compatible DotNet et conforme au standard ECMA. L’ensemble contient notamment un compilateur C# et un Common Language Runtime (CLR) adapté aux plates-formes cibles. Ce runtime contient à son tour un compilateur Just-In-Time (JIT) compatible avec une large variété de processeurs : Intel x86 et x86-64, IA64, SPARC, SPARC 64-bit, PowerPC, ARM et S390 (en 32 et 64 bits). Ce qui signifie que la compatibilité ne se limite pas à l’OS mais s’étend au hardware sous-jacent. Car c’est le compilateur JIT qui est chargé de transformer le code CLR en code machine natif mis en mémoire cache à mesure que l’application s’exécute – comme c’est d’ailleurs le cas avec DotNet sous Windows. Pour optimiser les performances, il est bien sûr possible de « précacher » l’image native avant son exécution. Mais même sans cela, la compilation JIT, finement optimisée, dépasse largement en performances l’approche interprétée.
En pratique : porter une application DotNet vers Mono
Le chemin qui sépare l’exécution d’une application DotNet dans son environnement natif et l’exécution de cette même application sous Linux ou Mac OS est moins tortueux qu’on pourrait le penser. Bien sûr, en fonction des classes mises en œuvre, la migration peut prendre plus ou moins de temps, mais l’effort n’est jamais surhumain. S’il s’agit d’applications classiques programmées de façon orthodoxe, il y a de grandes chances pour qu’aucun recodage ne soit à prévoir. Dans le cas contraire, il faudra peut-être réécrire certains algorithmes implémentant des classes non encore disponibles dans la version courante de l’environnement. Celles-ci sont d’ailleurs peu nombreuses, dès lors que vous n’utilisez pas WPF ou d’autres couches soit extrêmement récentes, soit étroitement liées aux fonctionnalités de Windows Vista ou de Windows Server 2003.
Pour nous faire une idée concrète du processus, suivons l’exemple préconisé par les développeurs officiels de Mono. Il s’agit du portage de NClass, un designer UML Open Source qui ressemble, dans son fonctionnement, à celui qui est inclus dans Visual Studio 2005. NClass est téléchargeable avec ses sources à l’adresse http://nclass.sourceforge.net/index.html. Cet exemple a en plus ceci d’intéressant que le code source est assorti d’une licence GPL/LGPL, ce qui permet d’envisager sereinement toutes les utilisations et tous les changements nécessaires à l’existant.
L’essentiel se fait sous Windows
Sachant que l’application est à l’origine un exécutable Windows, partons du principe que vous venez du monde Windows. Vous êtes donc a priori familier avec Visual Studio. La première étape de la marche vers Mono consiste donc à charger la solution (fichier nclass.sln) dans VS2005 et à recompiler le tout. La compilation s’effectue sans problème, les assemblages qui en découlent signifiant que vous avez accès à l’ensemble des ressources nécessaires pour intervenir au cœur du programme.
Avec ces assemblages, notamment les DLL, il est temps d’ouvrir MoMA, le Mono Migration Analyzer, un parseur de code qui détermine le degré de compatibilité de l’application avec les prérequis de Mono. MoMA permet de sélectionner un certain nombre d’assemblages de façon simultanée, qu’il s’agisse des modules propres à l’application ou des modules qu’elle référence. MoMA a également un autre avantage, c’est qu’il permet de sélectionner la version de Mono avec laquelle la compatibilité sera testée. Sachant que le projet évolue à vitesse grand V et que chaque release apporte un lot important de nouvelles classes, cette possibilité est très appréciable pour la mise en œuvre de projets concrets sur des versions de Linux ou de Mac OS qui peuvent varier.
Une fois l’analyse terminée (soit quelques instants après avoir pressé le bouton « Next » de l’assistant MoMA), un rapport s’affiche qui liste les méthodes indisponibles dans la version de Mono spécifiée, celles qui sont marquées dans Mono comme étant en cours d’implémentation, celles qui génèrent une exception NotImplementedException, et celles qui contiennent un P/Invoke, c’est-à-dire un appel d’API en mode non managé (pour l’accès direct aux composants Windows). Si les quatre indicateurs sont en vert, pas de problème, le portage est quasiment terminé. Dans le cas contraire, tout est fonction du rôle des méthodes. Avec NClass, on s’aperçoit qu’il s’agit principalement de méthodes de présentation liées aux contrôles utilisés (ListViews, ComboBoxes, PrintDialog…). Il est assez rare que le développeur un tant soit peu expérimenté ne trouve pas une solution de contournement facile, quitte à implémenter manuellement certains des comportements d’interface qui manquent. Hormis les P/Invoke qui, de toute façon, sont liés à l’API Windows standard et donc pas toujours implémentables à l’identique sur d’autres OS, la principale difficulté qu’on peut rencontrer est un événement manquant à l’appel car, dans ce cas, le code qui lui correspond n’est même pas appelé. Il faut alors souvent en revenir aux bonnes vieilles pratiques de déclenchement programmé. Ce qui signifie, au passage, que les nouvelles approches de programmation globalement événementielles, très à la mode en école d’ingénieurs aujourd’hui, sont à proscrire si les portages vers Mono ne sont pas exclus.
Voici notre application exemple portée sous Linux en moins d’une heure. Compte tenu du peu d’efforts nécessaires
pour y parvenir, le concept de Mono s’avère tout à fait probant.
Un test préalable pour identifier les erreurs
Nonobstant les avertissements de MoMA, il est possible de tester l’application directement. Dans l’exemple NClass comme dans beaucoup d’autres, les méthodes à problème ne devraient en effet apparaître que dans certaines conditions d’utilisation. Le test peut s’effectuer sous Windows, par le biais d’une émulation Mono. Lors de l’installation de l’environnement, un outil dédié, Mono Command Prompt, a été créé dans le menu Démarrer. Il suffit donc de le lancer et d’y saisir la commande « mono NClass.NClass.exe 2> error.txt », suivie de <Enter>. Ainsi formulée, cette commande génère un fichier d’explication en cas d’erreur et c’est tant mieux car NClass ne s’exécute pas telle quelle. Voyons donc ce que dit le fichier :
** (NClass.NClass.exe:38272): WARNING **: Missing method
"System.Windows.Forms.PrintDialog::set_UseEXDialog(bool) in assembly
"C:\PROGRA~1\MONO-1~1.4\lib\mono\gac\-
"System.Windows.Forms\2.0.0.0__b77a5c561934e089\
"System.Windows.Forms.dll, referenced in assembly
"C:\NClass\src\GUI\bin\Release\NClass.NClass.exe
Unhandled Exception: System.MissingMethodException: Method not found:
" 'System.Windows.Forms.PrintDialog.set_UseEXDialog'.
at <0x00000> <unknown method>
at NClass.GUI.MainForm.Init () [0x00000]
at NClass.GUI.MainForm..ctor () [0x00000]
at (wrapper remoting-invoke-with-check) NClass.GUI.MainForm:.ctor ()
at NClass.GUI.Program.Main (System.String[] args) [0x00000]
Clairement, c’est notre méthode PrintDialog.UseEXDialog qui est fautive. Mais MoMA nous avait prévenus. Il est donc temps d’entamer le réel travail de portage. L’option la plus simple consiste à mettre la méthode en commentaire. Mais c’est tout de même un peu radical. Il est possible aussi de définir une compilation conditionnelle à l’aide des balises #if !MONO / #endif, après quoi on n’oubliera pas de spécifier le symbole « MONO » dans l’onglet Générer des propriétés du projet de Visual Studio. Autre possibilité, détecter à l’exécution si l’on est Mono ou sous DotNet avec la méthode IsRunningOnMono. On obtient alors un code source unique pour toutes nos plates-formes, ce qui en rend la maintenance plus facile :
//
// printDialog
//
this.printDialog.Document = this.printDocument;
if (!IsRunningOnMono ()){
SetupPrintDialog ();
}
...
void SetupPrintDialog ()
{
this.printDialog.UseEXDialog = true;
}
Dans ce cas, il est préférable de déplacer le code vers une méthode séparée. Ainsi, le compilateur Just-In-Time ne lèvera pas d’exception lorsqu’il traitera le code d’une méthode qui n’existe pas puisqu’il ne l’atteindra même pas. Enfin, bien sûr, nous pouvons toujours réécrire le code. Parmi les éléments identifiés comme inexistant dans Mono par MoMA figurait l’événement ListView.ItemSelectionChanged. Mais dans le même temps, Mono implémente bien ListView.SelectedIndexChanged. L’adaptation n’est donc pas bien méchante : en quelques minutes, le problème est résolu de façon élégante.
Fin de la migration et premiers tests sous Linux
Une fois les arbitrages effectués en fonction des ressources exposées par la version de Mono utilisée, et NClass recompilée avec Visual Studio 2005, l’application peut être testée sous Windows mais via Mono. Bien sûr, le simple chargement des fichiers exemples ne suffit pas pour déterminer que le logiciel fonctionne correctement. Une procédure de test exhaustive et rigoureuse est nécessaire pour valider que la version Mono est opérationnelle. En cas de problème, il faudra déterminer si c’est le code source ou si c’est Mono qui est responsable. Dans la seconde hypothèse, n’oubliez pas de soumettre vos observations au bugzilla de Mono pour que l’erreur soit réparée et qu’elle profite aux autres membres de la communauté.
Voici maintenant venu le temps de tester NClass sous Linux. Quelle que soit la distribution que vous utilisez, des packages Mono appropriés sont disponibles, soit dans la distribution elle-même, soit dans la page de téléchargements du site officiel du projet (lire l’encadré Pour aller plus loin). Vous pouvez également opter pour l’image VMWare de openSUSE/Mono (disponible sur le site officiel de Mono). Une fois l’ensemble installé et NClass copié dans l’environnement Mono, vous devriez alors retrouver un logiciel strictement identique, à l’exception bien sûr des spécificités esthétiques de l’interface UI exécutée par la distribution. Voilà, le portage est terminé. Avouez que ce n’était pas la mer à boire. Et si pendant l’exécution vous constatez de légers dysfonctionnements, reportez-vous à notre encadré « Les erreurs classiques du portage Mono » pour y trouver une probable solution.
Pour aller plus loin
• www.mono-project.com : le site officiel de Mono, de ses packages et de sa documentation
• http://monofrance.tuxfamily.org : Monofrance, portail francophone des utilisateurs Mono
• www.go-mono.com : Monologue, agrégateur de fils et de blogs consacrés à Mono, principalement en anglais
|
|
Des outils pour mieux développer
Doc
Mono s’accompagne d’une documentation complète (standard ECMA) et d’un navigateur GTK# autorisant l’édition et l’ajout d’annotations, comme un Wiki.
ObjectBrowser
L’inspecteur d’objets créé par Radek Dudek est indispensable pour inspecter le code source des assemblages et les références des objets implémentés.
TypeReflector
Comme dans Visual Studio, une visionneuse affiche les données de System.Information correspondant aux assemblages, ce qui est très utile pour le développement d’applications
auto-évaluatives.
MonoUML
Mono est également éligible à la conception par modélisation grâce à MonoUML. Outil de Case complet basé sur les standards OMG, celui-ci est compatible avec les grands modeleurs propriétaires.
Petite galerie d’applications Mono
Gnunit
Conçu pour automatiser les tests unitaires sur vos assemblages via une interface GUI, Gnunit est un
des éléments qui permet d’envisager une assurance qualité pour le développement Mono.
SQLSharp
Frontal de commande SQL, SQLSharp est écrit lui aussi en C# et permet l’interrogation de
fournisseurs ADO.NET, comme sur cette capture une base SQL Server 2000.
iFolder
Exemple type d’une application Mono réussie, iFolder est une application de partage de fichiers entre Windows, Mac et Linux. Elle est développée en C# et utilise, selon la plate-forme, GTK#, Cocoa ou Windows Forms.
OpenVPN Admin
OpenVPN Admin propose une interface graphique permettant une gestion simplifiée de réseaux privés virtuels. Il est écrit en C# et fonction sous Windows et Linux.
SharpChess
SharpChess est un jeu d’échecs complet de niveau professionnel, avec historique des mouvements, délais de jeu variables, décompte de points, etc.
Dashboard
Dashboard est un gestionnaire d’informations personnelles capable d’afficher seul, de façon proactive, les fichiers correspondant à l’activité en cours : rédaction d’e-mails ou de textes, navigation Web, IM…
Muine
Exclusivement consacré à la musique – pas d’affichage vidéo – le lecteur Muine est d’une simplicité biblique, ne consomme que peu de ressources système, et implémente un code source simplissime, représentant ainsi une des grandes vertus de Mono.
Calendar
Ce n’est pas encore Outlook 2007, mais Calendar suffit à couvrir l’essentiel des besoins de gestion d’agendas, avec une interface simple au look (assez moderne) cohérent sur les différentes plates-formes Mono.
Blam
Lecteur RSS complet, Blam démontre lui aussi les bénéfices de Mono. Son interface et sa palette fonctionnelle simplifiées reposent quasi exclusivement sur les bibliothèques de l’environnement, d’où un code source simple et facilement évolutif.
|
|
|
|
|
|
|
|
|
|
| DotNetNuke® is copyright 2002-2008 by Perpetual Motion Interactive Systems Inc. |
|