Bonjour c'est mon premier journal. Alors please soyez indulgent.
Pas de problème. C'est argumenté, agréable à lire, il n'y a (pratiquement) pas de fautes d'orthographe, tu as fait l'effort d'utiliser les bonnes balises, et il y a même une formule de politesse ! On aimerait en voir plus souvent ! :-)
En effet microsoft a certes de nombreux brevets et les moyens d'en faire de nombreux et aussi de faire appliquer ceux-ci dans des actions légales. Mais il existe aussi de nombreuses autres sociétés concurrentes qui peuvent se décider a attaquer microsoft et on pourrait donc assister a un rush juridique contre microsoft.
On a hélas déjà vu ce que cela donnait. Les procès étendus sur des années entières, tant et si bien que le logiciel est déjà obsolète quand le jugement n'est pas encore rendu. Et puis, les accusations de trust qui meurent d'elles-même parce que Linux arrive sur le marché, les amendes payées en licences, etc.
Et puis entrer en procès coûte cher. Il y a de fortes chances que le plaignant meure de lui-même avant de réussir à obtenir quelque chose de Microsoft.
Ben dans ce cas le parc mondial n'aura qu'a passé a linux! :p
Cela ne changera rien. Ce n'est pas parce qu'un produit est distribué gratuitement (ce qui n'est même pas forcément le cas de GNU/Linux et sa suite, rappelons-le) que cela donne un droit d'usage sur le brevet, encore moins sans royalties.
Depuis un moment je m'intéresse et m'interroge sur les brevets logiciels. Je cherche les points positif et négatif et me dit que ça marche tout de même assez bien dans des endroits comme l'industrie automobile donc pourquoi pas dans l'informatique.
La principale menace des brevets logiciels, faut-il le rappeler, est son coté sournois. Personne ne comprend réellement de quoi il s'agit et les grands groupes à qui cela profite essayent de tirer avantage de ce flou pour faire voter une loi à leur avantage, ce qui est un crime d'un point de vue démocratique.
- D'une part, on a pas besoin d'un brevet pour protéger un logiciel puisqu'il l'est déjà par le droit d'auteur au même titre que toutes les créations intellectuelles et artistiques. Première entourloupe.
- Ensuite, on s'apprête à autoriser le brevetage des idées, ce qui est un non-sens en soi. La seule chose que l'on pourrait breveter, c'est le procédé de mise en oeuvre. Dans le cas des onglets ou autres, ce procédé est toujours le même : l'exécution d'un programme par un microprocesseur ! La seule chose que l'on peut faire est breveter l'informatique.
- Si l'on suit cette voie, c'est une brèche qui n'a aucune raison de se cantonner au domaine informatique et qui risque de s'étendre. Si l'on peut breveter des idées en informatique, on peut breveter des idées, ou des algorithmes, ou des formules mathématiques, dans tous les autres domaines.
- La durée de validité des brevets n'est pas adaptée à l'industrie informatique (et quand je dis industrie, c'est en fait à tout son petit monde). 20 ans, c'est déjà long dans un secteur normal, mais cela représente l'équivalent de 400 ans de progrès quand c'est à l'informatique que cela s'applique (il y a 20 ans, mon TO8D sortait sur le marché, et en même temps la toute première version de Windows qui n'a jamais réellement pris).
- Il est très facile de camoufler un principe trivial derrière une description absconse. Le brevet sur le OU Exclusif occupe 32 pages A4. Dans le même esprit, je pourrais très bien déposer un procédé qui consistant à calculer le montant d'une facture par addition successive du prix des différents articles. Ces deux procédés sont tout-à-fait comparables.
- On pourrait de la même façon breveter le concept du langage de programmation. Les seules marges de manoeuvre dont on disposerait consisteraient à immiter ce qui s'est fait jusque-là parce que cela tomberait sous le coup de l'antérioté au brevet. Plus aucune innovation ne serait possible alors que c'est précisément l'un arguments les plus mis en avant par les défenseurs d'une telle hérésie.
- Enfin, et c'est peut-être là le plus important, écrire des logiciels est une activité à la fois scientifique et intellectuelle, comme écrire des livres ou connaître les fondements de l'électricité ou de la chimie. Tout le monde devrait aujourd'hui faire un peu de programmation. Ce genre de directive va conduire à interdire de fait ce genre d'activité.
Je pense que c'est un effet de bord. Soit la segfault paraît lors de l'appel aux sous-fonctions dans ton switch (gdb + bt roulaizent), soit c'est ton tableau de parameters qui est mal déclaré. En admettant que ta macro MAX_EQ_PARAMETERS ne puisse pas être définie pour une raison ou une autre (ex: oubli du #include idoine), ta déclaration sera alors résolue en
double parameters[];
Ce qui reste correct d'un point de vue syntaxique, mais qui définit un pointeur sans la mémoire qui va derrière. Cela suffirait à expliquer tes segfaults intermittentes : Lorsque tu écriras dans ce tableau, tes données n'iront pas se loger dans un endroit prévu à cet effet mais dans l'espace réservé aux variables membres que tu définis plus loin ! Donc, tu as la place de semer la pagaille un bon moment avant de planter. En fait, ton programme pourra continuer à faire le con tant qu'il ne sortira pas du segment de mémoire alloué pour ta classe entière, lequel segment aura probablement une taille alignée sur une page quelquonque. Ceci pourrait expliquer les différences de plantage en fonction des plateformes.
Retire le mot-clé « ispeed » puisqu'il ne règle le débit que dans un seul sens. Ensuite essaie également avec d'autres valeurs puisque 9600/7/PE/S est répandu mais un peu lent désormais.
A mon avis, d'un coté on a soit une parité paire (et 7 bits de données), soit pas de parité du tout (8 bits de données). D'un autre, les débits sont presque toujours 9600, 19200 ou 38400. Cela fait 6 combinaisons à essayer.
Enfin, utilise le menu de configuration de minicom (Ctrl-A puis Z puis O (Configurer) puis Configurer le port série) car il réinitialise lui-même le port.
Es-tu sûr qu'il s'agisse bien d'une segfault déjà, et pas d'une division par zéro ou d'un « Abort » dù à une exception non rattrapée ?
Ensuite, elle est censée faire quoi ta fonction f ? Parce qu'une fonction mathématique sans inconnue (type void), c'est pas courant. A mon avis, le problème se situe dans le code de ta fonction.
Mets le tout en GPL et tu pourras bénéficier de l'aide de la communauté ! :-)
Vous aurez une piste que je puisses explorer un peu le truc ? Merci d'avance pour tout.
Essaie de régler correctement vitesse, parité, et bit de start/stop, tout devrait rentrer dans l'ordre. 9600Bauds/Parité paire/Un bit stop est une configuration très courante.
En principe, surtout si tu débutes en programmation, ce genre de choses sera complètement transparent pour toi. Seule chose à savoir, la taille des « int » (pour faire simple) sera par défaut sur 64 bits au lieu de 32. Ce serait surtout gênant dans l'autre sens. Dans ton cas, il faudra juste faire attention de mettre les masques de bits au bon format (et si tu ne vois pas de quoi je parles, c'est que tu n'en as pas encore besoin).
Moi j'utilise normalement g++, il fonctionne très bien (à condition d'avoir au moins la version 3 de GCC, cela dit). Si par « logiciel pour écrire en C++ » tu entends « un truc qui ressemble à Visual Studios », tu peux toujours utiliser KDevelop, et eventuellement Glade, mais ce n'est pas le chemin à prendre. Lance-toi plutôt directement dans la ligne de commande, tu en seras récompensé au quotidien en moins de temps qu'il ne t'en faudras pour le réaliser.
Voila un commentaire que je pertinente plutôt deux fois qu'une.
J'ai également été assez surpris de voir kppp relégué à l'arrière-plan par Mandrake. Cela fait partie des bizarreries dont souffre cette distribution depuis quelques temps.
En effet, bienvenue dans le monde merveilleux de la programmation des threads et des soucis qui en découlent !
Ceci dit, si l'on peut éviter d'utiliser un thread pour tout et n'importe quoi, c'est aussi bien. Le multitâche coopératif est extrêmement bénéfique lorsqu'on l'implémente au sein d'un même programme ...
Je l'ai fait sans problème. Bon il faut peut-être télécharger une JVM récente d'une part et autoriser le plug-in à se mettre à la bonne place, d'autre part, et enfin jeter un oeil à son firewalling, sinon ça marche.
Méfiance avec le AltGr+SysRq+SUB. En principe "u" est censé provoquer le démontage en règle des partitions actives, mais il m'est pourtant plusieurs fois arrivé de subir un e2fsck au redémarrage pour cause de disques non proprement démontés. Bref, l'opération se fait peut-être un niveau trop bas.
Fondamentalement, l'acquisition des caractères se fait soit par la console, soit par les événements X-Windows.
Donc, sous x, xmodmap devrait te tirer d'affaire. Evidement, il ne faut pas que le logiciel se soucie des scancodes, mais bon. En principe ce n'est jamais le cas.
Les filles faisaient déjà parler d'elles il y a 3 ans, et les photos, célèbres sont encore plus anciennes (regardez la tête de fillette d'Adrianna :-).
Le principe de base est de rendre communes les fonctions d'un programme qui présentent un intérêt général.
Exemple : Ouvrir une fenêtre. Il est bien sûr inconcevable que chaque programmeur réécrive lui-même le système X-Window depuis zéro pour pouvoir travailler. A la place, il va faire appel à une fonction de réputation publique (dont on mettra le prototype dans un *.h pour que le programme C sache comment l'utiliser).
Ensuite, au moment de construire l'exécutable, on intégrera dans le fichier les fonctions de gestion de fenêtres, déjà compilées à cet effet. C'est donc une bibliothèque statique. C'est exactement comme un exécutable sauf qu'il n'y pas de point d'entrée.
Par contre, quand il commence à y avoir beaucoup de programmes quu ouvrent des fenêtres, on se rend compte que d'une part les exécutables sont gargantuesques (toute la gestion du X est intégrée dans l'exécutable juste pour afficher Hello World à l'écran), et que d'autre part il est idiot de charger 15 fois en mémoire les même fonctions ! A la place, on ne va compiler que le nécéssaire et l'on va laisser "en l'air" les reférences à la bibliothèque partagée. Ce sera alors le boulot du système d'exploitation de charger LORSQUE C'EST NECESSAIRE les ressources dont un logiciel a besoin et de résoudre les noms de fonctions en adresse mémoire.
En outre, et c'est là l'intérêt majeur, si la ressource réclamée a déjà été chargée pour un autre logiciel, il est inutile de la charger une deuxième fois (gain de temps), et les deux programmes peuvent appeler le même endroit (gain de place).
Avantage de la compilation statique: On obtient un exécutable parfaitement autonome, ou presque, qui pourra fonctionner toutes les plateforme équipées d'un même OS. Inconvénient: Cela génère des exécutables gigantesques pour rien.
Avatnage de la compilation dynamique: On ne compile que ce qui est nécéssaire, on gagne du temps et de la place, et quand on met à jour une fonction, cela se répercute immédiatement sur tous les programmes qui l'utilisent. Inconvénient, lorsque l'on installe un logiciel, il faut installer toute sa suite avec, vérifier si les libs ne sont pas déjà en place, etc. et gérer les dépendances en cascades (tel logiciel à beosin de telle lib, qui elle même s'appuie sur une autre lib, qui à son tour a besoin deux trois libs de plus bas niveau, etc.).
# Yet another avis sur les brevets.
Posté par Obsidian . En réponse au journal un autre avis sur les brevets. Évalué à 6.
Pas de problème. C'est argumenté, agréable à lire, il n'y a (pratiquement) pas de fautes d'orthographe, tu as fait l'effort d'utiliser les bonnes balises, et il y a même une formule de politesse ! On aimerait en voir plus souvent ! :-)
On a hélas déjà vu ce que cela donnait. Les procès étendus sur des années entières, tant et si bien que le logiciel est déjà obsolète quand le jugement n'est pas encore rendu. Et puis, les accusations de trust qui meurent d'elles-même parce que Linux arrive sur le marché, les amendes payées en licences, etc.
Et puis entrer en procès coûte cher. Il y a de fortes chances que le plaignant meure de lui-même avant de réussir à obtenir quelque chose de Microsoft.
Cela ne changera rien. Ce n'est pas parce qu'un produit est distribué gratuitement (ce qui n'est même pas forcément le cas de GNU/Linux et sa suite, rappelons-le) que cela donne un droit d'usage sur le brevet, encore moins sans royalties.
La principale menace des brevets logiciels, faut-il le rappeler, est son coté sournois. Personne ne comprend réellement de quoi il s'agit et les grands groupes à qui cela profite essayent de tirer avantage de ce flou pour faire voter une loi à leur avantage, ce qui est un crime d'un point de vue démocratique.
- D'une part, on a pas besoin d'un brevet pour protéger un logiciel puisqu'il l'est déjà par le droit d'auteur au même titre que toutes les créations intellectuelles et artistiques. Première entourloupe.
- Ensuite, on s'apprête à autoriser le brevetage des idées, ce qui est un non-sens en soi. La seule chose que l'on pourrait breveter, c'est le procédé de mise en oeuvre. Dans le cas des onglets ou autres, ce procédé est toujours le même : l'exécution d'un programme par un microprocesseur ! La seule chose que l'on peut faire est breveter l'informatique.
- Si l'on suit cette voie, c'est une brèche qui n'a aucune raison de se cantonner au domaine informatique et qui risque de s'étendre. Si l'on peut breveter des idées en informatique, on peut breveter des idées, ou des algorithmes, ou des formules mathématiques, dans tous les autres domaines.
- La durée de validité des brevets n'est pas adaptée à l'industrie informatique (et quand je dis industrie, c'est en fait à tout son petit monde). 20 ans, c'est déjà long dans un secteur normal, mais cela représente l'équivalent de 400 ans de progrès quand c'est à l'informatique que cela s'applique (il y a 20 ans, mon TO8D sortait sur le marché, et en même temps la toute première version de Windows qui n'a jamais réellement pris).
- Il est très facile de camoufler un principe trivial derrière une description absconse. Le brevet sur le OU Exclusif occupe 32 pages A4. Dans le même esprit, je pourrais très bien déposer un procédé qui consistant à calculer le montant d'une facture par addition successive du prix des différents articles. Ces deux procédés sont tout-à-fait comparables.
- On pourrait de la même façon breveter le concept du langage de programmation. Les seules marges de manoeuvre dont on disposerait consisteraient à immiter ce qui s'est fait jusque-là parce que cela tomberait sous le coup de l'antérioté au brevet. Plus aucune innovation ne serait possible alors que c'est précisément l'un arguments les plus mis en avant par les défenseurs d'une telle hérésie.
- Enfin, et c'est peut-être là le plus important, écrire des logiciels est une activité à la fois scientifique et intellectuelle, comme écrire des livres ou connaître les fondements de l'électricité ou de la chimie. Tout le monde devrait aujourd'hui faire un peu de programmation. Ce genre de directive va conduire à interdire de fait ce genre d'activité.
[^] # Re: Autre suggestion
Posté par Obsidian . En réponse au message problème d'acces à une méthode. Évalué à 2.
double parameters[];
Ce qui reste correct d'un point de vue syntaxique, mais qui définit un pointeur sans la mémoire qui va derrière. Cela suffirait à expliquer tes segfaults intermittentes : Lorsque tu écriras dans ce tableau, tes données n'iront pas se loger dans un endroit prévu à cet effet mais dans l'espace réservé aux variables membres que tu définis plus loin ! Donc, tu as la place de semer la pagaille un bon moment avant de planter. En fait, ton programme pourra continuer à faire le con tant qu'il ne sortira pas du segment de mémoire alloué pour ta classe entière, lequel segment aura probablement une taille alignée sur une page quelquonque. Ceci pourrait expliquer les différences de plantage en fonction des plateformes.
[^] # Re: Z'avez une piste ?
Posté par Obsidian . En réponse au message Dialogue sur le port série /dev/ttyS0. Évalué à 3.
A mon avis, d'un coté on a soit une parité paire (et 7 bits de données), soit pas de parité du tout (8 bits de données). D'un autre, les débits sont presque toujours 9600, 19200 ou 38400. Cela fait 6 combinaisons à essayer.
Enfin, utilise le menu de configuration de minicom (Ctrl-A puis Z puis O (Configurer) puis Configurer le port série) car il réinitialise lui-même le port.
Bonne chance.
[^] # Re: Des détails, des détails :-)
Posté par Obsidian . En réponse au message problème d'acces à une méthode. Évalué à 2.
# Segfault ?
Posté par Obsidian . En réponse au message problème d'acces à une méthode. Évalué à 2.
Ensuite, elle est censée faire quoi ta fonction f ? Parce qu'une fonction mathématique sans inconnue (type void), c'est pas courant. A mon avis, le problème se situe dans le code de ta fonction.
Mets le tout en GPL et tu pourras bénéficier de l'aide de la communauté ! :-)
# Z'avez une piste ?
Posté par Obsidian . En réponse au message Dialogue sur le port série /dev/ttyS0. Évalué à 4.
Essaie de régler correctement vitesse, parité, et bit de start/stop, tout devrait rentrer dans l'ordre. 9600Bauds/Parité paire/Un bit stop est une configuration très courante.
# Ne t'inquiète pas.
Posté par Obsidian . En réponse au message Ordi 64 bits et C++. Évalué à 3.
# Ben G++
Posté par Obsidian . En réponse au message Logiciel C++. Évalué à 4.
[^] # Re: Istalle kppp !
Posté par Obsidian . En réponse au message comment créer un bouton d'accés internet sur le tableau de bord ?. Évalué à 2.
J'ai également été assez surpris de voir kppp relégué à l'arrière-plan par Mandrake. Cela fait partie des bizarreries dont souffre cette distribution depuis quelques temps.
[^] # Re: Chanceux
Posté par Obsidian . En réponse au message Editeur hexa. Évalué à 2.
( * Aïe ! *)
[^] # Ou rev ...
Posté par Obsidian . En réponse au message Parcourir un fichier à l'envers.. Évalué à 4.
$ cat fichier | rev | more
[^] # Re: yo
Posté par Obsidian . En réponse au message Question sur Perl-Gtk !. Évalué à 2.
Ceci dit, si l'on peut éviter d'utiliser un thread pour tout et n'importe quoi, c'est aussi bien. Le multitâche coopératif est extrêmement bénéfique lorsqu'on l'implémente au sein d'un même programme ...
[^] # Re: Ah bon ?
Posté par Obsidian . En réponse au message bug télédéclaration. Évalué à 2.
# /etc/shells
Posté par Obsidian . En réponse au message Nécessité de préciser "sh script.sh". Évalué à 3.
# Fais comme l'oiseau
Posté par Obsidian . En réponse au message icones. Évalué à 3.
Y a un certain LaFontaine qui avait fait un HOWTO sur le sujet, mais je crois qu'il date un peu maintenant ...
[^] # Re: solution du hacker fou
Posté par Obsidian . En réponse au message Inverser deux touches du clavier. Évalué à 2.
# Xmodmap
Posté par Obsidian . En réponse au message Inverser deux touches du clavier. Évalué à 3.
Donc, sous x, xmodmap devrait te tirer d'affaire. Evidement, il ne faut pas que le logiciel se soucie des scancodes, mais bon. En principe ce n'est jamais le cas.
[^] # Re: trop pas gros, passera pas...
Posté par Obsidian . En réponse à la dépêche FACT, un projet de directive européenne pour une dictature numérique ?. Évalué à 2.
http://linuxfr.org/2003/12/09/14814.html(...)
# Pas frais, ce poisson !
Posté par Obsidian . En réponse à la dépêche FACT, un projet de directive européenne pour une dictature numérique ?. Évalué à 6.
Moi, maintenant, j'aurais bien vu un truc du style :
"Après Hotmail, Microsoft acquiert DLFP"
Ca, ç'aurait été un bon trool des familles ! :-)
[^] # Re: Ce que Microsoft s'est bien gardé de dévoiler
Posté par Obsidian . En réponse au journal OEB recrute. Évalué à 4.
[ ] Oui
[ ] Non
[ ] Ne sais pas
[ ] <- Je sors.
Etant donné la proportion de « portes » déjà prises sur linuxfr.org, cela doit faire grimper le pourcentage. :-)
Plus sérieusement, s'il n'y avait que des lumières qui utilisaient Linux, cela se saurait. Et puis il faut prendre en compte la mauvaise foi aussi ...
# Pas nouveau ...
Posté par Obsidian . En réponse au journal XXX mais pas trop transparent. Évalué à 3.
http://www.linuxfr.org/2002/08/15/9275.html(...)
Linus himself a dù intervenir pour dire « C'est marrant, mais ça suffit ».
[^] # Re: Re:questions relatives à l'execution d'un programme....
Posté par Obsidian . En réponse au message questions relatives à l'execution d'un programme..... Évalué à 2.
DLL = Dynamically Linkable Library
Comme çà, tout est dit.
[^] # Re: correction
Posté par Obsidian . En réponse au message Petit problème d'ascenseur.... Évalué à 2.
# Petit problème d'ascenseur...
Posté par Obsidian . En réponse au message Petit problème d'ascenseur.... Évalué à 3.
Prendre l'escalier ? /o\
[^] # Re: Re:questions relatives à l'execution d'un programme....
Posté par Obsidian . En réponse au message questions relatives à l'execution d'un programme..... Évalué à 3.
Exemple : Ouvrir une fenêtre. Il est bien sûr inconcevable que chaque programmeur réécrive lui-même le système X-Window depuis zéro pour pouvoir travailler. A la place, il va faire appel à une fonction de réputation publique (dont on mettra le prototype dans un *.h pour que le programme C sache comment l'utiliser).
Ensuite, au moment de construire l'exécutable, on intégrera dans le fichier les fonctions de gestion de fenêtres, déjà compilées à cet effet. C'est donc une bibliothèque statique. C'est exactement comme un exécutable sauf qu'il n'y pas de point d'entrée.
Par contre, quand il commence à y avoir beaucoup de programmes quu ouvrent des fenêtres, on se rend compte que d'une part les exécutables sont gargantuesques (toute la gestion du X est intégrée dans l'exécutable juste pour afficher Hello World à l'écran), et que d'autre part il est idiot de charger 15 fois en mémoire les même fonctions ! A la place, on ne va compiler que le nécéssaire et l'on va laisser "en l'air" les reférences à la bibliothèque partagée. Ce sera alors le boulot du système d'exploitation de charger LORSQUE C'EST NECESSAIRE les ressources dont un logiciel a besoin et de résoudre les noms de fonctions en adresse mémoire.
En outre, et c'est là l'intérêt majeur, si la ressource réclamée a déjà été chargée pour un autre logiciel, il est inutile de la charger une deuxième fois (gain de temps), et les deux programmes peuvent appeler le même endroit (gain de place).
Avantage de la compilation statique: On obtient un exécutable parfaitement autonome, ou presque, qui pourra fonctionner toutes les plateforme équipées d'un même OS. Inconvénient: Cela génère des exécutables gigantesques pour rien.
Avatnage de la compilation dynamique: On ne compile que ce qui est nécéssaire, on gagne du temps et de la place, et quand on met à jour une fonction, cela se répercute immédiatement sur tous les programmes qui l'utilisent. Inconvénient, lorsque l'on installe un logiciel, il faut installer toute sa suite avec, vérifier si les libs ne sont pas déjà en place, etc. et gérer les dépendances en cascades (tel logiciel à beosin de telle lib, qui elle même s'appuie sur une autre lib, qui à son tour a besoin deux trois libs de plus bas niveau, etc.).