GuieA_7 a écrit 689 commentaires

Je précise tout de suite, je suis le développeur principal de CremeCRM, histoire qu'il n'y ait pas d’ambiguïté.

Mon collègue/associé/ami a récemment mis à jour le tutoriel pour pouvoir installer la dernière version (la 1.5 pour laquelle je n'ai pas encore pris le temps de faire une dépêche…):
http://www.cremecrm.com/forum/viewtopic.php?f=14&t=617&p=886#p886

Autant installer Creme n'est pas forcément complètement trivial, autant le tutoriel détaille même l'installation de Django. Si tu n'arrives toujours pas à installer Django avec ça, il faudra se poser des questions ! :)

le CRM doit être sous licence GPL;

Affero GPL v3.
Il n'y a pas de version communautaire opposée à une version commerciale ; tout est libre.
En fait on va même plus loin puisque même si tu choisissais d'utiliser notre version SaaS, tu peux récupérer quand tu le souhaites ton code ET tes données ; on peut aussi installer sur ton propre serveur par exemple.

le CRM ne doit être qu'un CRM et le faire bien (ce qui correspond à la philosophie UNIX sur les logiciels, donc "exit" les solutions ERP proposant un module CRM)

C'est le cas ; bon après CRM ça peut vouloir dire beaucoup de chose. Par exemple entre un CRM pour les TPE et un CRM pour les grands comptes il va y avoir un grande différence, et je pense qu'il va falloir un peu préciser tes besoins pour trouver le CRM de tes rêves de toutes les façons.

si possible, mais ce n'est pas une obligation, avoir des applications ANDROID et iOS pour y accéder à distance

En temps que webapp, Creme a toujours été accessible depuis les mobiles. Mais comme ce n'était pas forcément aussi confortable que possible, la 1.5 vient avec une interface pour les téléphones (qui n'empêche pas d'accéder à l'interface classique) (mais pas de version déconnectée si c'était la question):
http://www.cremecrm.com/forum/viewtopic.php?f=14&t=614

l'interface doit être traduite en français;

C'est le cas.

Si tu as des questions, il y a notre forum ou même notre chan IRC (#cremecrm sur Freenode).

Bon week-end !

mais oui Windows est une daube à côté.

Je trouve ça assez "dangereux" ce genre de propos. Alors oui les Windows 9*/millenium étaient des gros tas de boue plantogènes bien loin de l'état de l'art ; ceci dit les desktops Linux de la même époque, même s'ils s'appuyaient sur un noyau de qualité n'étaient pas vraiment assez conviviaux pour être confiés à M. et Mme Michu (des années plus tard je devais encore recourir très souvent au terminal et je ne parle pas de développement) ; certes microsoft avait déjà un budget conséquent, mais si ce n'est pas vraiment la question.

De nos jours, d'un côté comme de l'autre on a un OS qui plante rarement et un environnement perfectible mais qui fait à peu prêt son taff. Alors oui j'utilise exclusivement (personnellement et professionnellement) Linux depuis plus de 10 ans, et j'en suis très content, mais quand j'ai sauté le pas c'était pour avoir un système libre (et de qualité), pas un système qui soit intrinsèquement supérieur à tous les niveaux (parce que ce n'est pas le cas).

Du coup si tu dis à des gens qui utilisent windows, et pour qui ça marche plutôt bien, que c'est de la daube à côté de Linux, ils vont s'attendre à débarquer dans un monde merveilleux, qui fait tout au moins aussi bien que windows (sur tous les points, même ceux qui ne dépendent pas vraiment de Linux) sans les trucs qu'ils n'aiment pas. Et du coup ils courent juste à la grosse déception.

Et après ils viennent pleurer ici en majuscule :)

Enfin, Ogre3D v2.1 à refondu la gestion du matériel (au sens 3D, pas au sens matériel de l'ordinateur)

En fait ce que tu appelles "matériel 3D" s'appelle plutôt "matériau" (métal, bois, pierre…) donc pas de confusion possible.

Si tu es un novice en programmation tout court, je te conseillerai dans un premier de ne pas chercher à découper ton code en plusieurs fichiers, et plutôt à comprendre les notions fondamentales (variables, types, structures de contrôle, classes, fonctions …), quitte à d'abord tout mettre dans un seul fichier. De toutes les façons tes premiers programmes seront très simples, et tu ne vas pas te lancer dans quelques chose de trop ambitieux sans avoir bien compris les bases.

Mais bon revenons à ta question, qui nécessite quelques explications préliminaires:

Lorsque tu fais import foo, 'foo' doit être :

1. à l'endroit où sont présents les libs Python de ton système.
2. dans le même module que ton fichier courant.

Pour connaître les chemins où va chercher python tu peux faire dans une console python:

import sys
sys.path

En fait le problème du point 2, c'est qu'un de tes propres fichiers peut masquer un module standard (ex: tu crées un fichier 'math.py'). C'est pourquoi à partir de Python3, la façon 2 disparaît, et tu peux du coup faire :

from math import cos # la c'est la lib standard
from .math import ta_fonction_a_toi # ton propre math.py

Note que tu peux utiliser ce comportement en Python2 en mettant from __future__ import absolute_import au début de tes fichiers.

Attention si tu veux utiliser des imports relatifs ('from .math import ') tu devras lancer ton script avec l'option '-m' (et sans le '.py') pour le considérer comme un module.

Du coup pour ta question, et ben soit :

• tu mets complement/ dans le même module.
• tu le mets avec les libs installées classiquement (genre dans ton virtualenv histoire de pas péter ton système).
• tu modifies l'environnement Python (ce que fait virtualenv au final), genre comme ça.

Il y a quelques années on associait me semble-t-il généralement Perl6 avec la VM Parrot. Ce n'est visiblement plus le cas ; en allant sur leur site, il semble pourtant que le projet soit encore bien actif, avec une 7.4.0 sortie il y a 15 jours. Bien que je n'ai jamais trop cru en ce projet, je le trouvais quand même intéressant.

Quelqu'un aurait-il des informations sur la relation entre les 2 projets du coup ?

Fichier __init__:
Ce fichier est présent dans tous les répertoires qui doivent être identifiés comme des modules python (je crois qu'on peut s'en passer dans les dernières versions de Python3).

Imaginons tu aies un un module de dessin gfx.py ; avec le temps celui-ci grossit pas mal et tu veux le découper ; tu crées alors un répertoire gfx/ dans lequel tu mets un __init__.py, et les autres fonctionnalités découpées (circle.py, square.py …). Le code présent dans __init__.py sera exécuté dès lors que tu vas faire un import gfx
Si tu veux accéder au code de dessin tu pourras faire (entre autres):

from gfx import foo # ca c'est pour le code dans gfx/__init__.py

from gfx import square # ensuite tu pourra faire square.Square(...)

from gfx.square import Square # ensuite tu pourra faire Square(...)

L’intérêt de mettre un from square import Square dans gfx/__init__.py c'est de pouvoir écrire directement :

from gfx import Square

L'idée étant de remonter les symboles les plus utiles par exemples, mais ce n'est pas du tout obligatoire.

chaque developpement python , faut il créer un environnement virtuel ou c'est crée directement par python ?

Je ne suis pas sûr de comprendre la question. De base Python va utiliser l'environnement de ton shell, et va alors chercher les libs installées par ta distro (ou 'pip' lancé sans virtualenv). Le problème c'est quand les libs fournies par ta distro n'ont pas la version que tu souhaites ; ou pire que tu veux faire cohabiter des softs utilisant des versions différentes des mêmes libs. Du coup ça dépend que ce que tu veux !
Si tu veux utiliser/suivre les versions des libs de ta distro (pour être inclus un jour dedans par exemple), ben tu ne vas pas utiliser de virtualenv pour ton soft. Si tu t'en tapes et que tu veux des versions plus récentes, alors oui un virtualenv sera sûrement indiqué (histoire de ne pas foutre la grouille dans ton système). Et si tu distribues ton soft, donne au moins le moyen d'installer les bonnes versions des libs (fichier requirements.txt que tu peux donner directement à manger à pip).

y a t-il une difference entre windows et linux en dev

Il me semble que faire des virtualenv sous windows est encore un peu compliqué, mais que ça évolue dans le bon sens. Et sous windows il faudra un peu de taff pour avoir un shell/terminal de qualité ; de plus, en pratique un certain nombre de packages Python ne sont pas testés sous windows, ou ne marche pas du tout avec (mais ce n'est pas une majorité hein).

Oui évidemment, je citais C++ pour l'exemple.

La "solution" adoptée par un certain nombre de langages (ex: Java, C#) va être d'interdire tout simplement l'héritage multiple ; ça évite de tomber sur le problème, mais du coup ça prive aussi d'un outil qui peut s'avérer puissant. Je n'ai pas vraiment d'avis sur le fait que cela soit une bonne ou une mauvaise solution.

De la la même manière la "solution" de Rust au problème est de mettre une restriction, en s'appuyant visiblement sur des écueils rencontrés avec Haskell. Il s'agit la aussi d'un compromis (un peu comme toujours en technique certes).

mais la problématique est bien : quelle méthode sera appelé en cas de double définition

C'est en ça que je trouvais que sémantiquement ça se ressemble. Mais mon commentaire était vague c'est vrai.
Je crois qu'on est d'accord en fait.

Ça explique tout merci.
Dans l'esprit ça ressemble au problème des héritages en diamant de C++ par exemple.

Merci à vous 2 pour vos réponses de qualitay.

Allez zou distribution de +1

Il me semble que seules la crate définissant WordCount et la crate définissant String pouvaient implémenter le trait pour String, tout autre crate n'en a pas le droit.

Si c'est le cas, alors je me suis un peu emporté ! À vérifier donc.

Par contre tu peux bien implémenter WordCount pour un type défini dans ton propre code.

Ah ben oui forcément, sinon ça va être difficile de faire des API ! Parce que définir dans ton code une classe avec une interface d'un autre package c'est un peu le truc de base.

La subtilité étant de pouvoir étendre des types définis ailleurs (comme bool), vu qu'étendre ses propres types ça tombe sous le sens.
En revanche oui, à vérifier si on peut étendre dans C un type défini dans A avec un trait défini dans B, j'ai peut être dit des bêtises pour ce cas ; le lien que j'ai donné au dessus (sur http://blog.rust-lang.org) ne parle pas d'une telle restriction, mais ce n'est pas une documentation exhaustive non plus…

Oui tout à fait, mais les traits vont quand même un cran plus loin.

Les méthodes d'extensions comme les traits permettent de dire : à partir de maintenant, les String ont la méthode wordCount() ; sans cela tu devrais, dans ton code, appeler une méthode statique prenant une String en paramètre (d'ailleurs comme l'explique ton lien il s'agit principalement de sucre syntaxique qui fait cet appel statique à ta place).

En revanche, les traits permettent aussi de faire la chose suivante :
si un code tiers définit le trait WordCount (ayant une méthode wordCount()), ainsi que des fonctions manipulant des objets implémentant ce trait, je peux dans mon propre code dire que les String (définies dans la bibliothèque standard que je ne peux/veux pas modifier) implémentent ce trait, et donc appeler les fonctions de ce code en lui passant directement des String. Ce n'est pas possible en C# de dire que maintenant String implémente l'interface IWordCount.

En C#, tu devrais soit :

• dériver de String dans une classe WordCountableString (bon en l'occurrence les String ne sont pas dérivables en C#, mais avec une autre classe ça aurait pu être une possibilité).
• créé une classe proxy WordCountableString qui wrappe un objet String.

Mais du coup si du code tiers te génère des objets String, tu devras construire un objet WordCountableString correspondant pour pouvoir les passer aux méthodes attendant des IWordCount ; ce qui alourdit à la fois le code et l'exécution (à cause d'objets supplémentaires 'inutiles').

Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).

À moins que je n'ai pas compris ce que tu voulais dire, tu te trompes. Dans ce très bon lien sur les traits (que j'avais déjà donné plus haut) on peut lire :

Unlike interfaces in languages like Java, C# or Scala, new traits can be implemented for existing types (as with Hash above). That means abstractions can be created after-the-fact, and applied to existing libraries.

Il faut certes déclarer explicitement que le type existant implémente bien ton propre Trait, mais il n y a pas besoin de modifier la bibliothèque standard pour ça, tu le fais dans ton propre code.

Ok merci pour ta réponse ça explique bien des choses.

OpenRTS est 100% original (pas de risque de conflit avec une licence existante), et sa licence MIT ne l'oppose pas à un usage commercial.

• Spring a depuis longtemps laissé tomber le 'T.A.' de son nom, donc je pense qu'un studio qui lui adjoindrait des assets originaux n'aurait aucun risque de conflit de licence je pense.
• Attention à ne pas opposer libre et commercial. Un jeu peut tout à fait être libre et commercial. Il peut aussi avoir un moteur libre (sous licence GPL par exemple dans le cas de Spring), des assets propriétaire et être commercial. Après on est bien d'accord une licence MIT sera sûrement plus attractive en pratique, les studios rechignant classiquement même s'il faut juste libérer leur moteur.

Je n'ai jamais prétendu le contraire ; C++ évolue sans casser la compatibilité et c'est très bien au vue du nombre de logiciels écrits en C++. Mais du coup C++ se traînera toujours certains boulets, malgré toutes ses évolutions.

Rust apporte une solution à bon nombre de ces boulets ; ça ne veut pas dire qu'il est parfait. On peut même être sûr que s'il est toujours utilisé dans 30 ans (ce qui n'est pas gagné encore une fois), on aura largement eu le temps de lui déceler des tas de boulet à lui aussi.

Après tu as tout à fait le droit de douter de l'intérêt de Rust. Mais les arguments à base de "C++ c'est utilisé depuis 30 ans dans des millions de logiciels nananère" ne sont pas franchement très intéressants. Oui c'est vrai la popularité de C++ est un avantage sur tous pleins d'aspects ; mais bon ici on est sur linuxfr, on en connaît plein des logiciels géniaux qui ne sont pas hyper connus, mais qui arrivent à vivre depuis longtemps (tout le monde ici connaît Blender , pourtant c'est loin d'être le cas de tous les graphistes).

Je n'ai vu personne sur le thread dire qu'il fallait réécrire tous les logiciels C++ en Rust ; et pour une bonne raison c'est que ça serait stupide. En revanche pour un nouveau logiciel (et des logiciels libres qui manquent ben y en a des tas), cela peut être un choix intéressant.

En fait depuis le début j'ai l'impression que quand les gens écrivent "Rust est peut-être le C++ du futur", tu lis "le C++ c'est de la merde, et les devs C++ sont des idiots" : ce n'est absolument pas le cas ! Les créateurs de Rust ont beaucoup pratiqué le C++, l'aiment et suivent de près ses évolutions ; ils sont confrontés aux mêmes problèmes, et les solutions du C++ sont très réfléchies.

Déjà bravo pour le travail accompli ; il y a un mois j'avais vu passé le projet sur FreeGamer, et la vidéo de l'éditeur de carte est vraiment très sympa.

En revanche je m'interroge : y a-t-il des fonctionnalités qui vous différencient de Spring ?

Par exemple je ne pense pas que Spring permette de faire autres chose que des classiques maps rectangulaires ; alors que dans le monde propriétaire j'aime beaucoup (sans y avoir jouer) Planetary annihilation qui propose des maps qui sont des systèmes solaires avec de petites planètes ! Mais pour le coup, OpenRTS m'a l'air tout aussi classique (c'est juste une fonctionnalité qui me parait intéressante, mais il y a sûrement moyen d'innover sur d'autres fronts).

Qu'on compare Rust à Go, par exemple, me semble bien plus pertinent. Mais bizarrement, ça n'est jamais fait.

Dans mon journal sur la version 0.7 je comparais déjà Rust à Go (et j'expliquais en quoi ces langages sont très différents sur bien des plans).

À côté de ça Rust a vraiment une philosophie proche de C++ ("What you don’t use, you don’t pay for") ; par exemple voir ici une explication très intéressante sur les traits.

Et sur le reddit de Rust, les clashes avec Go et C++ sont tous les deux très courants.

Au moins, les développeurs de Go, ils sont conscients, ils ont une vraie vision du marché et ils s'aperçoivent bien que le gros des développeurs Go, ce ne sont pas des développeurs C/C++, mais des développeurs Python/Ruby.

Mouais ils ont écrit Go pour leur propre usage (comme Mozilla), et au bout d'un certain temps à essayer de le 'vendre' aux développeurs C++ se sont aperçus que c'est plutôt les dev Python/Ruby que ça intéressait ; ce n'est pas une critique en soit, mais de là en faire des génies du marketing… Bien des réussites de l'industrie étaient complètement inattendues, et aujourd'hui mis à part les géants que sont Microsoft (avec C#) ou Apple (avec Objective-C et Swift), aucune entreprise n'est capable d'imposer un langage ; les autres ben ils essaient de faire de leur mieux et parfois c'est un succès. Mais bon on peut aussi dire que C++ c'est le mieux que pourra faire l'humanité et donc on arrête de chercher tout de suite.

L'industrie ne peut pas se permettre deux concurrents, et souvent, l'un des deux meurt. Ou alors trouve sa niche mais dans ces cas là, ils ne sont plus concurrents, chacun vit sa vie de son côté.

C'est vrai, quelques langages se taillent la part du lion, et les autres se retrouvent bien souvent à vivoter (au mieux). D'un autre côté on a aussi les couples C#/Java et Python/Ruby, dans lesquelles des langages quand même très proches évoluent en parallèle (restant concurrents) et ont tous des communautés suffisamment dynamiques pour trouver un peu tout ce qu'on veut en terme de bibliothèques.

Le potentiel c'est quand même important ; Javascript (ou Python/Go/Java/… peu importe) ne pourront jamais être aussi rapides (ou léger en mémoire) que C/C++, car leur sémantique les en empêchera toujours. À côté de ça, les performances de ces différents langages ont largement eu le temps de s'améliorer depuis leur 1.0  ; Go par exemple était en 1.0 il n'y a pas si longtemps, et les performances n'étaient pas terribles.

Pour l'instant, ils ont fait les optimisations faciles

Il reste, je crois, encore pas mal d'optimisations assez faciles (le code de rustc n'étant pas forcément génial), le plus important ayant été de stabiliser la sémantique du langage, afin de s'assurer par exemple que les évolutions futures soient réalisables sans tout casser. En effet le concept des références/temps de vie est différent de ce qu'on connaît ailleurs, et nécessite souvent de concevoir son code de manière différente ; il était important que cette nouvelle approche ne soit pas globalement une régression.

Il n'y a pas si longtemps par exemple un simple 'Hello world' en Rust prenait plusieurs Mo (car il embarquait toute la lib standard, un truc comme ça).

Évidemment aller chercher le potentiel demandera du temps et des ressources, et rien ne garanti qu'il sera atteint un jour. Les résultats actuels sont déjà très intéressants, on peut donc faire preuve d'un certain optimisme !

Et surtout, il pourra s'approcher du C/C++ sans le dépasser parce qu'il utilise la même technologie (LLVM) que Clang.

Pas forcément. Au alentours de la 0.7, je me rappelle que rustc était déjà capable dans certains cas d’émettre des informations d'aliasing pour LLVM (et qui permettent des optimisations), et qui ne pouvaient pas être émises par du code C++ (le langage n'ayant pas la sémantique adéquate).

c'est pour ça qu'il s'appelle rouille, c'est les vieux trucs qui marchent

Non, ce n'est pas pour ça : http://www.reddit.com/r/rust/comments/27jvdt/internet_archaeology_the_definitive_endall_source/

En gros, la rouille un champignon robuste, distribuée et parallèle.

À l'heure actuelle, pour réussir à allumer 1 pixel, il faut se taper une bibliothèque… non, pire en fait, un framework complet… À l'époque ou l'accès au matos était direct, il suffisait de quelques lignes d'assembleur, de l'ordre de quelques 10aine

Mouais bof.

Tu prends 2 minutes (sûrement moins en fait sur n'importe quelle distro linux) pour installer pygame (par exemple), et pareil en 10 lignes tu fais une fenêtre et tu affiches un sprite. En quelques lignes tu peux le faire bouger avec les touches du clavier ; en 2 lignes tu joues une musique de fond, et 20 lignes tu fais un système basique de lecture/écriture de sauvegarde ; etc…

Que tu aies découvert les joies de la programmation avec l'assembleur, très bien. Je suis aussi passionné que toi, mais moi j'ai commencé par le BASIC (et j'ai fait du langage assembleur plus tard, en école d'ingénieur). Et les jeunes d'aujourd'hui, ils découvriront leur passion avec encore autre chose, peu importe.

Quand je vois le mal que mes profs d'info ont eu (2006-2007) à expliquer aux autres ce qu'était un pointeur ensuite, alors que la plupart des gens venaient de STI électronique, je me demande si commencer par du matos et des techniques obsolètes mais simples n'a pas un certain intérêt.

1. Pour moi tous les professionnels de la programmation doivent avoir fait pendant leur cursus de la programmation en langage assembleur (mais aussi en C, et de l'objet, et du fonctionnel, mais c'est un autre problème) et savoir un minimum comment fonctionne un processeur. Pendant mes études (2001/2004) c'était du MIPS (mais simulé, pas de machine physique), et c'était très bien. Mais dire qu'il faut commencer la programmation par là, alors non, c'est vraiment un autre problème.
2. Les passionnés, dans un domaine qui s'est autant répandu, sont toujours une minorité ; la plupart des programmeurs ont choisi ce domaine parce qu'ils pensent qu'ils pourront trouver du boulot . Ça ne veut pas dire qu'ils trouvent ça inintéressant, juste qu'il ne passeront pas des heures sur leur temps libre à coder par exemple. C'est triste, mais moi aussi en fin de cursus d'ingénieur, des tas de mes camarades ne savait même pas faire des malloc()/free() correctement ; cela n'a pourtant pas grand chose à voir avec une quelconque simplicité des outils, juste le fait de ne pas trop avoir envie de se creuser la tête…

Dans mes souvenirs qu'il y a quelques années, les développeurs d'OpenBSD avaient choisit que garder le verrou global, car mettre des verrous plus fins, en rendant le code plus complexe (et donc plus dur à auditer d'un point de vue sécurité) ne valait pas le coup dans leur optique de sécurité avant tout.

Qu'est ce qui a changé depuis ? Les problèmes de performances, avec la présence de multi-core dans la machine de Mme Michu, ont-ils rendu à présent le compromis intéressant ? Sont-ils plus nombreux pour pouvoir maintenant auditer un code plus complexe ? Ont-ils juste changé d'avis ?

Pourtant c'est très possible ; pas à Paris j'imagine, mais en province si (je suis à Marseille). J'ai été au SMIC pendant plusieurs années (monter sa boite c'est travailler plus pour gagner moins :) ), et oui économiser 250€ par mois était habituel :

• 500€ de loyer (y a moyen de trouver moins cher et plus grand, mais j'ai choisi de rester dans un quartier qui me plaît plus).
• 200€ de bouffe par mois (et en achetant pas mal de bio).
• 100€ pour assurance, internet, électricité, gaz, bus/métro (la moitié est payée par l'employeur).
• il reste encore 80€ pour les loisirs (si je table sur 250€ d'économie).

Tout d'abord je tiens à dire que je trouve votre projet très intéressant. En revanche, il soulève pas mal d'interrogations chez moi.

• Quand tu parles de film, tu parles d'un long métrage (genre plus de 1h) ?
• Sur votre site je n'ai pas vu la composition de l'équipe ; en plus de toi et d'Ahryeom, combien êtes-vous pour faire l'animation ?
• Lorsque vous mettrez en place la campagne de financement, y aura-t-il ne serait que quelques secondes d'animation (genre mini bande annonce) pour se rendre compte de la qualité de l'animation finale ?

• BlueMind distribue aussi au moins un plug-in proprio et payant et fait du service payant (heureusement pour eux), je ne vois pas en quoi ça peut être qualifié de "modèle totalement gratuit".
• Linagora vend principalement du service autour de logiciels libres qu'ils n'ont pas forcément développés (genre LibreOffice)(ce qui n'est pas un reproche encore une fois) ; donc pas de "modèle totalement gratuit" dans ce cas là non plus.
• de manière général aucune boite ne peut avoir un "modèle totalement gratuit", ça n'a pas de sens.

Si tu voulais dire qu'ils développent entre autre du logiciel libre (et gratuit), ben il fallait le dire. Mais bon c'était plus facile de balancer 3 questions absconses sans début de réponse, comme si tu voulais qu'on fasse tes devoirs.

sur des modèles totalement gratuits

Ça ne veut rien dire ! C'est quoi des modèles gratuits ? Selon ce que tu entends alors facebook et google aussi c'est du modèle gratuit ; et on n'est plus du tout dans le libre/oss du coup.

(Vu que les questions du journal était déjà incompréhensibles c'est dans le ton)