-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2010/09/23 19:31, M. Warner Losh wrote: > In message: <alpine.lnx.2.00.1009231841500.23...@ury.york.ac.uk> > Gavin Atkinson <ga...@freebsd.org> writes: > : On Thu, 23 Sep 2010, Ken Smith wrote: > : > The issues talked about so far all contribute to the reason for that. > : > But one of the more basic gut reactions to it all is that the users > : > want to be interested in helping with the debugging (even if just > : > providing the requested info) for any sort of crash information > : > to be useful. And at the point we shift something from -current > : > to -stable the percentage of people actively interested in participating > : > in that sort of stuff flip. The bulk of people using -current > : > know it's risky and they do it out of some interest in debugging > : > stuff. The *bulk* of people using -stable are less interested or > : > flat out not interested. And have no clue what crash dumps are, > : > may be challenged to notice partition-getting-full issues, etc. > : > : I'm not sure I buy this argument, I'm afraid. Part of the advantage of > : having all this done automatically on the as-shipped release media is that > : end users don't have to be interested in debugging - crashinfo(8) does > : most of the work for them. There's no easy way to actually determine > : figures, but even if say only 10-15% of crashes can be diagnosed and > : corrected just from the output of crashinfo(8) then that's a huge win for > : the project as a whole. I'm guessing 10-15% is not unrealistic. > : > : I appreciate the issue about filling partitions is a valid one. Would a > : possible compromise be that on release media, crashinfo(8) or similar will > : default to only keeping the most recent coredump or similar? Given /var > : now defaults to 4GB, Defaulting to keeping a single core is probably > : acceptable. > > Furthermore, if we aren't interested in crash dumps by default, why do > we install the huge .symbols files?
+1. Even textdump would be a huge help for the project (except it depends on KDB/DDB which should be considered more thoroughly due to security consequences). Cheers, - -- Xin LI <delp...@delphij.net> http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (FreeBSD) iQEcBAEBCAAGBQJMnQ+cAAoJEATO+BI/yjfBv+gH/27HC9fRFNlYh28YypZFjK/K FWKed15ZK+kR8pAvpONibBY/yWAWzsYyCxADn0q2aGAYItukQkonZnTWAQTbcbaG d4begzGOrr9xWRYbIar8VvLM7mlUu99FNVkscFMsNvkD6mMP7N6MB9SNnqg/yRSo jbSUceIkASnZni0poHoAKCpBJsPu2Yt/XnBXhbtR6tzHiWZKqKMCm5yfDHvH0+Cw kNcR6jInnGJk8f2qk2a6h2Qtu6/R9vwkmidtBCX7CLba07yRHP/cgjiAN79AgnKx 7AHw5ZCItGJMjyGukuc1eSBPJluzmTRXwhzZt+zbTB5He3gWe78jRkylDoj0qMw= =TtpC -----END PGP SIGNATURE----- _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
