Il est maintenant possible de lire et sauver des fichiers "nib" venant de MacOS X.
Quelques explications : avec GNUstep et Cocoa, l'interface d'un programme est généralement créé via un outil graphique (InterfaceBuilder sous Mac OS X, Gorm sous GNUstep) et sauvée dans un fichier "nib". Le format des nib étant propriétaire, GNUstep avait son propre format lui permettant d'être portable. Apple ayant décidé de basculer avec les dernières versions d'OS X à un format XML, il était théoriquement possible d'ajouter le support des nib OS X à GNUstep. C'est désormais chose faite ! La nouvelle version de Base apporte de nouvelles classe : NSPredicate, meilleure gestion des URL (implémentant les dernières additions d'Apple aux API), et améliore également le support sous Windows.
Du côté de GUI, le changement le plus notable est le support de l'encodage par clé (key encoding) pour toutes les classes graphiques -- ce qui veut dire qu'il est maintenant possible de lire et sauver des fichiers nib venant de Mac OS X.
Il est donc maintenant possible de prendre un programme Cocoa et de le recompiler tel quel sous GNUstep, sans nécessiter de recréer l'interface graphique avec Gorm. De la même façon, on peut prendre un programme GNUstep et le recompiler sous OS X, sans devoir recréer l'interface sous InterfaceBuilder. Bref, un gain de temps extrêmement appréciable, d'autant plus qu'un "nib" contient bien plus que la description de l'interface graphique -- c'est en fait une sérialisation du graphe d'objet, contenant du coup tous les attributs et relations entre objets...
En dehors de cette avancée, les bugfixes usuels, améliorations sur de nombreuses classes (NSWorkspace, GSSystemManager, NSHelpManager, NSTableView, NSToolbar, etc.), support du RTFD, un brin de nettoyage du côté graphique, un commencement de l'intégration avec camaelon (thème), un meilleur support de la GDI sous Windows, ainsi que des progrès sur le backend Cairo.
GWorkspace vient juste de sortir une nouvelle version (0.8.3) , qui apporte beaucoup de bugfixes, ainsi que de la documentation en ligne.
Aller plus loin
- GNUstep (43 clics)
- Gorm (12 clics)
- GWorkspace (9 clics)
- WP: Qu'est-ce que GNUstep ? (57 clics)
# youpi c'est mercredi !
Posté par dinomasque . Évalué à 6.
~> []
BeOS le faisait il y a 20 ans !
[^] # Re: youpi c'est mercredi !
Posté par yoho (site web personnel) . Évalué à 10.
# Incompétence
Posté par Rémi baudruche . Évalué à 6.
Bref, j'y comprend pas grand chose sur le rapport avec mac-os
Ca veux dire qu'on pourra faire tourner des programmes mac-os sous gnu-step et inversement ?
J'ai comme l'impression d'être à coté de la plaque....
[^] # Re: Incompétence
Posté par ThesmallgamerS . Évalué à 6.
Avant, le fichier qui décrivait l'interface du programme était incompatible avec GnuStep. Il fallait donc en faire un autre pour porter un programme sous GnuStep.
[^] # Re: Incompétence
Posté par anakin . Évalué à 9.
[^] # Re: Incompétence
Posté par iznogoud . Évalué à 8.
Le .nib, c'est un descriptif de l'interface. Donc, d'une part, les fenêtres, comment les divers éléments s'agencent... Mais aussi et surtout, comme le dit la dépêche, tout ce qui lit l'interface au code. Pour faire une espèce de comparaison un peu foireuse, l'interface, c'est la carrosserie de ta voiture, le code de l'application, le moteur. Le .nib va contenir la carrosserie, mais aussi ce qui lit la carrosserie au moteur.
En général, tu construis donc une interface, à laquelle tu vas lier des événements, des actions, des descriptifs d'objets...
Ensuite, tu génères des templates de code, et tu remplis. C'est très pratique :)
[^] # Re: Incompétence
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
Il y a deux principaux avantages à cette approche: 1) ça fait largement moins de code à écrire ou maintenir 2) un nib n'est pas du tout limité aux objets "graphiques" (boutons et autres) mais on peut tout à fait inclure dans le nib n'importe quel objet (objet controlleur de l'interface, un objet métier, etc)
Du coup on peut aussi créer des palettes d'objets à soit et utiliser Gorm (ou IB) comme un outil de RAD très haut niveau, et créer un programme en deux-clics de souris sans une ligne de code ;-) -- bref cette approche permet de réutiliser très facilement des composants.
voir les vidéos de démo: http://xdev.org/gnustep/ (flash)
[^] # Re: Incompétence
Posté par L Guillaume . Évalué à 1.
[^] # Re: Incompétence
Posté par Nicolas Roard (site web personnel) . Évalué à 5.
[^] # Re: Incompétence
Posté par L Guillaume . Évalué à 0.
[^] # Re: Incompétence
Posté par Larry Cow . Évalué à 1.
[^] # Re: Incompétence
Posté par L Guillaume . Évalué à 1.
[^] # Re: Incompétence
Posté par L Guillaume . Évalué à 1.
effectivement ce n'est pas pour la prochaine release le passage à cocoa
[^] # Re: Incompétence
Posté par Larry Cow . Évalué à 4.
Tant qu'il y aura portage d'applications vers le Mac et que l'ObjC ne sera pas plus répandu, Carbon n'a aucune chance de commencer à disparaître. Le contraire consisterait à se couper de la plupart des développeurs, et Apple n'en a clairement pas envie.
# À quoi bon ?
Posté par GPLorDIE . Évalué à 0.
Ce projet rend service à Apple en familiarisant des milliers de développeurs à leurs API propriétaires. Comme toute les API ne seront jamais réimplémentées à 100% dans GNUstep tôt ou tard le développeur libre franchira le pas et passera à Xcode et tout ce qui va avec et il sera perdu pour le monde GNU/Linux (ou BSD, etc etc).
[^] # Re: À quoi bon ?
Posté par Gniarf . Évalué à -2.
ne mélangeons pas les torchons et les serviettes.
[^] # Re: À quoi bon ?
Posté par Nicolas Roard (site web personnel) . Évalué à 10.
Pour faire simple: si Apple n'avait pas racheté NeXT et transformé NeXTSTEP en Mac OS X, et même imaginons que NeXT ait coulé complètement... Et bien il y aurait toujours des gens développant GNUstep. L'api et des outils comme Gorm sont, par eux-mêmes, intéressants. Ca reste l'environnement de développement le plus génial et bien foutu que je connaisse (si on excepte Smalltalk -- mais si Smalltalk est un environnement/langage assez fabuleux, l'api est une bouse à bien des égards comparé à OpenStep).
Le fait qu'Apple utilise Cocoa n'est que la cerise sur le gateau pour ceux que ça intéresse; on n'est pas du tout dans le cas de Wine par exemple, ou je doute que les développeurs bossent sur Win32 car ils trouvent l'api agréable à programmer.
[^] # Re: À quoi bon ?
Posté par - - . Évalué à 8.
c'est que l'API openstep et les outils de développement de NeXTstep allié à Objective C en faisait le meilleur environnement de développement unix du moment.
maintenant c'est Xcode/cocoa sous Os X. voilà tout.
---------------------
Gnustep est la plus grande erreur de Gnome et KDE : ils auraient du tous se lancer dans gnustep
voilà ce que je pense.
oui gnustep était (est?) balbutiant à l'époque mais tout le prototypage était fait, le langage Objective C gommait bien des débats stériles sur C/C++/JAVA/Mono etc grâce à un runtime puissant et complet
et non l'api n'est PAS propriétaire.
enfin bref, gnustep est simplement victime d'une non-rencontre. au moment du lancement de Kde par dessus QT et de Gimp 0.x les développeurs ne sont pas tombés sur gnustep ou le modèle de gnustep semblaient être trop compliqué pour le simple but du moment.
mais ce fut une erreur.
[^] # Re: À quoi bon ?
Posté par toctoc1 . Évalué à -1.
Autant je comprends ton argumentaire sur les qualités intrinsèques de gnustep, autant (et je reconnais que c'est terriblement subjectif) je trouve l'ensemble terriblement laid et dépassé (esthétiquement et ergonomiquement).
je fais le parallèle avec les voitures : la Fuego était une chouette bagnole. Mais qui roule encore en Fuego?
vous pouvez moinser, c'est pas un souci... :D
[^] # Re: À quoi bon ?
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
[^] # Re: À quoi bon ?
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Le seul environnement que je trouve plus évolué qu'OpenStep avec son InterfaceBuilder/Gorm est Squeak (un environnement Smalltalk), mais son ergonomie et surtout son approche micro-monde peut rebuter (j'avoue avoir moi même du mal).
# RTFD
Posté par oops (site web personnel) . Évalué à 0.
Il n'est en rien un format standard ( ni standard normalisé / ni standard de fait ).
[^] # Re: RTFD
Posté par Nicolas Roard (site web personnel) . Évalué à 4.
Mais le RTF est le format par défaut sous NeXT/GNUstep/ OS X pour le texte enrichi; et GNUstep savait donc déja lire/sauver du RTFD. Étendre le parseur pour du RTFD était trivial. le RTFD est une simple application du concept de bundle (en gros, considérer un répertoire comme un document) à un document RTF : c'est tout bêtement un répertoire contenant un ou plusieurs fichiers RTF accompagnés éventuellement d'images ou fichiers liés.
Bref 1) c'était simple à ajouter 2) ça existait sous NeXT et OS X 3) surtout, c'est un moyen simple de sauver facilement n'importe quel contenu enrichi à partir de n'importe quel textview, même contenant des images. Du coup par exemple, TextEdit peut être utilisé comme mini traitement de texte, il suffit de drag'n dropper des images dans la vue texte.
Accessoirement, le code pour lire/sauver du RTF(D) est gêré par un bundle (~plugin) sous GNUstep -- on peut tout à fait avoir le même genre de bundle pour d'autres formats (je voudrais d'ailleurs ajouter HTML en sauvegarde par exemple). Et la beauté de la chose du tout objet c'est là encore que toutes les vues textes disposeront de cette capacité automatiquement... (sans même recompiler)
[^] # Re: RTFD
Posté par Nicolas P. . Évalué à 1.
Tiens, c'est intéressant. Les bundles GNUstep ou Cocoa ne sont donc pas implémentés sous forme de librairies ? Ou alors ça vient du fait qu'en objective C les appels de méthodes sont résolus à l'exécution ?
[^] # Re: RTFD
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Ceci dit, ce que je dit marche(rait) aussi avec des "plugins" normaux -- c'est juste qu'objective-c est dynamique et baigne dans le polymorphisme... donc ce genre de chose est faisable bien plus facilement.
[^] # Re: RTFD
Posté par dinomasque . Évalué à 2.
Pourtant BeOS n'utilise que du bon vieux C++ des familles (tout le système de messagerie inter-processus était une API C++)
BeOS le faisait il y a 20 ans !
[^] # Re: RTFD
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
[^] # Re: RTFD
Posté par oops (site web personnel) . Évalué à 3.
> messagerie inter-processus était une API C++)
Ce n'est pas inter-processus. C'est un runtime ( donc de plus bas niveau ).
http://www.macdevcenter.com/pub/a/mac/2002/05/24/runtime_par(...)
et
http://www.macdevcenter.com/pub/a/mac/2002/05/31/runtime_par(...)
pour plus d'infos.
[^] # Re: RTFD
Posté par Nicolas Roard (site web personnel) . Évalué à 1.
[^] # Re: RTFD
Posté par shbrol . Évalué à 2.
[^] # Re: RTFD
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
Comme ide, y'a aussi ProjectManager (http://home.gna.org/pmanager/) qui est plutôt sympa.
Comme bouquin, je conseille celui d'Aaron Hillegass, excellent (plutôt l'édition anglaise que française, dont j'ai trouvé la traduc très moyenne, mais bon..). Y'a aussi celui de Garfinkel qui est paraît il très bien. Ils sont orientés Cocoa (même si Aaron parle de GNUstep, m'enfin il parle d'une vieille version...), mais sont focalisés sur le framework, donc appliquables plus ou moins tel quel à GNUstep. Concernant Objective-C uniquement, il y a le très complet petit guide d'O'Reilly sur Objective-C.
[^] # Re: RTFD
Posté par oops (site web personnel) . Évalué à 5.
- Apprendre le C
- Apprendre les grand design patterns
- Le petit guide O'Reilly ( Apprendre l'ObjC lorsque l'on connait le C est tivial )
- Les APIs GNUstep
[^] # Re: RTFD
Posté par Miguel Moquillon (site web personnel) . Évalué à 1.
Ce que j'aime dans l'approche de ProjectCenter est qu'il suit celle de Smalltalk ; en effet, je n'aime pas les approches à la Visual C++ où d'un côté tu as une arborescence de tes sources (que je trouve moins facile à utiliser), de l'autre ton code et pour finir tout un tas de boites de propriétés et une liste arborescente du contenu de tes classes d'objets, attributs et méthodes mélangés. J'epsère que ProjectManager ne va pas tomber dans ce travers horrible, mais au vue des captures d'écran, je crains le pire.
# http://jesseross.com/clients/gnustep/ui/concepts/
Posté par ctorah . Évalué à 1.
http://jesseross.com/clients/gnustep/ui/concepts/
Le truc du bas serait jolie à la place de window maker
[^] # Re: http://jesseross.com/clients/gnustep/ui/concepts/
Posté par Nicolas Roard (site web personnel) . Évalué à 3.
[^] # Re: http://jesseross.com/clients/gnustep/ui/concepts/
Posté par ctorah . Évalué à 1.
[^] # Re: http://jesseross.com/clients/gnustep/ui/concepts/
Posté par Nicolas Roard (site web personnel) . Évalué à 2.
Si tu parles du support des thèmes sous gnustep, ça fait très longtemps qu'on peut les utiliser... La seule chose c'est que le dit support n'est pas inclu par défaut, faut utiliser Camaelon, mais c'est pas la mort à utiliser hein... J'ai une branche sur le repository gnustep pour intégrer certaines parties de camaelon, mais j'avance pas très vite (j'ai plein d'autres trucs sur le feu, et une thèse à finir). L'intégration serait un _plus_ pour diverses raisons, mais n'est pas nécessaire -- la preuve, on utilise Camaelon avec étoilé, et on utilise bien le thème Nesedah par défaut...
Accessoirement, le look en question, ça peut difficilement faire 2-3 ans -- au pire ça fait dans les un peu plus d'un an, vu que c'est dans ces environs qu'il a été créé par jesse ross si je dit pas n'importe quoi.
'fin bon c'est comme tout hein, si y'a des contributeurs tout ça avance plus rapidement, bizarrement :-)
[^] # Re: http://jesseross.com/clients/gnustep/ui/concepts/
Posté par ctorah . Évalué à 1.
http://linuxfr.org/comments/643059.html#643059
C'est juste que le concept 01 m'avait bien plu et j'avais pensé que ça remplacerai avantageusement window maker.
mea culpa
[^] # Re: http://jesseross.com/clients/gnustep/ui/concepts/
Posté par Miguel Moquillon (site web personnel) . Évalué à 2.
Par exemple, pour le système d'onglets à la place d'un dock, pourquoi pas, mais le menu horizontal, je ne suis pas très chaud.
En fait, je préfère l'approche du menu vertical de NextStep mais qui serait "accolé" à l'extrémité supérieur gauche de la fenêtre de l'application et qui disparaitrait lorsque l'on passe d'une application à l'autre (au lieu d'être toujours situé au coin supérieur gauche).
A côté de ceci, par rapport au dock, j'aime bien l'approche d'apwal.
# Installer GNUStep ?
Posté par Mildred (site web personnel) . Évalué à 4.
- D'abord, les paquets GNUStep des distributions sont ils en général à jour (avec étoilé et tout) ou alors je dois tout compiler à la main ?
- Quels programmes installer (GWorkspace ?) et qu'est ce que je dois mettre dans mon ~/.Xsession ?
- Il me semble qu'on utilise WindowMaker comme gestionnaire de fenêtre ... comment intégrer le mieux les applications GNUStep et WindowMaker.
- Le style de WindowMaker s'adapte il aux styles etoilés ?
- Comment utiliser le gestionnaire de fichiers GNUstep ? Imme semblait que j'avais du mal à ouvrir un fichier avec une application X classique.
J'ai vraiment envie de l'installer, pour le découvrir, pour faire des programmes utilisant GNUStep ... mais lorsque je vais sur le site, je ne vois rien de tout ça, et le site insiste pour dire que c'est juste un frameword. Enfin, derrière il y a quand même un bureau comme on peut le voir sur bon nombre de sceenshoots.
[^] # Re: Installer GNUStep ?
Posté par Nicolas Roard (site web personnel) . Évalué à 6.
Ceci dit, c'est pas non plus bien difficile à compiler à la main... si les dépendances sont installées.. Un post d'il y a deux jours de Yen-ju : http://www.etoile-project.org/etoile/blog/2006/08/short-guid(...) explique tout ça.
Comme programme, ça dépends de ce que tu veux... GWorkspace comme file manager par exemple; si tu installes étoilé, EtoileMenuServer, etc.
Concernant WindowMaker, non, il ne s'adaptera pas aux thèmes gnustep; pour étoilé on a notre propre window manager, Azalea.
J'ai vraiment envie de l'installer, pour le découvrir, pour faire des programmes utilisant GNUStep ... mais lorsque je vais sur le site, je ne vois rien de tout ça, et le site insiste pour dire que c'est juste un frameword. Enfin, derrière il y a quand même un bureau comme on peut le voir sur bon nombre de sceenshoots.
C'est tout le problème... ce n'est qu'un framework, oui; mais d'un autre côté, il fournit tout ce qu'il faut (presque) pour avoir un bureau (cad que le framework fournit aussi quasiment tout les services nécessaires à un bureau -- notifications, préférences, notion de workspace commun, etc), de telle sorte que simplement utiliser une appli comme gworkspace (pour avoir un gestionnaire de fichier) et d'autres applis utilisant gnustep suffit pour avoir un bureau bien intégré (cf le livecd). D'ou l'ambivalence de GNUstep. Si tu veux, c'est au même niveau que les KDE libs -- elles ne sont pas le bureau KDE, mais elles fournissent tout ce qu'il faut pour créer des applis qui ensemblent forment un bureau.
Sauf qu'en plus, GNUstep fournit des applis pour le développement (Gorm, project center, etc) et même des applis qui sont carrèment fait pour un bureau comme gworkspace.
Mais GNUstep en tant que projet n'a pas eu comme objectif (et rétrospectivement c'est certainement une erreur) de créer un bureau. Il aurait fallu avoir cet objectif depuis longtemps, ou au moins un projet frère chargé d'en créer un...
Pour le moment, étoilé progresse bien, et régulièrement; mais on n'a pas encore un truc tout prêt à utiliser offrant un bureau nickel. Étoilé reste pour le moment une série de librairies, d'outils et d'applications (aaargh on dirait gnustep !!!). Mais bon on espère très fort avancer vite fait vers un bureau réellement utilisable :-D et en particulier, un filemanager + desktop + gestionnaire de session qui tienne la route (gworkspace ne nous plait pas pour diverses raisons).
En attendant.. ben je dirait que la combinaison gworkspace + window maker reste le plus sûr, plus project manager pour le développement ( http://pmanager.sf.net ) et gorm évidemment..
[^] # Re: Installer GNUStep ?
Posté par Mildred (site web personnel) . Évalué à 7.
Après, ce que je me demande, c'est comment utiliser GWorkspace. J'ai un exemple très concret. Mon fichier .Xsession (ou .xinitrc, j'ai oublié) contient un script qui va grace à xmessage me demander quelle session je veux lancer (Gnome, Xfce, Etoile, Fvwm ...). Je voulais le modifier pour rajouter Etoilé dans la liste à l'aide de mon éditeur favori (kwrite)
Je prend GWorkspace, je vais jusqu'au fichier et j'essaie de l'ouvrir, rien à faire, rien ne se passe. Le clic-droit ne propose pas bien plus de choix, je finis par me résoudre à utiliser thunar.
Sinon, dans les System Preferences, section Modifier Keys, le changement des touches de fonctions ne marche pas du tout, du moins je n'arrive pas a faire quelque chose qui puisse être remarqué. De plus dans la section Volumes, il s'obstine à me mettre les chemins par défaut dans Mount points for removable media (/mnt/*) alors que mon système utilise /media/*
De plus, avec Azalea lorsqu'on maximise une fenêtre comme Epiphany, la barre de titre se retrouve cachée par la barre de menus. Un peu gênant même si Alt-clic sur la fenêtre permet d'afficher le menu du WM.
Voila mes premières impressions. Mais bravo pour ce joli bureau. Avec un panel en bas qui permet de switcher entre les fenêtre, d'avoir des bureaux virtuels et une zone de notification pour gajim, gmpc et d'autres, c'est parfaitement utilisable. Reste à switcher vers des applications GNUstep qui sont malhereusement trop rares.
[^] # Re: Installer GNUStep ?
Posté par Mildred (site web personnel) . Évalué à -2.
Après, ce que je me demande, c'est comment utiliser GWorkspace. J'ai un exemple très concret. Mon fichier .Xsession (ou .xinitrc, j'ai oublié) contient un script qui va grace à xmessage me demander quelle session je veux lancer (Gnome, Xfce, Etoile, Fvwm ...). Je voulais le modifier pour rajouter Etoilé dans la liste à l'aide de mon éditeur favori (kwrite)
Je prend GWorkspace, je vais jusqu'au fichier et j'essaie de l'ouvrir, rien à faire, rien ne se passe. Le clic-droit ne propose pas bien plus de choix, je finis par me résoudre à utiliser thunar.
Sinon, dans les System Preferences, section Modifier Keys, le changement des touches de fonctions ne marche pas du tout, du moins je n'arrive pas a faire quelque chose qui puisse être remarqué. De plus dans la section Volumes, il s'obstine à me mettre les chemins par défaut dans Mount points for removable media (/mnt/*) alors que mon système utilise /media/*
De plus, avec Azalea lorsqu'on maximise une fenêtre comme Epiphany, la barre de titre se retrouve cachée par la barre de menus. Un peu gênant même si Alt-clic sur la fenêtre permet d'afficher le menu du WM.
Voila mes premières impressions. Mais bravo pour ce joli bureau. Avec un panel en bas qui permet de switcher entre les fenêtre, d'avoir des bureaux virtuels et une zone de notification pour gajim, gmpc et d'autres, c'est parfaitement utilisable. Reste à switcher vers des applications GNUstep qui sont malhereusement trop rares.
PS: linuxfr me dit que «Votre commentaire a déjà été posté» alors que ce n'est pas le cas lorsque je lis la dépêche. Si je le poste en double, veiller l'excuser, merci
# Plagiat
Posté par gaolinn . Évalué à -8.
[^] # Re: Plagiat
Posté par mickabouille . Évalué à 4.
1. Il implémente une API/norme/cequetuveux publique? (java, openstep, posix...)
2. Il ressucite une API qui est morte et que certains voulaient continuer à utiliser? (longtemps avant l'autre résurrection par apple)
3. Il s'amuse avec des trucs sympas entre deux séances de prog en C++ ou avec les APIs win32...
À toi de voir, je sais pas moi...
[^] # vive le pompage
Posté par Rémi baudruche . Évalué à 3.
J'ai trouvé tout seul cette jolie phrase ! si si !
Moi ce qu'il me plait avec le ll c'est justement le pompage : si quelqu'un a déja fait quelque chose autant le pomper et tant qu'a faire l'améliorer plutôt que de réinventer la roue à chaque fois
[^] # Re: vive le pompage
Posté par gaolinn . Évalué à -4.
La créativité c'est quoi pour les Linuxiens, repomper à tours de bras ou inventer de nouveaux concepts.
[^] # Re: vive le pompage
Posté par oops (site web personnel) . Évalué à 4.
[^] # Re: vive le pompage
Posté par Thomas Douillard . Évalué à 4.
Un autre intérêt : l'interropérabilité facilitée entre OSX et tous les OS sur lesquels tourne GNUStep.
Enfin, dire que GNUStep n'invente pas de nouveaux concepts, certe, mais de là à dire qu'il y a pas de créativité dans le LL, c'est douteux. Par exemple : de nombreux chercheurs publient du code en GPL, du code issu de recherche, donc pas forcément utilisable tel quel, mais à priori avec des trucs inédits dedans ...
[^] # Re: vive le pompage
Posté par Erwan . Évalué à 3.
Il n'y a pas "le logiciel libre" (ou "les linuxiens") contre "le logiciel proprietaire" comme deux equipes de foot qui s'affronteraient. C'est (excuse-moi parce que ca fait trop longtemps que je lis des trucs comme ca) completement con de comparer libre et proprio comme deux equipes qui s'affrontent.
Tu peux trouver des gens qui font du logiciel proprietaire et qui se detestent (Apple et Microsoft), des gens qui font du LL et qui ne s'entendent pas tres bien (Emacs et VIM) voire se detestent car ils ont une facon de penser completement differente (Emacs et XEmacs).
Tu peux aussi trouver des gens qui melangent libre et proprio (nvidia), ou des boites qui font du libres et passent un accord avec un editeur de softs proprios (Mozilla Corp et Google).
[^] # Re: vive le pompage
Posté par Larry Cow . Évalué à 8.
Tu veux dire que tu as oublié à qui tu l'as empruntée? ;)
# ils pourraient mettre à jour leur #$*%£@ de page !!!!!
Posté par Nicolas P. . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.