Le Sat, 8 Jan 2005 15:51:48 +0100, F. Senault écrivit:
Je suis en train de me demander si je ne vais pas leur demander de ne plus faire MX2 sur les domaines que je gère... L'autre solution est de trouver quelqu'un qui veuille bien héberger un
backup MX selon tes conditions. Ou de trouver le moyen d'avoir une
Je crois l'avoir déjà dit, mais si vous en avez besoin, je peux faire tout ça, à priori, sauf si vous demandez quelque chose de vraiment tordu...
Le Sat, 8 Jan 2005 15:51:48 +0100, F. Senault écrivit:
Je suis en train de me demander si je ne vais pas leur
demander de ne plus faire MX2 sur les domaines que je gère...
L'autre solution est de trouver quelqu'un qui veuille bien héberger un
backup MX selon tes conditions. Ou de trouver le moyen d'avoir une
Je crois l'avoir déjà dit, mais si vous en avez besoin, je peux
faire tout ça, à priori, sauf si vous demandez quelque chose de
vraiment tordu...
Le Sat, 8 Jan 2005 15:51:48 +0100, F. Senault écrivit:
Je suis en train de me demander si je ne vais pas leur demander de ne plus faire MX2 sur les domaines que je gère... L'autre solution est de trouver quelqu'un qui veuille bien héberger un
backup MX selon tes conditions. Ou de trouver le moyen d'avoir une
Je crois l'avoir déjà dit, mais si vous en avez besoin, je peux faire tout ça, à priori, sauf si vous demandez quelque chose de vraiment tordu...
Le Fri, 7 Jan 2005 19:38:18 +0000 (UTC), Marc Espie écrivit:
Justement, y'a pas mal de raisons pour lequelles ca sera plus facile à maintenir sur un BSD que sur un Linux. Aaaaaaah. Bien. Liste-les.
Perso, j'en vois deja une: je connais dix fois mieux mon
OpenBSD qu'un Linux.
Ça, c'est une contrainte perso, et par extention, c'est totalement subjectif.
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.
Le Fri, 7 Jan 2005 19:38:18 +0000 (UTC), Marc Espie écrivit:
Justement, y'a pas mal de raisons pour lequelles ca sera plus
facile à maintenir sur un BSD que sur un Linux.
Aaaaaaah. Bien. Liste-les.
Perso, j'en vois deja une: je connais dix fois mieux mon
OpenBSD qu'un Linux.
Ça, c'est une contrainte perso, et par extention, c'est
totalement subjectif.
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.
Le Fri, 7 Jan 2005 19:38:18 +0000 (UTC), Marc Espie écrivit:
Justement, y'a pas mal de raisons pour lequelles ca sera plus facile à maintenir sur un BSD que sur un Linux. Aaaaaaah. Bien. Liste-les.
Perso, j'en vois deja une: je connais dix fois mieux mon
OpenBSD qu'un Linux.
Ça, c'est une contrainte perso, et par extention, c'est totalement subjectif.
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.
A un moment, plus de 50% du spam qui arrivait chez moi passait par le MX2 - dans l'autre sens, 99% de ce qui sortait de mon MX2 était du spam, d'ailleurs. Finalement, j'ai laissé tomber aussi l'idée d'avoir deux MX temporairement.
A mon avis, le MX secondaire est aujourd'hui dépassé pour celui qui a une bonne connexion. A moins d'en avoir le controle pour ce qui est du filtrage, bien sur.
On le remplace avantageusement par plusieurs primaires (même poids dans le champ MX du DNS). Ca assure la repartition de charge et la resistance aux pannes.
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se retrouve deconnecté durablement. Il peut alors être interessant de se connecter par une liaison intermitente et de recuperer le courrier en UUCP. De telles situations se font rares.
-- 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:
A un moment, plus de 50% du spam qui arrivait chez moi passait par le
MX2 - dans l'autre sens, 99% de ce qui sortait de mon MX2 était du spam,
d'ailleurs. Finalement, j'ai laissé tomber aussi l'idée d'avoir deux MX
temporairement.
A mon avis, le MX secondaire est aujourd'hui dépassé pour celui qui a
une bonne connexion. A moins d'en avoir le controle pour ce qui est du
filtrage, bien sur.
On le remplace avantageusement par plusieurs primaires (même poids dans
le champ MX du DNS). Ca assure la repartition de charge et la resistance
aux pannes.
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se
retrouve deconnecté durablement. Il peut alors être interessant de se
connecter par une liaison intermitente et de recuperer le courrier en
UUCP. De telles situations se font rares.
--
Emmanuel Dreyfus
Un bouquin en français sur BSD:
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
A un moment, plus de 50% du spam qui arrivait chez moi passait par le MX2 - dans l'autre sens, 99% de ce qui sortait de mon MX2 était du spam, d'ailleurs. Finalement, j'ai laissé tomber aussi l'idée d'avoir deux MX temporairement.
A mon avis, le MX secondaire est aujourd'hui dépassé pour celui qui a une bonne connexion. A moins d'en avoir le controle pour ce qui est du filtrage, bien sur.
On le remplace avantageusement par plusieurs primaires (même poids dans le champ MX du DNS). Ca assure la repartition de charge et la resistance aux pannes.
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se retrouve deconnecté durablement. Il peut alors être interessant de se connecter par une liaison intermitente et de recuperer le courrier en UUCP. De telles situations se font rares.
-- Emmanuel Dreyfus Un bouquin en français sur BSD: http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
espie
In article <1gq3572.107ypcgyzcvzvN%, Emmanuel Dreyfus wrote:
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se retrouve deconnecté durablement. Il peut alors être interessant de se connecter par une liaison intermitente et de recuperer le courrier en UUCP. De telles situations se font rares.
Oui, ca ne couvre plus guere que la quasi-totalite des liaisons ADSL gerees par la plupart des fournisseurs d'acces.
J'ai entendu suffisamment d'histoires gore de connexions qui plantent sans arret a ce niveau-la (la derniere en date, un wanadoo capricieux qui ne passait pas les paquets, mais sans rien dire au niveau lcp) pour n'avoir qu'une confiance tres limitee dans la fiabilite des dits fournisseurs...
In article <1gq3572.107ypcgyzcvzvN%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se
retrouve deconnecté durablement. Il peut alors être interessant de se
connecter par une liaison intermitente et de recuperer le courrier en
UUCP. De telles situations se font rares.
Oui, ca ne couvre plus guere que la quasi-totalite des liaisons ADSL
gerees par la plupart des fournisseurs d'acces.
J'ai entendu suffisamment d'histoires gore de connexions qui plantent
sans arret a ce niveau-la (la derniere en date, un wanadoo capricieux
qui ne passait pas les paquets, mais sans rien dire au niveau lcp) pour
n'avoir qu'une confiance tres limitee dans la fiabilite des dits
fournisseurs...
In article <1gq3572.107ypcgyzcvzvN%, Emmanuel Dreyfus wrote:
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se retrouve deconnecté durablement. Il peut alors être interessant de se connecter par une liaison intermitente et de recuperer le courrier en UUCP. De telles situations se font rares.
Oui, ca ne couvre plus guere que la quasi-totalite des liaisons ADSL gerees par la plupart des fournisseurs d'acces.
J'ai entendu suffisamment d'histoires gore de connexions qui plantent sans arret a ce niveau-la (la derniere en date, un wanadoo capricieux qui ne passait pas les paquets, mais sans rien dire au niveau lcp) pour n'avoir qu'une confiance tres limitee dans la fiabilite des dits fournisseurs...
-- Thomas vO --
bonjour,
Olivier Tharan wrote:
* Thomas van Oudenhove (Thu, 06 Jan 2005 13:28:21 +0100):
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Aucun, bien sûr.
Au fait, quelle sera l'utilisation réelle de _votre_ machine au final ? Ce benchmark ne semble pas s'intéresser aux interactions avec le disque, mais ce n'est peut-être pas si important que ça finalement.
après avoir *bien* lu le benchmark, je me dis que les différences cont vraiment minimales... je garde mon FreeBSD, le logo est plus joli ;)
-- Thomas vO http://www.enstimac.fr/~vanouden/
bonjour,
Olivier Tharan wrote:
* Thomas van Oudenhove <vanouden@cf.webpage.invalid> (Thu, 06 Jan 2005 13:28:21 +0100):
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose
est la suivante : quels sont les avantages à utiliser FreeBSD *si* les
performances sur x86 passent en dessous de NetBSD ? le catalogue des
ports ? ...
Aucun, bien sûr.
Au fait, quelle sera l'utilisation réelle de _votre_ machine au final ?
Ce benchmark ne semble pas s'intéresser aux interactions avec le disque,
mais ce n'est peut-être pas si important que ça finalement.
après avoir *bien* lu le benchmark, je me dis que les différences cont
vraiment minimales... je garde mon FreeBSD, le logo est plus joli ;)
* Thomas van Oudenhove (Thu, 06 Jan 2005 13:28:21 +0100):
je n'ai lu qu'en diagonale ce papier, mais la question que je me pose est la suivante : quels sont les avantages à utiliser FreeBSD *si* les performances sur x86 passent en dessous de NetBSD ? le catalogue des ports ? ...
Aucun, bien sûr.
Au fait, quelle sera l'utilisation réelle de _votre_ machine au final ? Ce benchmark ne semble pas s'intéresser aux interactions avec le disque, mais ce n'est peut-être pas si important que ça finalement.
après avoir *bien* lu le benchmark, je me dis que les différences cont vraiment minimales... je garde mon FreeBSD, le logo est plus joli ;)
-- Thomas vO http://www.enstimac.fr/~vanouden/
F. Senault
F. Senault wrote:
A un moment, plus de 50% du spam qui arrivait chez moi passait par le MX2 - dans l'autre sens, 99% de ce qui sortait de mon MX2 était du spam, d'ailleurs. Finalement, j'ai laissé tomber aussi l'idée d'avoir deux MX temporairement.
A mon avis, le MX secondaire est aujourd'hui dépassé pour celui qui a une bonne connexion. A moins d'en avoir le controle pour ce qui est du filtrage, bien sur.
On le remplace avantageusement par plusieurs primaires (même poids dans le champ MX du DNS). Ca assure la repartition de charge et la resistance aux pannes.
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.
Dans l'absolu, dans tout ça, pour le moment, ce qui me bloque dans l'idée d'avoir un MX que je ne contrôle pas, c'est la synchronisation des adresses valides, pour éviter le /backscatter/ sur les attaques de dictionnaires (et j'en ai parfois des rafales de plusieurs centaines sur quelques minutes).
Fred -- I am the bullet in the gun and I control you I am the truth from which you run and I control you I am the silencing machine and I control you (Nine inch Nails, I am the end of all your dreams and I control you Mr Self Destruct)
F. Senault <fred@lacave.net> wrote:
A un moment, plus de 50% du spam qui arrivait chez moi passait par le
MX2 - dans l'autre sens, 99% de ce qui sortait de mon MX2 était du spam,
d'ailleurs. Finalement, j'ai laissé tomber aussi l'idée d'avoir deux MX
temporairement.
A mon avis, le MX secondaire est aujourd'hui dépassé pour celui qui a
une bonne connexion. A moins d'en avoir le controle pour ce qui est du
filtrage, bien sur.
On le remplace avantageusement par plusieurs primaires (même poids dans
le champ MX du DNS). Ca assure la repartition de charge et la resistance
aux pannes.
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.
Dans l'absolu, dans tout ça, pour le moment, ce qui me bloque dans
l'idée d'avoir un MX que je ne contrôle pas, c'est la synchronisation
des adresses valides, pour éviter le /backscatter/ sur les attaques de
dictionnaires (et j'en ai parfois des rafales de plusieurs centaines sur
quelques minutes).
Fred
--
I am the bullet in the gun and I control you
I am the truth from which you run and I control you
I am the silencing machine and I control you (Nine inch Nails,
I am the end of all your dreams and I control you Mr Self Destruct)
A un moment, plus de 50% du spam qui arrivait chez moi passait par le MX2 - dans l'autre sens, 99% de ce qui sortait de mon MX2 était du spam, d'ailleurs. Finalement, j'ai laissé tomber aussi l'idée d'avoir deux MX temporairement.
A mon avis, le MX secondaire est aujourd'hui dépassé pour celui qui a une bonne connexion. A moins d'en avoir le controle pour ce qui est du filtrage, bien sur.
On le remplace avantageusement par plusieurs primaires (même poids dans le champ MX du DNS). Ca assure la repartition de charge et la resistance aux pannes.
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.
Dans l'absolu, dans tout ça, pour le moment, ce qui me bloque dans l'idée d'avoir un MX que je ne contrôle pas, c'est la synchronisation des adresses valides, pour éviter le /backscatter/ sur les attaques de dictionnaires (et j'en ai parfois des rafales de plusieurs centaines sur quelques minutes).
Fred -- I am the bullet in the gun and I control you I am the truth from which you run and I control you I am the silencing machine and I control you (Nine inch Nails, I am the end of all your dreams and I control you Mr Self Destruct)
manu
Marc Espie wrote:
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se retrouve deconnecté durablement. Il peut alors être interessant de se connecter par une liaison intermitente et de recuperer le courrier en UUCP. De telles situations se font rares.
Oui, ca ne couvre plus guere que la quasi-totalite des liaisons ADSL gerees par la plupart des fournisseurs d'acces.
J'ai entendu suffisamment d'histoires gore de connexions qui plantent sans arret a ce niveau-la (la derniere en date, un wanadoo capricieux qui ne passait pas les paquets, mais sans rien dire au niveau lcp) pour n'avoir qu'une confiance tres limitee dans la fiabilite des dits fournisseurs...
Bon, effectivement si tu es dans le trip de faire un serveur de messagerie sur une connexion internet grand public où la prestation est merdique au point de te laisser off-line des jours durant, c'est ton choix et je le respecte, et effectivement t'as bien besoin d'un MX secondaire.
Je ne sais pas trop quelle fraction des serveurs de messageries sont dans cette situation, mais ca doit pas faire grand monde (en fait, ca doit se limiter à quelques unixiens avertis et les PME qui les emploient et qui les laissent se faire plaisir). L'ecrasante majorité des gens sur une ligne ADSL grand public utilisent le serveur de messagerie du FAI.
Remarque, sans secondaire, si t'es pas deconnecté trop longtemps, tu elimine des spams et des virus, ca fait une espece de liste grise, ca vaut le coup.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Marc Espie <espie@tetto.home> wrote:
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se
retrouve deconnecté durablement. Il peut alors être interessant de se
connecter par une liaison intermitente et de recuperer le courrier en
UUCP. De telles situations se font rares.
Oui, ca ne couvre plus guere que la quasi-totalite des liaisons ADSL
gerees par la plupart des fournisseurs d'acces.
J'ai entendu suffisamment d'histoires gore de connexions qui plantent
sans arret a ce niveau-la (la derniere en date, un wanadoo capricieux
qui ne passait pas les paquets, mais sans rien dire au niveau lcp) pour
n'avoir qu'une confiance tres limitee dans la fiabilite des dits
fournisseurs...
Bon, effectivement si tu es dans le trip de faire un serveur de
messagerie sur une connexion internet grand public où la prestation est
merdique au point de te laisser off-line des jours durant, c'est ton
choix et je le respecte, et effectivement t'as bien besoin d'un MX
secondaire.
Je ne sais pas trop quelle fraction des serveurs de messageries sont
dans cette situation, mais ca doit pas faire grand monde (en fait, ca
doit se limiter à quelques unixiens avertis et les PME qui les emploient
et qui les laissent se faire plaisir). L'ecrasante majorité des gens sur
une ligne ADSL grand public utilisent le serveur de messagerie du FAI.
Remarque, sans secondaire, si t'es pas deconnecté trop longtemps, tu
elimine des spams et des virus, ca fait une espece de liste grise, ca
vaut le coup.
Le seul cas où un MX secondaire sert à quelque chose, c'est quand on se retrouve deconnecté durablement. Il peut alors être interessant de se connecter par une liaison intermitente et de recuperer le courrier en UUCP. De telles situations se font rares.
Oui, ca ne couvre plus guere que la quasi-totalite des liaisons ADSL gerees par la plupart des fournisseurs d'acces.
J'ai entendu suffisamment d'histoires gore de connexions qui plantent sans arret a ce niveau-la (la derniere en date, un wanadoo capricieux qui ne passait pas les paquets, mais sans rien dire au niveau lcp) pour n'avoir qu'une confiance tres limitee dans la fiabilite des dits fournisseurs...
Bon, effectivement si tu es dans le trip de faire un serveur de messagerie sur une connexion internet grand public où la prestation est merdique au point de te laisser off-line des jours durant, c'est ton choix et je le respecte, et effectivement t'as bien besoin d'un MX secondaire.
Je ne sais pas trop quelle fraction des serveurs de messageries sont dans cette situation, mais ca doit pas faire grand monde (en fait, ca doit se limiter à quelques unixiens avertis et les PME qui les emploient et qui les laissent se faire plaisir). L'ecrasante majorité des gens sur une ligne ADSL grand public utilisent le serveur de messagerie du FAI.
Remarque, sans secondaire, si t'es pas deconnecté trop longtemps, tu elimine des spams et des virus, ca fait une espece de liste grise, ca vaut le coup.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
manu
F. Senault 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.
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.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
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.
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.
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
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.
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.
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
espie
In article , Arnaud Launay 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.
In article <slrncu02in.8sg.asl@citron.launay.org>,
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.
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.
