Si c'est un problème de visualisation, genre, luminosité trop faible/forte, xrandr pourrait vous aider.
Ca n'est qu'une bidouille logicielle par contre donc pas sûr qu'une économie de batterie soit espérable. Enfin, faut voir la nature exacte du problème après j'imagine.
En fait, tu souhaiterais qu'ils mettent la fonction en deprecated avant de la virer quoi?
Tu te rends compte de la somme de travail et maintenance que ça leur demanderais?
Je ne parle pas au niveau du code, bien entendu, mais au niveau moral: il leur faudrait alors accepter que ce qui est nouveau n'est pas optimal!
Non, testing n'est pas censé recevoir les dernières nouveautés. Testing, c'est la beta, après tout.
Au fait, quelqu'un sait comment sont incrémentés ces numéros de version?
Je n'arrive pas à les lire…. enfin… à les interpréter.
Avec le système initié par ubuntu, donc, les dates, on arrive à connaître l'âge d'une version.
Avec le système plus éprouvé M.m.b on arrive à estimer la différence de fonctionnalités.
Mais, avec les numéros débiles type firefox, chrome, et systemd, je n'arrive vraiment pas à avoir la moindre idée de la somme des changements entre 2 versions…
Pour les archis restée en 44, c'est pas illogique qu'elles ne soient pas montées plus haut. Ces systèmes sont minoritaires, et la portabilité de systemd est plus que discutable. Le sieur Lennart code pour la dernier version de linux, si je ne m'abuse, et les autres peuvent aller brouter ailleurs.
Conclusion: ceux qui ont des archis différentes, auront des emmerdes avec systemd. Mais bon, rien de neuf ici.
Rien de visible sans JS? A part un avertissement que sans JS c'est pas optimal… ( en meme temps, y'a rien, sans JS :/ )
Après activation, rien non plus ne s'affiche.
J'utilise opera en JS désactivé par défaut, je l'ai activé pour le site, mais… plus rien du tout.
Pour certains usages, je peux comprendre, mais pour une FAQ? Ce n'est pas censé être juste une page avec:
un sommaire
une liste contenant:
n questions
une réponse associée à chaque question
Et donc, pourquoi nécessiter JS pour si peu? Je sais, je suis chiant de désactiver JS par défaut. Mais c'est pour la sécurité de mon système, qui n'est en plus pas super musclé et donc, sur certains sites ( pas rares ) , JS pourrit l'utilisabilité de la machine.
J'imagine que tu plaisantes, mais j'ai récemment songé sérieusement à me mettre à l'ADA, qui offre un certain nombre de points commun avec le C++, en mieux ( encore plus casse-pied sur les types, il paraît… J'aime bien l'idée! Et puis, un langage qui produit de vrais binaires, vraiment lisibles par le CPU, ça se fait rare de nos jours, alors en connaître 2 ( 4 si je compte le C et l'asm intel x86 - hum, et encore - … ) me ferait bien plaisir )
Par contre, il semble qu'il y ait un manque critique de lib pour gérer correctement les IHM sous ce langage. Il y a aussi le fait que gnat soit infernal à utiliser. Ce truc est le pire IDE que j'aie tenté d'utiliser sérieusement… GUI bordélique à souhait, on sait même pas ou aller pour compiler un nouveau projet. Bref. Je ne parlerait pas du tuto qui présuppose un nombre élevé de trucs. Ca reste de la doc de gnou, dans le genre bestial on fait difficilement mieux (avis personnel).
Et je n'ai pas trouvé grand chose (rien en fait, mais j'avoue que pour m'initier à un nouveau langage, j'aurait préféré un outil qui en fasse un maximum à ma place, pour commencer gentiment. Donc pas plus cherché que ça) au sujet de compiler en ligne de commande, non plus ( pourtant, ça me suffit amplement, compte tenu du fait que mon système utilisateur est un vrai IDE pour c++ en tant que tel, à condition de savoir taper 3-4 commandes ).
SDL à un portage entamé pour ADA( sur github ), par quelqu'un qui veut prouver qu'on peut faire des jeux en ADA ( ce qui, compte tenu du fait que ce langage soit conçu pour créer des armes militaires, et donc pour être hyper fiable tout en pouvant gérer du bas niveau - comme C++ en fait, sauf pour les armes militaires - , me semble pas stupide! ). Mais je crains que ce portage ne soit pas spécialement utilisable.
Le concurrent de la SDL, la SFML, ne supporte certainement pas l'ADA, et personne ne semble s'y être mis ( logique, SFML est déjà peu utilisée en C++, alors porter pour ADA… ).
Et pour finir, il semble que, comme C++, ADA n'ait pas de lib pour créer des GUI, ou plutôt pas de "lib mainstream" ( mais pour un langage si peu connu… pas surprenant ).
Pour un jeu vidéo… ces détails sont gênants, car le jeu vidéo fait une grande utilisation de l'écran, et pas juste pour afficher 3 caractères qui se battent en duel ( toujours, toujours compter le témoin! Sinon, c'est un assassinat ;) ).
Du coup, coder un jeu en ADA serait… particulièrement intéressant, pour moi. Réinventer la roue n'est pas systématiquement mauvais ( la plupart des libs de toolkit le font, après tout, sauf wx ) si l'on fait un truc propre qui n'est pas lié par les contrainte historiques du langage.
Mais je ne crois pas que tout le monde serait d'accord avec moi. Réinventer la roue, remettre en question les implémentations séculaires ( ou demi-séculaires pour les logiciels ) n'est pas toujours bien vu, surtout s'il existe un truc libre.
Il s'agit de quelque chose que j'aimerais bien faire, en fait. Faire différemment des autres, par esprit de contradiction, mais aussi parce que je serais toujours moins bon que les autres dans leur domaine d'expertise si je me contente de les singer. Et faire différemment permets parfois de trouver de nouvelles façons efficaces de faire les choses. Les inventions et trouvailles majeures liées à des erreurs, ça existe, après tout (on peut rêver).
PS: si t'as des document expliquant comment faire un vrai hello world, en ligne de commande, pas à pas, expliquant la syntaxe et les paradigmes du langage plutôt que des trucs aussi inutiles que la description de l'API des fonctions standard ( pour lesquelles un lien vers un document les expliquant de façon technique me suffit. Je ne suis peut-être pas un maître du dev, mais je suis un dev malgré tout, lire de la doc d'API me fait pas peur. )
A partir d'un truc aussi petit, qui explique comment compiler et la syntaxe, on peut apprendre très vite le reste. Créer un mécanisme de GUI n'est pas si dur après tout: une classe fenetre, une sizer qui en hérite et agrège une liste de fenetre, une spacer qui hérite de fenetre, et une widget qui hérite de fenetre et agrège une image, et la moitié est faite. L'autre moitié, c'est dire que fenetre agrege des gestionnaires d'évènements… rien d'extraordinaire. Et avec la prog générique, on peut faire un truc qui aie le même comportement en mode graphique ou en mode texte en plus.)
C'est normal.
Après tout, Debian vise la stabilité, et, même s'ils ont accepté de passer à systemd, ils ne vont pas mettre à jour la stable à chaque version de build, qui apporte manifestement autant de bugfix que de nouveaux bugs nouvelles fonctionnalités.
( vous m'avez pourri mon dredi à pas troller pendant mes 7H… alors je me dévoue un peu )
Et pas de commentaire sur les trucs intéressants pour l'utilisateur final
En même temps, systemd, c'est pas censé être une amélioration pour l'utisateur final… ( le vendredi, c'est permis, non? )
Plus "sérieusement", j'ai réussi à me forcer à lire tout… jusqu'a la fin de la 1ère version ( par ordre d'apparition dans le nourjal). Après… TL;DR.
Alors, c'est vrai qu'un bon troll de compèt n'a pas besoin de lire, mais tout le monde ne peux pas être expert.
Merci de ton retour (quand je repasserais dans une période de gamer, je tenterais sûrement).
J'avoue ne pas être surpris, au vu des avis relativement unanimes que j'en ais lus sur le ouaib, mais, je me suis toujours demandé ( et flemme de chercher/expérimenter moi-même ) comment ça marche au niveau installation/configuration?
A part l'habituel "./configure && make && make install" je veux dire.
Est-ce complexe? Parce que j'avoue: autant j'aime me prendre la tête pour coder voire configurer mon environnement de bureau… autant, pour un jeu, non, ça ne me tente pas, et je me laisse aller à la faiblesse de rebooter en mode windows XP.
Ce qui est dommage, parce qu'a chaque fois que je le fais, je me sens juste… un peu comme un randonneur qui se récupère des béquilles… ( le gestionnaire de fenêtre de windows, quand on est habitué à i3—donc du tiling—est vraiment douloureux! )
Pour communiquer avec des appareils sur la distance, je crois que d'habitude on utilise des câbles ethernet. Après, rien ne t'empêche de les utiliser pour autre chose que le protocole tcp/ip. Ni de faire un adaptateur usb/rj45 pour ne pas avoir à modifier le câble ou l'arduino.
Boarf, c'est pas pire que la version papier-crayon… en tout cas, c'est le résultat du sondage avec mes potes crâniens: on est 15 à approuver, contre seulement 3 à ne pas être d'accord, plutôt pas mal comme score.
C'est effectivement possible de se faire passer pour 2 personnes différentes en modifiant son style d'écriture, mais l'exercice n'est pas simple, en tout cas pas pour moi. Il est tellement simple de faire une erreur qui révèle que les 2 personnes sont les mêmes: du genre dire quelque chose que seul l'autre ( des deux ) est censé savoir ( je me suis amusé à ce petit jeu sur un mmo rpg, en me faisant passer pour un débutant complet avec un de mes personnages créé pour l'occasion, alors que je connais plutôt bien le jeu en question ).
Après, si on se crée une sorte de dictionnaire d'expressions et de tics de langage non commun pour toutes ses identités, on peut berner facilement un lecteur pas trop attentif.
C'est installé par défaut sur les distributions grand public ?
Je pense que oui, mais j'ai beau utiliser une debian, je suis du genre à ne rien installé de base et ajouter juste les 10-20 outils que j'utilise réellement à la main donc…
Le paquet qui contiens cet outil, c'est xdg-utils, donc je pense qu'il est utilisé par les gros DEs.
Parler de xdg-open pourrait être utile: on parle de débutants, qui ne savent pas nécessairement reconnaître le programme associé à fichier en voyant son extension. Sans compter que certains programmes ne sont pas très sympa à utiliser en ligne de commande.
Quand tu parles d'arrêter/redémarrer la machine, tu peux aussi parler des hibernations ( tâches courantes ) via pm-[hibernate/suspend/whatever].
Et dernier point abordable dans "En savoir plus sur le shell", les autres redirections, notamment ">" qui est quand même super utile ( ainsi que ">>" mais personnellement je m'en sers déjà moins personellement ).
Sinon, en joujou utile, mais peut-être que ça va beaucoup trop loin la, c'est xclip, pour permettre de copier/coller le résultat d'une commande ou d'un fichier sans poncer la table.
En tout cas, chapeau bas, c'est bien écrit, clair, et surtout portable ( donc, plus simple à utiliser, ça évite de dire "alors, ce passage la, pas pour nous parce qu'on est pas sous ) !
Je pense le garder sous le coude pour le jour ou je dois expliquer à un dev windowsien comment on fait pour utiliser une machine qui n'a pas de serveur X :)
PS: pour le fait qu'un non "débutant complet" n'apprenne rien, c'est raté: je ne me considère pas comme "débutant complet", et pourtant je ne connaissais pas nohup. Ni pkill. Enfin, ce n'est pas non plus vital, juste confortable :)
PS2: dans la commande: "$ pkill firefox" pkill n'est pas coloré comme tu le fais avec les commandes habituellement. Idem pour cal, plus haut.
PS3: le temps de lire, et tu as mis à jour, donc certaines remarquent peuvent être obsolètes :)
Vu que c'est ( citation ) "pénible, il faut bien le dire, d'installer/gérer chaque fois qu'on installe un compte" de faire tout ça, as-tu déjà essayé de créer un paquet qui automatise le tout?
Je me demande si ça serait compliqué, mais ce qui est certain, c'est qu'un tel paquet ( voire un méta paquet qui dépendrait des plug-ins? ) serait très utile. En plus, un paquet, c'est comme le bon vin, ça se bonifie avec le temps, et tu aurais la possibilité d'avoir des retour de bien plus que les utilisateurs de linuxfr ;)
C'était le bon temps. Depuis, il est impossible d'utiliser le web sans cookies ni javascript.
Mouai.
Ou pas*.
Déjà, on peut n'accepter que les cookies du site sur lequel on est, avec un navigateur correct.
Ensuite, on peut les supprimer automatiquement à la fermeture dudit navigateur ( sur certains "sites" genre hotmail, plus rien ne marche par contre… ) .
Ça, c'est les bases.
Après, les interdire complètement, ça passe aussi pour la plupart des sites web, tant qu'on ne désire pas être loggué. Si on interdit les cookies, ça peut encore marcher, mais moins bien. Généralement, ça marche tant qu'on ne joue pas trop avec les onglets. Au moins la dernière fois que j'ai testé sur développez.com, c'était le cas.
Et pour javascript… navré de le dire, mais j'ai constaté, pour pratiquer la navigation sans JS quotidiennement ( avec acceptation pour le confort de certains sites en lesquels j'ai confiance, genre linuxfr ) que la plupart des sites n'offrant aucun contenu lié à flash fonctionnent.
L'interface est, bien entendu, vachement moins chiadée… mais ça reste utilisable.
Conclusion: il faut savoir ce qu'on veut. C'est un peu comme ne pas installer les paquets recommandés sous Debian: le système est plus léger, plus réactif, plus sûr ( moins il y a de code, moins il y a de bugs potentiels… ou pas ) mais possède moins de fonctionnalités.
Comme je l'ai dit à une personne ce midi qui disait que certains se font avoir en croyant n'importe quel document sur le web, on appelle internet "l'autoroute de l'information". Bah les autoroutes, c'est dangereux, donc y être imprudent amène souvent des problèmes. Bien sûr, avant, il y avait moins de monde sur les routes, et c'était moins dangereux donc. En plus, les voitures allaient moins vite…
Ah, on me signale que je suis hors sujet, alors je reformule: à l'époque du 56K, il y avais moins de monde sur le net, et on téléchargeait moins vite, alors les sites qui vous sniffaient étaient plus longs à rendre service, ce qui faisait qu'il était plus "naturellement simple" d'éviter l'accident.
*: quelques exemples de sites qui marchent très bien sans JS ( mais avec moins de confort ):
Cependant, attacher gdb sur apache2 ne suffit pas, parce que, par défaut sur ma debian(*), il y à 6 processus d'apache lancés, et en plus il faut les droits d'admin pour les contrôler (logique).
Donc, il faut lancer apache2 avec "-X", comme dit sur tant de sites. Sauf que, encore une fois, c'est plus compliqué que ça sur ma machine(*), car juste lancer "#/usr/sbin/apache2 -X" à la main n'exécute pas le contenu du fichier "/etc/apache2/envvars", qui contient un certain nombre de variables d'environnement nécessaire à la configuration d'apache ( qui se trouve elle dans "/etc/apache2/apache.conf" chez moi ).
Chose que j'ai mis… trop longtemps à voir… bref… il y a une ligne dans ce fameux fichier "/etc/apache2/envvar" qui définit la variable "APACHE_ARGUMENTS".
C'est ici qu'il faut ajouter le fameux "-X", ce qui donne donc:
export APACHE_ARGUMENTS=''
Ensuite, lancer apache, mais pas par son exécutable, ni par le mécanisme d'init comme on l'aurait fait pour d'autres services ( ça semble sûrement évident à certains, mais pour moi qui ne suis pas un admin, j'ai voulu utiliser la méthode classique de debian… grand mal m'a pris. ) mais par l'outil dédié d'apache ( je ne savais pas qu'il y en avait un, à ma décharge… je l'ai découvert via l'auto-complétion. ) via "#/usr/sbin/apache2ctl start".
Bien entendu, avec la config standard dans /etc, apache utilise le port 80, ce qui implique de devoir lancer cette commande sous root, ou de modifier la config, selon l'humeur et/ou les contraintes.
Lancer une requête pour le script qui pose problème, taper un petit "ps -A|grep mon_cgi" pour récupérer le pid, et enfin, attacher gdb à ce pid.
Si je fais un CGI, c'est parce que, au hasard, je ne suis/n'était/ne serait pas le seul à exploiter le port 80, peut-être?
Sinon, j'aurai utilisé autre chose qu'apache, crois-moi, il y a pas mal de serveurs web, voire http, bien plus légers et qui prétendent être moins pénibles à configurer ( n'ayant pas trop eu le "bonheur" de configurer ce type d'outils, je suis obligé de me fier aux prétentions qu'ils avaient quand j'ai croisé leurs descriptifs dans aptitude ) que le plus célèbre d'entre eux.
Non, je n'ai pas eu le temps de chercher plus en détails encore, d'autres tâches m'ont occupé :/ ( m'en occupe la )
Pour en revenir à ta question de comment je fais, en gros:
Je commence par créer une réponse http correcte, c'est à dire, je génère une string contenant cet en-tête: "content-type: foo/bar\n\n" ( bien sûr, content-type ne vaut pas foo/bar. Dans mon cas, j'ai utilisé pour le moment "text/plain". )
Puis je fais ma sauce, en créant des objets qui font le boulot, et qui ont une fonction "finale" qui renvoie une chaîne de caractères, que j'ajoute à mon en-tête, avant d'afficher le tout à la fin de mon script.
J'ai imaginé que c'était la façon la plus propre de faire.
Pour l'inexpérience dans l'écriture de CGI, je ne fais pas que la montrer: je l'admets largement.
Combien de temps vas-tu passer pour débugger ? A mettre dans la balance également.
En l'occurrence, ce que je débuggue, c'est le couple apache2 + mon CGI. En simulant du CGI normal, c'est à dire en passant les arguments GET via $QUERY_STRING et les arguments POST ( pardon pour les grossiers raccourcis ) via GET, je n'ai aucun problème, ce qui m'a aussi permis de mettre en place des tests unitaires.
Je ne prétends pas que le bug viens d'apache, juste que j'ai dû rater un détail, et pour le trouver, gdb m'aiderait pas mal.
Quand ce sera le cas, je ferais un TU pour pas qu'il revienne :)
Et juste par curiosité, tu utilises quel langage ?
C++. En utilisant le dernier standard ( C++11 ).
Peut-être pas ce qu'il y a de plus simple, peut-être, mais dès l'instant que je peux manipuler des chaînes de caractères correctement et facilement ( et le dernier standard aide pas mal pour ça ), avoir un langage avec typage statique ( oui j'y tiens ), me permettant d'utiliser à la fois la POO et la RAII, qui soit standardisé par un organisme qui aime la compatibilité ascendante ( C++ dans 10 ans compilera toujours mon programme, c'est important car il risque effectivement d'être utilisé pendant plusieurs années, sans avoir besoin d'être modifié ) et avec lequel je suis à l'aise… je pense que dans les contraintes que j'ai, ce n'est pas le pire.
A ce que j'ai lu a divers endroits, python, par exemple pourrais poser des problèmes ( certains se sont plains ici et là de ne pas pouvoir utiliser du code ancien sans devoir le modifier, notamment. Pas acceptable dans mon cas. ).
D'autres langages, comme php, ne sont pas typés, ou très faiblement, et je veux un truc ou l'outil qui lit mon code me dise que je vais avoir un problème. D'autres encore, genre perl, produisent du code qui, dans mon humble opinion, est peu lisible ( je m'y suis déjà essayé ).
Je ne dis pas que C++ est la panacée, mais qu'il me semble adapté à mon besoin actuel en fonction de mes contraintes actuelles.
Sans parler du fait que je préfère éviter de multiplier les technos employées en prod, et qu'a l'heure actuelle, php et C++ sont les 2 seuls langages utilisés.
C'est pas du web interactif ça ?
J'imagine que ça dépends de la définition d'interactif. Pour moi, interactif, ça veut dire qu'au cours de l'exécution du programme, l'utilisateur peut envoyer de nouvelles requêtes ( au sens général du terme ) à un logiciel qui se souviens du contexte. Ce qui implique un mécanisme d'identification de l'utilisateur ( pour interagir, on doit savoir identifier son interlocuteur ), par exemple les cookie pour le web.
Si on faisait le parallèle avec les applications sur terminal, on peut entendre par interactif une application qui pose des questions ( scanf, pour du C ) de façon bloquante ou non ( non bloquant impliquant soit que l'on mets un timeout sur les entrées, soit que l'on joue dans la cours du multi-thread ).
Genre aptitude, ncmpcpp, apt-get ( pas ncurses, mais il me semble qu'apt-get pose des questions via scanf ) …
Alors que non interactif serait plutôt les applications qui une fois invoquées ne font que traiter la requête ( en général en utilisant uniquement les arguments passés via ligne de commande, vu que lorsqu'elles lisent l'entrée standard, il arrive qu'elles puissent interagir, comme less ) sans pouvoir être interrompues ( vu que les signaux sont plus une façon de résoudre le problème d'une application trop lente… ou trop bugguée. En général. ).
Http est prévu, à ce que j'en sais ( cf prochaine parenthèse ), pour ne pas être interactif, mais les cookies, entres autres ( phpssessid aussi, ou un truc du genre? suis mauvais en dev web…) , sont un workaround qui permets de le rendre interactif.
voir un des liens que je t'ai proposé comme piste de départ
J'ai commencé à lire tes liens, il y a des chances que ça me mette sur des pistes sympa. La config d'apache n'est vraiment pas simple à gérer à mon niveau malheureusement. ( mais bon, c'est ça qui est en prod… )
Un script php, ou perl, ou shell, ou peu importe le langage, reste du CGI, tant qu'il utilise la RFC en question.
L'intérêt du CGI, c'est de ne pas avoir à développer un module complet dès que tu veux étendre ton serveur http, ou carrément écrire un serveur dédié. 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.
Il y a pléthore de langages très bien adaptés à du web interactif ….
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.
Et qui à parlé de web interactif?
Le programme en question est un webservice: tu lui poses une question, il te réponds. Pas d'état stocké sur serveur ( je n'ose pas parler de REST, car je n'ai pas fini de lire assez de choses à ce sujet, et je risquerais de déraper, mais disons que je tente de m'inspirer de ce que j'en comprend. )
Donc, la seule chose dont j'ai besoin, c'est de manipuler des chaînes de caractères aisément, chose que le langage que j'ai utilisé fait très bien. Ah, et interroger une DB. Ca aussi, pas de souci.
Comment peux-tu en être certain, vu que le programme qui l'appelle est multithreadé ?
Je voulais juste dire par la que le CGI en question n'utilise pas explicitement de thread multiples.
[^] # Re: Merci Lennart (and sinma)
Posté par freem . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 1.
Si c'est un problème de visualisation, genre, luminosité trop faible/forte, xrandr pourrait vous aider.
Ca n'est qu'une bidouille logicielle par contre donc pas sûr qu'une économie de batterie soit espérable. Enfin, faut voir la nature exacte du problème après j'imagine.
[^] # Re: Pulse Audio et BlueZ 5
Posté par freem . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 8.
En fait, tu souhaiterais qu'ils mettent la fonction en deprecated avant de la virer quoi?
Tu te rends compte de la somme de travail et maintenance que ça leur demanderais?
Je ne parle pas au niveau du code, bien entendu, mais au niveau moral: il leur faudrait alors accepter que ce qui est nouveau n'est pas optimal!
[^] # Re: Debian
Posté par freem . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
Non, testing n'est pas censé recevoir les dernières nouveautés. Testing, c'est la beta, après tout.
Au fait, quelqu'un sait comment sont incrémentés ces numéros de version?
Je n'arrive pas à les lire…. enfin… à les interpréter.
Avec le système initié par ubuntu, donc, les dates, on arrive à connaître l'âge d'une version.
Avec le système plus éprouvé M.m.b on arrive à estimer la différence de fonctionnalités.
Mais, avec les numéros débiles type firefox, chrome, et systemd, je n'arrive vraiment pas à avoir la moindre idée de la somme des changements entre 2 versions…
Pour les archis restée en 44, c'est pas illogique qu'elles ne soient pas montées plus haut. Ces systèmes sont minoritaires, et la portabilité de systemd est plus que discutable. Le sieur Lennart code pour la dernier version de linux, si je ne m'abuse, et les autres peuvent aller brouter ailleurs.
Conclusion: ceux qui ont des archis différentes, auront des emmerdes avec systemd. Mais bon, rien de neuf ici.
[^] # Re: Ada ?
Posté par freem . En réponse à la dépêche Concours de programmation CodinGame le 22 mars 2014. Évalué à 2.
Rien de visible sans JS? A part un avertissement que sans JS c'est pas optimal… ( en meme temps, y'a rien, sans JS :/ )
Après activation, rien non plus ne s'affiche.
J'utilise opera en JS désactivé par défaut, je l'ai activé pour le site, mais… plus rien du tout.
Pour certains usages, je peux comprendre, mais pour une FAQ? Ce n'est pas censé être juste une page avec:
Et donc, pourquoi nécessiter JS pour si peu? Je sais, je suis chiant de désactiver JS par défaut. Mais c'est pour la sécurité de mon système, qui n'est en plus pas super musclé et donc, sur certains sites ( pas rares ) , JS pourrit l'utilisabilité de la machine.
[^] # Re: Ada ?
Posté par freem . En réponse à la dépêche Concours de programmation CodinGame le 22 mars 2014. Évalué à 1.
J'imagine que tu plaisantes, mais j'ai récemment songé sérieusement à me mettre à l'ADA, qui offre un certain nombre de points commun avec le C++, en mieux ( encore plus casse-pied sur les types, il paraît… J'aime bien l'idée! Et puis, un langage qui produit de vrais binaires, vraiment lisibles par le CPU, ça se fait rare de nos jours, alors en connaître 2 ( 4 si je compte le C et l'asm intel x86 - hum, et encore - … ) me ferait bien plaisir )
Par contre, il semble qu'il y ait un manque critique de lib pour gérer correctement les IHM sous ce langage. Il y a aussi le fait que gnat soit infernal à utiliser. Ce truc est le pire IDE que j'aie tenté d'utiliser sérieusement… GUI bordélique à souhait, on sait même pas ou aller pour compiler un nouveau projet. Bref. Je ne parlerait pas du tuto qui présuppose un nombre élevé de trucs. Ca reste de la doc de gnou, dans le genre bestial on fait difficilement mieux (avis personnel).
Et je n'ai pas trouvé grand chose (rien en fait, mais j'avoue que pour m'initier à un nouveau langage, j'aurait préféré un outil qui en fasse un maximum à ma place, pour commencer gentiment. Donc pas plus cherché que ça) au sujet de compiler en ligne de commande, non plus ( pourtant, ça me suffit amplement, compte tenu du fait que mon système utilisateur est un vrai IDE pour c++ en tant que tel, à condition de savoir taper 3-4 commandes ).
SDL à un portage entamé pour ADA( sur github ), par quelqu'un qui veut prouver qu'on peut faire des jeux en ADA ( ce qui, compte tenu du fait que ce langage soit conçu pour créer des armes militaires, et donc pour être hyper fiable tout en pouvant gérer du bas niveau - comme C++ en fait, sauf pour les armes militaires - , me semble pas stupide! ). Mais je crains que ce portage ne soit pas spécialement utilisable.
Le concurrent de la SDL, la SFML, ne supporte certainement pas l'ADA, et personne ne semble s'y être mis ( logique, SFML est déjà peu utilisée en C++, alors porter pour ADA… ).
Et pour finir, il semble que, comme C++, ADA n'ait pas de lib pour créer des GUI, ou plutôt pas de "lib mainstream" ( mais pour un langage si peu connu… pas surprenant ).
Pour un jeu vidéo… ces détails sont gênants, car le jeu vidéo fait une grande utilisation de l'écran, et pas juste pour afficher 3 caractères qui se battent en duel ( toujours, toujours compter le témoin! Sinon, c'est un assassinat ;) ).
Du coup, coder un jeu en ADA serait… particulièrement intéressant, pour moi. Réinventer la roue n'est pas systématiquement mauvais ( la plupart des libs de toolkit le font, après tout, sauf wx ) si l'on fait un truc propre qui n'est pas lié par les contrainte historiques du langage.
Mais je ne crois pas que tout le monde serait d'accord avec moi. Réinventer la roue, remettre en question les implémentations séculaires ( ou demi-séculaires pour les logiciels ) n'est pas toujours bien vu, surtout s'il existe un truc libre.
Il s'agit de quelque chose que j'aimerais bien faire, en fait. Faire différemment des autres, par esprit de contradiction, mais aussi parce que je serais toujours moins bon que les autres dans leur domaine d'expertise si je me contente de les singer. Et faire différemment permets parfois de trouver de nouvelles façons efficaces de faire les choses. Les inventions et trouvailles majeures liées à des erreurs, ça existe, après tout (on peut rêver).
PS: si t'as des document expliquant comment faire un vrai hello world, en ligne de commande, pas à pas, expliquant la syntaxe et les paradigmes du langage plutôt que des trucs aussi inutiles que la description de l'API des fonctions standard ( pour lesquelles un lien vers un document les expliquant de façon technique me suffit. Je ne suis peut-être pas un maître du dev, mais je suis un dev malgré tout, lire de la doc d'API me fait pas peur. )
A partir d'un truc aussi petit, qui explique comment compiler et la syntaxe, on peut apprendre très vite le reste. Créer un mécanisme de GUI n'est pas si dur après tout: une classe fenetre, une sizer qui en hérite et agrège une liste de fenetre, une spacer qui hérite de fenetre, et une widget qui hérite de fenetre et agrège une image, et la moitié est faite. L'autre moitié, c'est dire que fenetre agrege des gestionnaires d'évènements… rien d'extraordinaire. Et avec la prog générique, on peut faire un truc qui aie le même comportement en mode graphique ou en mode texte en plus.)
PPS: pardon pour le pavé
[^] # Re: X.org
Posté par freem . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
La solution:
Utiliser GNU/FreeBSD :p ( faut vraiment que je fasse le test, d'ailleurs )
[^] # Re: Debian
Posté par freem . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 1.
C'est normal.
Après tout, Debian vise la stabilité, et, même s'ils ont accepté de passer à systemd, ils ne vont pas mettre à jour la stable à chaque version de build, qui apporte manifestement autant de bugfix que de
nouveaux bugsnouvelles fonctionnalités.( vous m'avez pourri mon dredi à pas troller pendant mes 7H… alors je me dévoue un peu )
[^] # Re: Merci Lennart (and sinma)
Posté par freem . En réponse à la dépêche Spéciale Lennart Poettering : nouvelles versions de systemd et PulseAudio. Évalué à 2.
En même temps, systemd, c'est pas censé être une amélioration pour l'utisateur final… ( le vendredi, c'est permis, non? )
Plus "sérieusement", j'ai réussi à me forcer à lire tout… jusqu'a la fin de la 1ère version ( par ordre d'apparition dans le nourjal). Après… TL;DR.
Alors, c'est vrai qu'un bon troll de compèt n'a pas besoin de lire, mais tout le monde ne peux pas être expert.
[^] # Re: En voila une bonne nouvelle
Posté par freem . En réponse au journal [journal bookmark] gog va au linux. Évalué à 1. Dernière modification le 21 mars 2014 à 21:51.
Merci de ton retour (quand je repasserais dans une période de gamer, je tenterais sûrement).
J'avoue ne pas être surpris, au vu des avis relativement unanimes que j'en ais lus sur le ouaib, mais, je me suis toujours demandé ( et flemme de chercher/expérimenter moi-même ) comment ça marche au niveau installation/configuration?
A part l'habituel "./configure && make && make install" je veux dire.
Est-ce complexe? Parce que j'avoue: autant j'aime me prendre la tête pour coder voire configurer mon environnement de bureau… autant, pour un jeu, non, ça ne me tente pas, et je me laisse aller à la faiblesse de rebooter en mode windows XP.
Ce qui est dommage, parce qu'a chaque fois que je le fais, je me sens juste… un peu comme un randonneur qui se récupère des béquilles… ( le gestionnaire de fenêtre de windows, quand on est habitué à i3—donc du tiling—est vraiment douloureux! )
[^] # Re: USB ?
Posté par freem . En réponse au message Des Arduinos sur un bus USB, un serveur de domotique, et une interface de contrôle REST. Évalué à 1.
Pour communiquer avec des appareils sur la distance, je crois que d'habitude on utilise des câbles ethernet. Après, rien ne t'empêche de les utiliser pour autre chose que le protocole tcp/ip. Ni de faire un adaptateur usb/rj45 pour ne pas avoir à modifier le câble ou l'arduino.
[^] # Re: Étymologie
Posté par freem . En réponse à la dépêche Première version de NOALYSS. Évalué à 2.
J'imagine déjà un logiciel de compta codé en brainfuck…
brainfuckcompta \o/
[^] # Re: Coquille dans le titre
Posté par freem . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 1.
Boarf, c'est pas pire que la version papier-crayon… en tout cas, c'est le résultat du sondage avec mes potes crâniens: on est 15 à approuver, contre seulement 3 à ne pas être d'accord, plutôt pas mal comme score.
[^] # Re: Coquille dans le titre
Posté par freem . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 2.
C'est effectivement possible de se faire passer pour 2 personnes différentes en modifiant son style d'écriture, mais l'exercice n'est pas simple, en tout cas pas pour moi. Il est tellement simple de faire une erreur qui révèle que les 2 personnes sont les mêmes: du genre dire quelque chose que seul l'autre ( des deux ) est censé savoir ( je me suis amusé à ce petit jeu sur un mmo rpg, en me faisant passer pour un débutant complet avec un de mes personnages créé pour l'occasion, alors que je connais plutôt bien le jeu en question ).
Après, si on se crée une sorte de dictionnaire d'expressions et de tics de langage non commun pour toutes ses identités, on peut berner facilement un lecteur pas trop attentif.
[^] # Re: En voila une bonne nouvelle
Posté par freem . En réponse au journal [journal bookmark] gog va au linux. Évalué à 2.
A priori non mais au moins sous mac OS X.
Sinon, il existe un moteur libre censé être capable de gérer les jeux infinity engine. J'avoue ne pas m'y être essayé cependant, question de flemme.
[^] # Re: Diverses remarques
Posté par freem . En réponse au message Tutoriel sur la ligne de commande. Évalué à 2.
Je pense que oui, mais j'ai beau utiliser une debian, je suis du genre à ne rien installé de base et ajouter juste les 10-20 outils que j'utilise réellement à la main donc…
Le paquet qui contiens cet outil, c'est xdg-utils, donc je pense qu'il est utilisé par les gros DEs.
# Diverses remarques
Posté par freem . En réponse au message Tutoriel sur la ligne de commande. Évalué à 1. Dernière modification le 18 mars 2014 à 10:48.
Parler de xdg-open pourrait être utile: on parle de débutants, qui ne savent pas nécessairement reconnaître le programme associé à fichier en voyant son extension. Sans compter que certains programmes ne sont pas très sympa à utiliser en ligne de commande.
Quand tu parles d'arrêter/redémarrer la machine, tu peux aussi parler des hibernations ( tâches courantes ) via pm-[hibernate/suspend/whatever].
Et dernier point abordable dans "En savoir plus sur le shell", les autres redirections, notamment ">" qui est quand même super utile ( ainsi que ">>" mais personnellement je m'en sers déjà moins personellement ).
Sinon, en joujou utile, mais peut-être que ça va beaucoup trop loin la, c'est xclip, pour permettre de copier/coller le résultat d'une commande ou d'un fichier sans poncer la table.
En tout cas, chapeau bas, c'est bien écrit, clair, et surtout portable ( donc, plus simple à utiliser, ça évite de dire "alors, ce passage la, pas pour nous parce qu'on est pas sous ) !
Je pense le garder sous le coude pour le jour ou je dois expliquer à un dev windowsien comment on fait pour utiliser une machine qui n'a pas de serveur X :)
PS: pour le fait qu'un non "débutant complet" n'apprenne rien, c'est raté: je ne me considère pas comme "débutant complet", et pourtant je ne connaissais pas nohup. Ni pkill. Enfin, ce n'est pas non plus vital, juste confortable :)
PS2: dans la commande: "$ pkill firefox" pkill n'est pas coloré comme tu le fais avec les commandes habituellement. Idem pour cal, plus haut.
PS3: le temps de lire, et tu as mis à jour, donc certaines remarquent peuvent être obsolètes :)
[^] # Re: Obfuscation ?
Posté par freem . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 3.
Vu que c'est ( citation ) "pénible, il faut bien le dire, d'installer/gérer chaque fois qu'on installe un compte" de faire tout ça, as-tu déjà essayé de créer un paquet qui automatise le tout?
Je me demande si ça serait compliqué, mais ce qui est certain, c'est qu'un tel paquet ( voire un méta paquet qui dépendrait des plug-ins? ) serait très utile. En plus, un paquet, c'est comme le bon vin, ça se bonifie avec le temps, et tu aurais la possibilité d'avoir des retour de bien plus que les utilisateurs de linuxfr ;)
[^] # Re: avant c'était mieux... oupa
Posté par freem . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 2.
Tu préfèrerais fais ton footing matinal sur route, ou sur autoroute? :p
# avant c'était mieux... oupa
Posté par freem . En réponse au journal Comment réduire les attaques à notre vie privée sur le web. Évalué à 5.
Mouai.
Ou pas*.
Déjà, on peut n'accepter que les cookies du site sur lequel on est, avec un navigateur correct.
Ensuite, on peut les supprimer automatiquement à la fermeture dudit navigateur ( sur certains "sites" genre hotmail, plus rien ne marche par contre… ) .
Ça, c'est les bases.
Après, les interdire complètement, ça passe aussi pour la plupart des sites web, tant qu'on ne désire pas être loggué. Si on interdit les cookies, ça peut encore marcher, mais moins bien. Généralement, ça marche tant qu'on ne joue pas trop avec les onglets. Au moins la dernière fois que j'ai testé sur développez.com, c'était le cas.
Et pour javascript… navré de le dire, mais j'ai constaté, pour pratiquer la navigation sans JS quotidiennement ( avec acceptation pour le confort de certains sites en lesquels j'ai confiance, genre linuxfr ) que la plupart des sites n'offrant aucun contenu lié à flash fonctionnent.
L'interface est, bien entendu, vachement moins chiadée… mais ça reste utilisable.
Enfin, si tu veux vraiment ne pas te faire repérer, sache qu'il existe des distributions linux centrées sur la discrétion et la vie privée
Conclusion: il faut savoir ce qu'on veut. C'est un peu comme ne pas installer les paquets recommandés sous Debian: le système est plus léger, plus réactif, plus sûr ( moins il y a de code, moins il y a de bugs potentiels… ou pas ) mais possède moins de fonctionnalités.
Comme je l'ai dit à une personne ce midi qui disait que certains se font avoir en croyant n'importe quel document sur le web, on appelle internet "l'autoroute de l'information". Bah les autoroutes, c'est dangereux, donc y être imprudent amène souvent des problèmes. Bien sûr, avant, il y avait moins de monde sur les routes, et c'était moins dangereux donc. En plus, les voitures allaient moins vite…
Ah, on me signale que je suis hors sujet, alors je reformule: à l'époque du 56K, il y avais moins de monde sur le net, et on téléchargeait moins vite, alors les sites qui vous sniffaient étaient plus longs à rendre service, ce qui faisait qu'il était plus "naturellement simple" d'éviter l'accident.
*: quelques exemples de sites qui marchent très bien sans JS ( mais avec moins de confort ):
[^] # Re: process séparé ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 3.
Bien vu aussi, c'est ce que j'ai fait du coup.
Cependant, attacher gdb sur apache2 ne suffit pas, parce que, par défaut sur ma debian(*), il y à 6 processus d'apache lancés, et en plus il faut les droits d'admin pour les contrôler (logique).
Donc, il faut lancer apache2 avec "-X", comme dit sur tant de sites. Sauf que, encore une fois, c'est plus compliqué que ça sur ma machine(*), car juste lancer "#/usr/sbin/apache2 -X" à la main n'exécute pas le contenu du fichier "/etc/apache2/envvars", qui contient un certain nombre de variables d'environnement nécessaire à la configuration d'apache ( qui se trouve elle dans "/etc/apache2/apache.conf" chez moi ).
Chose que j'ai mis… trop longtemps à voir… bref… il y a une ligne dans ce fameux fichier "/etc/apache2/envvar" qui définit la variable "APACHE_ARGUMENTS".
C'est ici qu'il faut ajouter le fameux "-X", ce qui donne donc:
export APACHE_ARGUMENTS=''
Ensuite, lancer apache, mais pas par son exécutable, ni par le mécanisme d'init comme on l'aurait fait pour d'autres services ( ça semble sûrement évident à certains, mais pour moi qui ne suis pas un admin, j'ai voulu utiliser la méthode classique de debian… grand mal m'a pris. ) mais par l'outil dédié d'apache ( je ne savais pas qu'il y en avait un, à ma décharge… je l'ai découvert via l'auto-complétion. ) via "#/usr/sbin/apache2ctl start".
Bien entendu, avec la config standard dans /etc, apache utilise le port 80, ce qui implique de devoir lancer cette commande sous root, ou de modifier la config, selon l'humeur et/ou les contraintes.
Lancer une requête pour le script qui pose problème, taper un petit "ps -A|grep mon_cgi" pour récupérer le pid, et enfin, attacher gdb à ce pid.
Welcome to your script.
*:
Debian testing
apache 2.4.7
sysVinit
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
Si je fais un CGI, c'est parce que, au hasard, je ne suis/n'était/ne serait pas le seul à exploiter le port 80, peut-être?
Sinon, j'aurai utilisé autre chose qu'apache, crois-moi, il y a pas mal de serveurs web, voire http, bien plus légers et qui prétendent être moins pénibles à configurer ( n'ayant pas trop eu le "bonheur" de configurer ce type d'outils, je suis obligé de me fier aux prétentions qu'ils avaient quand j'ai croisé leurs descriptifs dans aptitude ) que le plus célèbre d'entre eux.
[^] # Re: c'est probablement stupide
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
Non, je n'ai pas eu le temps de chercher plus en détails encore, d'autres tâches m'ont occupé :/ ( m'en occupe la )
Pour en revenir à ta question de comment je fais, en gros:
Je commence par créer une réponse http correcte, c'est à dire, je génère une string contenant cet en-tête: "content-type: foo/bar\n\n" ( bien sûr, content-type ne vaut pas foo/bar. Dans mon cas, j'ai utilisé pour le moment "text/plain". )
Puis je fais ma sauce, en créant des objets qui font le boulot, et qui ont une fonction "finale" qui renvoie une chaîne de caractères, que j'ajoute à mon en-tête, avant d'afficher le tout à la fin de mon script.
J'ai imaginé que c'était la façon la plus propre de faire.
Pour l'inexpérience dans l'écriture de CGI, je ne fais pas que la montrer: je l'admets largement.
[^] # Re: process séparé ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
J'aime bien l'idée du sleep… pas parfait, mais peut marcher.
Pour l'autre solution… je préfèrerais éviter, disons que ce n'est pas super souple.
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 1.
En l'occurrence, ce que je débuggue, c'est le couple apache2 + mon CGI. En simulant du CGI normal, c'est à dire en passant les arguments GET via $QUERY_STRING et les arguments POST ( pardon pour les grossiers raccourcis ) via GET, je n'ai aucun problème, ce qui m'a aussi permis de mettre en place des tests unitaires.
Je ne prétends pas que le bug viens d'apache, juste que j'ai dû rater un détail, et pour le trouver, gdb m'aiderait pas mal.
Quand ce sera le cas, je ferais un TU pour pas qu'il revienne :)
C++. En utilisant le dernier standard ( C++11 ).
Peut-être pas ce qu'il y a de plus simple, peut-être, mais dès l'instant que je peux manipuler des chaînes de caractères correctement et facilement ( et le dernier standard aide pas mal pour ça ), avoir un langage avec typage statique ( oui j'y tiens ), me permettant d'utiliser à la fois la POO et la RAII, qui soit standardisé par un organisme qui aime la compatibilité ascendante ( C++ dans 10 ans compilera toujours mon programme, c'est important car il risque effectivement d'être utilisé pendant plusieurs années, sans avoir besoin d'être modifié ) et avec lequel je suis à l'aise… je pense que dans les contraintes que j'ai, ce n'est pas le pire.
A ce que j'ai lu a divers endroits, python, par exemple pourrais poser des problèmes ( certains se sont plains ici et là de ne pas pouvoir utiliser du code ancien sans devoir le modifier, notamment. Pas acceptable dans mon cas. ).
D'autres langages, comme php, ne sont pas typés, ou très faiblement, et je veux un truc ou l'outil qui lit mon code me dise que je vais avoir un problème. D'autres encore, genre perl, produisent du code qui, dans mon humble opinion, est peu lisible ( je m'y suis déjà essayé ).
Je ne dis pas que C++ est la panacée, mais qu'il me semble adapté à mon besoin actuel en fonction de mes contraintes actuelles.
Sans parler du fait que je préfère éviter de multiplier les technos employées en prod, et qu'a l'heure actuelle, php et C++ sont les 2 seuls langages utilisés.
J'imagine que ça dépends de la définition d'interactif. Pour moi, interactif, ça veut dire qu'au cours de l'exécution du programme, l'utilisateur peut envoyer de nouvelles requêtes ( au sens général du terme ) à un logiciel qui se souviens du contexte. Ce qui implique un mécanisme d'identification de l'utilisateur ( pour interagir, on doit savoir identifier son interlocuteur ), par exemple les cookie pour le web.
Si on faisait le parallèle avec les applications sur terminal, on peut entendre par interactif une application qui pose des questions ( scanf, pour du C ) de façon bloquante ou non ( non bloquant impliquant soit que l'on mets un timeout sur les entrées, soit que l'on joue dans la cours du multi-thread ).
Genre aptitude, ncmpcpp, apt-get ( pas ncurses, mais il me semble qu'apt-get pose des questions via scanf ) …
Alors que non interactif serait plutôt les applications qui une fois invoquées ne font que traiter la requête ( en général en utilisant uniquement les arguments passés via ligne de commande, vu que lorsqu'elles lisent l'entrée standard, il arrive qu'elles puissent interagir, comme less ) sans pouvoir être interrompues ( vu que les signaux sont plus une façon de résoudre le problème d'une application trop lente… ou trop bugguée. En général. ).
Http est prévu, à ce que j'en sais ( cf prochaine parenthèse ), pour ne pas être interactif, mais les cookies, entres autres ( phpssessid aussi, ou un truc du genre? suis mauvais en dev web…) , sont un workaround qui permets de le rendre interactif.
J'ai commencé à lire tes liens, il y a des chances que ça me mette sur des pistes sympa. La config d'apache n'est vraiment pas simple à gérer à mon niveau malheureusement. ( mais bon, c'est ça qui est en prod… )
[^] # Re: Juste une question : quel est l'intérêt d'un CGI aujourd'hui ?
Posté par freem . En réponse au message débugguer un CGI avec GDB ( sous apache2 ). Évalué à 3.
Un script php, ou perl, ou shell, ou peu importe le langage, reste du CGI, tant qu'il utilise la RFC en question.
L'intérêt du CGI, c'est de ne pas avoir à développer un module complet dès que tu veux étendre ton serveur http, ou carrément écrire un serveur dédié. 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.
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.
Et qui à parlé de web interactif?
Le programme en question est un webservice: tu lui poses une question, il te réponds. Pas d'état stocké sur serveur ( je n'ose pas parler de REST, car je n'ai pas fini de lire assez de choses à ce sujet, et je risquerais de déraper, mais disons que je tente de m'inspirer de ce que j'en comprend. )
Donc, la seule chose dont j'ai besoin, c'est de manipuler des chaînes de caractères aisément, chose que le langage que j'ai utilisé fait très bien. Ah, et interroger une DB. Ca aussi, pas de souci.
Je voulais juste dire par la que le CGI en question n'utilise pas explicitement de thread multiples.