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.
La seule chose que je dit, ce n'est pas qu'il est mal ou stupide ou quoique ce soit d'utiliser un outil externe. Juste, qu'on ne peux pas prétendre faire le boulot soi-même quand c'est un outil qui fait tout à notre place.
Dans le cas du compilo, il ne produit pas du C++, mais du code machine. Son utilisateur fait du C++, le compilo génère un binaire, en code machine. Pas en C++, ou en tout cas pas sur ma machine vu que le processeur ne saurait pas quoi en faire.
En fait, j'ai fini par faire des scripts shell pour placer à peu près. Ca bug à cause du temps, mais ça marchotte. Pour le coup, j'ai posé la question sur la ml d'i3 au sujet de comment résoudre ces bugs, et on m'a répondu que la prochaine version inclue un mécanisme de layout, qui résout donc ce manque de fonctionnalité.
A condition d'utiliser le dépôt git, bien entendu.
Mes parents ont croisé une personne sur l'autoroute qui ne pouvais pas redémarrer après avoir changé une roue, ou un truc du genre. Je ne me souviens pas exactement ce qu'ils m'ont dit, mais en gros, le fait est que l'ordinateur de bord nécessitait un coup de valise pour accepter le fait que la panne ait été réparée.
Bref, je ne suis pas sûr que ce soit borderline niveau code de la route: après tout, si la voiture refuse de démarrer si les phares ne marchent pas, et qu'il faut une valise pour faire comprendre à l'ordi de bord qu'ils ont été changés, il n'y a pas infraction au code.
Et c'est aussi ce que propose le format texte fournit avec boost::serialization.
Il n'empêche que tu dois fatalement gérer la différence de version quelque part, dans ton code. Aucune lib ne peut le faire d'elle même.
Le point étant que, de toute façon, boost::serialization n'est pas un format, mais une lib générique permettant de (dé)sérialiser. Il peut utiliser divers formats, dont XML, plus ou moins indiféremment ( sauf que dans le cas d'xml ou json, il faut dans la méthode serialize() indiquer le noms des clés, forcément, chose qui n'est pas nécessaire dans le format texte brut offert par défaut ).
En même temps, dès que tu ajoutes ou supprimes des données importantes, peu importe la façon d'écrire/lire tes données, soit tu te cantonnes à l'ancien format qui sera donc limité ( pas de possibilités d'exploitation des nouveaux champs, et valeurs des champs supprimés perdues ), soit tu casses la compatibilité, soit tu implémentes un mécanisme de version, chose que boost::serialization fait, de mémoire, pas trop mal.
Et toi, tu fais comment dans ce type de cas ( question réelle, ce sujet m'intéresse ) ?
C'est sûr. Sauf que le modèle est quand même l'un des vrais points forts d'XML, donc, utiliser le fait que le parser ne soit pas trop compliqué en oblitérant une fonctionnalité phare pour dire que ce n'est pas si dur/long/whatever me paraît… douteux.
Sinon, si on parles du simple parsing ( en espérant ne pas me planter et ne pas en oublier trop ):
Il faut être capable de lier à , mais savoir que si on rencontre alors pas de balise fermante.
%XX génère un octet de valeur hexa XX.
%% génère un %.
&foobar; génère le caractère foobar.
" est un délimiteur. ' aussi. Ils peuvent être imbriqués de mémoire.
En terme de coût CPU, je trouve que c'est assez coûteux. Après, je ne nie pas que tous les langages ont des libs plus ou moins bien foutues pour le faire à notre place, mais ça ne veut pas dire que leur implémentation est triviale, surtout quand il y a un besoin de performances.
Un collègue à tenté d'utiliser je ne sais plus quel parseur php, le résultat était misérable en terme de perf, il à donc dû en implémenter un lui-même. Je gage que j'arriverais à faire bugguer le code en question sans trop de souci, en jouant sur les assertions non vérifiées.
Si cet outil php est lent, il doit bien y avoir une raison… ou juste peut-être que mon collègue s'en est mal servi, je n'en sais rien ( je n'étais pas dans la boîte à ce moment, donc je ne connaît pas tous les tenants et aboutissants ).
Il y a juste un point qui ne semble pas apparaître ( l'article est très instructif, mais long, donc j'ai dû accélérer "un peu" ma lecture… ) c'est la génération de lacs et de cours d'eau.
Je suppose qu'il est possible de définir manuellement ou aléatoirement des points de source pour les cours d'eau, et de faire ruisseler le dit cours d'eau en fonction de la pente ( il "suffirait" de regarder toutes les altitudes proches et de générer une érosion plus importante pour le point qui à l'altitude la moins élevée, et ce jusqu'à l'arrivée à un autre point d'eau: océan—niveau 0 --, autre cours d'eau, ou lac ) mais ce qui serait intéressant, ce serait d'être capable de générer des lacs quand le relief forme une cuve.
Peut-être en simulant une pluie:
Pour chaque point d'une zone, vérifier s'il est en contact avec un point plus bas non inondé, et si ce n'est pas le cas, inonder. En répétant l'opération N fois, on pourrait ainsi simuler une pluie de force N, j'imagine?
Du coup, on pourrait imaginer avoir une pluie de force suffisamment élevée pour dépasser le relief sur un point, qui formerait donc une source et génèrerait donc une rivière.
En fait, je n'ai aucune idée de la complexité de ce type de génération et de son implémentation potentielle, et je me demandais si tu as songé à ce détail lors de tes recherches et implémentations?
JSon est moins pire que XML, pour l'usage que la majorité des cas ou XML est utilisé ( c'est à dire sans validation du document ). A choisir entre la peste et le choléra…
Sinon, je préfère le whitespace au javascript, ça à l'avantage d'être reposant pour les yeux :)
[^] # 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.
[^] # Re: XML
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à 1.
La seule chose que je dit, ce n'est pas qu'il est mal ou stupide ou quoique ce soit d'utiliser un outil externe. Juste, qu'on ne peux pas prétendre faire le boulot soi-même quand c'est un outil qui fait tout à notre place.
Dans le cas du compilo, il ne produit pas du C++, mais du code machine. Son utilisateur fait du C++, le compilo génère un binaire, en code machine. Pas en C++, ou en tout cas pas sur ma machine vu que le processeur ne saurait pas quoi en faire.
[^] # Re: La réponse de Bram Moolenaar
Posté par freem . En réponse au journal Neovim : vim's rebirth for the 21st century. Évalué à 1.
En fait, j'ai fini par faire des scripts shell pour placer à peu près. Ca bug à cause du temps, mais ça marchotte. Pour le coup, j'ai posé la question sur la ml d'i3 au sujet de comment résoudre ces bugs, et on m'a répondu que la prochaine version inclue un mécanisme de layout, qui résout donc ce manque de fonctionnalité.
A condition d'utiliser le dépôt git, bien entendu.
A voir, donc.
[^] # Re: demain les voitures pourront peut être être "piratées" ?
Posté par freem . En réponse à la dépêche Encore un exemple de code spaghetti : Toyota. Évalué à 0.
Mes parents ont croisé une personne sur l'autoroute qui ne pouvais pas redémarrer après avoir changé une roue, ou un truc du genre. Je ne me souviens pas exactement ce qu'ils m'ont dit, mais en gros, le fait est que l'ordinateur de bord nécessitait un coup de valise pour accepter le fait que la panne ait été réparée.
Bref, je ne suis pas sûr que ce soit borderline niveau code de la route: après tout, si la voiture refuse de démarrer si les phares ne marchent pas, et qu'il faut une valise pour faire comprendre à l'ordi de bord qu'ils ont été changés, il n'y a pas infraction au code.
[^] # Re: XML
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à -9.
Pour moi, demander à quelqu'un de monter une chaise, ce n'est pas monter une chaire.
De même, pour moi, utiliser un parseur n'est pas parser.
C'est sûr, utiliser une lib, c'est facile. Ou du moins devrait l'être, mais ce n'est pas faire le boulot de la lib. Surtout le vendredi :p
[^] # Re: YAML
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à 1.
Et c'est aussi ce que propose le format texte fournit avec boost::serialization.
Il n'empêche que tu dois fatalement gérer la différence de version quelque part, dans ton code. Aucune lib ne peut le faire d'elle même.
Le point étant que, de toute façon, boost::serialization n'est pas un format, mais une lib générique permettant de (dé)sérialiser. Il peut utiliser divers formats, dont XML, plus ou moins indiféremment ( sauf que dans le cas d'xml ou json, il faut dans la méthode serialize() indiquer le noms des clés, forcément, chose qui n'est pas nécessaire dans le format texte brut offert par défaut ).
[^] # Re: Intérêt toujours aussi limité
Posté par freem . En réponse au journal Sortie de MATE 1.8. Évalué à 1.
C'est peut-être juste le temps que la pilule passe et que gnome 3 s'améliore.
[^] # Re: YAML
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à 2.
En même temps, dès que tu ajoutes ou supprimes des données importantes, peu importe la façon d'écrire/lire tes données, soit tu te cantonnes à l'ancien format qui sera donc limité ( pas de possibilités d'exploitation des nouveaux champs, et valeurs des champs supprimés perdues ), soit tu casses la compatibilité, soit tu implémentes un mécanisme de version, chose que boost::serialization fait, de mémoire, pas trop mal.
Et toi, tu fais comment dans ce type de cas ( question réelle, ce sujet m'intéresse ) ?
[^] # Re: XML
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à 2.
C'est sûr. Sauf que le modèle est quand même l'un des vrais points forts d'XML, donc, utiliser le fait que le parser ne soit pas trop compliqué en oblitérant une fonctionnalité phare pour dire que ce n'est pas si dur/long/whatever me paraît… douteux.
Sinon, si on parles du simple parsing ( en espérant ne pas me planter et ne pas en oublier trop ):
Il faut être capable de lier à , mais savoir que si on rencontre alors pas de balise fermante.
%XX génère un octet de valeur hexa XX.
%% génère un %.
&foobar; génère le caractère foobar.
" est un délimiteur. ' aussi. Ils peuvent être imbriqués de mémoire.
En terme de coût CPU, je trouve que c'est assez coûteux. Après, je ne nie pas que tous les langages ont des libs plus ou moins bien foutues pour le faire à notre place, mais ça ne veut pas dire que leur implémentation est triviale, surtout quand il y a un besoin de performances.
Un collègue à tenté d'utiliser je ne sais plus quel parseur php, le résultat était misérable en terme de perf, il à donc dû en implémenter un lui-même. Je gage que j'arriverais à faire bugguer le code en question sans trop de souci, en jouant sur les assertions non vérifiées.
Si cet outil php est lent, il doit bien y avoir une raison… ou juste peut-être que mon collègue s'en est mal servi, je n'en sais rien ( je n'étais pas dans la boîte à ce moment, donc je ne connaît pas tous les tenants et aboutissants ).
# lacs et cours d'eau
Posté par freem . En réponse à la dépêche Je crée mon jeu vidéo E10 : génération procédurale de carte (partie 1). Évalué à 6.
Excellent article, vraiment.
Il y a juste un point qui ne semble pas apparaître ( l'article est très instructif, mais long, donc j'ai dû accélérer "un peu" ma lecture… ) c'est la génération de lacs et de cours d'eau.
Je suppose qu'il est possible de définir manuellement ou aléatoirement des points de source pour les cours d'eau, et de faire ruisseler le dit cours d'eau en fonction de la pente ( il "suffirait" de regarder toutes les altitudes proches et de générer une érosion plus importante pour le point qui à l'altitude la moins élevée, et ce jusqu'à l'arrivée à un autre point d'eau: océan—niveau 0 --, autre cours d'eau, ou lac ) mais ce qui serait intéressant, ce serait d'être capable de générer des lacs quand le relief forme une cuve.
Peut-être en simulant une pluie:
Pour chaque point d'une zone, vérifier s'il est en contact avec un point plus bas non inondé, et si ce n'est pas le cas, inonder. En répétant l'opération N fois, on pourrait ainsi simuler une pluie de force N, j'imagine?
Du coup, on pourrait imaginer avoir une pluie de force suffisamment élevée pour dépasser le relief sur un point, qui formerait donc une source et génèrerait donc une rivière.
En fait, je n'ai aucune idée de la complexité de ce type de génération et de son implémentation potentielle, et je me demandais si tu as songé à ce détail lors de tes recherches et implémentations?
[^] # Re: Pour moi, XML, c'est comme le PHP...
Posté par freem . En réponse au journal XML c'est de la daube!!!. Évalué à 3.
JSon est moins pire que XML, pour l'usage que la majorité des cas ou XML est utilisé ( c'est à dire sans validation du document ). A choisir entre la peste et le choléra…
Sinon, je préfère le whitespace au javascript, ça à l'avantage d'être reposant pour les yeux :)