au risque de m'attirer les foudres de certains d'entre vous, je pose la
question suivante :
- quelles sont les différences majeures entre FreeBSD et Linux ?
In article <1g5nok5.v89e3z1lrzilxN%, Emmanuel Dreyfus wrote:
Olivier Cherrier wrote:
[NetBSD-current via releng.netbsd.org]
Oui, j'en conviens ... mais est-ce que ça doit vraiment rester secret comment vous faites pour compiler ??? On ne peut pas savoir ? ;-)
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera.
Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
mips
On 08 Dec 2003 16:01:07 GMT Arnaud Launay wrote:
Le Mon, 8 Dec 2003 15:00:03 +0100, mips écrivit:
Oui, j'en conviens ... mais est-ce que ça doit vraiment rester secret comment vous faites pour compiler ??? On ne peut pas savoir ?;-) Security through obscurity ;)
Et grâce à mips et pmk, on vous présente le nouveau concept: Security through obscenity
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory et que cela ne soit pas le cas de hlfl ;)
mips
On 08 Dec 2003 16:01:07 GMT
Arnaud Launay <arnaud@volfoni-brothers.org> wrote:
Le Mon, 8 Dec 2003 15:00:03 +0100, mips écrivit:
Oui, j'en conviens ... mais est-ce que ça doit vraiment rester
secret comment vous faites pour compiler ??? On ne peut pas
savoir ?;-)
Security through obscurity ;)
Et grâce à mips et pmk, on vous présente le nouveau concept:
Security through obscenity
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory
et que cela ne soit pas le cas de hlfl ;)
Oui, j'en conviens ... mais est-ce que ça doit vraiment rester secret comment vous faites pour compiler ??? On ne peut pas savoir ?;-) Security through obscurity ;)
Et grâce à mips et pmk, on vous présente le nouveau concept: Security through obscenity
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory et que cela ne soit pas le cas de hlfl ;)
mips
manu
Marc Espie wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera. Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Il m'est arrive aussi souvent d'oublier de committer un fichier. Chez moi ca marche, mais ce qui est dans le dépôt ne compile pas.
Bref, même si tout le monde verifie bien, -current peut avoir du mal à compiler.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Marc Espie <espie@tetto.gentiane.org> wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et
ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca
compilera.
Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse
un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que
finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines
archi, mais pas toutes. C'est des incidents qui peuvent très bien
survenir alors que tout le monde verifie bien son code. Vu que NetBSD a
beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus
de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce
genre de problèmes rapidement.
Il m'est arrive aussi souvent d'oublier de committer un fichier. Chez
moi ca marche, mais ce qui est dans le dépôt ne compile pas.
Bref, même si tout le monde verifie bien, -current peut avoir du mal à
compiler.
--
Emmanuel Dreyfus
A lire: 240 pages en français sur l'administration UNIX avec BSD
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera. Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Il m'est arrive aussi souvent d'oublier de committer un fichier. Chez moi ca marche, mais ce qui est dans le dépôt ne compile pas.
Bref, même si tout le monde verifie bien, -current peut avoir du mal à compiler.
-- Emmanuel Dreyfus A lire: 240 pages en français sur l'administration UNIX avec BSD http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Arnaud Launay
Le Mon, 8 Dec 2003 18:04:30 +0100, mips écrivit:
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory et que cela ne soit pas le cas de hlfl ;)
Trouver hlfl chez GNU, personnellement, j'aurais honte. Mais toi, visiblement, tu n'as peur de rien.
Arnaud.
Le Mon, 8 Dec 2003 18:04:30 +0100, mips écrivit:
Decidemment t'as du mal a digerer que pmk soit dans le GNU
directory et que cela ne soit pas le cas de hlfl ;)
Trouver hlfl chez GNU, personnellement, j'aurais honte. Mais toi,
visiblement, tu n'as peur de rien.
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory et que cela ne soit pas le cas de hlfl ;)
Trouver hlfl chez GNU, personnellement, j'aurais honte. Mais toi, visiblement, tu n'as peur de rien.
Arnaud.
Manuel Bouyer
Emmanuel Dreyfus wrote:
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Il m'est arrive aussi souvent d'oublier de committer un fichier. Chez moi ca marche, mais ce qui est dans le dépôt ne compile pas.
3ieme raison: checkout qui est fait au milieu d'un gros commit en plusieurs commandes CVS. Moi par exemple, quand j'ajoute un fichier je fais souvent un commit separe pour distrib/sets/. He ben si le checkout est fait entre les deux, le build.sh ne va pas jusqu'au bout.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Souvent les problèmes sont machine-dépendants: ca compile certaines
archi, mais pas toutes. C'est des incidents qui peuvent très bien
survenir alors que tout le monde verifie bien son code. Vu que NetBSD a
beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus
de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce
genre de problèmes rapidement.
Il m'est arrive aussi souvent d'oublier de committer un fichier. Chez
moi ca marche, mais ce qui est dans le dépôt ne compile pas.
3ieme raison: checkout qui est fait au milieu d'un gros commit en plusieurs
commandes CVS.
Moi par exemple, quand j'ajoute un fichier je fais souvent un commit
separe pour distrib/sets/. He ben si le checkout est fait entre les deux,
le build.sh ne va pas jusqu'au bout.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 24 ans d'experience feront toujours la difference
--
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Il m'est arrive aussi souvent d'oublier de committer un fichier. Chez moi ca marche, mais ce qui est dans le dépôt ne compile pas.
3ieme raison: checkout qui est fait au milieu d'un gros commit en plusieurs commandes CVS. Moi par exemple, quand j'ajoute un fichier je fais souvent un commit separe pour distrib/sets/. He ben si le checkout est fait entre les deux, le build.sh ne va pas jusqu'au bout.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
espie
In article <1g5nud8.169x7u6x4boz9N%, Emmanuel Dreyfus wrote:
Marc Espie wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera. Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Ben oui, je ne t'explique pas comment c'est complique et decourageant
parfois, quand comme moi on passe pas mal de temps avec la toolchain, ou dans des trucs qui peuvente potentiellement tout casser, de trouver des gens pour tout tester, meme les archis exotiques.
Au bout du compte, je me retrouve souvent a committer un truc apres avoir envoye quatre fois le meme patch, et avoir insiste tres fort pour que tout le monde le teste... a l'arrivee ca casse *peut-etre* alpha, ou hppa, mais c'est bien parce que personne ne s'est bouge le cul.
A l'arrivee, en tout cas, l'arbre est rarement casse plus de 24h d'affilee, et il doit compiler a peu pres 9 jours sur 10, au moins.
In article <1g5nud8.169x7u6x4boz9N%manu@netbsd.org>,
Emmanuel Dreyfus <manu@netbsd.org> wrote:
Marc Espie <espie@tetto.gentiane.org> wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et
ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca
compilera.
Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse
un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que
finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines
archi, mais pas toutes. C'est des incidents qui peuvent très bien
survenir alors que tout le monde verifie bien son code. Vu que NetBSD a
beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus
de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce
genre de problèmes rapidement.
Ben oui, je ne t'explique pas comment c'est complique et decourageant
parfois, quand comme moi on passe pas mal de temps avec la toolchain, ou
dans des trucs qui peuvente potentiellement tout casser, de trouver des
gens pour tout tester, meme les archis exotiques.
Au bout du compte, je me retrouve souvent a committer un truc apres avoir
envoye quatre fois le meme patch, et avoir insiste tres fort pour que tout
le monde le teste... a l'arrivee ca casse *peut-etre* alpha, ou hppa, mais
c'est bien parce que personne ne s'est bouge le cul.
A l'arrivee, en tout cas, l'arbre est rarement casse plus de 24h d'affilee,
et il doit compiler a peu pres 9 jours sur 10, au moins.
In article <1g5nud8.169x7u6x4boz9N%, Emmanuel Dreyfus wrote:
Marc Espie wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera. Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Ben oui, je ne t'explique pas comment c'est complique et decourageant
parfois, quand comme moi on passe pas mal de temps avec la toolchain, ou dans des trucs qui peuvente potentiellement tout casser, de trouver des gens pour tout tester, meme les archis exotiques.
Au bout du compte, je me retrouve souvent a committer un truc apres avoir envoye quatre fois le meme patch, et avoir insiste tres fort pour que tout le monde le teste... a l'arrivee ca casse *peut-etre* alpha, ou hppa, mais c'est bien parce que personne ne s'est bouge le cul.
A l'arrivee, en tout cas, l'arbre est rarement casse plus de 24h d'affilee, et il doit compiler a peu pres 9 jours sur 10, au moins.
Sylvain Tertois
Eric Masson a écrit:
Sylvain> Avant que tu me cries dessus, j'ai googlelé, sans trouver de Sylvain> réponse satisfaisante... Purée, la réputation de sauvage que je vais finir par me faire ;)
Mais non mais non ;-)
Ce qui m'a plu dans pf, c'est l'intégration AltQ, les tables, les macros, en bref tout ce qui te permet de monter une conf avec un minimum d'erreurs en un minimum de temps.
Ok. Pour avoir vu quelques exemples de configurations ipf, c'est vrai qu'ipf a l'air plus clair et facile à maintenir. En tous cas merci pour vos réponses!
-- Sylvain
Eric Masson a écrit:
Sylvain> Avant que tu me cries dessus, j'ai googlelé, sans trouver de
Sylvain> réponse satisfaisante...
Purée, la réputation de sauvage que je vais finir par me faire ;)
Mais non mais non ;-)
Ce qui m'a plu dans pf, c'est l'intégration AltQ, les tables, les
macros, en bref tout ce qui te permet de monter une conf avec un minimum
d'erreurs en un minimum de temps.
Ok. Pour avoir vu quelques exemples de configurations ipf, c'est vrai qu'ipf a
l'air plus clair et facile à maintenir.
En tous cas merci pour vos réponses!
Sylvain> Avant que tu me cries dessus, j'ai googlelé, sans trouver de Sylvain> réponse satisfaisante... Purée, la réputation de sauvage que je vais finir par me faire ;)
Mais non mais non ;-)
Ce qui m'a plu dans pf, c'est l'intégration AltQ, les tables, les macros, en bref tout ce qui te permet de monter une conf avec un minimum d'erreurs en un minimum de temps.
Ok. Pour avoir vu quelques exemples de configurations ipf, c'est vrai qu'ipf a l'air plus clair et facile à maintenir. En tous cas merci pour vos réponses!
-- Sylvain
Sylvain Tertois
Salus a écrit:
Je poste ici un autre troll alors:
Dis, les frites, avec ou sans mayo?
Ah mais celui-là il ne compte pas, c'est un troll hors charte! A la rigueur comparer les frites avec et sans mayo pour éviter de trop salir le clavier de son serveur favori avec ses mains toutes grasses :o) -- Sylvain
Salus a écrit:
Je poste ici un autre troll alors:
Dis, les frites, avec ou sans mayo?
Ah mais celui-là il ne compte pas, c'est un troll hors charte!
A la rigueur comparer les frites avec et sans mayo pour éviter de trop salir
le clavier de son serveur favori avec ses mains toutes grasses :o)
--
Sylvain
Ah mais celui-là il ne compte pas, c'est un troll hors charte! A la rigueur comparer les frites avec et sans mayo pour éviter de trop salir le clavier de son serveur favori avec ses mains toutes grasses :o) -- Sylvain
Olivier Cherrier
In article <1g5nud8.169x7u6x4boz9N%, Emmanuel Dreyfus wrote:
Marc Espie wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera. Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Oui, c'est vrai qu'il y a plus de problèmes liés à la quantité d'architectures.
M'enfin, quand tu lis : http://releng.netbsd.org/ab/B_HEAD/stat.html et que tu as une SPARC(32,64), il ne faut pas ménager l'option "-D XXX" de cvs.
In article <1g5nud8.169x7u6x4boz9N%manu@netbsd.org>, Emmanuel Dreyfus wrote:
Marc Espie <espie@tetto.gentiane.org> wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et
ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca
compilera.
Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse
un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que
finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines
archi, mais pas toutes. C'est des incidents qui peuvent très bien
survenir alors que tout le monde verifie bien son code. Vu que NetBSD a
beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus
de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce
genre de problèmes rapidement.
Oui, c'est vrai qu'il y a plus de problèmes liés à la quantité d'architectures.
M'enfin, quand tu lis : http://releng.netbsd.org/ab/B_HEAD/stat.html et que
tu as une SPARC(32,64), il ne faut pas ménager l'option "-D XXX" de cvs.
In article <1g5nud8.169x7u6x4boz9N%, Emmanuel Dreyfus wrote:
Marc Espie wrote:
Ben grace à releng, tu trouve un jour où ca compile pour ton port, et ensuite tu fais un checkout à 00h00 ce jour là, et tu es sur que ca compilera. Parfois, je me dis que Theo il fait chier a insister que tout le monde
verifie tout et a gueuler tres fort chaque fois que quelqu'un casse un petit detail.
Et puis, quand je vois des messages comme le tien, je me dis que finalement, il n'a peut-etre pas tort...
Souvent les problèmes sont machine-dépendants: ca compile certaines archi, mais pas toutes. C'est des incidents qui peuvent très bien survenir alors que tout le monde verifie bien son code. Vu que NetBSD a beaucoup plus d'architectures que OpenBSD, c'est normal qu'il ait plus de problème de ce type. releng.netbsd.org est d'ailleurs là pour voir ce genre de problèmes rapidement.
Oui, c'est vrai qu'il y a plus de problèmes liés à la quantité d'architectures.
M'enfin, quand tu lis : http://releng.netbsd.org/ab/B_HEAD/stat.html et que tu as une SPARC(32,64), il ne faut pas ménager l'option "-D XXX" de cvs.
mips
On 08 Dec 2003 17:20:48 GMT Arnaud Launay wrote:
Le Mon, 8 Dec 2003 18:04:30 +0100, mips écrivit:
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory et que cela ne soit pas le cas de hlfl ;)
Trouver hlfl chez GNU, personnellement, j'aurais honte. Mais toi, visiblement, tu n'as peur de rien.
Comme quoi je ne suis pas aussi integriste que ce que certains laissent a penser :) Pour moi que le GNU directory reference un projet BSD c'est plutot une victoire ...
mips
On 08 Dec 2003 17:20:48 GMT
Arnaud Launay <arnaud@volfoni-brothers.org> wrote:
Le Mon, 8 Dec 2003 18:04:30 +0100, mips écrivit:
Decidemment t'as du mal a digerer que pmk soit dans le GNU
directory et que cela ne soit pas le cas de hlfl ;)
Trouver hlfl chez GNU, personnellement, j'aurais honte. Mais toi,
visiblement, tu n'as peur de rien.
Comme quoi je ne suis pas aussi integriste que ce que certains
laissent a penser :)
Pour moi que le GNU directory reference un projet BSD c'est plutot une
victoire ...
Decidemment t'as du mal a digerer que pmk soit dans le GNU directory et que cela ne soit pas le cas de hlfl ;)
Trouver hlfl chez GNU, personnellement, j'aurais honte. Mais toi, visiblement, tu n'as peur de rien.
Comme quoi je ne suis pas aussi integriste que ce que certains laissent a penser :) Pour moi que le GNU directory reference un projet BSD c'est plutot une victoire ...
