Lorsque tu construit une centrale nucléaire tu applique des normes draconiennes , pourtant les centrale russe il y a qu'a Tchernobil qu'elles ont explosées, c'est donc pas si dangereux que ça.
Le vrai problème avec le nucléaire, c'est que c'est pas le principe de précaution qui est difficile à appliquer mais justement le principe de "postcaution", si je puis dire :
Les procédures sont parfaitement définies et tout le monde sait quoi faire en cas de pépin dans une centrale. Je pense même que ce genre d'endroit est même beaucoup plus sûr que la majorité des industries ... tant que quelqu'un s'en occupe !
Le problème, c'est que l'on ne peut pas savoir de quoi sera fait le prochain siècle, par exemple. Exploiter une technologie dont on est dépendant mais dont on ne maîtrise plus les ressources a toujours été dangereux, mais dans ce cas précis, le risque est beaucoup moins gérable que dans d'autres secteurs.
Et bien sûr qu'on peut prendre l'identité d'un utilisateur mais je vois pas l'intérêt de le préciser dans ton commentaire... ? Ça ne me permet pas de faire un chmod g+s vu que seul root peut le faire.
Absolument pas.
Il faut simplement être propriétaire du répertoire en question et membre du groupe auquel il appartient. Et ce, en local comme en NFS.
Comme ça les utilisateurs qui créent des fichiers dans ce dossier appartiennent au groupe www-data et par conséquent, sauf s'ils mettent des droits en x00, apache a les permissions pour accéder aux fichiers.
'faut p'têt écrire chgrp et pas chown ...
Lorsque root essaye de faire le chmod, il se prend un permission denied (ce qui est frustrant pour un root :)
Par défaut, un volume NFS monté en rw coté serveur considère root comme un utilisateur ordinaire. Il faut justement le partager en plus avec root= pour que l'utilisateur zéro ait les même pouvoirs dessus que sur un volume local.
Par contre, il n'y a rien qui t'empêche de passer root en local pour ensuite prendre l'identité d'un utilisateur, mais chut ...
Si c'est à deux, et si c'est simplement pour éviter de se marcher sur les pieds, tu peux essayer d'activer les mandatory locks sur ton système de fichiers.
Ainsi, si le logiciel de lecture a le bon goût de poser un verrou sur ton fichier, celui-ci sera en lecture seule pour les autres, voire inaccessible, le temps de la session.
C'est probablement très bête mais ton combiné clavier-souris sans fil a-t-il déjà fonctionné (notamment sur un autre O.S. si tu en es équipé) ?
Parce que le plus chiant avec les sans-fil, c'est de faire communiquer le récepteur et les périphs. J'avais déjà eu le problème chez une collègue avec une solution Logitech, je crois bien. Systématiquement, le clavier ou la souris, mais pas les deux.
Pour le reste, si ton engin fonctionne en USB, à moins d'avoir un clavier TRES spécial, il ne devrait pas avoir besoin de pilote particulier.
Je voulais dire par là que lancer un "Set-Cookie" avec un identifiant et un hash mixé à une clé secrète, c'est quand même à la portée de tout le monde. Ce n'était pas une démonstration de performance.
Le truc, c'est que c'est tellement courant qu'en principe, quand on en arrive là, on utilise la première technologie web venue. En l'occurence, c'était moins lourd de réécrire le peu dont j'avais besoin plutôt que d'assimiler et d'inclure dans le projet un module dédié.
Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
Je suis intéressé par votre proposition d'alternatives à Java/ Tomcat pour une application de gestion commerciale.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
Ca ne change rien. Mon commentaire n'était pas un pamphlet contre les mainframes, bien au contraire. Les applications qui y ont été développées, spécialement sur minis tels que les AS/400, ont perduré justement parce qu'elles étaient stables, rapides et efficaces. C'est pourquoi, jusqu'au début des années 2000, on a remplacé les terminaux par des PC émulant un 3270 ou assimilé pour perpétuer le service, plutôt que de réécrire l'application en local.
Il n'empêche que je ne placerai pas l'âge de gloire des mainframes à la fin des années 80. A cette époque, les terminaux proprios commençaient réellement à disparaître au profit des ordinateurs de bureaux et, parallèlement, le grand public avait déjà commencé (depuis le début des mêmes années 80) à goûter à la micro-informatique personnelle.
Je ne vois pas où il y a réécriture de l'histoire là-dedans.
Il y a une vingtaine d'année IBM était au faîte de sa puissance
J'aime bien ce goût raffiné pour le cynisme subtil : la liaison discrète du mot "faîte" vers le Wiktionnaire. Cela donne une idée du niveau de culture présumé que l'on attribue aux moules gallo-linuxéistes (qui, au passage, ne sauraient pas non plus se servir d'un dictionnaire).
Ensuite, il y a vingt ans, nous étions fin 1987. Ce n'était plus l'heure de gloire des mainframes mais au contraire celle de l'ascension en force des ordinateurs personnels 8 et 16 bits, avant même que, avec la chute progressive du prix du PC et l'explosion des réseaux locaux, on ne repasse justement à une architecture centralisée avec des serveurs.
Justement, ceux-ci ne remplissent plus que rarement leur rôle premier en entreprise. Si nous utilisons encore des batteries de serveurs accessibles avec des thin clients, pour la plupart des compagnies aujourd'hui, un serveur, c'est un dépôt de fichiers, généralement en SMB, sous Windows, avec une politique de licence d'accès client (CAL) aussi onéreuse que scandaleuse. Bref : les inconvénients de l'infrastructure sans les avantages (et sans le plaisir que pouvait apporter le métier à l'époque).
Sortir du moule propriétaire et mesurer une économie de 3 millions d'euros par an, c'est évidemment remarquable. Maintenant, est-ce que Tomcat-Java est un choix aussi évident qu'il en a l'air ? l'avenir nous le dira. Je ne pense pas qu'une technologie aussi lourde et aussi évolutive à la fois puisse être pérenne pendant vingt ans sans intervention. D'une manière générale, Java c'est bien, mais c'est un langage plus conçu pour les programmeurs que pour ses utilisateurs, à mon goût.
Gageons que cet article sera le guide de ce qu'il faut faire pour fermer cette (sombre) page de l'informatique.
Espérons surtout que l'on ne fermera pas une "page sombre" pour en ouvrir une autre.
J'ajouterais qu'il reste largement moins contraingnant de ne PAS faire de logiciel propriétaire, aussi bien pour l'auteur que pour ses utilisateurs. De telles contraintes se rencontrent en général dans trois cas :
1) L'application est développée par un éditeur professionnel pour le compte d'un client précis, par contrat, avec protection par dongle, etc. Cela se chiffre en général en dizaines de milliers d'euros au minimum.
2) L'application a une utilité mais le code est vraiment trop sale pour être publié en l'état.
3) Dans 95% des cas, l'application est développée par un programmeur débutant ou par quelqu'un dont ce n'est pas intrinsèquement le métier ou la vocation. On a réussi à écrire en entier un petit produit, on est fier de son travail et on ne veut surtout pas se faire piller. Le problème restant que, bien souvent, il n'y a en fait rien à piller.
Si en plus, il faut signer des accords de non-divulgation et mettre en place des choses très contraignantes du côté de l'utilisateur, celui-ci ne l'utilisera jamais. L'application sera alors utilisé par son concepteur, par deux ou trois proches et c'est tout. Elle va ensuite tomber dans l'oubli parce que le développeur exclusif n'aura plus le temps de s'en occuper, et enfin devenir obsolète. Bilan : de l'amertume et du temps perdu pour tout le monde.
Enfin, sache qu'il n'est pour ainsi dire plus possible du tout de faire de l'argent avec une application écrite dans son garage. Sans avoir vu l'application elle-même, je suis prêt à parier qu'elle existe déjà en cherchant un peu. Ensuite, non seulement on trouve une floppée d'outils en ligne sur le Net, mais les gens piratent à tour de bras. Paradoxe : ce sont les libristes, ceux qui à priori paient le moins souvent pour un logiciel, qui sont le plus attachés au respect d'une licence. Je pense que la majorité des personnes ici présentes n'ont pas le moindre winzip pirate sur leur disque.
Penser alors "faire éventuellement de l'argent" en vendant l'application si l'envie vous en prend, c'est être très naïf. On baigne dans un océan numérique à mille lieues de ce qui existait il y a encore quinze ans, où l'on apprenait l'existence d'applications utiles par le bouche à oreille et où l'on patientait deux semaines pour rencontrer "la personne qui l'avait" pour lui filer une disquette et attendre qu'elle nous la rende chargée de sa précieuse cargaison, comme un gamin à la veille de Noël.
Un logiciel, c'est comme un enfant : on le protège au tout début mais après il faut le laisser vivre sa vie et rencontrer du monde si l'on veut qu'il se développe correctement !:-)
Donc, le meilleur conseil que je puisse te donner : fais deux branches, une entièrement libre, l'autre éventuellement propriétaire (en commençant par la libre). Accepte le fait que le contenu de ta première branche soit public et le reste ad vitam æternam. Place-le sous licence GPL et laisse les gens modifier le code s'il le souhaite.
Si les gens ne sont pas pris en otage et peuvent avoir confiance en l'application qu'ils utilisent, alors le logiciel deviendra populaire, et les gens qui gagnent un salaire raisonnable pourront alors s'offrir le luxe d'acquérir une version propriétaire, full-featured, avec un minimum de documentation et d'assistance en cas de problème. A prévoir nécessairement si tu vends ton produit, si ta philosophie est "raque, démerde-toi tout seul et surtout n'essaie pas de voir comment j'ai fait", il est clair que tu as perdu d'avance.
A priori pas sur un serveur Samba, mais, pour autant que je me souvienne, les licences pour serveurs Windows sont vendues en te concédant un nombre ridicule de connexions forfaitaires, après quoi il te faut acheter de nouvelles licences de connexion, attribuées soit à un utilisateur (une seule personne peut se connecter de partout), soit à une machine (n'importe qui peut se connecter, mais seulement depuis une machine donnée).
C'est parce que ton expression régulière est incomplète. Essaie à la place d'utiliser la commande que je t'ai indiqué dans mon commentaire ci-dessous. A défaut, si tu tiens à utiliser awk, reprends l'expression que j'ai écrite en gras.
[^] # Re: économie contre écologie
Posté par Obsidian . En réponse au journal "revenir sur l'inscription du principe de précaution dans la Constitution". Évalué à 0.
Moi, déjà, je n'aurais pas répondu à quelqu'un qui en vient aux insultes pour se faire entendre.
[^] # Re: économie contre écologie
Posté par Obsidian . En réponse au journal "revenir sur l'inscription du principe de précaution dans la Constitution". Évalué à 3.
Le vrai problème avec le nucléaire, c'est que c'est pas le principe de précaution qui est difficile à appliquer mais justement le principe de "postcaution", si je puis dire :
Les procédures sont parfaitement définies et tout le monde sait quoi faire en cas de pépin dans une centrale. Je pense même que ce genre d'endroit est même beaucoup plus sûr que la majorité des industries ... tant que quelqu'un s'en occupe !
Le problème, c'est que l'on ne peut pas savoir de quoi sera fait le prochain siècle, par exemple. Exploiter une technologie dont on est dépendant mais dont on ne maîtrise plus les ressources a toujours été dangereux, mais dans ce cas précis, le risque est beaucoup moins gérable que dans d'autres secteurs.
[^] # Re: Option root=
Posté par Obsidian . En réponse au message chmod g+s sur une partition NFS. Évalué à 2.
Absolument pas.
Il faut simplement être propriétaire du répertoire en question et membre du groupe auquel il appartient. Et ce, en local comme en NFS.
# Option root=
Posté par Obsidian . En réponse au message chmod g+s sur une partition NFS. Évalué à 1.
'faut p'têt écrire chgrp et pas chown ...
Par défaut, un volume NFS monté en rw coté serveur considère root comme un utilisateur ordinaire. Il faut justement le partager en plus avec root= pour que l'utilisateur zéro ait les même pouvoirs dessus que sur un volume local.
Par contre, il n'y a rien qui t'empêche de passer root en local pour ensuite prendre l'identité d'un utilisateur, mais chut ...
[^] # Re: Annonce de dernière minute de l'Elysée
Posté par Obsidian . En réponse au journal C'est mort ici.. Évalué à 7.
"our uptime, your downtime"
Particulièrement subtil ! :-)
[^] # Re: Annonce de dernière minute de l'Elysée
Posté par Obsidian . En réponse au journal C'est mort ici.. Évalué à 2.
[^] # Re: pour le nologin
Posté par Obsidian . En réponse au message Aide création compte ftp. Évalué à 3.
Il ne manque pas un > supplémentaire dans ta commande ?
[^] # Re: Substitute
Posté par Obsidian . En réponse au message Suppression de meta-caractère avec sed. Évalué à 2.
Tu remplaces \(.*@.*\..*\) par \(.*\).
# Et les locks ?
Posté par Obsidian . En réponse au message Gestionnaire de version simple. Évalué à 2.
Ainsi, si le logiciel de lecture a le bon goût de poser un verrou sur ton fichier, celui-ci sera en lecture seule pour les autres, voire inaccessible, le temps de la session.
# Substitute
Posté par Obsidian . En réponse au message Suppression de meta-caractère avec sed. Évalué à 2.
# Truc bête
Posté par Obsidian . En réponse au message SOS clavier/souris sans-fil Sangha(slim-line) sucks. Évalué à 2.
Parce que le plus chiant avec les sans-fil, c'est de faire communiquer le récepteur et les périphs. J'avais déjà eu le problème chez une collègue avec une solution Logitech, je crois bien. Systématiquement, le clavier ou la souris, mais pas les deux.
Pour le reste, si ton engin fonctionne en USB, à moins d'avoir un clavier TRES spécial, il ne devrait pas avoir besoin de pilote particulier.
[^] # Re: Tous les jours ...
Posté par Obsidian . En réponse au sondage Vous lisez LinuxFr.org :. Évalué à 2.
[^] # Re: zi va
Posté par Obsidian . En réponse au message fingerprinting & linux. Évalué à 3.
L'orthographe ? /o\
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 2.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 2.
Le truc, c'est que c'est tellement courant qu'en principe, quand on en arrive là, on utilise la première technologie web venue. En l'occurence, c'était moins lourd de réécrire le peu dont j'avais besoin plutôt que d'assimiler et d'inclure dans le projet un module dédié.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 5.
Diantre. Je ne suis pas futurologue ! Cela relève déjà de la gageure en temps normal, mais alors en informatique, ça devient de la mystification. Plus précisément, cela doit faire l'objet d'une étude appronfondie, celle-là même que vous avez dû mener. Ce que je peux proposer dans une réponse de forum tient donc du point de vue, rien de plus sérieux.
En fait, je n'ai rien proposé. J'écris des logiciels pour le domaine de la recherche, donc nos besoins sont assez différents de celle de la gestion d'entreprise.
Comme je l'ai dit, le monde Java est extrêmement prisé des entreprises car presque toutes les technologies modernes y sont représentées et qu'il est plus facile d'y trouver des développeurs que dans d'autres environnements. Maintenant, cela restera toujours "une machine dans une machine" et cela pose problème. C'est lent et lourd, les JVM ne sont pas déployées par défaut sur les ordinateurs du grand public ni sous Windows, ni sous Linux, la communication avec l'environnement existe mais l'intégration beaucoup moins et surtout le déploiement en entreprise d'un truc style J2EE est tentaculaire !
C'est une centrale nucléaire et le problème est le même pour toutes les technos un tant soit peu ambitieuses : c'est très efficace tant qu'il y a des gens compétents et motivés pour le faire, après cela pose problème. Le passage à l'an 2000 a conduit les grandes compagnies à rappeler les cobolistes retraités pour une revue de code. Est-ce que les systèmes complexes actuels seront stables pendant 20 ans, et est-ce qu'au bout de cette période, il sera aisé de s'y replonger pour en préparer la migration, comme vous l'avez fait aujourd'hui ?
Coté utilisateur, je préconise -dans l'absolu- quelque chose qui soit stable, rapide, et peu gourmand en ressources système et en espace disque. Evidemment, ça demande de briser beaucoup de couches d'abstraction bâties au fil du temps et, parfois, de contourner le modèle objet. Ca demande beaucoup de compétences, du temps, et ce n'est plus économiquement intéressant. N'empêche que si Java est très utilisé en milieu professionnel, je n'ai encore jamais vu un logiciel grand public vendu en rayon qui soit écrit dans ce langage.
Je pense d'autre part que les applications basées sur des masques de saisie et des adresses de page peuvent être presque directement transcrites, pour ce qui est de l'interface utilisateur, vers du web/css sans technologie associée coté client (même pas du Javascript). Cela a l'avantage de fonctionner partout sans déploiement particulier (le navigateur web, lui, est désormais présent partout). Par contre, faire une migration pour conserver le même mode opérationnel, ce n'est pas forcément intéressant.
Personnellement, je me retrouve bien dans le C/C++, qui permettent d'écrire des applications au plus bas niveau possible et en minimisant les dépendances à des ressources externes.
A titre indicatif, j'ai réalisé une grosse application CGI standalone en C++ uniquement. Il est clair que cela a de quoi faire bondir la majorité des webmestres qui me lisent et que c'est généralement inadapté pour la plupart des solutions développées sur le web. Il n'en reste pas moins qu'aujourd'hui, le déploiement de cette application de 35000 lignes, c'est un seul fichier binaire. En pesant le pour et le contre, il était plus simple pour moi de gérer mon propre système de session et de manipuler directement l'interface CGI avec des "out <<" plutôt que d'instancier un objet déjà écrit et d'appeler une méthode du sixième niveau en ayant bien pris soin de ne rien avoir émis avant, comme en PHP par exemple. Point de vue empreinte en mémoire et temps d'exécution, l'application est imbattable.
A voir au cas par cas, donc.
[^] # Re: Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 3.
Il n'empêche que je ne placerai pas l'âge de gloire des mainframes à la fin des années 80. A cette époque, les terminaux proprios commençaient réellement à disparaître au profit des ordinateurs de bureaux et, parallèlement, le grand public avait déjà commencé (depuis le début des mêmes années 80) à goûter à la micro-informatique personnelle.
Je ne vois pas où il y a réécriture de l'histoire là-dedans.
# Ah oui, c'est vendredi.
Posté par Obsidian . En réponse à la dépêche Projet NACA : migration Mainframe IBM vers serveurs Intel/Linux. Évalué à 6.
J'aime bien ce goût raffiné pour le cynisme subtil : la liaison discrète du mot "faîte" vers le Wiktionnaire. Cela donne une idée du niveau de culture présumé que l'on attribue aux moules gallo-linuxéistes (qui, au passage, ne sauraient pas non plus se servir d'un dictionnaire).
Ensuite, il y a vingt ans, nous étions fin 1987. Ce n'était plus l'heure de gloire des mainframes mais au contraire celle de l'ascension en force des ordinateurs personnels 8 et 16 bits, avant même que, avec la chute progressive du prix du PC et l'explosion des réseaux locaux, on ne repasse justement à une architecture centralisée avec des serveurs.
Justement, ceux-ci ne remplissent plus que rarement leur rôle premier en entreprise. Si nous utilisons encore des batteries de serveurs accessibles avec des thin clients, pour la plupart des compagnies aujourd'hui, un serveur, c'est un dépôt de fichiers, généralement en SMB, sous Windows, avec une politique de licence d'accès client (CAL) aussi onéreuse que scandaleuse. Bref : les inconvénients de l'infrastructure sans les avantages (et sans le plaisir que pouvait apporter le métier à l'époque).
Sortir du moule propriétaire et mesurer une économie de 3 millions d'euros par an, c'est évidemment remarquable. Maintenant, est-ce que Tomcat-Java est un choix aussi évident qu'il en a l'air ? l'avenir nous le dira. Je ne pense pas qu'une technologie aussi lourde et aussi évolutive à la fois puisse être pérenne pendant vingt ans sans intervention. D'une manière générale, Java c'est bien, mais c'est un langage plus conçu pour les programmeurs que pour ses utilisateurs, à mon goût.
Espérons surtout que l'on ne fermera pas une "page sombre" pour en ouvrir une autre.
[^] # Re: Re:
Posté par Obsidian . En réponse au message protection d'un logiciel. Évalué à 2.
1) L'application est développée par un éditeur professionnel pour le compte d'un client précis, par contrat, avec protection par dongle, etc. Cela se chiffre en général en dizaines de milliers d'euros au minimum.
2) L'application a une utilité mais le code est vraiment trop sale pour être publié en l'état.
3) Dans 95% des cas, l'application est développée par un programmeur débutant ou par quelqu'un dont ce n'est pas intrinsèquement le métier ou la vocation. On a réussi à écrire en entier un petit produit, on est fier de son travail et on ne veut surtout pas se faire piller. Le problème restant que, bien souvent, il n'y a en fait rien à piller.
Si en plus, il faut signer des accords de non-divulgation et mettre en place des choses très contraignantes du côté de l'utilisateur, celui-ci ne l'utilisera jamais. L'application sera alors utilisé par son concepteur, par deux ou trois proches et c'est tout. Elle va ensuite tomber dans l'oubli parce que le développeur exclusif n'aura plus le temps de s'en occuper, et enfin devenir obsolète. Bilan : de l'amertume et du temps perdu pour tout le monde.
Enfin, sache qu'il n'est pour ainsi dire plus possible du tout de faire de l'argent avec une application écrite dans son garage. Sans avoir vu l'application elle-même, je suis prêt à parier qu'elle existe déjà en cherchant un peu. Ensuite, non seulement on trouve une floppée d'outils en ligne sur le Net, mais les gens piratent à tour de bras. Paradoxe : ce sont les libristes, ceux qui à priori paient le moins souvent pour un logiciel, qui sont le plus attachés au respect d'une licence. Je pense que la majorité des personnes ici présentes n'ont pas le moindre winzip pirate sur leur disque.
Penser alors "faire éventuellement de l'argent" en vendant l'application si l'envie vous en prend, c'est être très naïf. On baigne dans un océan numérique à mille lieues de ce qui existait il y a encore quinze ans, où l'on apprenait l'existence d'applications utiles par le bouche à oreille et où l'on patientait deux semaines pour rencontrer "la personne qui l'avait" pour lui filer une disquette et attendre qu'elle nous la rende chargée de sa précieuse cargaison, comme un gamin à la veille de Noël.
Un logiciel, c'est comme un enfant : on le protège au tout début mais après il faut le laisser vivre sa vie et rencontrer du monde si l'on veut qu'il se développe correctement !:-)
Donc, le meilleur conseil que je puisse te donner : fais deux branches, une entièrement libre, l'autre éventuellement propriétaire (en commençant par la libre). Accepte le fait que le contenu de ta première branche soit public et le reste ad vitam æternam. Place-le sous licence GPL et laisse les gens modifier le code s'il le souhaite.
Si les gens ne sont pas pris en otage et peuvent avoir confiance en l'application qu'ils utilisent, alors le logiciel deviendra populaire, et les gens qui gagnent un salaire raisonnable pourront alors s'offrir le luxe d'acquérir une version propriétaire, full-featured, avec un minimum de documentation et d'assistance en cas de problème. A prévoir nécessairement si tu vends ton produit, si ta philosophie est "raque, démerde-toi tout seul et surtout n'essaie pas de voir comment j'ai fait", il est clair que tu as perdu d'avance.
Voila, j'espère que je t'ai éclairé un peu.
[^] # Re: Voir ici :
Posté par Obsidian . En réponse au message Problème. Évalué à 1.
http://fr.wikipedia.org/wiki/Probl%C3%A8me_du_voyageur_de_co(...)
# Voir ici :
Posté par Obsidian . En réponse au message Problème. Évalué à 1.
[^] # Re: ...
Posté par Obsidian . En réponse au message Problème. Évalué à 5.
# Possible.
Posté par Obsidian . En réponse au message Samba nombre de connexion simultanée. Évalué à 3.
http://en.wikipedia.org/wiki/Client_Access_License
Possible qu'il y ait un paramètre dans la config de Samba qui limite également le nombre de connexions simultanées. C'est fragile, le SMB :-)
[^] # Re: Exemple du fichier d'entrée
Posté par Obsidian . En réponse au message retrouver la vraie IP avec AWK ou autres. Évalué à 2.
# Je propose :
Posté par Obsidian . En réponse au message retrouver la vraie IP avec AWK ou autres. Évalué à 2.
En considérant bien sûr qu'il n'y a pas de zéro non-significatif à gauche de chaque nombre ...