Date: Thu, 1 Feb 1996 14:52:53 +0200 (EET) From: "Andrew V. Stesin" <stesin@elvisti.kiev.ua> To: davidg@Root.COM Cc: stesin@elvisti.kiev.ua, stable@freebsd.org Subject: Re: What I'd like to see brought to -stable Message-ID: <199602011252.OAA11080@office.elvisti.kiev.ua> In-Reply-To: <199602011050.CAA01444@Root.COM> from "David Greenman" at Feb 1, 96 02:50:52 am
next in thread | previous in thread | raw e-mail | index | archive | help
Hello David, # >1. (kernel) A fix for "system binds" problem (IDE system with X11 # > "goes asleep" periodically for random periods of time). # # I think this is workable. The problem is apparantly in the object clean # code, and I think the changes can be retrofitted. HURRAAAAY!!!! :-) # >2. "phk malloc" by Paul Henning Kampf. It's one of the best performance # > improvements I've seen, why recompile approx. entire world after # > dropping it into an installed system? And, taken from -current, # > it works without a glitch -- only _times_ faster :) # # No, sorry, this won't be in the release. The main problem is that phk's # malloc does a better job recycling memory and this exposes bugs in # applications. Since 2.1-stable is supposed to be "stable", I don't want to # rock the boat - the result would only be the appearance that 2.1-stable was # far less than stable even though the real problem is in the apps. Since "apps" # also includes our *own* /usr/src, this would look very bad. I still think that this approach is questionable, as mentioned in my previous message. Of course, the last decision is yours, noone will ever try to blame you for the fact that you refused to open a tightly packed can of worms :-) But. Another view. The date of next release is upcoming slowly, but there _is_ some time left for testing. FreeBSD has it's user base splitted... not even in two, but in three parts -- stock RELEASE users, -stable users, -current developers. Three grades, with the quantity of potential testers decreasing, and people's readyness to risk increases from left to right. :-) New malloc() is of _much_ less risk to use than, for example, brand new UNIX pipes. The same with userland utils. Why not increase the number of testers for this "easy" stuff? And who forbids you, in case things are going wrong in -stable snapshots (they're experimental, anyway), replace phk malloc back with todays one? (So it will be used for _debugging_ -stable, first of all, and _not_ for -RELEASE, only in case everything is Ok). Some of phk-malloc-inspired changes are already in -current, btw. Just a thought. As for me myself, I'll use libc upgraded with phkmalloc, and probably periodically report bugs to -stable :-)) # There's also a # question as to whether all of the bugs in phkmalloc have been worked out. A # fairly serious bug was found just a few weeks ago. Considering the speed of FreeBSD development, few weeks really means "long ago"... ;-) # >3. "STARTUP_SETLOCALE hack" removal and a couple of localization # > changes done by Andrew Chernov throughout the userland # > utilities. # # I don't have a problem with this as long as Andrey is dedicated to managing # the changes. I'm not going to touch this myself, however. Ok, I'll ask Andrew directly about this. # >5. Recent PPP improvements. # # Yes, definately. BRAVO!!! # ...and lots of other fixes that haven't been mentioned. We'll be going # through all the changes soon to find other candidates. ... that's why I was so brave to ask. Tomorrow might be too late. :-) # -DG # # David Greenman # Core Team/Principal Architect, The FreeBSD Project -- With best regards -- Andrew Stesin. +380 (44) 2760188 +380 (44) 2713457 +380 (44) 2713560 "You may delegate authority, but not responsibility." Frank's Management Rule #1.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602011252.OAA11080>