C'est aussi un moyen simple de créer un programme qui peut être exécuté sur n'importe quelle machine ayant un serveur http supportant les CGI, qui sont un standard.
OK, ça se tient.
Je pourrais apprendre à utiliser un nouveau langage, tel que perl ou python, c'est vrai. Ou supporter l'absence de typage de php. Mais j'ai un impératif de temps aussi.
Combien de temps vas-tu passer pour débugger ? A mettre dans la balance également. Et juste par curiosité, tu utilises quel langage ?
Le programme en question est un webservice: tu lui poses une question, il te réponds.
C'est pas du web interactif ça ?
Je voulais juste dire par la que le CGI en question n'utilise pas explicitement de thread multiples.
Dans ce cas il te faut vérifier que tu utilises les bons modules apache, et que as tout configuré pour gérer ce cas de figure (voir un des liens que je t'ai proposé comme piste de départ).
Ah, encore un lien intéresant, qui combiné à celui que je t'ai indiqué plus haut devrait te permettre ( du moins je l'espère) de faire ce que tu veux :
Il y a pléthore de langages très bien adaptés à du web interactif ….
Sinon, si tu as un serveur web multithread et que ton CGI ne gère pas le multithread, ça ne peut pas marcher. Il faut que tu examine chaque fonction utilisée dans ton CGI pour savoir si elle est thread-safe. Beau sac de noeuds en perspective.
, il s'agit d'un cgi ( pas multi-threadé, le cgi, hein… )
Comment peux-tu en être certain, vu que le programme qui l'appelle est multithreadé ?
… du style : la commande passée et le message retourné, et également comment et sur quoi le volmume persistant ont été créés. Là, avec la meilleure volonté du monde, on ne peut aider.
Ou alors les devs ne sont pas des gros blaireaux et ils utilisent libxml ou autres bibliothèques codées par des gens qui savent écrire et tester un parseur.
Et ? Est-ce une obligation d'utiliser XML ? N'y a-t-il pas d'autres parseurs pour d'autres formats ?
Un truc qui commence à sévèrement me péter les noix, c'est justement les 42000 sortes de fichiers de configuration différents qu'on peut trouver sur nos systèmes. . Ca me parait contre-productif de devoir apprendre une nouvelle syntaxe pour configurer un produit donné, au lieu de se concentrer uniquement sur la partie "fonctionnelle".
XML ou pas, tu es obligé d'apprendre la syntaxe de chaque balise XML, etc … avec parfois des différences assez amusantes d'un produit à l'autre : ce qu'un développeur considèrera comme étant un argument pourra être considéré comme un élément XML par un autre. Donc même si tu as la même syntaxe, tu trouves beaucoup de différences également.
XML a été fait pour l'interopérabilité entre machines et OS ayant des représentations internes différentes, et de ce fait a utilisé un encodage de base plutôt "universel".
Je viens de vérifier, et il semble que finalement c'était l'un des buts du XML . J'avais lu il y a quelques temps déjà que le fait que XML soit lisible humainement était plutôt une conséquence qu'un objectif (je vais tenter de retrouver ma source). Celà dit c'est bizarre, car un document xml peut contenir des blobs binaires, ce qui est étrange pour un document lisible par un humain.
Maintenant, si on se penche sur le résultat, il est clair que l'objectif est complêtement raté de ce point de vue, et qu'il y a des formats mieux adaptés pour la lecture humaine …
Mais j'avoue que personnellement, je suis toujours resté septique par rapport à ce format qu'on m'a toujours vendu comme universel, car facile à comprendre par l'homme et le machine.
C'est l'erreur de base de tous les pros-xml.
XML a été fait pour l'interopérabilité entre machines et OS ayant des représentations internes différentes, et de ce fait a utilisé un encodage de base plutôt "universel".
Le format en lui même, bien que verbeux, n'est pas si mauvais que ça pour les cas ou il est bien employé : c'est le détournement qui en a été fait qui est pénible.
Personnellement je rale depuis des années sur les fichiers de conf XML à modifier à la main, là ou l'interopérabilité n'est pas nécessaire. Et en général, on se rend compte que la seule raison de la présence de XML, c'est la paresse des devs qui ne veulent pas écrire un parseur (celà dit il y a un tas de formats qui peuvent être utilisés à la place du XML sans avoir à réinventer la roue).
Celà dit je crois comprendre que la tendance s'inverse un peu : parenons l'exemple de JEE : a une époque, le XML était plus ou moins incontournable. Aujourd'hui il a évolué. On peut toujours utiliser le XML, mais ce n'est plus indispensable. Et j'espère que cette tendance continuera.
Tu devrais te renseigner sur la quantité de fils embarqués dans une voiture. Tu comprendrais que 'juste économiser du fil' peut avoir du sens, en terme de complexité et de maintenance.
Celà dit, c'est comme tout, il ne faut pas tomber dans l'extrême (d'un côté comme de l'autre).
ISCSI + Global Filesystem, ça pourrait peut-être le faire ?
En gros, quand tu ajoutes une nouvelle machine, tu la configures en serveur iscsi. Avec LVM + Global Filesystem, tu ajoutes tes LUNs ISCSI à un volume LVM + GFS.
Par contre si tu multriplies trop les machine,s ça risque de devenir compliqué à gérer ..
Oui, il y en a, parfois plus de 2. Toutr simplement parce que le contrôle des équipements de sécurité des contraintes de latence faible, et équiper l'ensemble du véhicule avec ce genre de composants couterait plus cher.
Posté par totof2000 .
En réponse au journal <3 goto.
Évalué à 2.
Ouai c'est tout de même dommage d'en venir à dire que le langage à une propriété qui pose problème aux outils. Autant j'aime bien python sur pleins de point autant je ne trouve pas que l'indentation comme seul marqueur de bloc soit une bonne idée (alors que la rendre obligatoire ça c'est une bonne idée).
Je suis tout à fait d'accord avec toi, parce que j'ai également rencontré ce genrte de problème, qui aurait pu être évité si l'indentation n'était pas utilisée comme délimiteur de bloc. Et je suis également d'accord avec toi sur le fait qu'obliger l'indentation dans un langage est une bonne idée. Mais quand je dis ça à un pythonneux "pragmatique", il fait la sourde oreille et trouve un tas d'excuses bidon, et en général, se défausse sur l'IDE.
Posté par totof2000 .
En réponse au journal <3 goto.
Évalué à 1.
J'ai pas souvenir d'avoir croisé d'extrémistes … Mais plutôt des pragmatiques.
Des gens qui imposent leur vision du pragmatisme, il y en a.
Des pseudo-pragmatiques qui te disent que Python c'est bien parce que ton programme ne peut pas bugger suite à un oubli de tabulation parce qu'il ne compilera pas aussi.
Posté par totof2000 .
En réponse au journal <3 goto.
Évalué à 2.
Et pourquoi tu ne réagis pas pareil avec Apple?
Il faut se remettre dans le contexte de la faille révélée dans le précédent journal : le code d'Apple était pourri et mal écrit. Si GNU TLS est aussi mal écrit, les mainteneurs n'ont qu'à changer de métier ou de hobby …
Posté par totof2000 .
En réponse au journal <3 goto.
Évalué à 3.
Et envers Red Hat? RHSA
Si le code de la lib est aussi pourri que celui fourni par Apple, si le bug pouvait être facilement détectable par des outils de vérification de code (détection de code mort, etc …), alors oui, ils sont autant à blamer qu'Apple. De même pour les mainteneurs de la lib GNU TLS si le bug incriminé aurait pu être détecté facilement avec les outils adéquat (la lib en question est une lib censée fournir de la sécurité). Maintenant, en cas de bug tordu difficile à détecter, ni Apple, ni Debian, ni personne n'est à blamer dans la mesure ou la faille est prise en compte et corrigée.
Posté par totof2000 .
En réponse au journal <3 goto.
Évalué à 2.
En fait, à force de trolls ici, je me rends compte que ce n'est pas Python qui est le plus horrible : je n'aime pas trop certaines choses dans le langage (et à l'inverse il y a des notions qui me plaisent dedans, mais c'est comme tout langage). En fait le plus horrible, ce sont les "défenseurs extrémistes" de Python qui vendent le langage avec des propriétés et des qualités qu'il n'a pas, ce qui fait qu'à la fin on est déçu parce que le langang e n'est pas si bien qu'on nous l'a vendu. Certains ont fait la même chose à une époque avec GNU/Linux (notamment Mandrake qui "vendait" une distrib censée être simple mais buggée jusqu'à la moelle). Le résultat : un tas de personnes qui ont voulu essayer Linux se sont fait "avoir" et n'y reviendront plus.
Posté par totof2000 .
En réponse au journal <3 goto.
Évalué à 3.
Exactement comme tous ces utilisateurs de GNUTLS qui ne veulent pas sortir la thune de leur poche.
Là je ne peux malhereusement qu'être d'accord avec toi …
Maintenant que tu parles de volonté, assume et insulte autant les utilisateurs de GNUTLS d'être de gros radins.
Pas que les utilisateurs de GNU TLS, mais beaucoup d'utilisateurs du libre (et j'en fais partie, bien que parfois je fasse quelques dons à quelques projets libres).
C'est le concours de qui est le plus faux-cul la. Merci pour les belles démonstrations
Non, c'est d'ailleurs pour ça que je suis moins critique envers Debian ou GNU TLS qu'envers Apple : si je veux que GNU TLS mette plus de moyens, je n'ai qu'à les payer. Et c'est assez cohérent quelque part.
[^] # Re: Pas de liaison mécanique ?
Posté par totof2000 . En réponse à la dépêche Encore un exemple de code spaghetti : Toyota. Évalué à 2.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . En réponse au journal XML c'est de la daube!!!. Évalué à -1.
0100010101110011011101000010110101100011011001010010000001110001011101010110010100100000011011010110000101101001011011100111010001100101011011100110000101101110011101000010000001110100011101010010000001100011011011110110110101110000011100100110010101101110011001000111001100100000011011000110000100100000011001000110100101100110011001101100001110101001011100100110010101101110011000110110010100100000011001010110111001110100011100100110010100100000011101000110010101111000011101000110010100100000011001010111010000100000011000100110100101101110011000010110100101110010011001010010000000111111
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . En réponse au journal XML c'est de la daube!!!. Évalué à -1.
Je vais te faire lire les Misérables en affichant les caractères en Hexa, peut-être que tu comprendras la différence
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par totof2000 . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 2.
J'aurais dû mette un smyley, ma remarque n'était pas à prendre au sérieux.
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par totof2000 . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 2.
Ou il te répond sans que tu poses de question ?
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par totof2000 . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 2.
OK, ça se tient.
Combien de temps vas-tu passer pour débugger ? A mettre dans la balance également. Et juste par curiosité, tu utilises quel langage ?
C'est pas du web interactif ça ?
Dans ce cas il te faut vérifier que tu utilises les bons modules apache, et que as tout configuré pour gérer ce cas de figure (voir un des liens que je t'ai proposé comme piste de départ).
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par totof2000 . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 2.
Ah, encore un lien intéresant, qui combiné à celui que je t'ai indiqué plus haut devrait te permettre ( du moins je l'espère) de faire ce que tu veux :
http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par totof2000 . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 2.
Pour plus d'infos :
http://httpd.apache.org/docs/current/mod/mod_cgid.html
# Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par totof2000 . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 3.
Il y a pléthore de langages très bien adaptés à du web interactif ….
Sinon, si tu as un serveur web multithread et que ton CGI ne gère pas le multithread, ça ne peut pas marcher. Il faut que tu examine chaque fonction utilisée dans ton CGI pour savoir si elle est thread-safe. Beau sac de noeuds en perspective.
Comment peux-tu en être certain, vu que le programme qui l'appelle est multithreadé ?
[^] # Re: Ce sondage
Posté par totof2000 . En réponse au journal Sondage : Que voulez-vous sur la page d'accueil de linuxfr ?. Évalué à 4.
Je n'arrive pas à voter. La réponse du site indique que j'ai déjà voté ce qui est faux. Pourri ce système de sondage !!!
# !n peu plus de détails seraient bienvenus.
Posté par totof2000 . En réponse au message "Cet ordinateur n'a plus que 0 octet d'espace disponible". Évalué à 2.
… du style : la commande passée et le message retourné, et également comment et sur quoi le volmume persistant ont été créés. Là, avec la meilleure volonté du monde, on ne peut aider.
Sinon, c'est quoi TAILS ?
[^] # Re: Sans être fan du tout
Posté par totof2000 . En réponse au journal XML c'est de la daube!!!. Évalué à -1.
Et ? Est-ce une obligation d'utiliser XML ? N'y a-t-il pas d'autres parseurs pour d'autres formats ?
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . En réponse au journal XML c'est de la daube!!!. Évalué à 4.
XML ou pas, tu es obligé d'apprendre la syntaxe de chaque balise XML, etc … avec parfois des différences assez amusantes d'un produit à l'autre : ce qu'un développeur considèrera comme étant un argument pourra être considéré comme un élément XML par un autre. Donc même si tu as la même syntaxe, tu trouves beaucoup de différences également.
[^] # Re: XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . En réponse au journal XML c'est de la daube!!!. Évalué à 3.
Je viens de vérifier, et il semble que finalement c'était l'un des buts du XML . J'avais lu il y a quelques temps déjà que le fait que XML soit lisible humainement était plutôt une conséquence qu'un objectif (je vais tenter de retrouver ma source). Celà dit c'est bizarre, car un document xml peut contenir des blobs binaires, ce qui est étrange pour un document lisible par un humain.
Maintenant, si on se penche sur le résultat, il est clair que l'objectif est complêtement raté de ce point de vue, et qu'il y a des formats mieux adaptés pour la lecture humaine …
# XML n'a jamais été fait pour être compréhensible par l'homme
Posté par totof2000 . En réponse au journal XML c'est de la daube!!!. Évalué à 10.
C'est l'erreur de base de tous les pros-xml.
XML a été fait pour l'interopérabilité entre machines et OS ayant des représentations internes différentes, et de ce fait a utilisé un encodage de base plutôt "universel".
Le format en lui même, bien que verbeux, n'est pas si mauvais que ça pour les cas ou il est bien employé : c'est le détournement qui en a été fait qui est pénible.
Personnellement je rale depuis des années sur les fichiers de conf XML à modifier à la main, là ou l'interopérabilité n'est pas nécessaire. Et en général, on se rend compte que la seule raison de la présence de XML, c'est la paresse des devs qui ne veulent pas écrire un parseur (celà dit il y a un tas de formats qui peuvent être utilisés à la place du XML sans avoir à réinventer la roue).
Celà dit je crois comprendre que la tendance s'inverse un peu : parenons l'exemple de JEE : a une époque, le XML était plus ou moins incontournable. Aujourd'hui il a évolué. On peut toujours utiliser le XML, mais ce n'est plus indispensable. Et j'espère que cette tendance continuera.
[^] # Re: Quelles sont les entrées / sorties d'un tel programme ?
Posté par totof2000 . En réponse au journal Encore un exemple de code spaghetti : Toyota. Évalué à 3.
Tu devrais te renseigner sur la quantité de fils embarqués dans une voiture. Tu comprendrais que 'juste économiser du fil' peut avoir du sens, en terme de complexité et de maintenance.
Celà dit, c'est comme tout, il ne faut pas tomber dans l'extrême (d'un côté comme de l'autre).
# une idée, sans cependant avoir creusé ...
Posté par totof2000 . En réponse au message Recherche système de fichier distribué extensible. Évalué à 2.
ISCSI + Global Filesystem, ça pourrait peut-être le faire ?
En gros, quand tu ajoutes une nouvelle machine, tu la configures en serveur iscsi. Avec LVM + Global Filesystem, tu ajoutes tes LUNs ISCSI à un volume LVM + GFS.
Par contre si tu multriplies trop les machine,s ça risque de devenir compliqué à gérer ..
[^] # Re: mkfifo + tail -f ?
Posté par totof2000 . En réponse au message exposer un script comme un service. Évalué à 2.
C'est ce que j'ai répondu plus haut. Il faut par contre jouer avec ses options pour esperer que le service se comporte comme il le veut.
[^] # Re: Quelles sont les entrées / sorties d'un tel programme ?
Posté par totof2000 . En réponse au journal Encore un exemple de code spaghetti : Toyota. Évalué à 3.
Oui, il y en a, parfois plus de 2. Toutr simplement parce que le contrôle des équipements de sécurité des contraintes de latence faible, et équiper l'ensemble du véhicule avec ce genre de composants couterait plus cher.
[^] # Re: goto
Posté par totof2000 . En réponse au journal <3 goto. Évalué à 2.
Je suis tout à fait d'accord avec toi, parce que j'ai également rencontré ce genrte de problème, qui aurait pu être évité si l'indentation n'était pas utilisée comme délimiteur de bloc. Et je suis également d'accord avec toi sur le fait qu'obliger l'indentation dans un langage est une bonne idée. Mais quand je dis ça à un pythonneux "pragmatique", il fait la sourde oreille et trouve un tas d'excuses bidon, et en général, se défausse sur l'IDE.
[^] # Re: goto
Posté par totof2000 . En réponse au journal <3 goto. Évalué à 1.
Des gens qui imposent leur vision du pragmatisme, il y en a.
Des pseudo-pragmatiques qui te disent que Python c'est bien parce que ton programme ne peut pas bugger suite à un oubli de tabulation parce qu'il ne compilera pas aussi.
[^] # Re: 2 poids, 2 mesures
Posté par totof2000 . En réponse au journal <3 goto. Évalué à 2.
[^] # Re: 2 poids, 2 mesures
Posté par totof2000 . En réponse au journal <3 goto. Évalué à 3.
Si le code de la lib est aussi pourri que celui fourni par Apple, si le bug pouvait être facilement détectable par des outils de vérification de code (détection de code mort, etc …), alors oui, ils sont autant à blamer qu'Apple. De même pour les mainteneurs de la lib GNU TLS si le bug incriminé aurait pu être détecté facilement avec les outils adéquat (la lib en question est une lib censée fournir de la sécurité). Maintenant, en cas de bug tordu difficile à détecter, ni Apple, ni Debian, ni personne n'est à blamer dans la mesure ou la faille est prise en compte et corrigée.
[^] # Re: goto
Posté par totof2000 . En réponse au journal <3 goto. Évalué à 2.
En fait, à force de trolls ici, je me rends compte que ce n'est pas Python qui est le plus horrible : je n'aime pas trop certaines choses dans le langage (et à l'inverse il y a des notions qui me plaisent dedans, mais c'est comme tout langage). En fait le plus horrible, ce sont les "défenseurs extrémistes" de Python qui vendent le langage avec des propriétés et des qualités qu'il n'a pas, ce qui fait qu'à la fin on est déçu parce que le langang e n'est pas si bien qu'on nous l'a vendu. Certains ont fait la même chose à une époque avec GNU/Linux (notamment Mandrake qui "vendait" une distrib censée être simple mais buggée jusqu'à la moelle). Le résultat : un tas de personnes qui ont voulu essayer Linux se sont fait "avoir" et n'y reviendront plus.
[^] # Re: 2 poids, 2 mesures
Posté par totof2000 . En réponse au journal <3 goto. Évalué à 3.
Là je ne peux malhereusement qu'être d'accord avec toi …
Pas que les utilisateurs de GNU TLS, mais beaucoup d'utilisateurs du libre (et j'en fais partie, bien que parfois je fasse quelques dons à quelques projets libres).
Non, c'est d'ailleurs pour ça que je suis moins critique envers Debian ou GNU TLS qu'envers Apple : si je veux que GNU TLS mette plus de moyens, je n'ai qu'à les payer. Et c'est assez cohérent quelque part.