Re: 1.1 memory management issue ??
Martin Konold: I read my reply this morning and see harshness in a message. I would like to apologize about that. Please look at the situation like this: I never said that Debian 1.1 was the pits. Rather, I see that the development team did a good job with 1.1; however, when 1.2 came out, it was even better! They out did themselves with 1.2. Memory management is better (not that it was bad to begin with). A few installation problems, but new distributions usually do. -- -= Sent by Debian 1.2 Linux =- Thomas Kocourek KD4CIK [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: 1.1 memory management issue ??
Martin Konold writes: Sorry I still do not get the point. Debian 1.1 never seemed to be slow to me compared to any other distribution. Of course any broken setup you might get by unstable/partial updates might slow down your machine to any degree. But this still means that contradictionary to the above statement 1.1 was not slow. I was pointing out that someone had problems because it was a partial update. I saw another gentleman who had kernel compilation problems. When he found the source of his predicament (and posted a message), I checked the very same source file and mine was fixed already. Difference being, I installed from a stable distribution and he didn't. And yes, if you don't do an entire upgrade, you stand a chance of having problems, kernel or otherwise. Based on what you have posted so far, I take it that you are a thorough individual who insures that he has an entire distribution and can't take a step backwards to see the big picture. My favorite phrase: one can't see the forest for the trees being in your way. -- -= Sent by Debian 1.2 Linux =- Thomas Kocourek KD4CIK [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: 1.1 memory management issue ??
Martin Konold writes: [snip] Thank heavens! 1.1 had terrible memory management. 1.2 (REX) is _much_ better. The memory management issue mentioned here with 1.1 may explain some slowness with my (1.1) machines. I do not get the point! Memory management is the job of the kernel. How does it depend on the distribution? Well, if you upgrade your system as a distribution, rather than piece-meal, on-the-fly, method (via dftp), it sure does make sense that a distribution influences memory management issues. I choose to wait until a stable distribution has been declared and upgrade my entire system in one sitting. That way, I _know_ that all the necessary packages have been upgraded. Unlike another gentleman on this list who upgraded the kernel, but did not upgrade the libc5 module and could not understand why his machine was slow. 8-) -- -= Sent by Debian 1.2 Linux =- Thomas Kocourek KD4CIK [EMAIL PROTECTED] -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: 1.1 memory management issue ??
On Tue, 31 Dec 1996 [EMAIL PROTECTED] wrote: Thank heavens! 1.1 had terrible memory management. 1.2 (REX) is _much_ better. The memory management issue mentioned here with 1.1 may explain some slowness with my (1.1) machines. I do not get the point! Memory management is the job of the kernel. How does it depend on the distribution? Well, if you upgrade your system as a distribution, rather than piece-meal, on-the-fly, method (via dftp), it sure does make sense that a distribution influences memory management issues. I choose to wait until a stable distribution has been declared and upgrade my entire system in one sitting. That way, I _know_ that all the necessary packages have been upgraded. Unlike another gentleman on this list who upgraded the kernel, but did not upgrade the libc5 module and could not understand why his machine was slow. 8-) Sorry I still do not get the point. Debian 1.1 never seemed to be slow to me compared to any other distribution. Of course any broken setup you might get by unstable/partial updates might slow down your machine to any degree. But this still means that contradictionary to the above statement 1.1 was not slow. Yours -- martin // Martin Konold, Muenzgasse 7, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Linux - because reboots are for hardware upgrades -- Edwin Huffstutler [EMAIL PROTECTED] -- Just go ahead and write your own multitasking multiuser os ! Worked for me all the times. -- Linus Torvalds -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: 1.1 memory management issue ??
On Sun, 29 Dec 1996, David B. Teague wrote: Hi there, Thank heavens! 1.1 had terrible memory management. 1.2 (REX) is _much_ better. The memory management issue mentioned here with 1.1 may explain some slowness with my (1.1) machines. I do not get the point! Memory management is the job of the kernel. How does it depend on the distribution? Yours, -- martin // Martin Konold, Muenzgasse 7, 72070 Tuebingen, Germany // // Email: [EMAIL PROTECTED] // Linux - because reboots are for hardware upgrades -- Edwin Huffstutler [EMAIL PROTECTED] -- Just go ahead and write your own multitasking multiuser os ! Worked for me all the times. -- Linus Torvalds -- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: 1.1 memory management issue ??
Martin Konold [EMAIL PROTECTED] writes: I do not get the point! Memory management is the job of the kernel. How does it depend on the distribution? Actually, it's more complicated than that unless you use sbrk etc. directly. If you use malloc (in C) or new (in C++) then libc plays a role in memory management. I think what's being referred to here is that in earlier versions of libc (i.e. the one in debian 1.1), free, or delete, didn't actually return the memory to the kernel. It just kept it around so that it could use it later. There are some reasonable arguments for doing this (at least for a little while), but it meant that programs that ran a long time and had fragmented memory usage could have a vm footprint that grew without bound. That's even though there were pages that could be returned to the kernel. At least that's my understanding. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
Re: 1.1 memory management issue ??
David B. Teague [EMAIL PROTECTED] writes: What package(s) do I upgrade to fix it? We are running the 2.0.27 kernel. Upgrade libc5. Version 5.4 of libc5 uses dl-malloc, while 5.2 used gnu-malloc. You'll also need to upgrade ldso. Long-running, memory-intensive apps, like X servers, will benefit greatly. You'll also get a plethora of security fixes as a bonus. Are there caveats? Please suggest Manuals/documents/books... Yes, the new malloc is much more brittle to memory overruns. Luckily dl-malloc has been in use for long enough so that very few programs are still known to be buggy. Netscape is the most notable. You can preload the old malloc for those programs which still crash. /usr/doc/libc5/FAQ.gz (on 5.4.x-x) contains details. Guy -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
