(J'espère qu'on vous l'a jamais faite, et que dans ce cas vous vous
rapellerez que c'est moi qui en suis l'auteur)
Bon, on a dit <sérieux>
Ma config actuelle: Woody/stable et Win 98SE, Athlon à 2GHz, RAM 512, 2
DD, 1 graveur et 1 lecteur de DVD
1) Free ou Net ?
J'ai vu sur le ng (VD il y a 4 jours, à propos d'un G4) que NetBSD
aurait «l'émulation linux».
Qu'est ce que ça signifie ?
Qu'on peut utiliser des applis dans le usr du pingouin qu'on monterait
dans le root de NetBSD ?
Dans la section 2.9.9 du HandBook de Free, il est dit «...will allow
running Linux software on FreeBSD.» et je sais qu'on peut compiler en
dur dans le noyau de FriBi, le support de l'ext2 pour monter mon home.
Alors Free ou Net ?
2) Les ports ?
Si j'ai bien compris, c'est ainsi qu'on appelle les sources des
applications en y ajoutant une gestion des dépendances et une
automatisation de l'installation et des upgrades. J'ai bon ?
(D'ailleurs en RTFMant, j'ai appris que les packages binaires étaient
plus petits que les sources, c'est marrant j'ai toujours été persuadé
du contraire. Quelqu'un explique ?)
3) Bootloader ?
La section 2.5.3 du handbook n'est pas très claire. Si j'installe le
boot manager de FreeBSD, est-ce qu'il me proposera de gérer mon win et
mon tux ?
Faut-il au contraire choisir "Leave the MBR untouched" ? Et dans ce cas,
est-il possible de configurer mon lilo pour booter FriBi ?
4) Taille des slices ?
J'ai pas très bien compris la distinction entre une partition et un
slice...
Pour la 'a', c'est OK: 100 MB.
Pour la 'b', ils disent 2 x RAM (comme tux donc), mais ça me paraît
énorme. Sous linux, j'ai 2 partitions de swap de 128 MB et jamais je ne
les remplis à plus de 20 %. Est-ce pareil sous *BSD ou est-il impératif
d'avoir 1 GB de swap ?
Est-il possible d'utiliser l'espace disque des partitions de swap de
linux pour y monter les partitions de swap de *BSD ?
Pour la 'e', OK.
Pour /usr, quelle taille prévoir ? Sous Linux, il fait 2 GB, mais je
pense y aller calmement au départ et j'imagine qu'il y a un outil pour
redimensionner les partitions si nécessaire.
5) AfterStep ?
Est-ce qu'il a été porté sous FriBi ?
J'ai les sources Linux, je peux le recompiler sans modif ?
Si oui est-ce généralisable à toutes les applis dont j'ai les sources ?
6) Mais où est passé TP ?
Je croyais que ce cher Pinuche était passé du coté du daemon, mais je ne
le voie pas fréquenter ce ng depuis 15 jours que je le lis. Qui a des
nouvelles ?
</sérieux>
Vous savez quoi ? 'BSD' est dans le dico américain et pas 'SysV'.
(cf <slrnbtehom.1fs.hugolino@localhost.localdomain>)
--
> Allez, soyez sympa ... traduisez-lui "linux"
Linux, c'est comme le miel : c'est vachement bon mais ça attire les
mouches. En plus, ça colle aux doigts et on a du mal à s'en défaire.
-+- TP in: Guide du linuxien pervers - "Barrez vous les mouches !"
Il est possible de mettre aussi peu de swap que l'on le désire. Cependant, dans l'hypothèse absurde où l'on souhaiterai pouvoir obtenir un coredump de son noyau après un malheureux plantage, il est nécessaire que la taille du slice de dump, qui est aussi celui de swap principal, soit supérieure à la quantité de mémoire de la machine.
Tiens, en parlant du dump du kernel, il faut qu'un slice contenant le swap soit au moins aussi grand que la mémoire, ou il suffit simplement que le total des slices de swap soit sup ou égal à la mémoire ?
Parce que j'ai trois disques, j'ai évidemment réparti le swap sur les trois, mais aucun slice de swap ne fait la taille de la mémoire (512 Mo de RAM, et trois slices de 256 Mo chacun). Qu'est-ce qui se passera en cas de dump du kernel (cas hautement improbable, j'en conviens) ?
D'ailleurs, c'est toute la mémoire qui est dumpée, ou simplement le kernel ?
-- Mais comment vous faites pour en trouver des comme ça ? Pourquoi moi ça ne m'arrive jamais ? -+- SP in GNU : le lecteur de news a mal configuré son neuneu -+-
Il est possible de mettre aussi peu de swap que l'on le désire.
Cependant, dans l'hypothèse absurde où l'on souhaiterai pouvoir obtenir
un coredump de son noyau après un malheureux plantage, il est nécessaire
que la taille du slice de dump, qui est aussi celui de swap principal,
soit supérieure à la quantité de mémoire de la machine.
Tiens, en parlant du dump du kernel, il faut qu'un slice contenant
le swap soit au moins aussi grand que la mémoire, ou il suffit
simplement que le total des slices de swap soit sup ou égal à la
mémoire ?
Parce que j'ai trois disques, j'ai évidemment réparti le swap sur
les trois, mais aucun slice de swap ne fait la taille de la mémoire
(512 Mo de RAM, et trois slices de 256 Mo chacun). Qu'est-ce qui se
passera en cas de dump du kernel (cas hautement improbable, j'en
conviens) ?
D'ailleurs, c'est toute la mémoire qui est dumpée, ou simplement le
kernel ?
--
Mais comment vous faites pour en trouver des comme ça ?
Pourquoi moi ça ne m'arrive jamais ?
-+- SP in GNU : le lecteur de news a mal configuré son neuneu -+-
Il est possible de mettre aussi peu de swap que l'on le désire. Cependant, dans l'hypothèse absurde où l'on souhaiterai pouvoir obtenir un coredump de son noyau après un malheureux plantage, il est nécessaire que la taille du slice de dump, qui est aussi celui de swap principal, soit supérieure à la quantité de mémoire de la machine.
Tiens, en parlant du dump du kernel, il faut qu'un slice contenant le swap soit au moins aussi grand que la mémoire, ou il suffit simplement que le total des slices de swap soit sup ou égal à la mémoire ?
Parce que j'ai trois disques, j'ai évidemment réparti le swap sur les trois, mais aucun slice de swap ne fait la taille de la mémoire (512 Mo de RAM, et trois slices de 256 Mo chacun). Qu'est-ce qui se passera en cas de dump du kernel (cas hautement improbable, j'en conviens) ?
D'ailleurs, c'est toute la mémoire qui est dumpée, ou simplement le kernel ?
-- Mais comment vous faites pour en trouver des comme ça ? Pourquoi moi ça ne m'arrive jamais ? -+- SP in GNU : le lecteur de news a mal configuré son neuneu -+-
Miod Vallat
Tiens, en parlant du dump du kernel, il faut qu'un slice contenant le swap soit au moins aussi grand que la mémoire, ou il suffit simplement que le total des slices de swap soit sup ou égal à la mémoire ?
Il n'y a qu'une seule zone de dump, et il s'agit de la première zone de swap - sauf à configurer son noyau explicitement pour avoir une zone de dump différente, chose que personne ne fait depuis belle lurette...
Donc : pas moyen de tricher en rajoutant une autre zone de swap après avoir rajouté une barette...
Parce que j'ai trois disques, j'ai évidemment réparti le swap sur les trois, mais aucun slice de swap ne fait la taille de la mémoire (512 Mo de RAM, et trois slices de 256 Mo chacun). Qu'est-ce qui se passera en cas de dump du kernel (cas hautement improbable, j'en conviens) ?
Il y aura un dump incomplet, que savecore ne peut pas gérer proprement.
D'ailleurs, c'est toute la mémoire qui est dumpée, ou simplement le kernel ?
Toute la mémoire addressable par le noyau. On y retrouve le noyau dedans, du coup...
Tiens, en parlant du dump du kernel, il faut qu'un slice contenant
le swap soit au moins aussi grand que la mémoire, ou il suffit
simplement que le total des slices de swap soit sup ou égal à la
mémoire ?
Il n'y a qu'une seule zone de dump, et il s'agit de la première zone de
swap - sauf à configurer son noyau explicitement pour avoir une zone de
dump différente, chose que personne ne fait depuis belle lurette...
Donc : pas moyen de tricher en rajoutant une autre zone de swap après
avoir rajouté une barette...
Parce que j'ai trois disques, j'ai évidemment réparti le swap sur
les trois, mais aucun slice de swap ne fait la taille de la mémoire
(512 Mo de RAM, et trois slices de 256 Mo chacun). Qu'est-ce qui se
passera en cas de dump du kernel (cas hautement improbable, j'en
conviens) ?
Il y aura un dump incomplet, que savecore ne peut pas gérer proprement.
D'ailleurs, c'est toute la mémoire qui est dumpée, ou simplement le
kernel ?
Toute la mémoire addressable par le noyau. On y retrouve le noyau
dedans, du coup...
Tiens, en parlant du dump du kernel, il faut qu'un slice contenant le swap soit au moins aussi grand que la mémoire, ou il suffit simplement que le total des slices de swap soit sup ou égal à la mémoire ?
Il n'y a qu'une seule zone de dump, et il s'agit de la première zone de swap - sauf à configurer son noyau explicitement pour avoir une zone de dump différente, chose que personne ne fait depuis belle lurette...
Donc : pas moyen de tricher en rajoutant une autre zone de swap après avoir rajouté une barette...
Parce que j'ai trois disques, j'ai évidemment réparti le swap sur les trois, mais aucun slice de swap ne fait la taille de la mémoire (512 Mo de RAM, et trois slices de 256 Mo chacun). Qu'est-ce qui se passera en cas de dump du kernel (cas hautement improbable, j'en conviens) ?
Il y aura un dump incomplet, que savecore ne peut pas gérer proprement.
D'ailleurs, c'est toute la mémoire qui est dumpée, ou simplement le kernel ?
Toute la mémoire addressable par le noyau. On y retrouve le noyau dedans, du coup...
talon
Philippe Chevalier wrote:
Enfin, a moins que tu n'ais envie de debugger le kernel et les applis pour savoir ce qui a crashe et que tu as les competences pour, sincerement ca ne sert a rien. Quant a les envoyer aux developpeurs pour qu'ils debuggent a ta place, hin hin hin... "c'est des benevoles donc ils n'ont pas a se pencher sur les problemes du premier venu".
Donc autant desactiver le dump, ca ne t'empechera pas de dormir.
Je ne veux pas enfoncer le clou, mais pour un utilisateur du libre, tu m'as l'air de faire preuve d'un égoisme assez phénoménal. Disposer du système BSD qui permet d'obtenir facilement des crash dumps et de les analyser avec gdb (compare à la situation sous Linux) et en faire fi, ça me paraît assez paradoxal. Effectivement ça suppose d'avoir un swap contigu plus grand que la mémoire. Au prix des disques durs, chipoter sur ce genre de choses est à mon avis ridicule. Ce qui est dommage c'est de ne pas utiliser le même swap pour Linux et FreeBSD quand on dual boote. La configuration qui marche bien:
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
K.
--
Michel TALON
Philippe Chevalier <news@kyoko.org> wrote:
Enfin, a moins que tu n'ais envie de debugger le kernel et les applis
pour savoir ce qui a crashe et que tu as les competences pour,
sincerement ca ne sert a rien. Quant a les envoyer aux developpeurs pour
qu'ils debuggent a ta place, hin hin hin... "c'est des benevoles donc
ils n'ont pas a se pencher sur les problemes du premier venu".
Donc autant desactiver le dump, ca ne t'empechera pas de dormir.
Je ne veux pas enfoncer le clou, mais pour un utilisateur du libre, tu
m'as l'air de faire preuve d'un égoisme assez phénoménal. Disposer du
système BSD qui permet d'obtenir facilement des crash dumps et de les
analyser avec gdb (compare à la situation sous Linux) et en faire fi, ça
me paraît assez paradoxal.
Effectivement ça suppose d'avoir un swap contigu plus grand que la
mémoire. Au prix des disques durs, chipoter sur ce genre de choses est à
mon avis ridicule. Ce qui est dommage c'est de ne pas utiliser le même
swap pour Linux et FreeBSD quand on dual boote.
La configuration qui marche bien:
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas
en faire la première partition de ad0s1 (sinon les mkswap ultérieurs
bouzilleront le label). Cette partition sera vue comme hda5 sous Linux
par exemple (prévoir un noyau avec support des labels BSD). Il suffit de
repérer dans les scripts de démrrage de Linux là où se trouve le swapon
et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans
*aucun* souci.
Enfin, a moins que tu n'ais envie de debugger le kernel et les applis pour savoir ce qui a crashe et que tu as les competences pour, sincerement ca ne sert a rien. Quant a les envoyer aux developpeurs pour qu'ils debuggent a ta place, hin hin hin... "c'est des benevoles donc ils n'ont pas a se pencher sur les problemes du premier venu".
Donc autant desactiver le dump, ca ne t'empechera pas de dormir.
Je ne veux pas enfoncer le clou, mais pour un utilisateur du libre, tu m'as l'air de faire preuve d'un égoisme assez phénoménal. Disposer du système BSD qui permet d'obtenir facilement des crash dumps et de les analyser avec gdb (compare à la situation sous Linux) et en faire fi, ça me paraît assez paradoxal. Effectivement ça suppose d'avoir un swap contigu plus grand que la mémoire. Au prix des disques durs, chipoter sur ce genre de choses est à mon avis ridicule. Ce qui est dommage c'est de ne pas utiliser le même swap pour Linux et FreeBSD quand on dual boote. La configuration qui marche bien:
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
K.
--
Michel TALON
fred
Michel Talon wrote:
[snip]
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
-- FP.
Michel Talon wrote:
[snip]
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas
en faire la première partition de ad0s1 (sinon les mkswap ultérieurs
bouzilleront le label). Cette partition sera vue comme hda5 sous Linux
par exemple (prévoir un noyau avec support des labels BSD). Il suffit de
repérer dans les scripts de démrrage de Linux là où se trouve le swapon
et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans
*aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il
pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot,
j'ai peur que ça soit un peu longuet.
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
-- FP.
Nicolas Le Scouarnec
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Pas trop, je pense.
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
C'est pas très long un mkswap, de mémoire, ca doit prendre 1 seconde. Et puis, 1 secondes, c'est rien, entre les différents menu pour choisir les options au boot, j'ai 45 secondes si je laisse défiler.
Voila.
/a/stang#time mkswap swapfile Configuration de l'espace d'échange version 1, taille = 67104768 octets
real 0m0.092s
0.092s pour 64 Mo.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Faire un mkswap à chaque boot ne rallentit-il
pas un tantinet le boot justement ?
Pas trop, je pense.
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot,
j'ai peur que ça soit un peu longuet.
C'est pas très long un mkswap, de mémoire, ca doit prendre 1 seconde.
Et puis, 1 secondes, c'est rien, entre les différents menu pour choisir
les options au boot, j'ai 45 secondes si je laisse défiler.
Voila.
/a/stang#time mkswap swapfile
Configuration de l'espace d'échange version 1, taille = 67104768 octets
real 0m0.092s
0.092s pour 64 Mo.
--
Nicolas Le Scouarnec
http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Pas trop, je pense.
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
C'est pas très long un mkswap, de mémoire, ca doit prendre 1 seconde. Et puis, 1 secondes, c'est rien, entre les différents menu pour choisir les options au boot, j'ai 45 secondes si je laisse défiler.
Voila.
/a/stang#time mkswap swapfile Configuration de l'espace d'échange version 1, taille = 67104768 octets
real 0m0.092s
0.092s pour 64 Mo.
-- Nicolas Le Scouarnec http://nlsn.free.fr (Slrnfr, Docs Linux/BSD, La grippe, ... )
Ralph-
Philippe Chevalier wrote:
On Wed, 14 Jan 2004 10:21:26 +0000 (UTC), Michel Talon sieu.fr> wrote:
Je ne veux pas enfoncer le clou, mais pour un utilisateur du libre, tu m'as l'air de faire preuve d'un égoisme assez phénoménal. Dispose r du système BSD qui permet d'obtenir facilement des crash dumps et de les analyser avec gdb (compare à la situation sous Linux) et en faire fi, ça me paraît assez paradoxal.
Je ne suis pas "egoiste". Je suis realiste.
Analysons le cas de l'utilisateur "lambda" (pas les augustes developpeu rs ici presents)
Premier point... Des utilisateurs "lambda", tu crois qu'il y a en des tonnes ici ? Deja que sous Linux faut etre un minimum motivé pour y rester apres un passage souvent "douloureux" pour ce genre d'utilisateur alors bon, soit il s'accroche soit bah, il retourne sous un autre OS. Etant donné que (malheureusement) y'a plus de pingouin que de demons (ca rejoint mon post, personne pour connait un BUG dans le Nord ?), je ne pense pas qu'il y a des millions de "lamdba" user .. On est pas sous Windows.. =)
Admettons que notre utilisateur nouveaubie crashe sa machine et se retrouve avec un zoli dump. Que va t'il en faire ?
Lancer gdb sur le bouzin et tenter de comprendre ce qui a merde ?
Il va essayer, rien comprendre et finalement effacer la chose parce que ca prend de la place dans /var (ne pas oublier /var qui doit etre taill e pour accueuillir le dump) et qu'entre temps, ben la machine fonctionne et le probleme ne s'est pas reproduit.
Ca risque fort, car a moins de recompiler tout son BSD en Debug, direct gdb, ca va etre "dur" pour "lambda".. Au fait, cet utilisateur connait gdb ? Il a l'air moins basique que prevu cet utilisateur..
Admettons que le probleme se reproduise systematiquement. Notre utilisateur est bien emmerde et va donc tenter de contacter les developpeurs, soit par mail, soit sur une ML, ou un NG.
Mail sur une ML ou un NG : son probleme va rencontrer un silence sideral, vu que personne ou presque sur la liste n'est competent sur le sujet et que de toute facon, il n'a pas fourni assez de details (c'est un nouveaubie). S'il fournit tous les details, c'est encore pire. Admettons qu'une personne competente lise son appel au secours et lui demande des precisions, je doute TRES FORT que cette personne lui demande de lui fournir son dump. Pas que ca a fout' non plus.
"Personne n'est competent": tu y tiens a ce toi... Ca me rappelle une histoire de traffic shapping et ipfw.. Je susi desole, les dev que j'ai contacté suite a ce genre de probleme m'ont repondu.. D'un autre coté, je ne vais pas prendre mon cas pour une generalité alors je te conseille de faire de meme!
Mail direct aux developpeurs : ca va venir s'empiler dans la boite que les developpeurs lisent quand ils ont le temps (parce que y a vraiment trop de questions cons posees par mail, ca finit par lasser). Admettons qu'il tombe sur un developpeur motive et competent : ca va commencer par une serie de mail avec des questions basiques, pour bien verifier que le nouveaubie ne s'est pas plante qq part, etc... pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Ca je trouve ca baleze.. En quoi le fait de ne pas garder le dump rendrait sa machine en etat de marche.. Tu melanges tout la... Tu sous entends qu'avec un dump ca va trainer etc etc.. Je vois pas en quoi SANS ca irait plus vite hein ? J'ai peut etre raté un episode, faudrait que tu expliques..
Puis le developpeur, ne comprenant pas ce qui ne marche pas (il n'arrive pas a reproduire le probleme, c'est bete mais il n'a pas la meme conf materielle), va finir par demander le dump afin de l'analyser. Apres plusieurs jours de ping pong de mail pour savoir comment mettre a disposition un fichier de 1Go quelque part, le developpeur va enfin avoir le dump a dispo. Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Donc le dump est dans un coin du disque du Gentil Developpeur Benevole.
Bon ben c'est pas tout ca hein, mais ya le vrai boulot qui est la, l'ecole, les cours, la femme, les gosses, whatever et bon... Pas que ca a fout' non plus. Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Au bout de X temps, le GDB (Gentil Developpeur Benevole, tiens bon acronyme ca), soyons optimiste, va _peut etre_ arriver a trouver ce qui ne va pas. S'il est competent et motive. Et _peut etre_ trouver un workaround ou un correctif. Qui fera son chemin dans le CVS et dans la validation etc pendant... oula... quelques semaines. Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Des semaines ? T'es sur de pas te tromper de systeme la ? Tu nous parles de SunOS la ? Parce que niveau reactivité, j'ai aussi l'impressi on que tu melanges tout..
Etc, etc...
Les chances pour que le probleme d'un utilisateur lambda soit resolu dans des temps raisonnables sont proches de zero. Donc le dump, il aurait pu se le rouler et se le fumer, ca aurait ete pareil.
En effet, avec ou sans, le fait que sa machine refonctionne (et encore je te trouve bien vague dans la definition de cette idée de "fonction- -nement"), c'est un peu pareil.. La difference, c'est que tu t'impliques dans un processus de remonte de probleme, tu restes pas passif.. Tu m'as (et pas qu'a moins a priori) d'etre un sacré consommateur toi, pas acteur
Le seul cas ou je vois que les choses peuvent aller VITE, c'est lorsque des masses d'utilisateurs sont bloques par le meme probleme et que ca finit par faire du bruit. Donc, la, forcement, les developpeurs s'agitent et sortent un patch en urgence. Mais la en general, ils ont leur propre dump et sont capable de reproduire le probleme. Pas la pein e d'avoir 500 dumps differents non plus.
Alors c'est sur que M. Talon, M. Espie, M. Dreyfuss ou M. Valat auront l'utilite d'un dump s'ils rencontrent un probleme sur leurs machines.
Sont pas les seuls hein ;)
Mais du point de vue du nouveaubie, il aura plus vite fait de changer d e machine, voire d'OS avant d'avoir une utilite de son Gigo de dump.
Et si c'est un plantage ponctuel qui arrive tous les 36 du mois pour un e raison inconnue (les taches solaires, l'humidite ambiante, la radioactivite qui est partout (merci Stan Lee)), il aura plus vite fait d'effacer le dump et de ne rien faire plutot que de se plonger dans les affres de gdb ou des GDB. Pas que ca a fout' non plus.
Mon avis final est donc : meme si on peut prevoir l'espace pour le crash dump, AMHA c'est inutile de l'activer parce que les chances que l e dump ait une utilite sont proches de zero _pour un utilisateur ordinaire_.
Et ca n'a rien de specifique aux BSD, rassurez vous.
En effet, depuis Xp on envoie (si on laisse par defaut) les dumps des crashs, mais je te vois venir... Windows je le payes, blah,blah... support blah blah.. (A moins que tu ais une version non OEM, tu n'as pas le support direct de MS, mais plutot Packard Bell etc etc..). Bah, on attends (enfin non, je m'en cogne moi perso) le fix d'url spooffing dans IE qui fait la joie de tous les scammers depuis plus d'un mois...
Bon ok, c'est pas du realisme, c'est du cynisme.
Non, on rigole bien, car t'es vraiment a coté de la plaque et surtout de l'esprit des BSD...
K.
Philippe Chevalier wrote:
On Wed, 14 Jan 2004 10:21:26 +0000 (UTC), Michel Talon <talon@lpthe.jus sieu.fr> wrote:
Je ne veux pas enfoncer le clou, mais pour un utilisateur du libre, tu
m'as l'air de faire preuve d'un égoisme assez phénoménal. Dispose r du
système BSD qui permet d'obtenir facilement des crash dumps et de les
analyser avec gdb (compare à la situation sous Linux) et en faire fi, ça
me paraît assez paradoxal.
Je ne suis pas "egoiste". Je suis realiste.
Analysons le cas de l'utilisateur "lambda" (pas les augustes developpeu rs
ici presents)
Premier point... Des utilisateurs "lambda", tu crois qu'il y a en des
tonnes ici ? Deja que sous Linux faut etre un minimum motivé pour y
rester apres un passage souvent "douloureux" pour ce genre d'utilisateur
alors bon, soit il s'accroche soit bah, il retourne sous un autre OS.
Etant donné que (malheureusement) y'a plus de pingouin que de demons
(ca rejoint mon post, personne pour connait un BUG dans le Nord ?), je
ne pense pas qu'il y a des millions de "lamdba" user .. On est pas sous
Windows.. =)
Admettons que notre utilisateur nouveaubie crashe sa machine et se
retrouve avec un zoli dump. Que va t'il en faire ?
Lancer gdb sur le bouzin et tenter de comprendre ce qui a merde ?
Il va essayer, rien comprendre et finalement effacer la chose parce que
ca prend de la place dans /var (ne pas oublier /var qui doit etre taill e
pour accueuillir le dump) et qu'entre temps, ben la machine fonctionne
et le probleme ne s'est pas reproduit.
Ca risque fort, car a moins de recompiler tout son BSD en Debug,
direct gdb, ca va etre "dur" pour "lambda".. Au fait, cet utilisateur
connait gdb ? Il a l'air moins basique que prevu cet utilisateur..
Admettons que le probleme se reproduise systematiquement. Notre
utilisateur est bien emmerde et va donc tenter de contacter les
developpeurs, soit par mail, soit sur une ML, ou un NG.
Mail sur une ML ou un NG : son probleme va rencontrer un silence
sideral, vu que personne ou presque sur la liste n'est competent sur le
sujet et que de toute facon, il n'a pas fourni assez de details (c'est
un nouveaubie). S'il fournit tous les details, c'est encore pire.
Admettons qu'une personne competente lise son appel au secours et lui
demande des precisions, je doute TRES FORT que cette personne lui
demande de lui fournir son dump. Pas que ca a fout' non plus.
"Personne n'est competent": tu y tiens a ce toi... Ca me rappelle
une histoire de traffic shapping et ipfw.. Je susi desole, les dev
que j'ai contacté suite a ce genre de probleme m'ont repondu.. D'un
autre coté, je ne vais pas prendre mon cas pour une generalité alors
je te conseille de faire de meme!
Mail direct aux developpeurs : ca va venir s'empiler dans la boite que
les developpeurs lisent quand ils ont le temps (parce que y a vraiment
trop de questions cons posees par mail, ca finit par lasser). Admettons
qu'il tombe sur un developpeur motive et competent : ca va commencer
par une serie de mail avec des questions basiques, pour bien verifier
que le nouveaubie ne s'est pas plante qq part, etc... pendant ce temps,
le nouveaubie n'a pas de machine en etat de marche.
Ca je trouve ca baleze.. En quoi le fait de ne pas garder le dump
rendrait sa machine en etat de marche.. Tu melanges tout la...
Tu sous entends qu'avec un dump ca va trainer etc etc.. Je vois pas
en quoi SANS ca irait plus vite hein ? J'ai peut etre raté un episode,
faudrait que tu expliques..
Puis le developpeur, ne comprenant pas ce qui ne marche pas (il
n'arrive pas a reproduire le probleme, c'est bete mais il n'a pas
la meme conf materielle), va finir par demander le dump afin de
l'analyser. Apres plusieurs jours de ping pong de mail pour savoir
comment mettre a disposition un fichier de 1Go quelque part, le
developpeur va enfin avoir le dump a dispo. Pendant ce temps, le
nouveaubie n'a pas de machine en etat de marche.
Donc le dump est dans un coin du disque du Gentil Developpeur Benevole.
Bon ben c'est pas tout ca hein, mais ya le vrai boulot qui est la,
l'ecole, les cours, la femme, les gosses, whatever et bon... Pas que ca
a fout' non plus. Pendant ce temps, le nouveaubie n'a pas de machine en
etat de marche.
Au bout de X temps, le GDB (Gentil Developpeur Benevole, tiens bon
acronyme ca), soyons optimiste, va _peut etre_ arriver a trouver
ce qui ne va pas. S'il est competent et motive. Et _peut etre_
trouver un workaround ou un correctif. Qui fera son chemin dans le
CVS et dans la validation etc pendant... oula... quelques semaines.
Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Des semaines ? T'es sur de pas te tromper de systeme la ? Tu nous
parles de SunOS la ? Parce que niveau reactivité, j'ai aussi l'impressi on
que tu melanges tout..
Etc, etc...
Les chances pour que le probleme d'un utilisateur lambda soit resolu
dans des temps raisonnables sont proches de zero. Donc le dump, il
aurait pu se le rouler et se le fumer, ca aurait ete pareil.
En effet, avec ou sans, le fait que sa machine refonctionne (et encore
je te trouve bien vague dans la definition de cette idée de "fonction-
-nement"), c'est un peu pareil.. La difference, c'est que tu t'impliques
dans un processus de remonte de probleme, tu restes pas passif..
Tu m'as (et pas qu'a moins a priori) d'etre un sacré consommateur toi, pas
acteur
Le seul cas ou je vois que les choses peuvent aller VITE, c'est lorsque
des masses d'utilisateurs sont bloques par le meme probleme et que ca
finit par faire du bruit. Donc, la, forcement, les developpeurs
s'agitent et sortent un patch en urgence. Mais la en general, ils ont
leur propre dump et sont capable de reproduire le probleme. Pas la pein e
d'avoir 500 dumps differents non plus.
Alors c'est sur que M. Talon, M. Espie, M. Dreyfuss ou M. Valat auront
l'utilite d'un dump s'ils rencontrent un probleme sur leurs machines.
Sont pas les seuls hein ;)
Mais du point de vue du nouveaubie, il aura plus vite fait de changer d e
machine, voire d'OS avant d'avoir une utilite de son Gigo de dump.
Et si c'est un plantage ponctuel qui arrive tous les 36 du mois pour un e
raison inconnue (les taches solaires, l'humidite ambiante, la
radioactivite qui est partout (merci Stan Lee)), il aura plus vite fait
d'effacer le dump et de ne rien faire plutot que de se plonger dans les
affres de gdb ou des GDB. Pas que ca a fout' non plus.
Mon avis final est donc : meme si on peut prevoir l'espace pour le
crash dump, AMHA c'est inutile de l'activer parce que les chances que l e
dump ait une utilite sont proches de zero _pour un utilisateur
ordinaire_.
Et ca n'a rien de specifique aux BSD, rassurez vous.
En effet, depuis Xp on envoie (si on laisse par defaut) les dumps des
crashs, mais je te vois venir... Windows je le payes, blah,blah...
support blah blah.. (A moins que tu ais une version non OEM, tu n'as
pas le support direct de MS, mais plutot Packard Bell etc etc..).
Bah, on attends (enfin non, je m'en cogne moi perso) le fix d'url
spooffing dans IE qui fait la joie de tous les scammers depuis plus
d'un mois...
Bon ok, c'est pas du realisme, c'est du cynisme.
Non, on rigole bien, car t'es vraiment a coté de la plaque et
surtout de l'esprit des BSD...
On Wed, 14 Jan 2004 10:21:26 +0000 (UTC), Michel Talon sieu.fr> wrote:
Je ne veux pas enfoncer le clou, mais pour un utilisateur du libre, tu m'as l'air de faire preuve d'un égoisme assez phénoménal. Dispose r du système BSD qui permet d'obtenir facilement des crash dumps et de les analyser avec gdb (compare à la situation sous Linux) et en faire fi, ça me paraît assez paradoxal.
Je ne suis pas "egoiste". Je suis realiste.
Analysons le cas de l'utilisateur "lambda" (pas les augustes developpeu rs ici presents)
Premier point... Des utilisateurs "lambda", tu crois qu'il y a en des tonnes ici ? Deja que sous Linux faut etre un minimum motivé pour y rester apres un passage souvent "douloureux" pour ce genre d'utilisateur alors bon, soit il s'accroche soit bah, il retourne sous un autre OS. Etant donné que (malheureusement) y'a plus de pingouin que de demons (ca rejoint mon post, personne pour connait un BUG dans le Nord ?), je ne pense pas qu'il y a des millions de "lamdba" user .. On est pas sous Windows.. =)
Admettons que notre utilisateur nouveaubie crashe sa machine et se retrouve avec un zoli dump. Que va t'il en faire ?
Lancer gdb sur le bouzin et tenter de comprendre ce qui a merde ?
Il va essayer, rien comprendre et finalement effacer la chose parce que ca prend de la place dans /var (ne pas oublier /var qui doit etre taill e pour accueuillir le dump) et qu'entre temps, ben la machine fonctionne et le probleme ne s'est pas reproduit.
Ca risque fort, car a moins de recompiler tout son BSD en Debug, direct gdb, ca va etre "dur" pour "lambda".. Au fait, cet utilisateur connait gdb ? Il a l'air moins basique que prevu cet utilisateur..
Admettons que le probleme se reproduise systematiquement. Notre utilisateur est bien emmerde et va donc tenter de contacter les developpeurs, soit par mail, soit sur une ML, ou un NG.
Mail sur une ML ou un NG : son probleme va rencontrer un silence sideral, vu que personne ou presque sur la liste n'est competent sur le sujet et que de toute facon, il n'a pas fourni assez de details (c'est un nouveaubie). S'il fournit tous les details, c'est encore pire. Admettons qu'une personne competente lise son appel au secours et lui demande des precisions, je doute TRES FORT que cette personne lui demande de lui fournir son dump. Pas que ca a fout' non plus.
"Personne n'est competent": tu y tiens a ce toi... Ca me rappelle une histoire de traffic shapping et ipfw.. Je susi desole, les dev que j'ai contacté suite a ce genre de probleme m'ont repondu.. D'un autre coté, je ne vais pas prendre mon cas pour une generalité alors je te conseille de faire de meme!
Mail direct aux developpeurs : ca va venir s'empiler dans la boite que les developpeurs lisent quand ils ont le temps (parce que y a vraiment trop de questions cons posees par mail, ca finit par lasser). Admettons qu'il tombe sur un developpeur motive et competent : ca va commencer par une serie de mail avec des questions basiques, pour bien verifier que le nouveaubie ne s'est pas plante qq part, etc... pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Ca je trouve ca baleze.. En quoi le fait de ne pas garder le dump rendrait sa machine en etat de marche.. Tu melanges tout la... Tu sous entends qu'avec un dump ca va trainer etc etc.. Je vois pas en quoi SANS ca irait plus vite hein ? J'ai peut etre raté un episode, faudrait que tu expliques..
Puis le developpeur, ne comprenant pas ce qui ne marche pas (il n'arrive pas a reproduire le probleme, c'est bete mais il n'a pas la meme conf materielle), va finir par demander le dump afin de l'analyser. Apres plusieurs jours de ping pong de mail pour savoir comment mettre a disposition un fichier de 1Go quelque part, le developpeur va enfin avoir le dump a dispo. Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Donc le dump est dans un coin du disque du Gentil Developpeur Benevole.
Bon ben c'est pas tout ca hein, mais ya le vrai boulot qui est la, l'ecole, les cours, la femme, les gosses, whatever et bon... Pas que ca a fout' non plus. Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Au bout de X temps, le GDB (Gentil Developpeur Benevole, tiens bon acronyme ca), soyons optimiste, va _peut etre_ arriver a trouver ce qui ne va pas. S'il est competent et motive. Et _peut etre_ trouver un workaround ou un correctif. Qui fera son chemin dans le CVS et dans la validation etc pendant... oula... quelques semaines. Pendant ce temps, le nouveaubie n'a pas de machine en etat de marche.
Des semaines ? T'es sur de pas te tromper de systeme la ? Tu nous parles de SunOS la ? Parce que niveau reactivité, j'ai aussi l'impressi on que tu melanges tout..
Etc, etc...
Les chances pour que le probleme d'un utilisateur lambda soit resolu dans des temps raisonnables sont proches de zero. Donc le dump, il aurait pu se le rouler et se le fumer, ca aurait ete pareil.
En effet, avec ou sans, le fait que sa machine refonctionne (et encore je te trouve bien vague dans la definition de cette idée de "fonction- -nement"), c'est un peu pareil.. La difference, c'est que tu t'impliques dans un processus de remonte de probleme, tu restes pas passif.. Tu m'as (et pas qu'a moins a priori) d'etre un sacré consommateur toi, pas acteur
Le seul cas ou je vois que les choses peuvent aller VITE, c'est lorsque des masses d'utilisateurs sont bloques par le meme probleme et que ca finit par faire du bruit. Donc, la, forcement, les developpeurs s'agitent et sortent un patch en urgence. Mais la en general, ils ont leur propre dump et sont capable de reproduire le probleme. Pas la pein e d'avoir 500 dumps differents non plus.
Alors c'est sur que M. Talon, M. Espie, M. Dreyfuss ou M. Valat auront l'utilite d'un dump s'ils rencontrent un probleme sur leurs machines.
Sont pas les seuls hein ;)
Mais du point de vue du nouveaubie, il aura plus vite fait de changer d e machine, voire d'OS avant d'avoir une utilite de son Gigo de dump.
Et si c'est un plantage ponctuel qui arrive tous les 36 du mois pour un e raison inconnue (les taches solaires, l'humidite ambiante, la radioactivite qui est partout (merci Stan Lee)), il aura plus vite fait d'effacer le dump et de ne rien faire plutot que de se plonger dans les affres de gdb ou des GDB. Pas que ca a fout' non plus.
Mon avis final est donc : meme si on peut prevoir l'espace pour le crash dump, AMHA c'est inutile de l'activer parce que les chances que l e dump ait une utilite sont proches de zero _pour un utilisateur ordinaire_.
Et ca n'a rien de specifique aux BSD, rassurez vous.
En effet, depuis Xp on envoie (si on laisse par defaut) les dumps des crashs, mais je te vois venir... Windows je le payes, blah,blah... support blah blah.. (A moins que tu ais une version non OEM, tu n'as pas le support direct de MS, mais plutot Packard Bell etc etc..). Bah, on attends (enfin non, je m'en cogne moi perso) le fix d'url spooffing dans IE qui fait la joie de tous les scammers depuis plus d'un mois...
Bon ok, c'est pas du realisme, c'est du cynisme.
Non, on rigole bien, car t'es vraiment a coté de la plaque et surtout de l'esprit des BSD...
K.
Erwan David
fred écrivait :
Michel Talon wrote:
[snip]
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
mkswap ne fait qu'écrire un ent-ête en début de partition, c'est très rapide.
fred <fredantispam@free.fr> écrivait :
Michel Talon wrote:
[snip]
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas
en faire la première partition de ad0s1 (sinon les mkswap ultérieurs
bouzilleront le label). Cette partition sera vue comme hda5 sous Linux
par exemple (prévoir un noyau avec support des labels BSD). Il suffit de
repérer dans les scripts de démrrage de Linux là où se trouve le swapon
et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans
*aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il
pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot,
j'ai peur que ça soit un peu longuet.
mkswap ne fait qu'écrire un ent-ête en début de partition, c'est très
rapide.
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
mkswap ne fait qu'écrire un ent-ête en début de partition, c'est très rapide.
talon
fred wrote:
Michel Talon wrote:
[snip]
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
Non c'est instantané, ça écrit juste quelques octets au début de la partition.
--
Michel TALON
fred <fredantispam@free.fr> wrote:
Michel Talon wrote:
[snip]
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas
en faire la première partition de ad0s1 (sinon les mkswap ultérieurs
bouzilleront le label). Cette partition sera vue comme hda5 sous Linux
par exemple (prévoir un noyau avec support des labels BSD). Il suffit de
repérer dans les scripts de démrrage de Linux là où se trouve le swapon
et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans
*aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il
pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot,
j'ai peur que ça soit un peu longuet.
Non c'est instantané, ça écrit juste quelques octets au début de la
partition.
Prévoir le swap sur BSD, par exemple ad0s1b pour Free, et ne surtout pas en faire la première partition de ad0s1 (sinon les mkswap ultérieurs bouzilleront le label). Cette partition sera vue comme hda5 sous Linux par exemple (prévoir un noyau avec support des labels BSD). Il suffit de repérer dans les scripts de démrrage de Linux là où se trouve le swapon et de mettre mkswap /dev/hda5 juste au dessus. Problème résolu, et sans *aucun* souci.
Faire un mkswap à chaque boot ne rallentit-il pas un tantinet le boot justement ?
Parce que sinon c'est bien ce que je ferais, mais bon, à chaque boot, j'ai peur que ça soit un peu longuet.
Non c'est instantané, ça écrit juste quelques octets au début de la partition.
--
Michel TALON
talon
Philippe Chevalier wrote:
Mail sur une ML ou un NG : son probleme va rencontrer un silence sideral, vu que personne ou presque sur la liste n'est competent sur le sujet et que de toute facon, il n'a pas fourni assez de details (c'est un nouveaubie). S'il fournit tous les details, c'est encore pire. Admettons qu'une personne competente lise son appel au secours et lui demande des precisions, je doute TRES FORT que cette personne lui demande de lui fournir son dump. Pas que ca a fout' non plus.
Je ne peux que te donner mon exemple personnel sur FreeBSD. Il m'est arrivé 2 ou 3 fois d'avoir un dump en quelques années. Je l'ai posté sur une mailing list (freebsd-stable à l'époque) de façon raisonnablement concise (avec le backtrace mais pas trop en plus) et j'ai toujours eu un contact de développeur le jour même. Un exemple dont je me souviens touche à un sujet récemment évoqué ici. Il s'agissait d'exécuter le staroffice de Linux, placé sur une partition linux, sous freebsd, ce qui crashait la machine. Le point étant que le "backing" de l'exécutable pour la VM était sur une partition ext2 ce qui causait un bug. Le problème a été corrigé le jour même. Une autre fois je me suis amusé à faire la connerie que certains préconisent régulièrement de rebooter avec un nouveau userland et l'ancien noyau. Crash au démarrage de mountd. Là encore ça a été corrigé en peu de temps. A mon avis, quand on a affaire à un système où il y a beaucoup de développeurs, et qu'on prend soin d'écrire là où ils regardent (pas dans les newsgroups), c'est efficace.
--
Michel TALON
Philippe Chevalier <news@kyoko.org> wrote:
Mail sur une ML ou un NG : son probleme va rencontrer un silence
sideral, vu que personne ou presque sur la liste n'est competent sur le
sujet et que de toute facon, il n'a pas fourni assez de details (c'est
un nouveaubie). S'il fournit tous les details, c'est encore pire.
Admettons qu'une personne competente lise son appel au secours et lui
demande des precisions, je doute TRES FORT que cette personne lui
demande de lui fournir son dump. Pas que ca a fout' non plus.
Je ne peux que te donner mon exemple personnel sur FreeBSD. Il m'est
arrivé 2 ou 3 fois d'avoir un dump en quelques années. Je l'ai posté
sur une mailing list (freebsd-stable à l'époque) de façon
raisonnablement concise (avec le backtrace mais pas trop en plus) et
j'ai toujours eu un contact de développeur le jour même. Un exemple dont
je me souviens touche à un sujet récemment évoqué ici. Il s'agissait
d'exécuter le staroffice de Linux, placé sur une partition linux, sous
freebsd, ce qui crashait la machine. Le point étant que le "backing" de
l'exécutable pour la VM était sur une partition ext2 ce qui causait un
bug. Le problème a été corrigé le jour même. Une autre fois je me suis
amusé à faire la connerie que certains préconisent régulièrement de
rebooter avec un nouveau userland et l'ancien noyau. Crash au démarrage
de mountd. Là encore ça a été corrigé en peu de temps. A mon avis, quand
on a affaire à un système où il y a beaucoup de développeurs, et qu'on
prend soin d'écrire là où ils regardent (pas dans les newsgroups), c'est
efficace.
Mail sur une ML ou un NG : son probleme va rencontrer un silence sideral, vu que personne ou presque sur la liste n'est competent sur le sujet et que de toute facon, il n'a pas fourni assez de details (c'est un nouveaubie). S'il fournit tous les details, c'est encore pire. Admettons qu'une personne competente lise son appel au secours et lui demande des precisions, je doute TRES FORT que cette personne lui demande de lui fournir son dump. Pas que ca a fout' non plus.
Je ne peux que te donner mon exemple personnel sur FreeBSD. Il m'est arrivé 2 ou 3 fois d'avoir un dump en quelques années. Je l'ai posté sur une mailing list (freebsd-stable à l'époque) de façon raisonnablement concise (avec le backtrace mais pas trop en plus) et j'ai toujours eu un contact de développeur le jour même. Un exemple dont je me souviens touche à un sujet récemment évoqué ici. Il s'agissait d'exécuter le staroffice de Linux, placé sur une partition linux, sous freebsd, ce qui crashait la machine. Le point étant que le "backing" de l'exécutable pour la VM était sur une partition ext2 ce qui causait un bug. Le problème a été corrigé le jour même. Une autre fois je me suis amusé à faire la connerie que certains préconisent régulièrement de rebooter avec un nouveau userland et l'ancien noyau. Crash au démarrage de mountd. Là encore ça a été corrigé en peu de temps. A mon avis, quand on a affaire à un système où il y a beaucoup de développeurs, et qu'on prend soin d'écrire là où ils regardent (pas dans les newsgroups), c'est efficace.
--
Michel TALON
Stephane Dupille
Ah mais non. J'ai pas dit que Windows pour les utilisateurs lambda etait mieux. Si tu veux un support vaguement potable de la part de microsoft, faut sortir le chequier et la rapidite est nullement garantie. Mais tu es certain d'avoir une reponse au moins.
Voilà. Avec BSD (et linux) c'est pareil, si tu veux avoir la garantie d'une réponse, il faut sortir le chéquier. Sauf qu'en plus, tu as le choix du prestataire qui va te la faire, la réponse.
-- QU'EST CE QU'ILS VIENNENT NOUS FAIRENT CHIER AVEC LEURS CONCURENCE il n'y a pas de concurence pour les communications loal. Pour wandoo quelle concurence peu gene FT. Aucune, ou alors qu'on m'explique. -+-CY in : <http://www.le-gnu.net> - Faut pas me la faire -+-
Ah mais non. J'ai pas dit que Windows pour les utilisateurs lambda etait
mieux. Si tu veux un support vaguement potable de la part de microsoft,
faut sortir le chequier et la rapidite est nullement garantie. Mais tu
es certain d'avoir une reponse au moins.
Voilà. Avec BSD (et linux) c'est pareil, si tu veux avoir la
garantie d'une réponse, il faut sortir le chéquier. Sauf qu'en plus,
tu as le choix du prestataire qui va te la faire, la réponse.
--
QU'EST CE QU'ILS VIENNENT NOUS FAIRENT CHIER AVEC LEURS CONCURENCE
il n'y a pas de concurence pour les communications loal. Pour wandoo
quelle concurence peu gene FT. Aucune, ou alors qu'on m'explique.
-+-CY in : <http://www.le-gnu.net> - Faut pas me la faire -+-
Ah mais non. J'ai pas dit que Windows pour les utilisateurs lambda etait mieux. Si tu veux un support vaguement potable de la part de microsoft, faut sortir le chequier et la rapidite est nullement garantie. Mais tu es certain d'avoir une reponse au moins.
Voilà. Avec BSD (et linux) c'est pareil, si tu veux avoir la garantie d'une réponse, il faut sortir le chéquier. Sauf qu'en plus, tu as le choix du prestataire qui va te la faire, la réponse.
-- QU'EST CE QU'ILS VIENNENT NOUS FAIRENT CHIER AVEC LEURS CONCURENCE il n'y a pas de concurence pour les communications loal. Pour wandoo quelle concurence peu gene FT. Aucune, ou alors qu'on m'explique. -+-CY in : <http://www.le-gnu.net> - Faut pas me la faire -+-
