Pour les mal-comprenants, un petit rappel: OpenBSD existe, OpenBSD fonctionne. Si les users un peu concon qui essaient une fois ne nous rapportent pas d'eventuels problemes, les problemes en question n'existent pas.
Contrairement a ce que le debile moyen pourrait penser, les ordinateurs ne sont pas si standardises que ca. Marcher partout n'est pas evident, surtout lorsqu'on a decide qu'on n'aimait vraiment pas les drivers proprietaires, entre ndis, les pilote nvidia, la compat binaire 32 bits avec nunux et autres...
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement, mais que vous apportez pas votre petite pierre en disant ce qui deconne, vous ne servez a rien....
(coup de gueule du soir, bonsoir)
In article <l6bpca-7ic.ln1@unices.org>, ST <st@unices.org> wrote:
On 2013-07-31, Cyrille Lefevre
<cyrille.lefevre-news%nospam@laposte.net.invalid> wrote:
C'est dans un contexte de production où faut que ça marche.
Pour les mal-comprenants, un petit rappel: OpenBSD existe, OpenBSD
fonctionne. Si les users un peu concon qui essaient une fois ne nous
rapportent pas d'eventuels problemes, les problemes en question n'existent
pas.
Contrairement a ce que le debile moyen pourrait penser, les ordinateurs ne
sont pas si standardises que ca. Marcher partout n'est pas evident, surtout
lorsqu'on a decide qu'on n'aimait vraiment pas les drivers proprietaires,
entre ndis, les pilote nvidia, la compat binaire 32 bits avec nunux et
autres...
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement,
mais que vous apportez pas votre petite pierre en disant ce qui deconne,
vous ne servez a rien....
Pour les mal-comprenants, un petit rappel: OpenBSD existe, OpenBSD fonctionne. Si les users un peu concon qui essaient une fois ne nous rapportent pas d'eventuels problemes, les problemes en question n'existent pas.
Contrairement a ce que le debile moyen pourrait penser, les ordinateurs ne sont pas si standardises que ca. Marcher partout n'est pas evident, surtout lorsqu'on a decide qu'on n'aimait vraiment pas les drivers proprietaires, entre ndis, les pilote nvidia, la compat binaire 32 bits avec nunux et autres...
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement, mais que vous apportez pas votre petite pierre en disant ce qui deconne, vous ne servez a rien....
(coup de gueule du soir, bonsoir)
espie
In article <ktdnhn$bfg$, Patrick Lamaizière wrote:
ST :
On 2013-07-31, Cyrille Lefevre
<cyrille.lefevre-news% wrote:
C'est dans un contexte de production où faut que ça marche.
vous avez vraiment rien d'autre à dire que des conneries, c'est un forum sérieux, ici, bordel de merde ! ;^)
OpenBSD, j'adore aussi. Mais j'ai essayé une fois dans un contexte de production pour un firewall. La machine s'endormait toute seule de façon aléatoire, il fallait lui téléphoner sur son modem pour la réveiller.
en tant que pare-feu ici ça marche bien (depuis deux ans).
Depuis, en prod, c'est Linux, FreeBSD ou Solaris.
Y'a des bugs partout., Sauf que je ne trouve pas OpenBSD super réactif sur les pb...
Tiens une panique à l'instant en 5.3-STABLE/amd64 S'il y a des courageux...
panic: vinvalbuf: dirty bufs ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 vinvalbuf() at vinvalbuf+0xb1 ffs_unmout() at sys_unmout()+0x116 dounmout() at dounmout+0x88 sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
In article <ktdnhn$bfg$1@news.davenulle.org>,
Patrick Lamaizière <patnews1@davenulle.org> wrote:
C'est dans un contexte de production où faut que ça marche.
vous avez vraiment rien d'autre à dire que des conneries,
c'est un forum sérieux, ici, bordel de merde ! ;^)
OpenBSD, j'adore aussi. Mais j'ai essayé une fois dans un contexte de
production pour un firewall. La machine s'endormait toute seule de façon
aléatoire, il fallait lui téléphoner sur son modem pour la réveiller.
en tant que pare-feu ici ça marche bien (depuis deux ans).
Depuis, en prod, c'est Linux, FreeBSD ou Solaris.
Y'a des bugs partout., Sauf que je ne trouve pas OpenBSD super réactif
sur les pb...
Tiens une panique à l'instant en 5.3-STABLE/amd64
S'il y a des courageux...
panic: vinvalbuf: dirty bufs
ddb> trace
Debugger() at Debugger+0x5
panic() at panic+0xe4
vinvalbuf() at vinvalbuf+0xb1
ffs_unmout() at sys_unmout()+0x116
dounmout() at dounmout+0x88
sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des
écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
In article <ktdnhn$bfg$, Patrick Lamaizière wrote:
ST :
On 2013-07-31, Cyrille Lefevre
<cyrille.lefevre-news% wrote:
C'est dans un contexte de production où faut que ça marche.
vous avez vraiment rien d'autre à dire que des conneries, c'est un forum sérieux, ici, bordel de merde ! ;^)
OpenBSD, j'adore aussi. Mais j'ai essayé une fois dans un contexte de production pour un firewall. La machine s'endormait toute seule de façon aléatoire, il fallait lui téléphoner sur son modem pour la réveiller.
en tant que pare-feu ici ça marche bien (depuis deux ans).
Depuis, en prod, c'est Linux, FreeBSD ou Solaris.
Y'a des bugs partout., Sauf que je ne trouve pas OpenBSD super réactif sur les pb...
Tiens une panique à l'instant en 5.3-STABLE/amd64 S'il y a des courageux...
panic: vinvalbuf: dirty bufs ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 vinvalbuf() at vinvalbuf+0xb1 ffs_unmout() at sys_unmout()+0x116 dounmout() at dounmout+0x88 sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
ST
On 2013-08-05, Marc Espie wrote:
T'as evidemment bug-reporte comme il se doit ?
Une fois j'ai essayé, me suis fait engueulé (peut-etre bien par toi d'ailleurs), depuis j'ai laissé tombé OpenBSD (sauf pour m'amuser une fois de temps en temps sur une machine virtuelle).
Bon maintenant, un OS qui s'endort tout seul sur une machine de prod et qui se fait reveiller par un modem sur port série. On est plus dans le bug, on est dans le pre-alpha du systeme d'exploitation. Tu me feras pas croire que c'est un probleme de driver (surtout sur du DL-360, on peut pas plus standard comme serveur).
C'est dommage, j'aime bien OpenBSD. Il y a des trucs que je trouve bizarre quand meme, comme par exemple installer un fvwm par défaut pas à jour. Ré-écrire son propre générateur de page man au lieu d'utiliser Groff.
Par contre, j'aime bien l'initiative OpenSMTPd, c'est bien foutu, le concept est original. Bon j'ai pas testé le truc à fond, mais rien que ça, ça me donne des envies de tests. Je passe sur des trucs comme OpenSSH, ça c'est du top de chez top.
Bref, il y a du à prendre et à laisser. Mais je dois bientot installer un serveur un peu général (MX, WEB, backup, monitoring ...) me demande si je vais pas me laisser tenter par un OpenBSD, juste pour le fun. Risque pas grand chose à tester de toutes façons.
-- Je ne suis pas d'accord avec la vérité, en conséquence, je n'écris que des mensonges et des contre-vérités.
On 2013-08-05, Marc Espie <espie@lain.home> wrote:
T'as evidemment bug-reporte comme il se doit ?
Une fois j'ai essayé, me suis fait engueulé (peut-etre bien par toi
d'ailleurs), depuis j'ai laissé tombé OpenBSD (sauf pour m'amuser une
fois de temps en temps sur une machine virtuelle).
Bon maintenant, un OS qui s'endort tout seul sur une machine de prod et
qui se fait reveiller par un modem sur port série. On est plus dans le
bug, on est dans le pre-alpha du systeme d'exploitation. Tu me feras pas
croire que c'est un probleme de driver (surtout sur du DL-360, on peut
pas plus standard comme serveur).
C'est dommage, j'aime bien OpenBSD. Il y a des trucs que je trouve
bizarre quand meme, comme par exemple installer un fvwm par défaut pas à
jour. Ré-écrire son propre générateur de page man au lieu d'utiliser
Groff.
Par contre, j'aime bien l'initiative OpenSMTPd, c'est bien foutu, le
concept est original. Bon j'ai pas testé le truc à fond, mais rien que
ça, ça me donne des envies de tests. Je passe sur des trucs comme
OpenSSH, ça c'est du top de chez top.
Bref, il y a du à prendre et à laisser. Mais je dois bientot installer
un serveur un peu général (MX, WEB, backup, monitoring ...) me demande
si je vais pas me laisser tenter par un OpenBSD, juste pour le fun.
Risque pas grand chose à tester de toutes façons.
--
Je ne suis pas d'accord avec la vérité, en conséquence, je n'écris que
des mensonges et des contre-vérités.
Une fois j'ai essayé, me suis fait engueulé (peut-etre bien par toi d'ailleurs), depuis j'ai laissé tombé OpenBSD (sauf pour m'amuser une fois de temps en temps sur une machine virtuelle).
Bon maintenant, un OS qui s'endort tout seul sur une machine de prod et qui se fait reveiller par un modem sur port série. On est plus dans le bug, on est dans le pre-alpha du systeme d'exploitation. Tu me feras pas croire que c'est un probleme de driver (surtout sur du DL-360, on peut pas plus standard comme serveur).
C'est dommage, j'aime bien OpenBSD. Il y a des trucs que je trouve bizarre quand meme, comme par exemple installer un fvwm par défaut pas à jour. Ré-écrire son propre générateur de page man au lieu d'utiliser Groff.
Par contre, j'aime bien l'initiative OpenSMTPd, c'est bien foutu, le concept est original. Bon j'ai pas testé le truc à fond, mais rien que ça, ça me donne des envies de tests. Je passe sur des trucs comme OpenSSH, ça c'est du top de chez top.
Bref, il y a du à prendre et à laisser. Mais je dois bientot installer un serveur un peu général (MX, WEB, backup, monitoring ...) me demande si je vais pas me laisser tenter par un OpenBSD, juste pour le fun. Risque pas grand chose à tester de toutes façons.
-- Je ne suis pas d'accord avec la vérité, en conséquence, je n'écris que des mensonges et des contre-vérités.
Patrick Lamaizière
Marc Espie :
panic: vinvalbuf: dirty bufs ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 vinvalbuf() at vinvalbuf+0xb1 ffs_unmout() at sys_unmout()+0x116 dounmout() at dounmout+0x88 sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
Pas essayé, pas eu le temps et current n'est pas une option envisageable ici.
Marc Espie :
panic: vinvalbuf: dirty bufs
ddb> trace
Debugger() at Debugger+0x5
panic() at panic+0xe4
vinvalbuf() at vinvalbuf+0xb1
ffs_unmout() at sys_unmout()+0x116
dounmout() at dounmout+0x88
sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des
écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
Pas essayé, pas eu le temps et current n'est pas une option
envisageable ici.
panic: vinvalbuf: dirty bufs ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 vinvalbuf() at vinvalbuf+0xb1 ffs_unmout() at sys_unmout()+0x116 dounmout() at dounmout+0x88 sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
Pas essayé, pas eu le temps et current n'est pas une option envisageable ici.
Patrick Lamaizière
Marc Espie :
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement, mais que vous apportez pas votre petite pierre en disant ce qui deconne, vous ne servez a rien....
Ça ne sert pas à grand chose si 90% des pb sont ignorés...
Tiens le coup du carp demote sur pfsync depuis 5.2/5.3, c'est hyper discutable comme (nouveau) fonctionnement, et plusieurs personnes ont déjà signalé ça. J'ai du bricoler pour pallier à ça.
Sans compter que si c'est pour me dire d'essayer current (la réponse standard) je n'en ai tout simplement pas la possibilité en prod.
Ceci dit j'envoie quasi toujours un mail sur misc@ en cas de soucis.
(coup de gueule du soir, bonsoir)
du midi, ennui.
(Je me doute bien que c'est pas facile)
Marc Espie :
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement,
mais que vous apportez pas votre petite pierre en disant ce qui deconne,
vous ne servez a rien....
Ça ne sert pas à grand chose si 90% des pb sont ignorés...
Tiens le coup du carp demote sur pfsync depuis 5.2/5.3, c'est hyper
discutable comme (nouveau) fonctionnement, et plusieurs personnes ont
déjà signalé ça. J'ai du bricoler pour pallier à ça.
Sans compter que si c'est pour me dire d'essayer current (la réponse
standard) je n'en ai tout simplement pas la possibilité en prod.
Ceci dit j'envoie quasi toujours un mail sur misc@ en cas de soucis.
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement, mais que vous apportez pas votre petite pierre en disant ce qui deconne, vous ne servez a rien....
Ça ne sert pas à grand chose si 90% des pb sont ignorés...
Tiens le coup du carp demote sur pfsync depuis 5.2/5.3, c'est hyper discutable comme (nouveau) fonctionnement, et plusieurs personnes ont déjà signalé ça. J'ai du bricoler pour pallier à ça.
Sans compter que si c'est pour me dire d'essayer current (la réponse standard) je n'en ai tout simplement pas la possibilité en prod.
Ceci dit j'envoie quasi toujours un mail sur misc@ en cas de soucis.
(coup de gueule du soir, bonsoir)
du midi, ennui.
(Je me doute bien que c'est pas facile)
espie
In article <ktqnmk$bkt$, Patrick Lamaizière wrote:
Marc Espie :
panic: vinvalbuf: dirty bufs ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 vinvalbuf() at vinvalbuf+0xb1 ffs_unmout() at sys_unmout()+0x116 dounmout() at dounmout+0x88 sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
Pas essayé, pas eu le temps et current n'est pas une option envisageable ici.
J'ai bien dit 5.4, hein... la on a a peu pres fini la release, ce que tu trouves sur les serveurs est, a peu pres de facto, une 5.4.
In article <ktqnmk$bkt$1@news.davenulle.org>,
Patrick Lamaizière <patnews1@davenulle.org> wrote:
Marc Espie :
panic: vinvalbuf: dirty bufs
ddb> trace
Debugger() at Debugger+0x5
panic() at panic+0xe4
vinvalbuf() at vinvalbuf+0xb1
ffs_unmout() at sys_unmout()+0x116
dounmout() at dounmout+0x88
sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des
écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
Pas essayé, pas eu le temps et current n'est pas une option
envisageable ici.
J'ai bien dit 5.4, hein... la on a a peu pres fini la release, ce que
tu trouves sur les serveurs est, a peu pres de facto, une 5.4.
In article <ktqnmk$bkt$, Patrick Lamaizière wrote:
Marc Espie :
panic: vinvalbuf: dirty bufs ddb> trace Debugger() at Debugger+0x5 panic() at panic+0xe4 vinvalbuf() at vinvalbuf+0xb1 ffs_unmout() at sys_unmout()+0x116 dounmout() at dounmout+0x88 sys_unmout() at syscall+0x162
ça doit être parce que j'ai fais un umount -f alors qu'il y avait des écritures en cours (j'avais pas vu...) sur un périfphérique vnd:
Et en 5.4, ca donne quoi ?..
Pas essayé, pas eu le temps et current n'est pas une option envisageable ici.
J'ai bien dit 5.4, hein... la on a a peu pres fini la release, ce que tu trouves sur les serveurs est, a peu pres de facto, une 5.4.
espie
In article <ktqodn$cdu$, Patrick Lamaizière wrote:
Marc Espie :
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement, mais que vous apportez pas votre petite pierre en disant ce qui deconne, vous ne servez a rien....
Ça ne sert pas à grand chose si 90% des pb sont ignorés...
Tiens le coup du carp demote sur pfsync depuis 5.2/5.3, c'est hyper discutable comme (nouveau) fonctionnement, et plusieurs personnes ont déjà signalé ça. J'ai du bricoler pour pallier à ça.
Les problemes ne sont pratiquement jamais ignores, en fait... j'en ai aussi parle sur misc@ recemment (je crois), mais le plus souvent, c'est longuement discute en interne, et teste... parfois les fix sont complexes.
Parlant pour ma pomme, j'ai un backlog de bugs sur make, pkg_add et autres... certains sont assez croquignolesques pour reclamer de la reecriture de gros bouts de code... et donc plein de tests.
Par exemple, je sais que pkg_add -u se vautre si la hierarchie de fichiers change suffisamment (repertoire qui devient lien symbolique sur un fichier et assimile), mais ca reclame d'entierement reecrire Vstat.pm pour avoir deux layers separes, refaire le fold de layers convenablement pour que ca explose pas en memoire, et retester tous les cas tordus.
Ou 'make update-plist' qui craque completement vis-a-vis des multi-packages plus SUBST_CMD zarbi. La-aussi reecriture complete.
La "lenteur" du developpement correspond aussi a eviter d'introduire d'autres regressions en voulant reparer un probleme... mais les problemes ne sont pas ignores!
In article <ktqodn$cdu$1@news.davenulle.org>,
Patrick Lamaizière <patnews1@davenulle.org> wrote:
Marc Espie :
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement,
mais que vous apportez pas votre petite pierre en disant ce qui deconne,
vous ne servez a rien....
Ça ne sert pas à grand chose si 90% des pb sont ignorés...
Tiens le coup du carp demote sur pfsync depuis 5.2/5.3, c'est hyper
discutable comme (nouveau) fonctionnement, et plusieurs personnes ont
déjà signalé ça. J'ai du bricoler pour pallier à ça.
Les problemes ne sont pratiquement jamais ignores, en fait... j'en ai
aussi parle sur misc@ recemment (je crois), mais le plus souvent, c'est
longuement discute en interne, et teste... parfois les fix sont complexes.
Parlant pour ma pomme, j'ai un backlog de bugs sur make, pkg_add et autres...
certains sont assez croquignolesques pour reclamer de la reecriture de
gros bouts de code... et donc plein de tests.
Par exemple, je sais que pkg_add -u se vautre si la hierarchie de fichiers
change suffisamment (repertoire qui devient lien symbolique sur un fichier
et assimile), mais ca reclame d'entierement reecrire Vstat.pm pour avoir
deux layers separes, refaire le fold de layers convenablement pour que
ca explose pas en memoire, et retester tous les cas tordus.
Ou 'make update-plist' qui craque completement vis-a-vis des multi-packages
plus SUBST_CMD zarbi. La-aussi reecriture complete.
La "lenteur" du developpement correspond aussi a eviter d'introduire d'autres
regressions en voulant reparer un probleme... mais les problemes ne sont
pas ignores!
In article <ktqodn$cdu$, Patrick Lamaizière wrote:
Marc Espie :
donc du coup, si vous essayez Open une fois, que ca marche pas parfaitement, mais que vous apportez pas votre petite pierre en disant ce qui deconne, vous ne servez a rien....
Ça ne sert pas à grand chose si 90% des pb sont ignorés...
Tiens le coup du carp demote sur pfsync depuis 5.2/5.3, c'est hyper discutable comme (nouveau) fonctionnement, et plusieurs personnes ont déjà signalé ça. J'ai du bricoler pour pallier à ça.
Les problemes ne sont pratiquement jamais ignores, en fait... j'en ai aussi parle sur misc@ recemment (je crois), mais le plus souvent, c'est longuement discute en interne, et teste... parfois les fix sont complexes.
Parlant pour ma pomme, j'ai un backlog de bugs sur make, pkg_add et autres... certains sont assez croquignolesques pour reclamer de la reecriture de gros bouts de code... et donc plein de tests.
Par exemple, je sais que pkg_add -u se vautre si la hierarchie de fichiers change suffisamment (repertoire qui devient lien symbolique sur un fichier et assimile), mais ca reclame d'entierement reecrire Vstat.pm pour avoir deux layers separes, refaire le fold de layers convenablement pour que ca explose pas en memoire, et retester tous les cas tordus.
Ou 'make update-plist' qui craque completement vis-a-vis des multi-packages plus SUBST_CMD zarbi. La-aussi reecriture complete.
La "lenteur" du developpement correspond aussi a eviter d'introduire d'autres regressions en voulant reparer un probleme... mais les problemes ne sont pas ignores!
Patrick Lamaizière
Marc Espie :
Pas essayé, pas eu le temps et current n'est pas une option envisageable ici.
J'ai bien dit 5.4, hein... la on a a peu pres fini la release, ce que tu trouves sur les serveurs est, a peu pres de facto, une 5.4.
La politique de la maison c'est d'être en release - 1. La j'ai passé en 5.3+erratas vu qu'elle a un peu de bouteille (mai déjà).
C'est pas quand n'a pas confiance :) mais c'est les pare-feu du boulot et je ne peux pas m'amuser avec, ni même tester sur une maquette vu le trafic qui passe.
Pour le problème cité j'essaierais de le reproduire après les vacances en 5.4.
Marc Espie :
Pas essayé, pas eu le temps et current n'est pas une option
envisageable ici.
J'ai bien dit 5.4, hein... la on a a peu pres fini la release, ce que
tu trouves sur les serveurs est, a peu pres de facto, une 5.4.
La politique de la maison c'est d'être en release - 1. La j'ai passé en
5.3+erratas vu qu'elle a un peu de bouteille (mai déjà).
C'est pas quand n'a pas confiance :) mais c'est les pare-feu du boulot
et je ne peux pas m'amuser avec, ni même tester sur une maquette vu le
trafic qui passe.
Pour le problème cité j'essaierais de le reproduire après les vacances
en 5.4.
Pas essayé, pas eu le temps et current n'est pas une option envisageable ici.
J'ai bien dit 5.4, hein... la on a a peu pres fini la release, ce que tu trouves sur les serveurs est, a peu pres de facto, une 5.4.
La politique de la maison c'est d'être en release - 1. La j'ai passé en 5.3+erratas vu qu'elle a un peu de bouteille (mai déjà).
C'est pas quand n'a pas confiance :) mais c'est les pare-feu du boulot et je ne peux pas m'amuser avec, ni même tester sur une maquette vu le trafic qui passe.
Pour le problème cité j'essaierais de le reproduire après les vacances en 5.4.
