Tu vois, un truc marrant, ton code, j'ai _beaucoup_ de mal à le comprendre. Bein oui, il est tout simple, et tout petit, mais c'est un style avec lequel je ne suis pas du tout familier.
Le "for" j'ai du mal à comprendre comment il fonctionne, il ne décrit pas une étape simple (il combine un assignement, un test et un saut, et introduit un bloc). J'ai du mal à voir que "list" c'est un test+un saut et à quel moment c'est réalisé. Je ne sais pas si quand "list" est null il va refaire un tour de boucle ou pas.
Pareil, sans les accollades je dois réfléchir un moment avant de comprendre si "goto found" fait partie de la boucle ou pas, idem pour le "return default_item;".
J'aurais naturellement écrit le truc comme ça :
if ((list = my_list) != NULL) {
do {
if (match(list->item, template_item) != 0) {
return list->item;
}
} while ((list = list->next) != NULL);
}
return default_item;
Le résultat est identique. Mais là, je vois immédiatement ce que ça fait, comment ça va etre converti en langage machine, et comment le CPU va l'interpréter. Par contre tu vas probablement trouver ça bizarre, pas intuitif et trop long.
Comme quoi le style reflete vraiment une personnalité.
Mouais, les "goto" ca peut etre très instructif aussi.
Il y a par exemple :
- Le gars qui ne veut pas y toucher parce qu'il a entendu dire que ce n'était "pas propre" et il n'a pas cherché plus loin. Pour sortir de deux boucles, il préfère gacher des variables et ajouter des tests.
- Le gars qui l'utilise en toute logique, quand ça convient beaucoup mieux que le reste et que ça évite des acrobaties.
- Le gars qui code (!= programme) et qui sait qu'une fois compilé, un programme est constitué à 70% de "goto" (jmp, bra, beq, jnz, jump, etc) .
- Le gars qui voit ton code source et qui se dit "pourquoi il a pas écrit "return list->item" au lieu de "goto" ?
- Le gars qui explique et démontre au précédent que le code généré par gcc est *exactement* le meme.
- Le gars qui trouve quand dans ton code source, le fait de ne pas mettre d'accollades après le "for" et le "if" rend ton code beaucoup plus difficile à suivre que le "goto" (au moins on sait où il va, alors que le reste, sans indentation, c'est loin d'etre évident) .
- Le demomaker qui abuse des possibilités étendues de "goto" dans GCC (saut vers des pointeurs, comme en assembleur) et qui trouve ca infiniment plus simple que les machins conventionnels.
- Le gars qui s'efforce d'écrire des boucles partout sans se rendre compte que ce n'est rien d'autre qu'un goto.
- Le gars qui dit que c'est impossible de maintenir du code de plus de 10 lignes avec des "goto".
- Le gars qui lui répond qu'il y a pourtant 17785 goto dans le code source de Linux 2.4.20-gentoo-r1.
- Le gars qui répond au précédent que Linux de toutes facons, ca suxx et que BSD ca roulaize.
- Un autre gars qui répond au précédent qui à répondu au précédent qu'il y en a 40044 dans OpenBSD.
- Un troisième gars qui ajoute qu'il ne faut pas confondre goto (qui peut etre extremement "propre") et setjmp/jmplong.
A mon humble avis, le point le plus important n'est pas le résultat final, mais tout ce qui s'est passé depuis l'écriture de la première ligne.
Il y a par exemple :
- Le type qui a passé 2 ans à faire un cahier des charges, a modélisé des machins en merise, fait des dessins dans tous les sens, et possède sur papier le détail de chaque classe et de chaque fonction à implémenter. Le premier truc concret qu'il va probablement faire est d'écrire tous les prototypes. Le remplissage avec du code viendra bien après, et la structure (théoriquement) ne changera jamais sans repasser par la case départ.
- Le type qui écrit un truc infect qui fonctionne 10 minutes après, mais avec toutes les valeurs en dur, aucune gestion d'erreur, aucune précaution liée à la sécurité, aucun effort de portabilité, etc. Ces détails seront éventuellement ajoutés bien plus tard, lorsque l'application fonctionnera.
- Le type qui va au contraire toujours prévoir tous les cas de figure possible. Par exemple pour effectuer une simple requete SQL, il va prendre soin de quoter absolument tout, y compris les nombres (on sait jamais, des fois que plus tard, on change le nombre par autre chose), il va systématiquement utiliser des transactions, réessayer plusieurs fois en cas d'erreur, ajouter un cache et des délais exponentiels pour éviter un effet zeno, considérer que n'importe quelle fonction de la libc peut etre bogguée ou ne pas fonctionner exactement comme documentée, etc. Résultat : il va falloir beaucoup plus de temps que le type précédent pour avoir un code "ou y a quelque chose à voir". Mais une fois le truc en prod, il n'aura jamais à s'excuser ("ah euh, ouais, c'est normal, c'est parce qu'il n'y avait plus de place sur le disque") .
- Le type qui suit à la ligne un modèle qu'on lui a enseigné ou qu'il a lu dans un bouquin.
- Le type qui fait un patchwork avec des bouts de code repiqués de-ci, de-là, en y ajoutant des rustines pour qu'ils cohabitent.
Autre solution : arreter d'utiliser Cyrus qui cumule les failles de sécurité et s'arrete de fonctionner sans préavis quand on dépasse un certain nombre d'utilisateurs (ex: plus de 32k comptes dans un sous-répertoire en ext2/3 ou ufs) .
En definitive, quel est la meilleur bibliotheque pour encoder, Xvid 1.0 ou ffmpeg?
Il me semble avoir lu plusieurs fois que ffmpeg (libavcodec) produisait des resultats de meilleur qualite de Xvid, est-ce toujours d'actualite?
Certes, les BSD ayant beaucoup moins de gadgets que GNU/Linux, un outil de configuration n'est pas indispensable mais bon... franchement, ca manque quand meme sous BSD.
En editant le fichier de conf d'un noyau BSD, on a vite fait d'effacer des lignes par erreur, ou d'oublier des dependances. "config" rale, il faut recommencer, penser faire des recherches dans tous les sens chaque fois que l'on retire un truc, et jongler entre la config en cours d'edition, le GENERIC, le LINT et le man.
Le site de la Bred fonctionne pas mal. Aussi bien sous Opera que Konqueror que Mozilla.
Seul truc gonflant : on se tape une boite d'alerte a l'entree du site "Attention vous devez utiliser un navigateur en version 4 ou superieure" (ah merde, je n'ai que Mozilla 1.2 et Konqueror 3.1) .
Mais bon, meme si la mise en page est parfois un peu bizarre, toutes les operations bancaires fonctionnent correctement.
On peut aussi recuperer l'etat de son compte sous GNUCash.
Detail amusant : leur site deconnait completement sur le Mac de mon papa, sous ... IE! Il a donc appelle l'espece de "support technique" de la Bred et on lui a explique que IE sur Mac etait merdique, et qu'il devait installer Netscape. Et effectivement, sous Netscape, il n'a plus eu de probleme.
Peu de temps apres les failles de PHP, c'est maintenant au tour d'Apache, mod_ssl et OpenSSH d'avoir de gros trous de securite. C'est un coup dur pour le logiciel libre, il y en a beaucoup qui n'attendaient que ca pour ricanner et dire que finalement, l'opensource ne valait pas mieux qu'un bon vieux Windows.
C'est d'autant plus flippant que ces failles sont presentes depuis tres longtemps et viennent seulement d'etre connues.
Bah apres tout, ca va encourager tout le monde a employer systematiquement des outils comme Lids, GrSecurity et Systrace pour limiter la casse.
Il y a des patches et des outils tres utiles. Mais il y a par exemple eu un root exploit sur deux d'entre eux (une variante de checkpassword et un truc de SSL) .
La derniere version de Qmail est effectivement sortie en 98. Pourtant, elle est toujours tres utilisee, car il n'y a toujours pas de gros bogue ou de faille de securite en vue. En dehors de Qmail, y a-t-il beaucoup de softs que vous feriez tourner depuis 4 ans sans le moindre upgrade?
La contrainte des repertoires d'installation est un peu hors normes (/var/qmail, /packages, ...) . Et c'est en grande partie a cause de ca que DJB s'est fait expulser d'OpenBSD. Mais bon, rien ne t'empeche de creer des liens dans /usr/local/bin, ou de monter les repertoires.
ucspi-tcp et daemontools sont des packages tres utiles, et au contraire pas spaghettis du tout dans la mesure ou un programme fait une chose bien precise et rien d'autre. Perso ce sont les premiers trucs que j'installe sur une nouvelle machine.
DJB est a mon avis l'une des rares personnes a pouvoir se permettre de "se la ramener". Quand il critique quelque chose, ce n'est pas gratuit. Il demontre toujours ce qu'il affirme. Que ce soit en securite, en optimisation ou en maths, DJB calme pas mal de monde.
Concernant la license de DjbDNS comme pour celle de QMail, le principe est le suivant :
- Les sources sont disponibles et librements redistribuables sans modification.
- On peut aussi creer des binaires a partir des sources d'origine et les distribuer librement.
- _Mais_ il est interdit de diffuser des binaires crees a partir de sources trafiques sans l'autorisation de l'auteur. Il est aussi interdit de diffuser des sources modifies sans autorisation.
Voila pourquoi certains reprochent a Qmail et DjbDNS de ne pas etre "libres".
Neanmoins, cette license n'est pas idiote.
Imagine que je prenne DjbDNS, que j'ajoute des fonctions et que j'en distribue des RPM. 2 mois plus tard, un gros trou de securite est trouve dans ces RPM. Tout le monde va dire "putain DjbDNS c'est de la merde, y a un root exploit dedans!". Pourtant, ce n'est pas vrai. La version d'origine etait clean.
Si je veux distribuer DjbDNS avec des modifs, la license m'oblige a distribuer :
- Le source original.
- Les patches que j'y ajoute.
Et pas de package binaire. Comme ca, on sait exactement ce qu'on installe. On sait explicitement quelles modifications ont ete apportees.
DJB donne des sous a quiconque arrivera a trouver le moindre trou de securite dans ses softs. Jusqu'a present, personne n'en a trouve. Le fait que chacun ne vienne pas mettre son grain de sel dans le code source sans son approbation y est pour beaucoup.
La license est particuliere. Ce n'est pas "libre" comme la license BSD. Mais ca ne signifie pas que les softs sont inutilisables ou que l'on cache quoi que ce soit. Au contraire.
CBS permet visiblement d'autoriser les ports en fonction des utilisateurs.
La encore, pourquoi reinventer la roue? Sous OpenBSD-current, les regles de firewall peuvent dependre de l'uid/gid. Linux sait aussi faire ca depuis des lustres.
Si IPF ne sait pas le faire, pourquoi ne pas ajouter cette fonctionnalite plutot que d'inventer une espece de bibliotheque en userland necessitant de recompiler tous les serveurs?
Eh oh, on est en 2002, il faut se reveiller, l'epoque ou seul tcp-wrappers existait pour faire du filtrage, c'etait il y a 10 ans!
Je ne vois pas l'interet de ce truc.
Pour faire tourner un service ayant besoin d'un port < 1024 sans etre root, il suffit de binder ce service sur un port utilisateur et d'effectuer une redirection de port.
Par exemple pour Apache, je le fais ecouter 127.0.0.1:8000 uniquement, et une regle du firewall se charge de rediriger 127.0.0.1:8000 sur l'IP externe.
Ca marche sur n'importe quel OS disposant d'un noyau avec un firewall (quasiment tous les OS libres), ca ne necessite pas d'installer quoi que ce soit, c'est stable, et ca ne ralentit pas du tout les traitements.
Tu n'as pas a changer systematiquement quoi que ce soit. Tu as juste a utliser ton compte habituel pour mettre a jour /usr/src et /usr/ports. Il n'y aura jamais de machin appartenant a 'root' qui va venir se loger la dedans.
# Re: Complétion avec GNU Bash
Posté par j . En réponse au message [Terminal] Complétion avec GNU Bash. Évalué à 1.
# Re: Vos meilleures adresses sur la sécurité, contre-attaque
Posté par j . En réponse à la dépêche Vos meilleures adresses sur la sécurité, contre-attaque. Évalué à -1.
# DOM Inspector ?
Posté par j . En réponse à la dépêche Nouveau plan de route pour Mozilla !. Évalué à 10.
Franchement, ce truc est génial pour créer des pages web ou voir ce qui merde dans des pages existantes.
J'espere qu'il sera possible d'utiliser le DOM Inspector sous Phoenix (à moins que l'on puisse déjà le faire ? Comment ?)
# Gentoo
Posté par j . En réponse à la dépêche Sortie de KDE 3.1.1!. Évalué à -2.
[^] # Re: vive les gotos
Posté par j . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 2.
Le "for" j'ai du mal à comprendre comment il fonctionne, il ne décrit pas une étape simple (il combine un assignement, un test et un saut, et introduit un bloc). J'ai du mal à voir que "list" c'est un test+un saut et à quel moment c'est réalisé. Je ne sais pas si quand "list" est null il va refaire un tour de boucle ou pas.
Pareil, sans les accollades je dois réfléchir un moment avant de comprendre si "goto found" fait partie de la boucle ou pas, idem pour le "return default_item;".
J'aurais naturellement écrit le truc comme ça :
Le résultat est identique. Mais là, je vois immédiatement ce que ça fait, comment ça va etre converti en langage machine, et comment le CPU va l'interpréter. Par contre tu vas probablement trouver ça bizarre, pas intuitif et trop long.
Comme quoi le style reflete vraiment une personnalité.
[^] # Re: vive les gotos
Posté par j . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 8.
Il y a par exemple :
- Le gars qui ne veut pas y toucher parce qu'il a entendu dire que ce n'était "pas propre" et il n'a pas cherché plus loin. Pour sortir de deux boucles, il préfère gacher des variables et ajouter des tests.
- Le gars qui l'utilise en toute logique, quand ça convient beaucoup mieux que le reste et que ça évite des acrobaties.
- Le gars qui code (!= programme) et qui sait qu'une fois compilé, un programme est constitué à 70% de "goto" (jmp, bra, beq, jnz, jump, etc) .
- Le gars qui voit ton code source et qui se dit "pourquoi il a pas écrit "return list->item" au lieu de "goto" ?
- Le gars qui explique et démontre au précédent que le code généré par gcc est *exactement* le meme.
- Le gars qui trouve quand dans ton code source, le fait de ne pas mettre d'accollades après le "for" et le "if" rend ton code beaucoup plus difficile à suivre que le "goto" (au moins on sait où il va, alors que le reste, sans indentation, c'est loin d'etre évident) .
- Le demomaker qui abuse des possibilités étendues de "goto" dans GCC (saut vers des pointeurs, comme en assembleur) et qui trouve ca infiniment plus simple que les machins conventionnels.
- Le gars qui s'efforce d'écrire des boucles partout sans se rendre compte que ce n'est rien d'autre qu'un goto.
- Le gars qui dit que c'est impossible de maintenir du code de plus de 10 lignes avec des "goto".
- Le gars qui lui répond qu'il y a pourtant 17785 goto dans le code source de Linux 2.4.20-gentoo-r1.
- Le gars qui répond au précédent que Linux de toutes facons, ca suxx et que BSD ca roulaize.
- Un autre gars qui répond au précédent qui à répondu au précédent qu'il y en a 40044 dans OpenBSD.
- Un troisième gars qui ajoute qu'il ne faut pas confondre goto (qui peut etre extremement "propre") et setjmp/jmplong.
- etc.
# Re: Critères de personnalité d'un code
Posté par j . En réponse à la dépêche Critères de personnalité d'un code. Évalué à 2.
Il y a par exemple :
- Le type qui a passé 2 ans à faire un cahier des charges, a modélisé des machins en merise, fait des dessins dans tous les sens, et possède sur papier le détail de chaque classe et de chaque fonction à implémenter. Le premier truc concret qu'il va probablement faire est d'écrire tous les prototypes. Le remplissage avec du code viendra bien après, et la structure (théoriquement) ne changera jamais sans repasser par la case départ.
- Le type qui écrit un truc infect qui fonctionne 10 minutes après, mais avec toutes les valeurs en dur, aucune gestion d'erreur, aucune précaution liée à la sécurité, aucun effort de portabilité, etc. Ces détails seront éventuellement ajoutés bien plus tard, lorsque l'application fonctionnera.
- Le type qui va au contraire toujours prévoir tous les cas de figure possible. Par exemple pour effectuer une simple requete SQL, il va prendre soin de quoter absolument tout, y compris les nombres (on sait jamais, des fois que plus tard, on change le nombre par autre chose), il va systématiquement utiliser des transactions, réessayer plusieurs fois en cas d'erreur, ajouter un cache et des délais exponentiels pour éviter un effet zeno, considérer que n'importe quelle fonction de la libc peut etre bogguée ou ne pas fonctionner exactement comme documentée, etc. Résultat : il va falloir beaucoup plus de temps que le type précédent pour avoir un code "ou y a quelque chose à voir". Mais une fois le truc en prod, il n'aura jamais à s'excuser ("ah euh, ouais, c'est normal, c'est parce qu'il n'y avait plus de place sur le disque") .
- Le type qui suit à la ligne un modèle qu'on lui a enseigné ou qu'il a lu dans un bouquin.
- Le type qui fait un patchwork avec des bouts de code repiqués de-ci, de-là, en y ajoutant des rustines pour qu'ils cohabitent.
etc.
# Re: Cyrus veut plus rien savoir ?
Posté par j . En réponse au message [Mail] Cyrus veut plus rien savoir ?. Évalué à 1.
DBmail est une alternative bien plus simple et sans limites : http://www.dbmail.org/(...)
Courier-Imap aussi.
# Re: IBM va encore tout exploser avec ses nouveaux supers ordinateurs !!!
Posté par j . En réponse à la dépêche IBM va construire deux nouveaux supers ordinateurs. Évalué à 1.
# Xvid ou ffmpeg?
Posté par j . En réponse à la dépêche La première version officielle d'XviD est sortie.. Évalué à 7.
Il me semble avoir lu plusieurs fois que ffmpeg (libavcodec) produisait des resultats de meilleur qualite de Xvid, est-ce toujours d'actualite?
[^] # Re: make -jx, ou comment ralentir/acceler une compilation
Posté par j . En réponse au message [Terminal] make -jx, ou comment ralentir/acceler une compilation. Évalué à 1.
http://www.42-networks.com/faq/library.html(...)
# Re: Posez vos questions à un rédacteur de
Posté par j . En réponse à la dépêche Posez vos questions à un rédacteur de "Hackerz Voice". Évalué à 1.
# Pourquoi SQL?
Posté par j . En réponse à la dépêche Version 0.9.2 de Templeet. Évalué à 1.
Est-ce-qu'il est prevu d'utiliser des alternatives plus legeres comme BerkeleyDB, DynDB, GDBM, voire SQLite?
# A quand la meme chose pour BSD?
Posté par j . En réponse à la dépêche Nouvel outil de configuration pour le kernel Linux. Évalué à 1.
En editant le fichier de conf d'un noyau BSD, on a vite fait d'effacer des lignes par erreur, ou d'oublier des dependances. "config" rale, il faut recommencer, penser faire des recherches dans tous les sens chaque fois que l'on retire un truc, et jongler entre la config en cours d'edition, le GENERIC, le LINT et le man.
# La Bred
Posté par j . En réponse à la dépêche Banques et navigateurs alternatifs : le temps de l'action. Évalué à 1.
Seul truc gonflant : on se tape une boite d'alerte a l'entree du site "Attention vous devez utiliser un navigateur en version 4 ou superieure" (ah merde, je n'ai que Mozilla 1.2 et Konqueror 3.1) .
Mais bon, meme si la mise en page est parfois un peu bizarre, toutes les operations bancaires fonctionnent correctement.
On peut aussi recuperer l'etat de son compte sous GNUCash.
Detail amusant : leur site deconnait completement sur le Mac de mon papa, sous ... IE! Il a donc appelle l'espece de "support technique" de la Bred et on lui a explique que IE sur Mac etait merdique, et qu'il devait installer Netscape. Et effectivement, sous Netscape, il n'a plus eu de probleme.
[^] # Re: A noter l'existance d'un BSD peut connu : MicroBSD
Posté par j . En réponse à la dépêche Evaluation de OpenBSD 3.2 (snapshot). Évalué à 1.
# Autre descendant de JunkBuster
Posté par j . En réponse à la dépêche Privoxy 3.0 est sorti !. Évalué à 10.
qui sert principalement a passer outre les protections des sites qui se protegent via le HTTP_REFERER .
Base sur Junkbuster, avec des ameliorations de securite, et une version Windows avec un bel installateur.
# Boooohhh
Posté par j . En réponse à la dépêche Vulnérabilité OpenSSH. Évalué à 4.
C'est d'autant plus flippant que ces failles sont presentes depuis tres longtemps et viennent seulement d'etre connues.
Bah apres tout, ca va encourager tout le monde a employer systematiquement des outils comme Lids, GrSecurity et Systrace pour limiter la casse.
[^] # Re: Petite histoire de Bind
Posté par j . En réponse à la dépêche Vulnérabilité de type DoS sur BIND 9. Évalué à 9.
La derniere version de Qmail est effectivement sortie en 98. Pourtant, elle est toujours tres utilisee, car il n'y a toujours pas de gros bogue ou de faille de securite en vue. En dehors de Qmail, y a-t-il beaucoup de softs que vous feriez tourner depuis 4 ans sans le moindre upgrade?
La contrainte des repertoires d'installation est un peu hors normes (/var/qmail, /packages, ...) . Et c'est en grande partie a cause de ca que DJB s'est fait expulser d'OpenBSD. Mais bon, rien ne t'empeche de creer des liens dans /usr/local/bin, ou de monter les repertoires.
ucspi-tcp et daemontools sont des packages tres utiles, et au contraire pas spaghettis du tout dans la mesure ou un programme fait une chose bien precise et rien d'autre. Perso ce sont les premiers trucs que j'installe sur une nouvelle machine.
[^] # Re: Petite histoire de Bind
Posté par j . En réponse à la dépêche Vulnérabilité de type DoS sur BIND 9. Évalué à 10.
Concernant la license de DjbDNS comme pour celle de QMail, le principe est le suivant :
- Les sources sont disponibles et librements redistribuables sans modification.
- On peut aussi creer des binaires a partir des sources d'origine et les distribuer librement.
- _Mais_ il est interdit de diffuser des binaires crees a partir de sources trafiques sans l'autorisation de l'auteur. Il est aussi interdit de diffuser des sources modifies sans autorisation.
Voila pourquoi certains reprochent a Qmail et DjbDNS de ne pas etre "libres".
Neanmoins, cette license n'est pas idiote.
Imagine que je prenne DjbDNS, que j'ajoute des fonctions et que j'en distribue des RPM. 2 mois plus tard, un gros trou de securite est trouve dans ces RPM. Tout le monde va dire "putain DjbDNS c'est de la merde, y a un root exploit dedans!". Pourtant, ce n'est pas vrai. La version d'origine etait clean.
Si je veux distribuer DjbDNS avec des modifs, la license m'oblige a distribuer :
- Le source original.
- Les patches que j'y ajoute.
Et pas de package binaire. Comme ca, on sait exactement ce qu'on installe. On sait explicitement quelles modifications ont ete apportees.
DJB donne des sous a quiconque arrivera a trouver le moindre trou de securite dans ses softs. Jusqu'a present, personne n'en a trouve. Le fait que chacun ne vienne pas mettre son grain de sel dans le code source sans son approbation y est pour beaucoup.
La license est particuliere. Ce n'est pas "libre" comme la license BSD. Mais ca ne signifie pas que les softs sont inutilisables ou que l'on cache quoi que ce soit. Au contraire.
# Petite histoire de Bind
Posté par j . En réponse à la dépêche Vulnérabilité de type DoS sur BIND 9. Évalué à -2.
[^] # Re: Redirection de port
Posté par j . En réponse à la dépêche CBS / Enfin un outil qui nous facilite la vie.. Évalué à 10.
La encore, pourquoi reinventer la roue? Sous OpenBSD-current, les regles de firewall peuvent dependre de l'uid/gid. Linux sait aussi faire ca depuis des lustres.
Si IPF ne sait pas le faire, pourquoi ne pas ajouter cette fonctionnalite plutot que d'inventer une espece de bibliotheque en userland necessitant de recompiler tous les serveurs?
Eh oh, on est en 2002, il faut se reveiller, l'epoque ou seul tcp-wrappers existait pour faire du filtrage, c'etait il y a 10 ans!
# Redirection de port
Posté par j . En réponse à la dépêche CBS / Enfin un outil qui nous facilite la vie.. Évalué à 10.
Pour faire tourner un service ayant besoin d'un port < 1024 sans etre root, il suffit de binder ce service sur un port utilisateur et d'effectuer une redirection de port.
Par exemple pour Apache, je le fais ecouter 127.0.0.1:8000 uniquement, et une regle du firewall se charge de rediriger 127.0.0.1:8000 sur l'IP externe.
Ca marche sur n'importe quel OS disposant d'un noyau avec un firewall (quasiment tous les OS libres), ca ne necessite pas d'installer quoi que ce soit, c'est stable, et ca ne ralentit pas du tout les traitements.
[^] # Re: OpenBSD vulnérable !
Posté par j . En réponse à la dépêche Backdoor dans irssi. Évalué à 10.
Seul 'make install' en a besoin.
[^] # Re: OpenBSD vulnérable !
Posté par j . En réponse à la dépêche Backdoor dans irssi. Évalué à 10.