Je recherche un retour d'expérience sur la mise en place de routage
multicast dans un routeur/Firewall FreeBSD ou OpenBSD en s'intégrant
dans un réseau utilisant le protocole PIM-SM. J'ai bien trouvé
diverses implémentations existante sur nos BSD préférés, mais
malheureusement plus supportées.
Si qq a eu ce genre de cas, je recherche tous types de solution
utilisées (Tunnel, DVMRP/Mrouted etc...)
Ah mais c'est là le problème: on est pas sur que Miod s'interesse à autre chose que les sparc :-)
Le doute est permis, effectivement, mais il y a aussi les m88k, voyons.
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type de problème particulier, je risque en effet de conclure hâtivement que le problème est généralisé...
Ah mais c'est là le problème: on est pas sur que Miod s'interesse à
autre chose que les sparc :-)
Le doute est permis, effectivement, mais il y a aussi les m88k, voyons.
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type
de problème particulier, je risque en effet de conclure hâtivement que
le problème est généralisé...
Ah mais c'est là le problème: on est pas sur que Miod s'interesse à autre chose que les sparc :-)
Le doute est permis, effectivement, mais il y a aussi les m88k, voyons.
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type de problème particulier, je risque en effet de conclure hâtivement que le problème est généralisé...
manu
Miod Vallat wrote:
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type de problème particulier, je risque en effet de conclure hâtivement que le problème est généralisé...
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Miod Vallat <miod@online.fr> wrote:
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type
de problème particulier, je risque en effet de conclure hâtivement que
le problème est généralisé...
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type de problème particulier, je risque en effet de conclure hâtivement que le problème est généralisé...
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Miod Vallat
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type de problème particulier, je risque en effet de conclure hâtivement que le problème est généralisé...
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
On peut donc en conclure que les plate-formes sparc* sont considérées
comme secondaires pour NetBSD.
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type
de problème particulier, je risque en effet de conclure hâtivement que
le problème est généralisé...
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
On peut donc en conclure que les plate-formes sparc* sont considérées
Ceci étant, si les ports sparc* de NetBSD sont plus sensibles à un type de problème particulier, je risque en effet de conclure hâtivement que le problème est généralisé...
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
On peut donc en conclure que les plate-formes sparc* sont considérées
comme secondaires pour NetBSD.
manu
Miod Vallat wrote:
sur i386, amd64 et macppc je n'ai aucun problème avec les threads. On peut donc en conclure que les plate-formes sparc* sont considérées
comme secondaires pour NetBSD.
Y'a pas de notion de plateforme secondaire dans NetBSD. Y'a eventuellement des plateformes mal entretenues faute de developeur compétent, ayant du temps et ayant accès au matos. Mais ca n'est pas à toi que je vais expliquer comment marchent les projets annimés par des bénévoles.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
Miod Vallat <miod@online.fr> wrote:
sur i386, amd64 et macppc je n'ai aucun problème avec les threads.
On peut donc en conclure que les plate-formes sparc* sont considérées
comme secondaires pour NetBSD.
Y'a pas de notion de plateforme secondaire dans NetBSD. Y'a
eventuellement des plateformes mal entretenues faute de developeur
compétent, ayant du temps et ayant accès au matos. Mais ca n'est pas à
toi que je vais expliquer comment marchent les projets annimés par des
bénévoles.
sur i386, amd64 et macppc je n'ai aucun problème avec les threads. On peut donc en conclure que les plate-formes sparc* sont considérées
comme secondaires pour NetBSD.
Y'a pas de notion de plateforme secondaire dans NetBSD. Y'a eventuellement des plateformes mal entretenues faute de developeur compétent, ayant du temps et ayant accès au matos. Mais ca n'est pas à toi que je vais expliquer comment marchent les projets annimés par des bénévoles.
-- Emmanuel Dreyfus http://hcpnet.free.fr/pubz
asl
Le Mon, 11 Apr 2005 23:30:14 +0200, Emmanuel Dreyfus écrivit:
packages: pkgsrc/net/xorp) C'est le même sur FreeBSD et OpenBSD.
Ben oui c'est le même, on va pas s'ammuser à se faire un fork
packages: pkgsrc/net/xorp) C'est le même sur FreeBSD et OpenBSD.
Ben oui c'est le même, on va pas s'ammuser à se faire un fork
de Xorp rien que pour nous, quand même! Vous, non...
Ah tu vois venir OpenXorp, c'est ca?
-- 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
<asl@launay.org> wrote:
packages: pkgsrc/net/xorp)
C'est le même sur FreeBSD et OpenBSD.
Ben oui c'est le même, on va pas s'ammuser à se faire un fork
de Xorp rien que pour nous, quand même!
Vous, non...
Ah tu vois venir OpenXorp, c'est ca?
--
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
packages: pkgsrc/net/xorp) C'est le même sur FreeBSD et OpenBSD.
Ben oui c'est le même, on va pas s'ammuser à se faire un fork
de Xorp rien que pour nous, quand même! Vous, non...
Ah tu vois venir OpenXorp, c'est ca?
-- 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
Eric Masson
(Emmanuel Dreyfus) writes:
Ah tu vois venir OpenXorp, c'est ca?
Z'êtes mauvaises langues, Tdr ne s'est encore brouillé avec personne du projet pour le moment...
Éric Masson
-- JdC > [OUI] CR > mais [NON] (c) Fufage contradictoire compulsif. Il n'y a pas de remède connu. -+- jdc in <http://www.le-gnu.net> : Un suppo et au lit -+-
manu@netbsd.org (Emmanuel Dreyfus) writes:
Ah tu vois venir OpenXorp, c'est ca?
Z'êtes mauvaises langues, Tdr ne s'est encore brouillé avec personne du
projet pour le moment...
Éric Masson
--
JdC > [OUI]
CR > mais [NON] (c)
Fufage contradictoire compulsif. Il n'y a pas de remède connu.
-+- jdc in <http://www.le-gnu.net> : Un suppo et au lit -+-
Z'êtes mauvaises langues, Tdr ne s'est encore brouillé avec personne du projet pour le moment...
Éric Masson
-- JdC > [OUI] CR > mais [NON] (c) Fufage contradictoire compulsif. Il n'y a pas de remède connu. -+- jdc in <http://www.le-gnu.net> : Un suppo et au lit -+-
Anonyme
mknux écrivait :
Bonjour,
Je recherche un retour d'expérience sur la mise en place de routage multicast dans un routeur/Firewall FreeBSD ou OpenBSD en s'intégrant dans un réseau utilisant le protocole PIM-SM. J'ai bien trouvé diverses implémentations existante sur nos BSD préférés, mais malheureusement plus supportées.
Ryan McBride a commité le support de PIM (voir pim(4)) dans OpenBSD il y a quelques mois.
Si qq a eu ce genre de cas, je recherche tous types de solution utilisées (Tunnel, DVMRP/Mrouted etc...)
mrouted(8) est dans le système de base, et XORP est dans l'arbre des ports; il supporte PIM-SM et MLDv1 (mais pas MLDv2 à ma connaissance). Ryan McBride a commité le support de PIM (voir pim(4)) dans OpenBSD il y a quelques mois.
Si qq a eu ce genre de cas, je recherche tous types de solution utilisées (Tunnel, DVMRP/Mrouted etc...)
mrouted(8) est dans le système de base, et XORP est dans l'arbre des ports; il supporte PIM-SM et MLDv1 (mais pas MLDv2 à ma connaissance).
--
Anonyme
mknux écrivait :
Bonjour,
Je recherche un retour d'expérience sur la mise en place de routage
multicast dans un routeur/Firewall FreeBSD ou OpenBSD en s'intégrant
dans un réseau utilisant le protocole PIM-SM. J'ai bien trouvé
diverses implémentations existante sur nos BSD préférés, mais
malheureusement plus supportées.
Ryan McBride a commité le support de PIM (voir pim(4)) dans OpenBSD il y
a quelques mois.
Si qq a eu ce genre de cas, je recherche tous types de solution
utilisées (Tunnel, DVMRP/Mrouted etc...)
mrouted(8) est dans le système de base, et XORP est dans l'arbre des
ports; il supporte PIM-SM et MLDv1 (mais pas MLDv2 à ma connaissance).
Ryan McBride a commité le support de PIM (voir pim(4)) dans OpenBSD il y
a quelques mois.
Je recherche un retour d'expérience sur la mise en place de routage multicast dans un routeur/Firewall FreeBSD ou OpenBSD en s'intégrant dans un réseau utilisant le protocole PIM-SM. J'ai bien trouvé diverses implémentations existante sur nos BSD préférés, mais malheureusement plus supportées.
Ryan McBride a commité le support de PIM (voir pim(4)) dans OpenBSD il y a quelques mois.
Si qq a eu ce genre de cas, je recherche tous types de solution utilisées (Tunnel, DVMRP/Mrouted etc...)
mrouted(8) est dans le système de base, et XORP est dans l'arbre des ports; il supporte PIM-SM et MLDv1 (mais pas MLDv2 à ma connaissance). Ryan McBride a commité le support de PIM (voir pim(4)) dans OpenBSD il y a quelques mois.
Z'êtes mauvaises langues, Tdr ne s'est encore brouillé avec personne du projet pour le moment...
Ça doit pouvoir s'arranger :-)
-- Mathieu Arnold
Miod Vallat
On peut donc en conclure que les plate-formes sparc* sont considérées comme secondaires pour NetBSD.
Y'a pas de notion de plateforme secondaire dans NetBSD. Y'a eventuellement des plateformes mal entretenues faute de developeur compétent, ayant du temps et ayant accès au matos. Mais ca n'est pas à toi que je vais expliquer comment marchent les projets annimés par des bénévoles.
Pas de notion théorique, alors.
Parce que je ne peux pas supposer l'espace d'un instant que, à l'occasion de la sortie de 2.0, il n'y ait pas eu un travail d'assurance qualité effectué.
Après tout, les fonctionnalités RAS ne sont pas disponibles ou pas fiables sur toutes les plate-formes, et on ne voit nulle part l'annonce de 2.0 se gargarisant de cette fonctionnalité, ce qui n'est pas le cas des lwp. Et - corrigez-moi si je me trompe - il n'y a rien dans pkgsrc qui indique que «euh, en 2.0*, les lwp sur sparc/sparc64/vax ne doivent pas être utilisés».
On est a un stade où, si l'on veut un NetBSD stable sur certaines plate-formes, il faut se résigner à 1.6.3, ah non, mince, 1.6.2, bien que l'annonce de 2.0 indique que toutes les plate-formes sont supportées. Allez donc expliquer ça au pauvre hère qui installe un NetBSD 2 tout frais sur sa babasse, pour la découvrir plantée avant qu'il n'aie le temps de dire «ouf».
Mais je suis d'accord avec toi sur le fond : il est nettement plus important de donner un pc532 à Chuck Silvers plutôt que de corriger les problèmes des lwp - après tout, on attend toujours les binaires de NetBSD 1.6 pour pc532...
On peut donc en conclure que les plate-formes sparc* sont considérées
comme secondaires pour NetBSD.
Y'a pas de notion de plateforme secondaire dans NetBSD. Y'a
eventuellement des plateformes mal entretenues faute de developeur
compétent, ayant du temps et ayant accès au matos. Mais ca n'est pas à
toi que je vais expliquer comment marchent les projets annimés par des
bénévoles.
Pas de notion théorique, alors.
Parce que je ne peux pas supposer l'espace d'un instant que, à
l'occasion de la sortie de 2.0, il n'y ait pas eu un travail d'assurance
qualité effectué.
Après tout, les fonctionnalités RAS ne sont pas disponibles ou pas
fiables sur toutes les plate-formes, et on ne voit nulle part l'annonce
de 2.0 se gargarisant de cette fonctionnalité, ce qui n'est pas le cas
des lwp. Et - corrigez-moi si je me trompe - il n'y a rien dans pkgsrc
qui indique que «euh, en 2.0*, les lwp sur sparc/sparc64/vax ne doivent
pas être utilisés».
On est a un stade où, si l'on veut un NetBSD stable sur certaines
plate-formes, il faut se résigner à 1.6.3, ah non, mince, 1.6.2, bien
que l'annonce de 2.0 indique que toutes les plate-formes sont
supportées. Allez donc expliquer ça au pauvre hère qui installe un
NetBSD 2 tout frais sur sa babasse, pour la découvrir plantée avant
qu'il n'aie le temps de dire «ouf».
Mais je suis d'accord avec toi sur le fond : il est nettement plus
important de donner un pc532 à Chuck Silvers plutôt que de corriger les
problèmes des lwp - après tout, on attend toujours les binaires de
NetBSD 1.6 pour pc532...
On peut donc en conclure que les plate-formes sparc* sont considérées comme secondaires pour NetBSD.
Y'a pas de notion de plateforme secondaire dans NetBSD. Y'a eventuellement des plateformes mal entretenues faute de developeur compétent, ayant du temps et ayant accès au matos. Mais ca n'est pas à toi que je vais expliquer comment marchent les projets annimés par des bénévoles.
Pas de notion théorique, alors.
Parce que je ne peux pas supposer l'espace d'un instant que, à l'occasion de la sortie de 2.0, il n'y ait pas eu un travail d'assurance qualité effectué.
Après tout, les fonctionnalités RAS ne sont pas disponibles ou pas fiables sur toutes les plate-formes, et on ne voit nulle part l'annonce de 2.0 se gargarisant de cette fonctionnalité, ce qui n'est pas le cas des lwp. Et - corrigez-moi si je me trompe - il n'y a rien dans pkgsrc qui indique que «euh, en 2.0*, les lwp sur sparc/sparc64/vax ne doivent pas être utilisés».
On est a un stade où, si l'on veut un NetBSD stable sur certaines plate-formes, il faut se résigner à 1.6.3, ah non, mince, 1.6.2, bien que l'annonce de 2.0 indique que toutes les plate-formes sont supportées. Allez donc expliquer ça au pauvre hère qui installe un NetBSD 2 tout frais sur sa babasse, pour la découvrir plantée avant qu'il n'aie le temps de dire «ouf».
Mais je suis d'accord avec toi sur le fond : il est nettement plus important de donner un pc532 à Chuck Silvers plutôt que de corriger les problèmes des lwp - après tout, on attend toujours les binaires de NetBSD 1.6 pour pc532...
