In article ,
Wilk wrote:Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez
contradictoire...
Pour ne pas s'appuyer sur une couche logiciel propietaire en evitant
ainsi un sur-cout du produit.
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
La protection des sources sert surtout à ne pas encourager le
developpement specifique et donc a preserver l'integriter du framework
pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
In article <87652zzfg4.fsf@chat.blakie.riol>,
Wilk <wilk-ml@flibuste.net> wrote:
Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez
contradictoire...
Pour ne pas s'appuyer sur une couche logiciel propietaire en evitant
ainsi un sur-cout du produit.
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
La protection des sources sert surtout à ne pas encourager le
developpement specifique et donc a preserver l'integriter du framework
pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
In article ,
Wilk wrote:Pourquoi utiliser des logiciels open source dans ce cas ? C'est assez
contradictoire...
Pour ne pas s'appuyer sur une couche logiciel propietaire en evitant
ainsi un sur-cout du produit.
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
La protection des sources sert surtout à ne pas encourager le
developpement specifique et donc a preserver l'integriter du framework
pour ne pas rendre plus complexe la maintenance.
Tu pourrais détailler ton raisonnement ?
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
Dans ton message précédent tu parlais d'entreprises ne voulant pas
investir dans l'open-source. Hors développer un logiciel dessus c'est
déjà s'investir dans l'open-source.
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
Dans ce cas il suffit d'avoir un md5 du programme.
C'est une solution pour controler le "niveau de version". Pas pour
Mais comme tu le dis, si le client modifie les sources sans le dire
puisqu'il n'a pas les droits, il va être emmerdé lors de chaque mise à
jour, ce n'est pas dans son intérêt. Donc il renvoi la modification pour
qu'elle soit intégrée et tt le monde y gagne.
Et si il n'installe plus les mises à jour, c'est un client perdu, donc
peu importe qu'il modifie les sources où non.
Mieux vaut prevenir que guerrir. Il vaut mieux que la solution vienne de
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
Dans ton message précédent tu parlais d'entreprises ne voulant pas
investir dans l'open-source. Hors développer un logiciel dessus c'est
déjà s'investir dans l'open-source.
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
Dans ce cas il suffit d'avoir un md5 du programme.
C'est une solution pour controler le "niveau de version". Pas pour
Mais comme tu le dis, si le client modifie les sources sans le dire
puisqu'il n'a pas les droits, il va être emmerdé lors de chaque mise à
jour, ce n'est pas dans son intérêt. Donc il renvoi la modification pour
qu'elle soit intégrée et tt le monde y gagne.
Et si il n'installe plus les mises à jour, c'est un client perdu, donc
peu importe qu'il modifie les sources où non.
Mieux vaut prevenir que guerrir. Il vaut mieux que la solution vienne de
Les projets qui s'appuient sur de l'open source ne sont pas tous
obligatoirement open source.
Dans ton message précédent tu parlais d'entreprises ne voulant pas
investir dans l'open-source. Hors développer un logiciel dessus c'est
déjà s'investir dans l'open-source.
C'est simple : Une entreprise qui achete les sources est libre de les
modifier à sa guise. Si elle n'achete pas les sources, elle n'a pas le
droit de les modifier. Cependant, avec un script "en clair" la tentation
peut etre grande de vouloir faire la modification soit meme, car suivant
les clauses contractuelles, la maintenance peut aussi avoir un cout. Et
bien sur, cette modification ne sera pas repertoriee. Cerise sur le
gateau, en cas de livraison d'une nouvelle version, ces modifications
risquent fort d'etre ecrassees et nous voila face a une regression sans
que personne ne sache pourquoi. Ca peut sembler delirant, mais c'est
encore pire quand ca arrive. Et devine qui est en tort dans ce cas la ?
Dans ce cas il suffit d'avoir un md5 du programme.
C'est une solution pour controler le "niveau de version". Pas pour
Mais comme tu le dis, si le client modifie les sources sans le dire
puisqu'il n'a pas les droits, il va être emmerdé lors de chaque mise à
jour, ce n'est pas dans son intérêt. Donc il renvoi la modification pour
qu'elle soit intégrée et tt le monde y gagne.
Et si il n'installe plus les mises à jour, c'est un client perdu, donc
peu importe qu'il modifie les sources où non.
Mieux vaut prevenir que guerrir. Il vaut mieux que la solution vienne de
In article ,
Wilk wrote:Laurent writes:Je cherche a empecher l'edition du code et a rendre possible un
deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que
sur ce point Python est plus ouvert que Java sans etre oblige de sortir
la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules
(option -m du 2.4). Ton problème ne vient pas de python mais
d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs
solutions...
binfmts du côté linux par ex
Je vais aller voir de ce cote. Car c'est en effet la relation
bytecode/lanceur qui est problematiaue. Si toute fois quelqu'un avait
une parade sous apache...Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique
qui fasse un import de ton script (qui pourrait être dans un zip en
prime).
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
In article <874qijhnfh.fsf@chat.blakie.riol>,
Wilk <wilk-ml@flibuste.net> wrote:
Laurent <statikit@free.fr> writes:
Je cherche a empecher l'edition du code et a rendre possible un
deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que
sur ce point Python est plus ouvert que Java sans etre oblige de sortir
la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules
(option -m du 2.4). Ton problème ne vient pas de python mais
d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs
solutions...
binfmts du côté linux par ex
Je vais aller voir de ce cote. Car c'est en effet la relation
bytecode/lanceur qui est problematiaue. Si toute fois quelqu'un avait
une parade sous apache...
Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique
qui fasse un import de ton script (qui pourrait être dans un zip en
prime).
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
In article ,
Wilk wrote:Laurent writes:Je cherche a empecher l'edition du code et a rendre possible un
deploiement de logiciel en .pyc ou .pyo au niveau web. Bref ! Est-ce que
sur ce point Python est plus ouvert que Java sans etre oblige de sortir
la grosse artillerie.
Python sait lancer directement des pyc ou pyo, et même des modules
(option -m du 2.4). Ton problème ne vient pas de python mais
d'unix/apache, il faut que tu regarde de ce côté, y a plusieurs
solutions...
binfmts du côté linux par ex
Je vais aller voir de ce cote. Car c'est en effet la relation
bytecode/lanceur qui est problematiaue. Si toute fois quelqu'un avait
une parade sous apache...Au pire, si tu n'y arrive pas, tu peux très bien lancer un cgi classique
qui fasse un import de ton script (qui pourrait être dans un zip en
prime).
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
N'est-ce pas justement le but de l'import ?
Il charge en mémoire le contenu d'un fichier python, lui-même
définissant une ou plusieurs classes ?
Evidemment, au lieu de la "simple" directive import, il y a des méthodes
dans "je ne sais plus quel module" pour faire du chargement dynamique
plus ... "pointus", comme en Java.
Et sinon, en mattante simplement les extensions .pyc comme étant aussi
exécutable en mode cgi, ça devrait fonctionner non ?
Ma ligne de commande "python test.pyc" lance bien mon script "compilé"...
Bien sur, sur site client on ne déploi que les fichiers .pyc
Je sais pas si c'est faisable avec le mod_python...
Je pense qu'avec mod_python je pourrais aussi développer un controler,
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
N'est-ce pas justement le but de l'import ?
Il charge en mémoire le contenu d'un fichier python, lui-même
définissant une ou plusieurs classes ?
Evidemment, au lieu de la "simple" directive import, il y a des méthodes
dans "je ne sais plus quel module" pour faire du chargement dynamique
plus ... "pointus", comme en Java.
Et sinon, en mattante simplement les extensions .pyc comme étant aussi
exécutable en mode cgi, ça devrait fonctionner non ?
Ma ligne de commande "python test.pyc" lance bien mon script "compilé"...
Bien sur, sur site client on ne déploi que les fichiers .pyc
Je sais pas si c'est faisable avec le mod_python...
Je pense qu'avec mod_python je pourrais aussi développer un controler,
Un import de script ne me pose pas de contrainte, mais je prefererais
une option plus "elegante" un peu a la manière du "loadsclass" de java.
Merci.
N'est-ce pas justement le but de l'import ?
Il charge en mémoire le contenu d'un fichier python, lui-même
définissant une ou plusieurs classes ?
Evidemment, au lieu de la "simple" directive import, il y a des méthodes
dans "je ne sais plus quel module" pour faire du chargement dynamique
plus ... "pointus", comme en Java.
Et sinon, en mattante simplement les extensions .pyc comme étant aussi
exécutable en mode cgi, ça devrait fonctionner non ?
Ma ligne de commande "python test.pyc" lance bien mon script "compilé"...
Bien sur, sur site client on ne déploi que les fichiers .pyc
Je sais pas si c'est faisable avec le mod_python...
Je pense qu'avec mod_python je pourrais aussi développer un controler,
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste iciLe but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la
volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste ici
Le but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la
volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
( Fri, 17 Dec 2004 20:43:34 +0100 ) Laurent :
Je ne sais pas vers ou placer le follow-up alors je reste iciLe but est de proteger le code ...
Quelles sont, de nos jours, les motivations possible qui justifient la
volonté de "proteger un code source" ?
On voit bien de nos jours la qualité des programmes open source, ...
In article <41c3e1af$0$10241$,
Gilles Lenfant wrote:En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou
un .pyo plutot que d'executer un .py
Le but est de proteger le code (bien sur, ça n'empechera pas le Revers
Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que
fait py2exe. En cherchant sur google... Cependant, si tu espères une
amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
py2exe ne fonctionne que pour un seul OS (window$). Donc, cette solution
n'est pas recevable pour moi.
Arfff... Ca soulagera au moins un peu l'interpreteur, du moins j'espere.
Autrement, pour protéger le code source, les directives de configuration
Apache pour CGI permettent de déclarer certains types comme
"exécutables" coté serveur et empêcher leur téléchargement sur le poste
client.
http://httpd.apache.org/docs/howto/cgi.html
On ne parle pas de la meme chose. Mes CGIs Python s'executent bien et le
code ne peut etre visible cote client web car il est correctement
interprete. Je suis habitue à l'utilisation de CGI ;)
Si le script n'est pas un executable, il sera affiche comme du texte
classique.
Les CGI ne peuvent etre que des executables, que ce soient des scripts
ou bien des binaires. Pour un script CGI (suivant l'OS), c'est la
première ligne du script qui va indiquer quel interpreteur utiliser, ou
alors son extension. Or, les bytecode ne contiennent pas cette ligne et
sous Linux ca pose un probleme.
Sous apache il y a donc deux solutions (a ma connaissance) pour faire
executer Python :
- Utilisation du mod_python : Probleme, on se trouve dans une
configuration type PHP, JSP, ASP ; script embarqué dans une page HTML
avec interpretation cote serveur. Donc, le code est lisible. Sauf si un
Python peut charger un .pyc ou un .pyo et l'executer. Dans ce cas, la
page peyt faire office de wrapper.
- Le CGI : idem, le code est en claire. Ici, meme chose : faire un
wrapper.
Quand à Zope, si je dis pas de betise, je dirais qu'il est à Python ce
que Tomcat est à Java.
In article <41c3e1af$0$10241$8fcfb975@news.wanadoo.fr>,
Gilles Lenfant <nospam@bigfoot.com> wrote:
En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou
un .pyo plutot que d'executer un .py
Le but est de proteger le code (bien sur, ça n'empechera pas le Revers
Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que
fait py2exe. En cherchant sur google... Cependant, si tu espères une
amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
py2exe ne fonctionne que pour un seul OS (window$). Donc, cette solution
n'est pas recevable pour moi.
Arfff... Ca soulagera au moins un peu l'interpreteur, du moins j'espere.
Autrement, pour protéger le code source, les directives de configuration
Apache pour CGI permettent de déclarer certains types comme
"exécutables" coté serveur et empêcher leur téléchargement sur le poste
client.
http://httpd.apache.org/docs/howto/cgi.html
On ne parle pas de la meme chose. Mes CGIs Python s'executent bien et le
code ne peut etre visible cote client web car il est correctement
interprete. Je suis habitue à l'utilisation de CGI ;)
Si le script n'est pas un executable, il sera affiche comme du texte
classique.
Les CGI ne peuvent etre que des executables, que ce soient des scripts
ou bien des binaires. Pour un script CGI (suivant l'OS), c'est la
première ligne du script qui va indiquer quel interpreteur utiliser, ou
alors son extension. Or, les bytecode ne contiennent pas cette ligne et
sous Linux ca pose un probleme.
Sous apache il y a donc deux solutions (a ma connaissance) pour faire
executer Python :
- Utilisation du mod_python : Probleme, on se trouve dans une
configuration type PHP, JSP, ASP ; script embarqué dans une page HTML
avec interpretation cote serveur. Donc, le code est lisible. Sauf si un
Python peut charger un .pyc ou un .pyo et l'executer. Dans ce cas, la
page peyt faire office de wrapper.
- Le CGI : idem, le code est en claire. Ici, meme chose : faire un
wrapper.
Quand à Zope, si je dis pas de betise, je dirais qu'il est à Python ce
que Tomcat est à Java.
In article <41c3e1af$0$10241$,
Gilles Lenfant wrote:En fait, je cherche a savoir s'il y a moyen de faire executer un .pyc ou
un .pyo plutot que d'executer un .py
Le but est de proteger le code (bien sur, ça n'empechera pas le Revers
Engineering) et d'accelerer le temps de reponse du CGI
A+
Il y a un moyen d'exécuter directement les .pyc ou .pyo, c'est ce que
fait py2exe. En cherchant sur google... Cependant, si tu espères une
amélioration spectaculaire des perfs, tu te fourres le doigt dans l'oeil :)
py2exe ne fonctionne que pour un seul OS (window$). Donc, cette solution
n'est pas recevable pour moi.
Arfff... Ca soulagera au moins un peu l'interpreteur, du moins j'espere.
Autrement, pour protéger le code source, les directives de configuration
Apache pour CGI permettent de déclarer certains types comme
"exécutables" coté serveur et empêcher leur téléchargement sur le poste
client.
http://httpd.apache.org/docs/howto/cgi.html
On ne parle pas de la meme chose. Mes CGIs Python s'executent bien et le
code ne peut etre visible cote client web car il est correctement
interprete. Je suis habitue à l'utilisation de CGI ;)
Si le script n'est pas un executable, il sera affiche comme du texte
classique.
Les CGI ne peuvent etre que des executables, que ce soient des scripts
ou bien des binaires. Pour un script CGI (suivant l'OS), c'est la
première ligne du script qui va indiquer quel interpreteur utiliser, ou
alors son extension. Or, les bytecode ne contiennent pas cette ligne et
sous Linux ca pose un probleme.
Sous apache il y a donc deux solutions (a ma connaissance) pour faire
executer Python :
- Utilisation du mod_python : Probleme, on se trouve dans une
configuration type PHP, JSP, ASP ; script embarqué dans une page HTML
avec interpretation cote serveur. Donc, le code est lisible. Sauf si un
Python peut charger un .pyc ou un .pyo et l'executer. Dans ce cas, la
page peyt faire office de wrapper.
- Le CGI : idem, le code est en claire. Ici, meme chose : faire un
wrapper.
Quand à Zope, si je dis pas de betise, je dirais qu'il est à Python ce
que Tomcat est à Java.
