J'en vois une deuxieme: les outils de gestion de packages font exactement ce que je veux et ce dont j'ai besoin. Si ce n'est pas a 100% le cas, de toutes facons, c'est de ma faute, et je n'ai qu'a finir d'ecrire le code.
C'est aussi le cas d'une Gentoo, par exemple.
Eh bien, clairement non, puisque j'ai ecrit ceux d'OpenBSD et pas ceux de la GenToo.
Heureusement, les packages dans le userland, pas glop, pas glop !
-- Laurent
espie@tetto.home (Marc Espie) writes:
Arnaud Launay <asl@launay.org> wrote:
Marc Espie wrote:
J'en vois une deuxieme: les outils de gestion de packages font
exactement ce que je veux et ce dont j'ai besoin. Si ce n'est
pas a 100% le cas, de toutes facons, c'est de ma faute, et je
n'ai qu'a finir d'ecrire le code.
C'est aussi le cas d'une Gentoo, par exemple.
Eh bien, clairement non, puisque j'ai ecrit ceux d'OpenBSD et pas
ceux de la GenToo.
Heureusement, les packages dans le userland, pas glop, pas glop !
J'en vois une deuxieme: les outils de gestion de packages font exactement ce que je veux et ce dont j'ai besoin. Si ce n'est pas a 100% le cas, de toutes facons, c'est de ma faute, et je n'ai qu'a finir d'ecrire le code.
C'est aussi le cas d'une Gentoo, par exemple.
Eh bien, clairement non, puisque j'ai ecrit ceux d'OpenBSD et pas ceux de la GenToo.
Heureusement, les packages dans le userland, pas glop, pas glop !
-- Laurent
Arnaud Launay
Le 09 Jan 2005 09:39:33 +0100, Laurent Lefevre écrivit:
C'est aussi le cas d'une Gentoo, par exemple. Eh bien, clairement non, puisque j'ai ecrit ceux d'OpenBSD et
pas ceux de la GenToo. Heureusement, les packages dans le userland, pas glop, pas glop !
Marc a donc écrit *tous* les ports qu'il utilise sous openbsd. Ça c'est un homme un vrai qui en a une (*).
Tout ça pour dire que c'est vraiment subjectif comme truc, sauf pour les machins en binaire, principalement ceux qui vont taper dans le matériel. Tiens, par exemple, je ne pense pas voir de sitôt un support pour la carte wifi Intel 2200, intégrée dans mon portable, sous OpenBSD, alors que ça, heu, marchotte sous Linux.
Arnaud.
(*) Une barbe bien sûr. Zavez vraiment l'esprit mal placé.
-- http://launay.org/blog/ http://www.cusae.com/
Le 09 Jan 2005 09:39:33 +0100, Laurent Lefevre écrivit:
C'est aussi le cas d'une Gentoo, par exemple.
Eh bien, clairement non, puisque j'ai ecrit ceux d'OpenBSD et
pas ceux de la GenToo.
Heureusement, les packages dans le userland, pas glop, pas glop !
Marc a donc écrit *tous* les ports qu'il utilise sous openbsd. Ça
c'est un homme un vrai qui en a une (*).
Tout ça pour dire que c'est vraiment subjectif comme truc, sauf
pour les machins en binaire, principalement ceux qui vont taper
dans le matériel. Tiens, par exemple, je ne pense pas voir de
sitôt un support pour la carte wifi Intel 2200, intégrée dans mon
portable, sous OpenBSD, alors que ça, heu, marchotte sous Linux.
Arnaud.
(*) Une barbe bien sûr. Zavez vraiment l'esprit mal placé.
Le 09 Jan 2005 09:39:33 +0100, Laurent Lefevre écrivit:
C'est aussi le cas d'une Gentoo, par exemple. Eh bien, clairement non, puisque j'ai ecrit ceux d'OpenBSD et
pas ceux de la GenToo. Heureusement, les packages dans le userland, pas glop, pas glop !
Marc a donc écrit *tous* les ports qu'il utilise sous openbsd. Ça c'est un homme un vrai qui en a une (*).
Tout ça pour dire que c'est vraiment subjectif comme truc, sauf pour les machins en binaire, principalement ceux qui vont taper dans le matériel. Tiens, par exemple, je ne pense pas voir de sitôt un support pour la carte wifi Intel 2200, intégrée dans mon portable, sous OpenBSD, alors que ça, heu, marchotte sous Linux.
Arnaud.
(*) Une barbe bien sûr. Zavez vraiment l'esprit mal placé.
-- http://launay.org/blog/ http://www.cusae.com/
Arnaud Launay
Le Sun, 9 Jan 2005 10:56:58 +0000 (UTC), Loic Tortay écrivit:
Mh. Je ne comprends pas où tu veux en venir avec le contrôle du filtrage ; la question est presque la même : si tu as plusieurs primaires, tu *dois* avoir la contrôle sur le filtrage. Par contre, si tu as des secondaires, il est possible de déléguer une partie du filtrage au secondaire. Précisément, ce qui se fait sur la transaction SMTP (eventuels DNSBL, tests de reverse, contrôle de helo, greylists, etc) doit être fait des deux côtés pour bien faire ; par contre, les tests de contenu (SpamAssassin, anti-virus, et autres) peuvent être centralisés sur le primaire.
C'est interessant de faire tous les filtrages dans la transation SMTP, car tu peux rejeter les courriers indésirables sans avoir à faire confiance à l'adresse d'expediteur.
Dans mon cas, non ; le filtrage sur le contenu varie selon les utilisateurs et les adresses de destination. J'ai certaines personnes qui acceptent des virus sur certaines de leurs adresses (notamment la mainteneuse de la FAQ de fcs.virus...). Comme SMTP n'a qu'une réponse binaire sur le data, je ne peux pas faire autrement (problème des copies avec une adresse qui accepte et l'autre qui rejette).
Si tu filtre les virus uniquement sur ton primaire, alors pour ceux qui rentrent par le secondaire, tu vas refuser sur le primaire et le secondaire enverra un DSN à l'adresse de l'expediteur. Qui n'a rien à voir avec l'envoi, comme tu sais.
Je sais. Du coup, en ce moment, je loggue les virus (et spams) entrants, et je droppe (sans bounces) les messages correspondants. Ca marche assez bien, quand les logs sont régulièrement consultés (ce qui est le cas).
Bon, par contre, avec la lourdeur de la mécanique, je suis pas sûr que ça /scale/ bien... :}
Fred -- Stress is when you wake up screaming and realise you haven't fallen asleep yet.
F. Senault <fred@lacave.net> wrote:
Mh. Je ne comprends pas où tu veux en venir avec le contrôle du
filtrage ; la question est presque la même : si tu as plusieurs
primaires, tu *dois* avoir la contrôle sur le filtrage. Par contre, si
tu as des secondaires, il est possible de déléguer une partie du
filtrage au secondaire. Précisément, ce qui se fait sur la transaction
SMTP (eventuels DNSBL, tests de reverse, contrôle de helo, greylists,
etc) doit être fait des deux côtés pour bien faire ; par contre, les
tests de contenu (SpamAssassin, anti-virus, et autres) peuvent être
centralisés sur le primaire.
C'est interessant de faire tous les filtrages dans la transation SMTP,
car tu peux rejeter les courriers indésirables sans avoir à faire
confiance à l'adresse d'expediteur.
Dans mon cas, non ; le filtrage sur le contenu varie selon les
utilisateurs et les adresses de destination. J'ai certaines personnes
qui acceptent des virus sur certaines de leurs adresses (notamment la
mainteneuse de la FAQ de fcs.virus...). Comme SMTP n'a qu'une réponse
binaire sur le data, je ne peux pas faire autrement (problème des copies
avec une adresse qui accepte et l'autre qui rejette).
Si tu filtre les virus uniquement sur ton primaire, alors pour ceux qui
rentrent par le secondaire, tu vas refuser sur le primaire et le
secondaire enverra un DSN à l'adresse de l'expediteur. Qui n'a rien à
voir avec l'envoi, comme tu sais.
Je sais. Du coup, en ce moment, je loggue les virus (et spams)
entrants, et je droppe (sans bounces) les messages correspondants. Ca
marche assez bien, quand les logs sont régulièrement consultés (ce qui
est le cas).
Bon, par contre, avec la lourdeur de la mécanique, je suis pas sûr que
ça /scale/ bien... :}
Fred
--
Stress is when you wake up screaming and realise you haven't fallen
asleep yet.
Mh. Je ne comprends pas où tu veux en venir avec le contrôle du filtrage ; la question est presque la même : si tu as plusieurs primaires, tu *dois* avoir la contrôle sur le filtrage. Par contre, si tu as des secondaires, il est possible de déléguer une partie du filtrage au secondaire. Précisément, ce qui se fait sur la transaction SMTP (eventuels DNSBL, tests de reverse, contrôle de helo, greylists, etc) doit être fait des deux côtés pour bien faire ; par contre, les tests de contenu (SpamAssassin, anti-virus, et autres) peuvent être centralisés sur le primaire.
C'est interessant de faire tous les filtrages dans la transation SMTP, car tu peux rejeter les courriers indésirables sans avoir à faire confiance à l'adresse d'expediteur.
Dans mon cas, non ; le filtrage sur le contenu varie selon les utilisateurs et les adresses de destination. J'ai certaines personnes qui acceptent des virus sur certaines de leurs adresses (notamment la mainteneuse de la FAQ de fcs.virus...). Comme SMTP n'a qu'une réponse binaire sur le data, je ne peux pas faire autrement (problème des copies avec une adresse qui accepte et l'autre qui rejette).
Si tu filtre les virus uniquement sur ton primaire, alors pour ceux qui rentrent par le secondaire, tu vas refuser sur le primaire et le secondaire enverra un DSN à l'adresse de l'expediteur. Qui n'a rien à voir avec l'envoi, comme tu sais.
Je sais. Du coup, en ce moment, je loggue les virus (et spams) entrants, et je droppe (sans bounces) les messages correspondants. Ca marche assez bien, quand les logs sont régulièrement consultés (ce qui est le cas).
Bon, par contre, avec la lourdeur de la mécanique, je suis pas sûr que ça /scale/ bien... :}
Fred -- Stress is when you wake up screaming and realise you haven't fallen asleep yet.
espie
In article , Arnaud Launay wrote:
Le Sun, 9 Jan 2005 10:56:58 +0000 (UTC), Loic Tortay écrivit:
These firmware files are not free because Intel refuses to grant distri- bution rights without contractual obligations. As a result, even though OpenBSD includes the driver, the firmware files cannot be included and users have to find these files on their own. The official person to state your views to about this issue is at (858) 391 1857.
Si t'es un homme, un vrai, tu sais ce qu'il te reste a faire... ;-)
In article <slrncu24dt.f5.asl@citron.launay.org>,
Arnaud Launay <asl@launay.org> wrote:
Le Sun, 9 Jan 2005 10:56:58 +0000 (UTC), Loic Tortay écrivit:
These firmware files are not free because Intel refuses to grant distri-
bution rights without contractual obligations. As a result, even though
OpenBSD includes the driver, the firmware files cannot be included and
users have to find these files on their own. The official person to
state your views to about this issue is peter.engelbrecht@intel.com at
(858) 391 1857.
Si t'es un homme, un vrai, tu sais ce qu'il te reste a faire... ;-)
These firmware files are not free because Intel refuses to grant distri- bution rights without contractual obligations. As a result, even though OpenBSD includes the driver, the firmware files cannot be included and users have to find these files on their own. The official person to state your views to about this issue is at (858) 391 1857.
Si t'es un homme, un vrai, tu sais ce qu'il te reste a faire... ;-)
Olivier Cherrier
On 2005-01-08, Marc Espie wrote:
In article <1gq1mnm.1gspi1x15h3m35N%, Emmanuel Dreyfus wrote:
Marc Espie wrote:
(*) depuis que j'ai viré spamassassin de mes MX. Tu as mis quoi a la place ?
Le puissant milter-greylist, pardi! Ca nettoie bien et pour pas cher en CPU.
Mouaip, faudra que je me decide a franchir le pas et me doter d'un vrai MX, surtout que mon ISP veut bien faire MX secondaire...
En attendant, le greylisting, ca marche helas pas trop sur du pop3,
Greylisting marche pas mal mais, c'est loin de tout arrêter et des ISPs avec des configurations plutôt mal torchées comme Belgacom ne parviennent jamais à passer spamd. Leurs temps de retry doivent être de l'ordre de l'année ... ?
On 2005-01-08, Marc Espie <espie@tetto.home> wrote:
In article <1gq1mnm.1gspi1x15h3m35N%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Marc Espie <espie@tetto.home> wrote:
(*) depuis que j'ai viré spamassassin de mes MX.
Tu as mis quoi a la place ?
Le puissant milter-greylist, pardi!
Ca nettoie bien et pour pas cher en CPU.
Mouaip, faudra que je me decide a franchir le pas et me doter
d'un vrai MX, surtout que mon ISP veut bien faire MX secondaire...
En attendant, le greylisting, ca marche helas pas trop sur du pop3,
Greylisting marche pas mal mais, c'est loin de tout arrêter et des ISPs
avec des configurations plutôt mal torchées comme Belgacom ne
parviennent jamais à passer spamd. Leurs temps de retry doivent être de
l'ordre de l'année ... ?
In article <1gq1mnm.1gspi1x15h3m35N%, Emmanuel Dreyfus wrote:
Marc Espie wrote:
(*) depuis que j'ai viré spamassassin de mes MX. Tu as mis quoi a la place ?
Le puissant milter-greylist, pardi! Ca nettoie bien et pour pas cher en CPU.
Mouaip, faudra que je me decide a franchir le pas et me doter d'un vrai MX, surtout que mon ISP veut bien faire MX secondaire...
En attendant, le greylisting, ca marche helas pas trop sur du pop3,
Greylisting marche pas mal mais, c'est loin de tout arrêter et des ISPs avec des configurations plutôt mal torchées comme Belgacom ne parviennent jamais à passer spamd. Leurs temps de retry doivent être de l'ordre de l'année ... ?
manu
F. Senault wrote:
Dans mon cas, non ; le filtrage sur le contenu varie selon les utilisateurs et les adresses de destination. J'ai certaines personnes qui acceptent des virus sur certaines de leurs adresses (notamment la mainteneuse de la FAQ de fcs.virus...). Comme SMTP n'a qu'une réponse binaire sur le data, je ne peux pas faire autrement (problème des copies avec une adresse qui accepte et l'autre qui rejette).
Ah oui, ca c'est un problème difficile à résoudre. On en discutait recement sur la mailing list de milter-greylist (but: rejeter a DATA plutot que RCPT pour marcher mieux avec les systèmes de callback).
Note que si pour chaque message, tu accepte pour le premier destinataire et tempfail pour les autres, tu dois pouvoir reussir à separer les messages, mais ca introduit du delais.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
F. Senault <fred@lacave.net> wrote:
Dans mon cas, non ; le filtrage sur le contenu varie selon les
utilisateurs et les adresses de destination. J'ai certaines personnes
qui acceptent des virus sur certaines de leurs adresses (notamment la
mainteneuse de la FAQ de fcs.virus...). Comme SMTP n'a qu'une réponse
binaire sur le data, je ne peux pas faire autrement (problème des copies
avec une adresse qui accepte et l'autre qui rejette).
Ah oui, ca c'est un problème difficile à résoudre. On en discutait
recement sur la mailing list de milter-greylist (but: rejeter a DATA
plutot que RCPT pour marcher mieux avec les systèmes de callback).
Note que si pour chaque message, tu accepte pour le premier destinataire
et tempfail pour les autres, tu dois pouvoir reussir à separer les
messages, mais ca introduit du delais.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
Dans mon cas, non ; le filtrage sur le contenu varie selon les utilisateurs et les adresses de destination. J'ai certaines personnes qui acceptent des virus sur certaines de leurs adresses (notamment la mainteneuse de la FAQ de fcs.virus...). Comme SMTP n'a qu'une réponse binaire sur le data, je ne peux pas faire autrement (problème des copies avec une adresse qui accepte et l'autre qui rejette).
Ah oui, ca c'est un problème difficile à résoudre. On en discutait recement sur la mailing list de milter-greylist (but: rejeter a DATA plutot que RCPT pour marcher mieux avec les systèmes de callback).
Note que si pour chaque message, tu accepte pour le premier destinataire et tempfail pour les autres, tu dois pouvoir reussir à separer les messages, mais ca introduit du delais.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
pornin
According to F. Senault :
Ben non, mais c'est un excellent troll à garder dans la manche, ça...
Le problème, c'est que c'est un troll atomique : il blaste Linux mais aussi les *BSD, Windows, Solaris et même OS/2. Ah, je ne sais pas ce qu'il en est de Minix-i386, la version non-VM (sans swap) : il est possible qu'il n'active pas la MMU, comme sa variante 16-bit. Faudrait vérifier.
Et puis Minix est très décent maintenant qu'il est en licence BSD.
--Thomas Pornin
According to F. Senault <fred@lacave.net>:
Ben non, mais c'est un excellent troll à garder dans la manche, ça...
Le problème, c'est que c'est un troll atomique : il blaste Linux mais
aussi les *BSD, Windows, Solaris et même OS/2. Ah, je ne sais pas ce
qu'il en est de Minix-i386, la version non-VM (sans swap) : il est
possible qu'il n'active pas la MMU, comme sa variante 16-bit. Faudrait
vérifier.
Et puis Minix est très décent maintenant qu'il est en licence BSD.
Ben non, mais c'est un excellent troll à garder dans la manche, ça...
Le problème, c'est que c'est un troll atomique : il blaste Linux mais aussi les *BSD, Windows, Solaris et même OS/2. Ah, je ne sais pas ce qu'il en est de Minix-i386, la version non-VM (sans swap) : il est possible qu'il n'active pas la MMU, comme sa variante 16-bit. Faudrait vérifier.
Et puis Minix est très décent maintenant qu'il est en licence BSD.
--Thomas Pornin
pornin
According to Marc Espie :
Si ce n'est pas a 100% le cas, de toutes facons, c'est de ma faute, et je n'ai qu'a finir d'ecrire le code.
Ben moi, personnellement, quand j'installe quelque chose chex quelqu'un, si ça plante, je préfère que ce soit la faute de quelqu'un d'autre plutôt que la mienne. M'enfin c'est toi qui vois.
(Ceci est une variante sur le thème : on ne peut pas se prendre un blâme pour avoir mis du Windows, même si le système est en rade tout le temps. Sur le long terme, la médiocrité l'emporte toujours, et l'avenir appartient aux tièdes. Etc...)
--Thomas Pornin
According to Marc Espie <espie@nerim.net>:
Si ce n'est pas a 100% le cas, de toutes facons, c'est de ma faute, et
je n'ai qu'a finir d'ecrire le code.
Ben moi, personnellement, quand j'installe quelque chose chex
quelqu'un, si ça plante, je préfère que ce soit la faute de quelqu'un
d'autre plutôt que la mienne. M'enfin c'est toi qui vois.
(Ceci est une variante sur le thème : on ne peut pas se prendre un
blâme pour avoir mis du Windows, même si le système est en rade tout le
temps. Sur le long terme, la médiocrité l'emporte toujours, et l'avenir
appartient aux tièdes. Etc...)
Si ce n'est pas a 100% le cas, de toutes facons, c'est de ma faute, et je n'ai qu'a finir d'ecrire le code.
Ben moi, personnellement, quand j'installe quelque chose chex quelqu'un, si ça plante, je préfère que ce soit la faute de quelqu'un d'autre plutôt que la mienne. M'enfin c'est toi qui vois.
(Ceci est une variante sur le thème : on ne peut pas se prendre un blâme pour avoir mis du Windows, même si le système est en rade tout le temps. Sur le long terme, la médiocrité l'emporte toujours, et l'avenir appartient aux tièdes. Etc...)
--Thomas Pornin
F. Senault
According to F. Senault :
Ben non, mais c'est un excellent troll à garder dans la manche, ça...
Le problème, c'est que c'est un troll atomique : il blaste Linux mais aussi les *BSD, Windows, Solaris et même OS/2.
Chhhhht. 'Pas obligé de le dire, non plus ! Sinon, ce serait plus un troll, mais un fait, enfin !
Ah, je ne sais pas ce qu'il en est de Minix-i386, la version non-VM (sans swap) : il est possible qu'il n'active pas la MMU, comme sa variante 16-bit. Faudrait vérifier.
Et puis Minix est très décent maintenant qu'il est en licence BSD.
Ah ? Amusant, ça.
--Thomas Pornin
Fred -- It enters your veins It enters your soul It tries to obsess you It looks for defaults Try not to lose Not to lose control It tries to destroy you It tries to tear you down (Hooverphonic, Plus Profond)
According to F. Senault <fred@lacave.net>:
Ben non, mais c'est un excellent troll à garder dans la manche, ça...
Le problème, c'est que c'est un troll atomique : il blaste Linux mais
aussi les *BSD, Windows, Solaris et même OS/2.
Chhhhht. 'Pas obligé de le dire, non plus ! Sinon, ce serait plus un
troll, mais un fait, enfin !
Ah, je ne sais pas ce
qu'il en est de Minix-i386, la version non-VM (sans swap) : il est
possible qu'il n'active pas la MMU, comme sa variante 16-bit. Faudrait
vérifier.
Et puis Minix est très décent maintenant qu'il est en licence BSD.
Ah ? Amusant, ça.
--Thomas Pornin
Fred
--
It enters your veins It enters your soul It tries to obsess you
It looks for defaults Try not to lose Not to lose control
It tries to destroy you It tries to tear you down
(Hooverphonic, Plus Profond)
Ben non, mais c'est un excellent troll à garder dans la manche, ça...
Le problème, c'est que c'est un troll atomique : il blaste Linux mais aussi les *BSD, Windows, Solaris et même OS/2.
Chhhhht. 'Pas obligé de le dire, non plus ! Sinon, ce serait plus un troll, mais un fait, enfin !
Ah, je ne sais pas ce qu'il en est de Minix-i386, la version non-VM (sans swap) : il est possible qu'il n'active pas la MMU, comme sa variante 16-bit. Faudrait vérifier.
Et puis Minix est très décent maintenant qu'il est en licence BSD.
Ah ? Amusant, ça.
--Thomas Pornin
Fred -- It enters your veins It enters your soul It tries to obsess you It looks for defaults Try not to lose Not to lose control It tries to destroy you It tries to tear you down (Hooverphonic, Plus Profond)
