Comment Linux deviendra l’environnement graphique Ultime

Traduit de l’anglais par G.Ryckeboer
lundi 16 septembre 2002
par  Delmar Watkins
popularité : 1%

Vous pouvez dire ce que vous voulez, la plupart des gens sont d’accord
sur le fait que Mac OS X possÚde une excellente GUI (Interface Graphique Utilisateur).

Pendant que les partisans de linux dénoncent l’aspect bonbon rose, et
que les fanatiques d’OS 9 pleurent que leur Window Manager préféré a été
défiguré dans OS X, la plupart des personnes conviennent que l’intégration d’Aqua (la GUI) constitue un grand pas en avant vers un véritable Bureau (Desktop) interactif. Malheureusement, OS X n’existe que sur du matériel propriétaire et relativement onéreux.

D’un autre côté, vous avez KDE et Gnome, qui en
eux-même, ont joué un rôle non négligeable pour rendre Linux accessible aux utilisateurs lambda. Sans ces efforts, et sans ces deux projets de GUI, les logiciels Open Source ne seraient aujourd’hui encore exploités que sur des serveurs, des systèmes embarqués, ou via la ligne de commande sur le Bureau [NDT].

Cela dit, même le supporter de Linux le plus convaincu ne pourra pas
nier qu’alors que ces projets rendaient linux utilisable comme station
de travail, bien peu de travail a été fait pour le rendre accessible au
grand public.

Dans l’ombre de Windows

KDE et Gnome, malgré de gros efforts, ne sont rien de plus que
l’ombre des produits de Microsoft (Nasdaq
MSFT). Pendant que les Bureaux ressemblent et se comportent comme
Windows, de vraies applications courantes restent absentes, un
aspect que même WINE et Lindows n’ont pu changer. On ne peut pas dénombrer le nombre d’applications que les passionnés utilisent pour
répondre à leurs besoins, mais les utilisateurs en entreprise et les utilisateurs avancés ont besoin d’un mélange d’applications libres et
commerciales.

Au delà de la compatibilité Windows, il y a un autre moyen d’apporter des programmes commerciaux de haute qualité à cette plateforme OpenSource. Plutôt que de chercher à émuler Windows, les environnements Linux devraient chercher à devenir compatible avec MacOS X, et ainsi, de créer un grand environnempent graphique, bosstant la croissance d’OS X et de Linux, et en apportant plus de dévelopepurs aux deux plateformes.

NeXT et Cocoa

OS X possède un environnement de programmation beau et élégant, nommé Cocoa, qui descend directement de la plate-forme NeXT. L’environnement Cocoa est réellement impressionnant : Objective C possède tous les meilleurs aspects de Java sans être "contaminé" par les décisions écervellées de Sun pour le rendre lent, pénible et inféodé à la stratégie commerciale de l’éditeur américain.

Le système objet de Cocoa est incroyable, et l’environnement de développement est vraiment très facile à utiliser. Les applications développées avec Cocoa passent en production plus rapidement qu’avec d’autres langages. Elles s’exécutenet rapidement, interragissent avec d’autres applications via des interfaces scriptabels, et ont une couche logique.

Objectifs doubles

De plus, la plupart des API ont déjà été dupliquées par le projet
GNUStep. Des projets comme WindowMaker et SimplyGNUStep utilisent les
équivalents GNU de l’environnement Cocoa. La plupart du travail a déjà été fait pour rendre les bases d’OS X compatible avec les celles de
WindowMaker, Ghostscript et les autres logiciels GNU.

Les développeurs, chez Simply
GNUStep
essayent de lancer l’idée de créer un OS orienté Bureau avec Linux. Ils n’ont pas publiquement déclaré qu’ils le voulaient compatible avec MacOS X. Pourtant, dès que l’environnement de développement permettra aux developpeurs de compiler des programmes pour les deux plate-formes (MacOS X et Linux) à partir de sources communes, il existera la possibilité d’avoir une distribution Linux capable d’exécuter les applications prévues pour OS X.

Alors que la communauté Linux se bat pour deux API qui n’auront jamais le support tant attendu, elle pourrait, à la place, créer un environnement de bureau afin de construire facilement des applications compilables de manière simple, pour OS X et Linux.

Partages d’idées entre développeurs

Ecrire une application pour Windows est une opération sans ambiguité, simple. Vous payez, vous obtenez les outils de développement, et vous y allez... afin de créer une application que vous pourrez vendre à 95% de la population utilisant un ordinateur. C’est aussi vrai pour OS X, excepté qu’au lieu d’avoir une chance de vendre — ou toucher — une majorité de clients, vous vous limitez à environ 5% des utilisateurs.

Avec Linux, vous avez à choisir entre deux environnements en concurrence
qui représente chacun environ 1% du marché. Regardez les choses en
face, aucune application commerciale sérieuse ne sera jamais portée sous
Linux dans ces conditions.

Mais si un développeur pouvait écrire du code natif qui pourrait satisfaire deux groupes marginaux distincts, qui à eux deux représentent 6% du marché, on aurait gagné le pompon ! Alors les logiciels développés pour MacOS X pourront aussi arriver facilement sous Linux. De façon similaire, les logiciels proposés sous Linux, y compris les applications serveurs Unix (server-side Unix applications), pourraient être portées sous OS X. Et les deux camps seront alors gagnants.

Linux et OS X, les bénéfices de la coopération

D’un côté, les logiciels Open Source ouvrent des opportunités commerciales à OS X. De l’autre côté, des logiciels commerciaux de
qualité [NDT] — et un bureau bien construit —
permettraient aux utilisateurs de basculer vers un système d’exploitation libre.

Au lieu de fabriquer aveuglément des applications, gestionnaires de
Bureau et des interfaces incompatibles avec d’autres systèmes, comme des
systèmes propriétaires, Linux et OS X pourraient tous deux gagner beaucoup à intégrer conjointement un très bon environnement de développement, qui plus est, d’ores et déjà quasiment terminé.

Les entreprises commerciales devraient prendre Linux et OS X —
particulièrement Cocoa — plus au sérieux si elles veulent être capables
de s’offrir deux marchés distincts d’un seul coup, et pourquoi pas voler
une petite part, si jalousement gardée, du marché de Microsoft.

Delmar Watkins sur OSOpinion


[NDTC’est relativement inexact, n’oublions pas WindowMaker, qui existe déjà depuis longtemps, et que l’auteur cite plus loin dans l’article.

[NDTCe qui ne veux aucunement dire que les logiciels Open Source soient de mauvaise qualité.


Commentaires

samedi 8 octobre 2005 à 11h25
mercredi 10 décembre 2003 à 12h01 - par  Yu

Un problÚme majeur on va descendre un peu en bas pour remonter osx utilise un noyau
overflow de BSD avec un micro-kernel
appelé mach == Darwin

linux dans ce sens possÚde un noyau obsolÚte

ce n’est pas pour rien que NEXT avait choisi
comme noyau BSD car BSD intÚgre plus ou moins facilement la possiblité de port de code
alors que le port d’une application native BSD
sous Linux c’ est une autre paire de manches

De plus la couche NEXT et Darwin sont pour l’instant optimisé pour un hardware PPC

Deux va falloir que tu expliques à Apple de lacher les sources de Quartz
alors qu’Apple possÚde un OS Unix Based Libre == FreeCode et non GNU comme linux

et peux facilement maintenant intégrer
tout ce qui est fait en projet open source

Apple se fou royalement du monde Linux
historiquement Linux est une aventure formidable —> FSF ecetera

mais technologiquement obsolete
comme windows qui est un OS obsolete
et trÚs en retard basé sur des principes informatiques de la fin des années 70

Je pense qu’il faut avant tout se baser
sur la création d’un noyau d’aujourd’hui avant
de penser au dev d’un GUI

La force de Cocoa pour le GUI reste Quartz
ou comment je me paye un moteur Graphique
digne d’une console de jeux video pour faire
mon GUI

et la est la solution c’est dabord un bon noyeau un moteur graphique puissant

Logo de laotseu
lundi 3 février 2003 à 21h16 - par  laotseu

>Il faut aussi que l’entreprise qui vend son application fasse un support. Et faire du support cela coûte cher. Alors le faire pour 5 ou 6%... C’est pas trÚs rentable.


Et en prenant le problÚme dans l’autre sens ? Pourquoi ne pas garder le logiciel libre, et faire payer le support ?

jeudi 16 janvier 2003 à 22h48

Et si on faisait en sorte, pour palier au palladium de pouvoir faire des clones avec un processeur powerpc, et des périphérique venant du monde x86, comme carte graphique, carte son, modem routers, souris, clavier, anceinte, etc. Aprés tout apple installe bien des périphiques qui marchent sur ibm pc compatibles x86 et sur ses ordinateurs.

vendredi 8 novembre 2002 à 12h26

Sauf que, malheureusement, Adobe et compagnie utilisent pour l’instant l’API Carbon, une évolution de l’API de MacOS 9, afin que ces produits (principalement destinés à des graphistes professionnels) puissent fonctionner sous Mac OS 9.

Ceci dit, la programmation en Cocoa est tellement plus simple que les gros logiciels commerciaux y seront certainement portés dans un avenir plus ou moins proche.

De plus, l’arrivée de Mac OS X a déjà décidé pas mal d’entreprises (Alias|Wavefront par exemple) à développer pour cette plateforme, on peut donc rester confiant.

mercredi 18 septembre 2002 à 00h10

L’environnement n’est pas le même. Mais si l’API et l’interface sont identique. Il restera toujours des "petites" différences (Darwin et Linux ne doivent certainement pas fonctionner de la même maniÚre). Et puis le matériel est différent (même si Apple réutilise certains éléments venant du monde PC pour abaisser les coûts).

Toutes ces différences font que les entreprises seront obligées de faire du support pour deux environnements différents.

mardi 17 septembre 2002 à 10h49

Il faut aussi que l’entreprise qui vend son application fasse un support. Et faire du support cela coûte cher. Alors le faire pour 5 ou 6%... C’est pas trÚs rentable.
Est-ce moins rentable de le faire pour 6% que pour 5% ? Les boites qui vendent pour Macintosh (Adobe, Steinberg, Aldus, eLogic etc...) n’ont pas vraiment d’effort supplémentaire à faire pour supporter la même appli pour le même environnement.... Et ça permettrait de faire évoluer ledit environnement, et donc de faire grimper le nombre d’utilisateurs sous GNUStep...

mardi 17 septembre 2002 à 01h59

Le tout n’est pas d’avoir une API compatible. Si il n’y avait que ça pour avoir des applications professionelles venant du monde Windows...

Il faut aussi que l’entreprise qui vend son application fasse un support. Et faire du support cela coûte cher. Alors le faire pour 5 ou 6%... C’est pas trÚs rentable.

Je pense qu’il faudra se contenter pendant encore longtemps d’applications OpenSource (et pour certaines qui vallent presque leur équivalent propriétaire).

Mais c’est vrai qu’il serait pas mal du tout d’unifier un peu toutes les différentes API existantes. On y gagnerait beaucoup.

lundi 16 septembre 2002 à 15h11 - par  Drol

C’est pas marqué dessus ? Archeron ?

Logo de asr
lundi 16 septembre 2002 à 14h08 - par  asr

Un window maker de base, c’est juste l’appli app.mail qui fait de l’effet ;-)

lundi 16 septembre 2002 à 13h06

Des projets comme WindowMaker utilisent les >équivalents GNU de l’environnement Cocoa.

WindowMaker n’utilse pas le framework OpenStep/Cocoa/GNUstep.
Cela pose certain problemes et GNUstep devra se tourner vers un autre Window Manager pour plus d’intégration.

mais si un développeur pouvait écrire du code natif qui pourrait satisfaire deux groupes marginaux distincts, qui à eux deux représentent 6% du marché,

C’est bien plus que ca. GNUStep fonctionne (ou devrait) sur plateforme win32 en natif (sans X).
Ce qui augmente considérablement le pourcentage :)

GNUstep est déjà assez mature pour avoir les même applications dans les 2 mondes (MacOSX/Cocoa et GNUstep)

GNUStep à MacOSX
C’est le cas de GNUmail
ou de GWorkspace par exemple (attention le screenshot de GWorkspace est la 0.0.1 alors que la version officiel approche la 0.4)

ou de MacOSX/OpenStep à GNUStep comme
ToyViewer FreeTar ou CVL

lundi 16 septembre 2002 à 13h00

C’est quoi, le thÚme WindowMaker figurant sur la capture d’écran ?

Annonces

Annuaire LibreNord

Retrouvez l’annuaire de logiciels libres créé par l’association Club Linux Nord-Pas de Calais sur le site suivant http://www.librenord.org


Sur le Web

17 avril - L'Apes recrute son Assistant.e et animateur.rice de réseau

16 avril - #205 - Les évolutions majeures dans la gouvernance des logiciels libres - « Libre à vous ! » diffusée mardi 2 avril 2024 sur radio Cause Commune

16 avril - Rencontre d'auteur autour du livre "Penser avec la frontière"

15 avril - Revue de presse de l’April pour la semaine 15 de l’année 2024

15 avril - Les chaussures de sécurité les plus confortables

11 avril - Tour des Gull: Bookynette participe au petit déjeuner du libre spécial Libre en Fête à Wimille

11 avril - L'April présente avec un stand aux Rencontres Professionnelles du Logiciel Libre (RPLL) le 10 juin 2024 à Lyon

11 avril - Loi SREN : adoption du texte de la commission mixte paritaire

10 avril - L'April présente aux Journées du Logiciel Libre (JDLL) les 25 et 26 mai 2024 à Lyon

10 avril - Semaines de la Mer 2024

9 avril - Salon de la réparation #2

9 avril - Salon de la réparation #2 - samedi 20 avril à Genech

9 avril - OFFRE DE STAGE : FERME URBAINE DE LA GARE SAINT SAUVEUR

9 avril - Libre en Fête 2024 se termine : le bilan

8 avril - Ateliers Wikisource Autrices par Le Deuxième Texte et Wikipédia par Les sans pagEs samedi 13 avril 2024 dans les locaux de l'April

8 avril - Revue de presse de l’April pour la semaine 14 de l’année 2024

4 avril - Accompagnement local pour passer aux logiciels libres ou progresser dans vos usages

4 avril - Laurent Fayeulle au Centre de doc MRES

2 avril - Lettre d'information publique de l'April du 1er avril 2024

2 avril - 7e édition des journées écocitoyennes à Anstaing